Hello, and welcome to Android bys powered by Esper, the podcast that

dives deep into the world of Android.

I'm Michelle Ramon.

And while I'd normally be joined by my co-host David Ruddock, he unfortunately

couldn't make it to this one.

Still.

We've got a great topic and guest lined up on the show this week,

we'll be talking about security, specifically mobile app security.

So if you listen to our podcast before, you know, we've talked about Android

security model, at least when it comes to applications, as well as our

permissions work in the previous episode.

But this time, we want to focus more specifically on how Google app

developers and outside firms team up to protect you and your Android device.

So today we've invited Brian Reed, chief mobility officer at now secure

to talk about mobile app security.

Welcome to the show,

Brian.

Thanks, Michelle.

It's great to be here and part of your community.

Thanks for having me.

Thanks for joining us.

So

this is the topic that in my now seven years of covering Android, you know,

I've kind of delved into the security side a bit here and there, even though, while

it's been up in my primary focus, just covering the Android platform ecosystem,

these security issues come up and tend to cover them pretty much every week.

You'll hear from some mobile security threat firm that there's

some new malware strain out in the wild, and that is wing havoc.

And then when you dive into the details you discover, oh, they're mostly misusing

some Android API or application some permission or they're tricking users

into enabling some sensitive permiss.

And so like, this is a topic that is ever pervasive in our lives, because

you probably know people in your lives who could be tricked into enabling

something they shouldn't have when songs something they shouldn't have.

And even if you think that you wouldn't do that, there's a very high

chance that you could be tricked to.

No one is ever completely foolproof from fishing or any other malware attacks.

There are many things you can do to prevent yourself from

being taken advantage of.

But on the ecosystem side, there are also many things that Android

does and that Google does and that outside firms can do to proactively

protect you from harming yourself.

So just so we're all on the same page, I kind of wanna just touch upon

the background of Android security model and how Android actually

protects you at a platform level.

So we talked about this before, but every time you install

an app, it comes an APK file.

And within that APK file.

There's all the assets, the code, the resources, et cetera, but there's also

a digital signature that is generated whenever the developer signs a package.

And whenever that app installs on your device, it's given a unique package name.

And whenever you try to install an app that has a package name matching an

existing app, it installed on the device.

If that signature doesn't match the signature, that was with the previous.

Then Android will object the installation.

And because it's assumed that the signing key, the developer used to sign that

app is generally kept somewhere safe and secure within their own repository on

their computer, or upload it to Google.

Then you can assume that some third party didn't just modify

the app and then upload it.

And then you installed it onto your device.

So that's how Android generally secures updating applications.

The one challenge with that is while it ensures that some outside developer

didn't modify and push an app onto your device, it doesn't guarantee that the

update hasn't been tampered with hasn't had in any malicious or potentially

harmful code within the update.

Like it could still be signed by the original developer, but how do you.

If that update is still safe to use.

And that's generally where firms like now secure come in.

So I wanted to ask you, Brian, can you tell us a bit about the company?

Sure.

So now secure actually got started as a forensics company in 2008 and 2009.

So the birth of Android that was around the same time as iOS.

Our founder got interested in these cool little devices that seemed to

have a whole lot of computing power and a lot of forensic data on him.

And while he wasn't a forensic specialist, he actually became the world's expert

in mobile forensics and ultimately build a business that is now secure today.

We're kind of an all in one solution provider we have for

mobile application securities.

So we have testing tools, developing tools, pen testing

services, open source tools.

Training all of those kinds of things and partner with lots of organizations

to make sure they're able to deliver those secure applications on whatever

mobile operating system they want.

So our roots are in Android, cuz that's really where he started and we

continue to do a lot with Google and the entire ecosystem community today.

Thanks Brian.

And just to follow up on the Android aspect, one other thing that Android

does at the platform level to protect you is that it has a very secure

model of protecting applications from interacting with other applications.

So you may have heard the term sandbox before.

So whenever you install an app on Android, every app that has a unique

package name, you know, every app has to have a unique package name.

You can't have two apps with the same package name solved on a.

So what happens is that that package is assigned a, a unique identifier.

And when you run that app, Android runs it in a container

and it's called the process.

And then that identifier is called the P I D for that process.

So by putting processes in containers, Android ensures

that apps can only interact with other apps through a well-defined

process called the binder IPC.

So this way apps can only interact and only execute only like send a

request to get data from another app.

Through well defined permissions through well defined, intense and whatnot.

So like you can't just have one app poking around the data of another app

without break the sandbox, which is just not something that is very easily

achievable without some very serious exploit in the Android platform.

I wanted to ask you, Brian, how does this in your experience,

how does Android security model compare to other operating systems?

Would you say it's more or less secure?

Yeah, that's always a loaded question.

What I would say is that the Linux kernel underneath the Android in and

of itself with its advanced security capabilities, gives it a strength.

Apple has a more closed system on iOS, just in terms of how they operate.

Uh, the sandboxing model is very strong.

You know, the containerization of applications, the

control of the IPC channel.

All of those things are good strengths for Android.

What's been really interesting to watch is that Android kind of was very heavy.

I've been around this since Blackberry, just to be my background.

I was with the original mobile security company called Blackberry.

So I've seen a lot over the years and Blackberry was completely locked down

and completely impossible to innovate.

Just about it all, but it was really secure, right?

And that's an example of a niche user experience with high security,

but it was really inflexible when you wanted to write applications.

The Android world kind of has two communities.

You have the, I just wanna get stuff done.

And then you have kind of the fanboy world I wanna customize

and do really interesting things and, you know, so on and so forth,

which leads to rooting and more customizations in the operating system.

What has been really interesting to watch is that Android has become incredibly.

If you look at the number of CVEs and cess listed for Android operating system

or for device hardware for at least the tier one manufacturers, they have gone

down as a rate over time, apple hasn't.

Now apple may have been a little bit ahead.

So there sort of is this, it depends.

On who your hardware manufacturer is, how they are properly or improperly

using the operating system and the licensing that they're doing around the

play store and the tooling around that.

But Android today is a very safe environment.

And so I live in a blended world.

So I have yes, one of everything because I'm in a mobile business.

I have no qualms about saying which device or which operating system is better.

Android and iOS are both better than windows, frankly.

And so from that perspective, there's lots of different places we can go

in terms of talking about, well, how do I make sure I'm safe and secure?

And how do I make sure I do the right things?

You mentioned

something that I wanna kind of wanted to follow up on power users.

You know, there are people who like the brute and tinker their devices.

That's something that wasn't really possible with the older,

more lockdown operating systems and current ones like iOS.

So on Android, you are allowed.

Side load applications.

This term side loading.

Isn't really much of a thing in the windows world, but it is

something that exists in Android.

And in order to side load, an application from outside of the official

Google play store, you have to opt in, you have to enable permission.

You have to do it on a per application basis.

And there are also other security features that kind of irk power users.

And I wanted to ask you your thoughts first on side loading.

Like how does Google balance.

Ability to allow users to side load applications with actually protecting

them from installing something that's potentially untrusted.

Yeah.

I think there's kind of two ways to look at it.

So I'm gonna take a macro view and then kind of a micro view.

So the macro view is there are three or 4 billion users of Android, and

that means everybody of every kind everywhere in the world, trying

to do everything you can imagine.

Right.

And so there's lots of different segments of people that wanna

use it in certain behavior.

I do a lot of work with companies that use lockdown, Android tablets that are

purpose designed for a specific use.

They may have one application on them.

I do work in automotives.

I do work in healthcare, right?

And so there's that class financial services where regulatory matters control

matters, sensitive data matters you as a patient, don't want that data lost.

If it's your car, you don't want that car broken into.

Right.

So there's that category.

And then you kind of move into the more general maybe business user.

Then you move into the more generalized consumer and then you move into the

tinkerer category, like the fanboy and you know, and what I think

Google's done a pretty good job of is trying to balance all of them, right.

From that perspective.

And so they've set up the guardrails.

They've continued to improve the guardrails and gates to

make it hard to be malicious.

So you've got the containerized model.

We just talked about side loading to me is an enabler for the category

of people who want it, but most people should stay away from it.

If you were to ask me how do regular people, consumers, not more technical,

advanced customizer, stay safe.

Don't side.

Because Google play with play protect data, safety labels, and all of the system

services that are built into the premium level are designed to keep you safe.

And it's really easy to stay safe when you're leveraging those things.

Side loading is one of the top malware paths.

The other biggest breach vector actually is SMS fishing, and that's not Google

or apple or anybody else's fault.

That's the nature of the way SMS behaves.

And that's a whole different security conversation.

And the fact that people click on that stuff just in the same way,

they sometimes click on spam email.

Right.

So side loading, isn't a bad thing, but side loading can get you in trouble.

So you really should focus on brand name apps from brand name companies,

you know, that have attestation in them with data safety program.

That have four or more stars have millions of downloads, right?

That's just the collective being safe, doing the smart thing, which

is probably 80% of the world really.

Right.

I kind of like in side loading to deciding where to purchase something online.

So if you're a side loader, you're kind of bypassing all the.

Extra scrutiny that is placed on those applications by Google play and by

play protect and all the stuff that's that developers have to go through

to even get their apps on there.

So like if you were to shop online, sure.

You could go to all express.

You could find literally anything you want at any time, but you're

kind of putting yourself at risk by, you know, are you actually gonna

get what you're trying to order?

Is the seller actually legitimate is the product actually as described.

Or could you just do the easy thing and go to like Amazon, you know?

Sure.

There are going to be some fakes.

There are going to pieces of product issues, but generally those are

more vetted because there's more barriers to entry to get on there.

Right.

You know, a lot of this is risk and reward for the bad guys.

Right?

So those barriers of entry, the friction that's put in the system make it harder

for the people who wanna be malicious to behave malicious and the cost of being M.

Becomes so high, it's not worth it.

So from that perspective, take advantage of everything.

You can buy a first class device from a first class vendor, make sure they're

using they're licensing, Google correctly, and leveraging that technology and so

on and so forth and you can be safe.

And when we look at what Google has done for the two primary safety systems, we

have the play protect side of the house.

We have the data safety label side of the house and data safety labels just

became mandatory in the last week.

And so between those two things, if I can play protect is basically

Google's giant malware engine.

Google is continuously scanning for malware.

Google has a lot of partners that are in security and endpoint management that are

contributing to the malware signature.

While you sometimes see it.

And I'm not saying they're in any it's way better now than it used to be.

And that database allow our signatures and the sophistication of the testing

between Google and Google's partners continues to get better and better and

better take advantage of play protect.

You can run it on your own device.

It's being scanned when it's going into the app store.

If you find something reported and kind of help the community, the data

safety label is really interesting.

So I'll show my age.

I remember when my parents would only buy electronics if they had the

underwriter's laboratory safety label on it, which meant some third party

company tested that piece of electronics.

So it wouldn't like burn you or blow up your house or, you

know, something else like that.

And for the first time, anywhere in software that I have ever seen, Google's

actually added labeling that this thing's.

It's called a data safety label.

And so one half of a label is the software developer is going to attest and say,

here is what my app does with your data.

I transmit it.

I collect it.

I send it.

What have you, the other half is you can get an independent security verification

done by an accredited third party.

And that accredited third party now secures one of them will actually

test it sufficiently to say, yeah, this app is safe based on

this industry standard benchmark.

That's like a good housekeeping seal of approval or underwriter's

lab label on it now.

So now with play protect, I'm protecting myself from malware

with data safety labels.

I'm also ensuring that the app manufacturer is doing the right thing.

And that's really great for users.

So

just to take a step back, because on this show, we love to

talk about a O S P and GMs, and try to differentiate between them.

Google play protect, as Brian had mentioned is part

of Google mobile services.

So it's something that is available on devices with GMs, Android.

So, if you were to compile a S P from Google ski repositories, you would

not have play protect available to you because it is part of, I believe Google

play store app itself, or Google play services, either one of those two.

And as Brian mentioned, it is a massive database of malware signatures.

And I kind of wanted to talk about now, like I wanted to ask you how exactly.

Is that malware signature database actually built.

How does Google go out and decide to add something to its database?

So for the two who looked up anything related to this before you might have

heard terms like static and dynamic analysis, can you walk us through what

those mean?

Sure.

So there is something called the app defense Alliance.

So I'm just gonna introduce the, how does the data get collected?

So the app defense Alliance was created.

Five six years ago.

And it's a group of folks who do malware.

They do endpoint management, they do antivirus a lot of the subjects

you might expect in this world.

And so Google said, Hey, we wanna crowdsource this stuff.

We've got a whole bunch.

We know you have more.

So let's start collecting them.

So through all of the different vendors who participate in that, when

they find something, they submit it through a special channel to Google.

Google adds it to their database, verifies that the giant database gets bigger.

And it's because there's multiple vendors scanning billions of device.

You get a pretty good signature database as a result of that.

Now, what we're all doing under the hood is we're basically doing

some combination of static and dynamic analysis or SAST and DAS.

And so SAST is basically scanning code either the source code or binary image

of the app to statically identify coding failures in the application.

So with SAST, you might find things like say hard coded secrets embedded

in the application or debugging code that made it into production

in the app store submission or hard coded URLs or stuff like that.

Those are vulnerabilities.

You could.

You can also find malicious behavior, like, Hey, it's scooping up this data

and transmitting it to this IP address.

And then dat, which is dynamic analysis is actually running the app.

Most of us who participate in the program have some sort of dynamic

analysis, which we observe the app running on a real device, whether it's

in a lab or it's on some customer's device that has an agent running on it.

And we see the malicious behavior, we capture it.

So dynamic finds things like permissions, escalation,

because something changes over.

It finds transmission of sensitive data that maybe shouldn't be there.

Is that data properly encrypted?

Does it go to a bad end point?

That's a known malware harvester endpoint from the endpoint databases on the.

Things like that.

So what's interesting about it is the collective is kinda looking for

malware through bad behaviors, but also looking for vulnerabilities.

Some of the more recent issues we found in the market weren't actually malware.

They were vulnerable commercial applications used by millions of

people where the bad guys figured out how to exploit weakness in them.

There was a security weakness that their developers had introduced to.

So that's a little bit about how that works.

Now, the app defense Alliance recently added the MAs specification,

which is that independent security verification strategy.

So this is how to use SAS and dat to analyze the app for vulnerabilities that

could be exploited work with the vendor to fix them, and then give them that good

housekeeping label of approval, which is the independent security review stamp.

So that when you go their data safety label, In the Google play store.

You see, it says independent security review has been completed

by an attested third party.

This is deep save for use in these categories.

And now you have that attestation, which is great from the third party.

So you mentioned

before that, you know, you typically look at either the source

code or the compiled code of an application, and I'm guessing like 99%

of the time you don't have access to the source code of the application.

You're looking for most of the time, you're looking at the binary, the

compiled binary, and you'd have to use some kind of de compilation.

Or some kind of analyzer to analyze behavior while it's on device.

Can you tell us about like some of the tools that you might use?

Are they like all inhouse?

We use any

commercial for those who are into reversing, you may have heard of Frida

and rod Aari are the top two reversing disassembly tools in the market.

Frida and red were created by researchers on our now secure.

And pancake are their handles.

And so those are used by a lot of security researchers.

They're also used in some other tooling by other folks, and

those are embedded in our tools.

So we can reverse and disassemble an iOS or an Android app, whether it's DRM

or not with it, you can break most of the obfuscation tools and hook the app.

Even the ones that have anti Frita capabilities in it, it's

like a cat and mouse game.

They try to block and then you find new ways around it.

But in reversing it, you can get down to bite code or Java code or some

intermediate language that you can then scan to get a sense from a static

perspective about what's going on.

What I will say is that freedom and Dari are great tools.

Have a look at them.

If you really wanna kinda learn your way through what this world looks.

There's some free training on how to use freedom, Ary and participate in the

community on our academy.now secure.com or you can just find them on the internet.

They're great tools.

There's some other tools out there.

There are various other tools that might go into kit.

You might use perp suite to do network sniffing and some things like that

when you kind of build out a tool kit.

So we leverage those and other advance.

IP that we built.

So do the other vendors have all built something that involves some combination

of static and dynamic analysis?

Speaking of static and dynamic analysis, there is one thing

I wanted to follow up with you on.

And it's something that I think requires some clarification for

listeners who may not be familiar.

And it's that why is dynamic analysis actually important to do?

Why do you have to test on a real device versus why can't you just statically

analyze the code and look for some, say potentially malicious thing happening.

We talked earlier about containers in IPC and data transmission between

say two containers or two processes.

Right?

Well, that's why you need dynamic analysis, static analysis.

We'll never see if data was improperly transmitted to the IPC

found from one process to another.

You need dynamic analysis to understand what's being written to the device in

log files, or being stored on the device.

We find key material, forensic data.

IP.

We actually found a, uh, coupon code generator.

The actual IP generation of that was spewed out and log

files under error conditions.

Now static source code scanning.

Won't find that you only find that when you run it dynamically.

So it's a general rule.

Dynamic is about testing the crypto.

Is the crypto working correctly.

And then it's testing storage, which is what is being written

and what can I forensically find?

And what's being written into my own address, space, my own storage,

other storage file system log files, and then network transmission.

So what is getting transmitted over the air?

Is it intercept?

Am I doing proper certificate pinning?

Am I using the TLS channel?

Correct.

What endpoints am I talking to?

Are those endpoints safe?

There's a whole bunch of things you can test around authentication

and authorization that you'll pick out through testing dynamically.

So I'll give you wild data.

We scan all the apps in the app store.

So there are 6 million app and Google play store apps.

Approximately we scan almost all of them on a regular basis.

And what I can tell you is that 80% of them have security vulnerability.

The good news is 20%.

Don't have really bad security vulnerabilities in 'em, but 80% do.

And that number's been the same for five or six years since

we've been benchmarking them.

What's also interesting is that when you carve into that static

versus dynamic, almost everything we're finding is dynamically found.

It's really hard to do dynamic analysis and dynamic testing

at scale in a development.

So a lot of 'em just don't do it.

So they run a static analyzer until we find a very low proportion

of static vulnerabilities in production apps, because most

people are using static tools.

Dynamic is really hard to do.

It's expensive if you pay somebody to do it, not a lot of people do it.

And that's why we find that's where most of the vulnerabilities

are in storage in crypto, in network and backend APIs by far.

Yeah, I'm not surprised because you know, they want to avoid detection.

So if you just have all your malicious code statically, it's in the application

itself and it's easy to find, then there's nothing in it for them.

It's, it's gonna be detected and, you know, added to the database

and then detected in the future again and over and over again.

And I've heard stories of like these malicious applications

that behave differently or.

Different parts of code differently, depending on your location or

what device you're running or a combination of those factors.

So like you need to be able to test, and that

can be hard to find exactly.

It can be hard to find two dynamics.

So, uh, screw an ator.

You're not necessarily gonna see all the IC conversation to the ator.

You're not necessarily gonna see the interaction with the OS layer all the

way down through the hardware or the wifi chip before the carrier chip.

Right.

So what we have found.

For a number of clients who have done emulator based

testing, they bring it to us.

We find stuff.

I mean, you can't truly emulate the environment to get full coverage.

And again, sometimes it's malware.

A lot of it's just vulnerabilities.

I mean, last year, Walgreens slack, they had vulnerabilities that were exploited.

People stole prescription data to the Walgreens mobile app

because of a vulnerability in it.

Slack had a zero day.

So even what you would think would be really great companies.

They can make mistakes, their developers can make mistakes, it might be code.

They write party libraries that put in it.

But what we're actually seeing is the nation state actors and

the criminals are finding these zero days in these applications.

And they're exploiting them as bad or worse as they are the malware,

the price of building malware and getting it into the app store

is getting higher and higher.

Cuz it's harder and harder cuz of everything we just talked about today.

But you know what, if I can find a zero.

In slack and go steal a bunch of corporate data or, you know, shopping cart X and

there's numerous applications like that.

Well, then I can harvest information off of that and use that, you know, there, uh,

if I can diverge for a second, a couple years ago, British airway was preached.

They found a weakness in the way British airways mobile app

was talking to its back backend.

So they learned how to attack the backend by the mobile app.

Then they attacked the backend 380,000 records were stolen, including passport

information, travel history, credit cards.

They were fine.

Bridge share was fined 158 million pounds by the EU as the first GDPR.

Fine.

Now all of that had to do with the fact of a poorly written mobile application.

That was exploitable.

There was no malware involved.

It was just straight up good scientific research that discovered it.

And then they used it to go after the back end.

And that's what we need to think about is mobile's just part of the overall chain of

all the it systems that some company has.

Then you make sure the mobile app and what it talks to is secure, whether it's

malware or whether it's a commercial app.

So this

whole time we've been talking mostly about malware

and like malicious applications.

But if you read online about like what Google pay, protect actually

identifies it, doesn't usually.

Positively identify actual malicious behavior.

It identifies potentially harmful applications.

Can you describe what exactly qualifies to potentially harmful application?

Yeah, so potentially harmful application is the app is collecting and

maybe transmitting over the error data.

It shouldn't be the app is trying to execute system level commands.

It shouldn't have rights to execute.

It could be spyware.

It could be fishing.

You know, more common things.

We know it could be ransomware in terms of its behavior.

I haven't heard a lot of production ransomware on mobile, but we've seen some

academic experiments along those lines.

Uh, there's a lot of system logging going on, data harvesting going on.

And so what kind of comes back is, Hey, this has some unusual beha,

it's a camera app and it's great.

The entire contact database and shipped it to the cloud.

Right.

And that's gonna get a flag.

If it's picked up, right?

Cause it doesn't make sense that someone who's taking photos is scraping the

entire address book off the device or the history of all the wifi nodes that this

device ever connected to with the S S I D and whatever passwords hashed or not.

Right.

So that's part of what it's looking for is it doesn't make sense that this app

would be doing that thing, whether it's obviously malicious or possibly malicious.

Right.

And another thing is that potentially dodgy and sketchy or malicious behavior,

isn't only limited to apps that you can install from the Google play store

or outside of the Google play store.

It can also be happening within pre-installed applications, which Google

refers to as mobile bundle applications.

This isn't really talked about much from what I can see, mostly because it's

like a conversation Google has with O.

They have like strict requirements about what these mobile bundle applications can.

And can't do.

I wanted to ask you, what do you know about the security risks

with mobile bundle applications?

I

can't speak for all the carriers.

I can't speak for all Google.

I can't speak for all the device manufacturers.

You need to talk to each of them.

What I would say is that most manufacturers and carriers are

working hard to do it the right way.

So for example, we work with at and T and Google.

And so the things that at and T sells are tested and certified by us.

And we work with a lot of the other carriers.

There are other vendors like us that work with the carriers

to try to do the right thing.

Google has some attestation and testing requirements that the device manufacturers

and carriers must submit, especially if they're part of the Google play ecosystem.

And if they're, you know, full GMs licensees.

And so what they're trying to do is enable lots of people to grow

vibrant businesses and enable.

This very broad ecosystem that we have today that has so many users and

so many kinds of applications on it.

The trick is saying, Hey, here's a set of standards.

We want you to align with.

And we are either gonna test you or have used an independent third

party or self attest that you are doing the right things here and here.

And by and large, everybody's got the right idea and

trying to do the right thing.

You don't hear so much about really bad stuff happening.

I will say that supply chain attacks like we've been hearing in the market

overall on lots of different things, whether you're the colonial pipeline

or what have you, those are out there, and those are hitting mobile, just like

they're hitting other corporate systems.

And so to no fault of their own developers may wind up with an

exploitable or malicious app because of some third party library they're

using or system service they're using that suddenly changed because

a bad actor got in there and made a.

So that will be something I think we're gonna live on in the mobile world,

the web world, the network world, and every other world, until we really get

supply chain management under control and, and more safe use of components.

All right.

So on that front, what can app developers do to protect their

applications from any malicious exploits?

You know, I think there's a handful of things.

So when we work with organizations who are application developers,

whether they're large or small, we give them a set of recommendations.

First one is make sure you've got some basic security

training for your developers.

Make sure they understand the fundamentals.

Make sure we've got like a guide.

That's like here's 10 APIs.

You should make sure you use and how to configure them properly.

And then a guide on permissioning.

A lot of it has to do with just don't collect and store it.

If you don't need it, then there are things about how to handle storage,

how to handle crypto, how to handle network, how to handle backend API.

They're not very difficult.

In many instances, it's they didn't know there was a flag they should set.

They didn't know there was a configuration option they should be using.

They didn't know there was an ordering of operations.

They should be using, make sure devs doing the right thing.

The second thing is, make sure that there are product requirements that.

What kind of security, this thing should have, right?

If I'm building a banking app, there should be fundamental requirements

that say I'm regulated by the industry.

Here's a set of requirements.

Well, if I'm not building a banking app, we've been building something else.

This requirements may not clear, but just like you're saying, you want a

really cool augmented reality experience, make sure that you're protecting

using multifactor authentication and protecting my Phi while you do it.

Right test it.

Whether you using SAS in the pipeline or SA and da in the pipeline, there

are open source and paid commercial tools that are cheap and easy to use.

They can run autonomously, they catch all the low hanging through.

They make your life easier.

What's really cool about a lot of the DAS tools including now secure.

Now, is it also identifies app store blockers?

So you may have a build version issue.

You may have a third party SDK issue.

You may have some other reason.

Google may say, Nope, I'm not gonna accept this binary because you're

not following one of my rules.

You can catch that too.

So that's not just security and privacy.

That's finding those rules.

And if you're super high end app, you're that embedded health app, that's

maintaining my heartbeat to a cardiac monitor or you're my banking app or

my financial account management app.

You should be doing pen testing once in a while and have really smart

experts, tear it down just to make sure there isn't something exploitable.

So teach requirements, automate your testing everywhere you.

Pen test the high risk stuff.

Be serious enough that say, Hey, we wanna have a great user experience

and millions or billions of downloads.

And we just wanna make sure that people's data does what it's supposed to do.

Security is essential, of course, for every application and developer

should be top of mind, but it should be even more top of mind, especially

if you're dealing with sensitive data.

And as Brian mentioned, medical financial, you don't want to be slapped with, uh,

billions of dollars in a lawsuit for mishandling or having some data breach.

That you could have solved by protecting your application better.

And if you are dealing with any mission critical application or you need to

deploy mission critical applications onto fleets of dedicated devices, and

you wanna make sure that the firmware it's running on and the data you

depend on secured, come talk to us.

That SPER we specialize in helping companies manage fleets of dedicated

devices, including deploying and keeping your apps updated on them.

If you're trying to deploy a kiosk or point of sale terminal,

you need to lock it down.

So potentially malicious applications, can't be side loaded onto.

That's especially important because most of the time, these dedicated

devices won't have GMs on them.

So you can't count on Google, play, protect for protection.

And if you're worried about any mobile bundle applications that are pre-installed

on the off the shelf hardware that you've picked up for your dedicated device

fleet, you'll need to look at deploying your own firmware based on AOS P.

We can also help with that.

Check us out@esper.io and Brian, thanks for joining us on

this episode of Android bites.

Is there anything you'd like to close us off with?

Can you like work?

Can people find you online and work?

Can people work with now secure on securing their application?

Yeah, so you, you can find us online.

There's a bunch of great resources.

I'm gonna talk out real quick.

So now secure.com/nasa, M a S a that will help you understand the app defense

Alliance and the independent security.

If you're a user look to see that the apps you're choosing have

an independent security review.

If you're a developer, get your independent security review, we

can help you expedite that process.

That's cheap and easy to go do.

If you want some training@cat.now secure.com is a free training environment.

It's for development, QA, DevOps, and security teams to learn everything they

needed to know about building testing and running secure apps in production.

Again, that's a free resource.

You can find me all over the place.

I'm actually known as read on the run is my handle.

So you can find me on, you know, LinkedIn, Twitter, and other kinds of fun places.

Speaking to events of all kinds.

The last thing I'll give you is O O is growing dramatically.

The O OS mobile project is advancing.

There's some really great things coming from O O this fall.

And until later this year with the evolution of the

mobile app security project.

So if you're into the community activities, come join us at OAS, spend the

mobile project and get involved because there's some really great stuff going on.

It's a place you can learn a place you can contribute.

And really be part of a community.

Who's trying to do the right thing for mobile application

security.

And just to clarify, what is O OSP?

Exactly?

What does it stand for?

Oh,

O OSP is the open web application security project or program.

It's an independent vendor, agnostic community of, uh, security professionals.

Who've been building standards and specifications for how to build secure web

apps, mobile apps, how to secure your APIs on the back end and things of that nature.

So O O for those who are in the security.

Are generally familiar with it as a non-for-profit that drives that

O OSP has a number of initiatives going on in the development world.

And what's really great about it is that Google has fully embraced O O

so the app defense Alliance master certification program, which gets you

that independent security verification actually is using the O OSP standard.

And you're gonna see the O OSP standard in many other places.

As a mechanism for a common industry standard for what security means, whether

it's web mobile network, device or API.

So there's some really great things going on at that

standards body.

All right.

Thank you, Brian.

And thank you everyone again for listening to another episode of Android bites.