Building Baselines Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

1 hour 12 minutes
Video Transcription
what we're ultimately getting at is policy. We want to create policy that's effective. And it makes sense for that app. Because if we're creating policy and controls
that don't make any sense to the people who are creating zaps and implementing these controls, they're gonna ask us, Hey, why is this control in place? It doesn't seem like it matters. It doesn't seem like it actually causes on the effect. And we want to be able to have guidelines that show people Hey,
other people in our industry are doing these things, and we should be doing it, too, because it is a security best practice. But not only that. It effects our app in this way and this way if we don't implement those controls, and those controls are crucial to making our APS more secure.
So let's actually talk a little bit about how we can implement this out, one out to and are. And the way you implement it is this thing called the mobile app SEC model. And here's what I'll tell you. It's kind of like threat novel ing,
but we're actually considering how that app runs and how that apus start model itself its application threat modelling. And let's start off with l one. L one is basically going to be the standard security option, and it's gonna be examples off
like APS that really don't do much. APS that really don't have any complex
compliance requirements don't really do anything too complex. In general, an example might be an act. That's a news feed app Barnett that doesn't have any authentication that maybe shows you the weather. Or maybe it's an application that you know really just doesn't do much. The conference APS would be another example,
but those app still have security requirements. Each of those APs could leak information about you if they're used insecure communications. They could do things incorrectly and leak to fishing issues or other issues because you know,
insecurities and the simple APS really do cause problems down the line.
If we get into l two, we're talking about the fence in depth maps. So now we're talking about APS that maybe deal with financial information or health care information, and these EPS actually have ah complex compliance requirements, and we want to make sure that you know we're doing our best to protect that data the interactions in the app itself are pretty simple.
So these APS maybe like a banking app
but itself doesn't really do anything too complex, like some other APS that maybe
you peer to peer interactions. Or maybe they do something else that's a little more interesting,
but they still have a compliance requirement. So we really want to make sure that they are, in fact, secure.
When we start getting into this l one plus R, you're probably thinking yourself, Why would I want an app that has reverse engineering resilience but doesn't really have these defense in depth requirements? Well, there's a lot of good APs that are examples of this something like a maybe app that tells you what the song that you're listening to is at that moment. Or maybe an app
that's for playing games.
He's don't really have a complex compliance requirement, but they have a lot of I, P and I. P needs to be protected. So if that I p isn't protected, somebody might be able to reverse engineer. Yeah, figure out how the a p I works figure out something in the source code. That's important. And once they figure that out there able to recreate that at themselves, pirate it
do something bad, maybe even give themselves,
like, fake currency within the app if it's a gaming app or something else. All of these air totally part of the attack scenario for these APS. So it's important to understand that. And that's why it's so important that those APS have reverse engineering resilience.
And I bet you can guess what the final one is.
L two plus, are these air really complex? APS The's a wraps that are doing, you know, really important things. Ah, perfect example. Might be something that has peer to peer money sharing.
Maybe it has some sensitive I pee in there but also has, like, credit card transactions that are handled within the app.
And there are tons of options
that we could go into, what different types of APS maybe like a Venmo, or maybe something like uber. But we really want to be sure that these abs are secure because again they're dealing with sensitive I. P. They have a compliance regulation body that they need to adhere to. So if they're not adhering to those standards and they're not protecting in your I p you know,
they're in trouble. They have a really big attack surface. And because of that,
they really need more protection than that Al one app. And they have more reverse engineering resilience requirements than that l two app. So, you know, we want to make sure that you know these air, the APS that are getting additional coverage, that they're getting the right type of coverage to
and ultimately are absent model kind of helps us figure out where these APS fault.
So actually, our next thing would be to actually try to apply this to some maps that we might be using today.
So figuring out where you fall really comes down to a few things we're gonna figure out, like what? The purpose of that app is, what type of data that app handles. And then let's consider kind of some perspective like, How do we use that app and why do we care about that app? It's important for us, Toe. Consider that because that really does help us determine where that falls.
So let's take the business expense up. Let's take a nap. Like, you know, I'm not going to say any company names, but everyone has business expenses up. You don't get paid through that app, but you're submitting receipts to it.
That app itself doesn't seem like it has a lot of, you know, peer to peer interactions,
but it does handle financial values and really, you know you want it to be secure, and it does have some compliance requirements. So that means it's now two up.
This one's pretty straightforward. So let's do another example.
In this case, we have a conference app.
I kind of gave this one away, But think about it. Limited functionality. There's not really much going on in the APP. There is not any peer to peer interactions, and really, it's just there to show you a schedule. Maybe tell you what's going on at what time giving you a map of where to go in certain events. And it really shouldn't be collecting much data. It shouldn't be
communicating and securely because those are major issues,
so we do want some standard security behind that at, so this happens. No. One
next one is one that almost everyone uses now a corporate messaging app. You can fill in the blank, but there's a ton of them out there, and more often than not, people are using these applications to really communicate information that they shouldn't.
Maybe if you're developer, you might be sharing code snippets of stuff that really shouldn't be shared through 1/3 party at. But it happens, you know, that's the way it is. Everybody is trying to communicate as quickly as possible. But not only that, Like, this is a business critical lap. This is an app that is gonna hold sensitive data.
And that data might be, you know, held to compliance. So this is an L two plus art. This is a really crucial app, and it requires additional protections. So being aware of what those protections might be, you know, you want to make sure that this app is actually secured, that it's device binding self. You know, somebody tries to set up an account
on their device somewhere else.
It won't allow them because it's bound to the device that it was originally set up. Teoh.
The final example is the gaming app. So we talked a little bit about how that gaming that might be affected, But let's actually consider how somebody might reverse engineer that app, modify multiplayer competitive play and make themselves number one. They might change certain pay to play features into free to play.
There's a ton of examples,
and as a user, you know, we wouldn't really care. Like we see those things And we think, Well, you know, back in my day, we just set up, up, down, down Left, right, left, right, be eight start and, you know, continue down. But in mobile games where you know they're relying on this
pay and play model where they're trying to make revenue off these games, it really is important for them, you know, to protect them.
So we went through this video pretty quickly and we covered a lot of information. But in short, we covered this idea of creating security baselines and really relying on a wasp to help us create them because it is the industry guiding mobile to do that. On top of that,
we also came up with some testing. Resource is so if your security pen tester or somebody who wants to get into that or is just kind of curious about what's going on
and what the pen testers are doing when they're testing that, making sure they're doing it the right way. We have some information now, and finally we've come up with kind of a threat model. The abstract model really does help us figure out where that act should be and how we should apply security requirements against it. So keeping that in mind as you go forward
always consider what are the important policy decisions that you're making in your app
before we go into the next week. I want to thank you for your time, and I hope to see in the next one.
Up Next