Building Baselines Part 1

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
Hey, folks, this is mobile app Set Quanta one. A cyber recourse on mobile application security testing. I am Tony Ramirez, senior application security analyst at Now Secure. And today we're going to be covering building baselines. This is the fourth video ending mobile app. *** Siri's.
So what are we covering today?
For today's video? We have a couple learning objectives will be covering some ways to establish baselines in your organization. Some resource is on how to get more out of testing kind of determine what type of app you have, what kind of coverage you should be looking for. And ultimately using the right types of resource is to test APS.
We'll also be covering this thing called the Mobile APP Sect model will get into it. And it's a really important concept to understand, because it really is gonna dictate
how you should be testing and protecting your applications and how you should be prioritizing what should get fixed. So remember that whenever we're actually looking into testing, we're always talking about not testing less, but fixing more our goals to always fix more and make sure that our APS air meeting some baseline and that kind of leads us to this first question.
How do we prioritize these issues? Because ultimately that's what we're trying to figure out. How do we prioritize something that's high risk versus low risk versus medium risk? And how do we figure out if it's a real issue? But the thing is, is that not every organization is the same. Not every happens the same. So we really want to figure that out early on.
This kind of leads us into this concept of having baselines and drivers of those baselines. And for most organizations it's pretty obvious. But in case you don't
have one, let's figure that out right now. For some organizations, things like standards, data, privacy, compliance and, like I p are all important concepts. But business continuity reputation are just as important. And I'll tell you why
your reputation as an organization really does lend itself to whether your APP is gonna get downloaded or not. But on top of that business continuity, there are people out there in the field using your app, and if it doesn't work, they're gonna go on and tell their staff. Don't use that app anymore. Doesn't work anymore. So you want people to keep using it at
on the intellectual property side, You know, you might have something that sensitive and I pee in there that you don't want stolen or taken from you.
And if that gets stolen, you know that's really another driver behind what your baseline should be. And of course, compliance is always the obvious one. Same with privacy. Those standards are hard to figure out for some people. But once you figure out what your organization does and what you prioritize, it's pretty easy to figure out where you should be aligning
This leads us into APP security. This is gonna lead us into finding the right resource is the right guidelines and methodologies for figuring out how to secure APS. And I'm going to give you a clue. The big topic today really is around a wasp.
So if you're not familiar with the WASP, a WASP is the open Web application security project, and we're not gonna talk too much about back. Today. We're gonna talk about a specific project called the Mobile Security Project. The mobile security project was created to kind of give people guidelines that how not only toe test mobile APS,
but how to develop programs around those mobile laps and secure them.
So you have a couple things here you have your lost top 10. You have the MST G, and you have the M E S V s. And let's actually kind of break these all apart.
So really, there's something for everyone in this Oh, ask mobile security project. And really, the 1st 1 we want to really talk about is the OS Mobile top 10. Because this is really created for developers to understand what are the big issues that they need to be aware of, that they should be avoiding that they should try to know triage before you know,
begin to production.
And we kind of covered that top 10 earlier on. But it's something to keep in mind when you're talking to developers, because if they're not aware of that, it may be something worth showing to them.
Next on that list is the M. E S B s, otherwise known as the Mobile Application Security Verification Standard. It is a mouthful, but we just call it Mavs for right now and what that is. It's for establishing baselines, establishing what your organization should be concerned about understanding what
your app might be doing and having kind of some guidelines on what you're protecting.
It's important to know those things because if you don't know what you're protecting, then you're probably not protecting it. And that's the reality.
Next we're going to get into the MST G, otherwise known as the Mobile Security Testing Guide, and that is the cookbook of mobile security testing issues. So if you're trying to figure out how you should be tested in the zaps, what you should be looking for and you know you got this checklist already
you may be you have, like, this list of things that are filled by policy. But you want, like a cookbook of like, These are the issues thes air, the things I need to be looking at.
That's what I must e. G is. It's a living doc. It's being changed constantly because mobile still changing. And there are new things coming up every day, and being able to tackle those things kind of have some guidelines in the industry is super important. So I'm stg really does fulfill that, and that kind of leads us to our last piece, which is the checklist.
The mobile security testing checklist is exactly that.
You know, if you're getting a pan test on your you're doing security testing on your APS, you really want to have a checklist and that really allows you need two things. Number one, somebody else's testing your app. You convict them. Number two. If you're testing your own app, you want to make sure that you're going through all those points.
So all these guides there for IOS and Android and their things to keep in mind there, open source and they're available out there. They were part of that course material. So remember earlier I said, Hey, these air good docks toe have we're gonna reference them later. Well, guess what. We're referencing them right now, and it's exciting it
So let's actually dig in a little bit on EMI SVs. What mes Bs does is that translates that mst g guide that mobile security testing guide. So we have all these lists of tracks and all these tests we want to do and we have a cookbook and we want to make sure we have full coverage and the best way to do that
is kind of break it up into domains. And that's what Mavs does.
So Maps takes that it kind of implements a checklist, sort of. And not only that, it kind of breaks things up into whether something is high priority or if it's defense in depth or if it's a reverse engineering resilience requirement, and we're gonna talk about each of those three things in just a moment. But keep in mind that, you know,
again, different acts have different requirements.
So breaking things up makes sense. We want to be able to have full coverage for every different type of app our organization might be using. So having this idea in their mind that you know certain naps have special requirements is important, and that's really gonna help us build a better program.
So, like I said before, Mavs is broken up in the eight domains, and each domain is specific to a different part of mobile application security testing and just mobile in general, for instance, architecture and design. You have data storage issues, you have cryptographic requirements. Not only do you have
authentication in session management requirements, but you also have to consider those network interactions
where that application is sending out net requests. But if it's not doing it the right way, then it could be insecure. That's different from the authentication and session management that the APP might handle. For instance, in that has a log in or a nap has some type of oh, off requirement or it has something else. And on top of that, it has some session management. After that authentications taken place
those air different domains. You also have that environmental interaction. Like I said, absent communicate to one another, they have I p R I. P sees that they used to communicate between different APs, and that's an important part of testing. Finally, we have that code quality requirement. We talked a little bit about that earlier. How you want to configure your bill to be,
You know, I secures possible and leverage all those free security things that they give you and
both Android and IOS and finally reverse engineering resilience. Those air requirements, like protecting your application against reverse engineering like code obfuscation, device binding and there's many others and it really depends on the type of app you're creating these air requirements that are not made to protect your app
from the security issues that already has
but made to harden your app and make it harder for Attackers out there to find your shoes in your app again. We don't wanna octus Kate the security of our APS. We want a hard in them and we want to make sure that they're secure.
So I talked a little bit about this like l one l two and R and really it kind of breaks down into standard security, which is that one l two is defense in depth, and ours reverse engineering resilience. So, like I said before, we have L one, which is like the standard security best practices. We want to certain naps to do certain things
and all of them to do those things, because if they're not doing those things,
they're really high risk. They're not get things to do. There really indications that developers or security teams or enterprises aren't really carrying and making the effort to make their app secure 10 years out to have applications that have special requirements. Those could be things like performing certificate, pinning or other technologies
that really hard in your app
and these air applications that really do have some, you know, additional requirement. And we're gonna kind of break these up in a moment and actually talk about the differences between all of them and then finally, reverse engineering resilience. Can I told you before, but we're looking at the vice binding code office cation, an anti tamper and other things. But again, they're not meant
to cover up for poor security.
They're meant to enhance the security of the APP oven already security.
Up Next