Hello, welcome to Nowhere Connect. Today we're going to talk about how to build a mobile app risk management program. So we call that MARMM uh for short. You've heard about it in other things we've gone through. And we wanted to take you through what the details are. So I'm Alan Snider. I'm the CEO of Now Secure. and I'm going to be the uh guide to talk about what a MARMM program is, why you should have one, and then walk you through a best practices example that we use uh with customers and prospects to help them uh along the line and make it easier to build one. So first let's talk about what is a mobile app risk pro management program which is fundamentally it's just a structured way of thinking about how to organize and then continuously assess and mitigate risks of the apps mobile apps in your environment. So really it's just your plan. Uh super simple. What we see is most customers already have things like this for their web apps and the other uh components in their uh environment be it cloud or network uh but they don't typically have it for uh mobile apps. And so what we're trying to do is kind of leverage some of the work that's already been done in the website, but then also to adjust and give people uh ways to think about the fact that mobile is different and therefore it needs to be treated a little bit differently and there are certain parameters that are a little bit different for mobile. So we'll walk you through that and explain that. But what is also super important is you need to think through the what works for you in your environment based on your threat model, based on your business needs, based on how important mobile is, how's it used in your operations versus uh how you use it to interact with customers and partners. Right? So what we're going to go through today is what we would consider to be a best practice. It's not intended to be adopted as is. We would expect that any customer, any prospect, anybody is going to want to take it and make it your own and make adjustments and changes that are unique and specific to your business and maybe even to uh by business unit uh as well. And fundamentally too, the what's important about a program is it's really based on what is the impact to the business if something from a cyber security standpoint were to happen to that app. Right. So we're really looking at it based on what is the risk to the business, what is the impact to the business. We call them uh business impact tiers uh to make a differentiation between impacted business and then whether something is or is not a risk that will cause an impact. Uh just we find it makes it easier to have that conversation and not use risk in too many places. Um this is also something that it's independent of how or where that app originated. Right? Our view is whether uh it was built uh by you, whether it was built by a third-party vendor, why whether it was built by somebody else and you use it to conduct business, if it is important to the business, if it has a business impact, it doesn't matter who or how it was built. What matters is the impact to the business. Okay. And then the final piece is it really needs to take into account not just the impact of a business but then once I understand that what is the appropriate testing regimen across things like the frequency of testing the depth of testing the type of testing the coverage right how much of the app do I look at and uh examine and then also do I want to test against standards all of those things need to be considered and that to us is that's what a mobile app risk program management or program is. Now let's talk a little bit about why, right? Why does this matter? Um first we'll talk about the challenges, right? What we frequently see um across the board is uh and this is actually one of my favorite questions to ask is how do you know when a mobile app is ready to go to production? Uh and that could be a very awkward question. you get a lot of uh stairs because realistically there's not a good clean answer to that of what defines ready for production right and so what that leads to is friction between the security teams development teams and we hear the development teams frequently saying just tell me what the bar is and I'll hit it but just tell me what it is um and so to us getting that understanding and common understanding of what does ready for production from a cyber security and privacy standpoint. What does that mean? That makes a huge difference. The other piece that we see is how do you prove that you've taken reasonable care and this proof could come in from multiple avenues, right? It could be the board of directors. It could be an outside auditor. Could be an internal auditor. Could be a regulator. It could be that there was a cyber security incident and now folks are looking at it and they want to say did you take reasonable care because there was an incident. All of these things lead to how do you demonstrate to others that you've taken reasonable care that the app was trustworthy, it was secure. Um you know this is in essence how do you know you've done enough right? Not just is it ready for production, but how do you know you've done enough and then how do you prove that to others? Right now, what we see is it's really hard thing to answer the questions of uh when is it ready to go to production and how do you know that you've done enough? Well, we think a program will actually help you with both of those. And what those items lead to is we see gaps in security testing and privacy testing, right? And those gaps lead to business risk. We see inconsistent uh security and privacy testing in terms of between apps, between versions of an app right across the board. All of these things expose you to business risk that needs to be addressed. And that's why the MARM program, you come in with structure, you come in with here's what it means to us in terms of business impact, here's what it means from a testing regimen, here's what it means in terms of frequency, depth, coverage. All those things get answered and maintained. Right? So as the market changes right weren't testing a lot for AI and mobile apps maybe two years ago now absolutely uh critical item uh because all of our customers everybody has uh governance policies now that say we must know where AI is being used in mobile apps and we must know where that data is going to and how it's being used. So big changes right so you really also need to have something that will continuously change and evolve and stay current for the both the threat model and the changing technology and that's really what program gets you right it gets you clearly defined process and standards so you can say this is what production ready means for us again doesn't matter what kind of app whether it's one you built or one somebody else built this is what production ready means and that then gives you all sorts of benefits like you can move to production faster because now all parties know this is the bar we need to get to. And when something falls short of the bar, it's very clear this needs to get remediated for it to go to production. Oh, this is um above the bar. So maybe it goes in the backlog. Maybe it's just a acceptable risk. Uh the other piece is you also get improved privacy and security because you know you're hitting that minimum bar every single time as appropriate to the business. And that's where the appropriate to the business really matters because that means now you're getting a much more efficient use of resources. Um you're not spending too much time on something that doesn't matter to the business and you are spending the appropriate amount of time on something that really has a big impact to the business. And the final piece is you're consistent. And that also means that you've got uh provability when it comes to going to third parties. If there ever is an issue, which hopefully there's not, but if there ever is, you can prove that you've taken reasonable care and you can prove it across all the different apps, all the different versions every time it went to production. And to us, that's what then you look at and say, I'm more efficient. I can move faster. So I got the increased development release speed that I want. I raised the bar in terms of security and I improved my efficiency because I used automation and uh appropriate use of resources relevant to the impact to the business. All of those things mean that you're going to operate significantly better uh while also uh reducing risk to the business. So with that, let's dive in and look at what we would recommend and what a sample program would look at. So this is the now secure best practice like I said you can take and adjust and you know we're happy to share this with folks and then adopt it and make it your own as appropriate for your business. So it super simple four steps and four steps not super simple to do but super simple to understand the four steps. So the first is hey what does impact of the business mean to you? define those typically multiple tiers. We've defined three and we'll go through some samples of what they look like. We've got some customers that have upwards of seven. Um we've got others that have uh none because they haven't implemented a program yet. So the wide spectrum um we recommend three to start and then adjust as necessary. The next piece is really asset inventory. What mobile apps do you have in your environment that are in essence reason you need to do step one is you need to understand what does business impact mean. So then you can go look and say like let's just say in step one you said if I'm putting intellectual property into an app then that app should be in the asset inventory. Great. Then you need to go look and say okay it could be a third-party app. It could be I'm putting information into teams. I'm putting information into Slack. I didn't build it, but I have sensitive data and IP that needs to be protected in there. So now we've done the what's the impact to the business, what are the asset inventory of things that need to be uh uh basically uh analyzed and assessed. So then you get to step three, which is okay, great. I'm going to take those apps and I'm going to assign them to an impact tier. And the fourth part is pretty uh straightforward which is now I'm going to execute the program and do the security analysis and the privacy analysis on those apps as per the program direction in terms of the testing regimen to make sure that every time that app goes to production it meets my uh standard. So let's dive in. We're going to take a look at step one. So the defining your business impact tiers, right? I've talked about it a bit. Um we recommend high, medium, and low. I think the best way to do this is just dive in and show you what we would recommend uh for high. Right? And this is unique to mobile. And I'll explain why it's unique to mobile. Right? So the first piece pretty straightforward sensitive data handling. Are you putting PII? Are you putting financial information? Are you putting, you know, health location? you our health information in there, uh, PHI and if you are, we believe that you have an obligation to protect and secure uh, that app if it has PII, PHI, and we would put it in a high business impact tier. Um, then you start to look at some of the subjective pieces, right? Because that's pretty um, objective of is PII in or not present in that mobile app. reputation risk. Does it have your brand? If it were out of service, what would happen? Right? Just even in the last uh uh 24 hours, there's been an impact of a major brand that had to take apps offline, both mobile and web because of cyber security incident, right? So, what is that brand impact uh to you? What does that mean to your business? Um core business functions, right? How critical is this to actually running and operating your business? Is this a um you keep customers updated with the latest news and product features or is this we can't restock our store shelves or we can't uh run and operate the business or this is uh generating 80% of our revenue right how core is it to the business function and the operations right so again how much damage would it do to the business if it were taken offline compromised or out of service um how many users right again this is related to core business functions but how many users these are good things the metrics to go look at uh users is much easier to understand because you have active daily user numbers already I'm sure you know all of the teams at your organization are monitoring and looking at this in terms of downloads and active users um connectivity this one super interesting because remember most of these apps you know have 60% third-party components so our view is an app that is sending data to lots of different endpoints and lots of different in a sense has many connections that has a much larger attack surface than in an app that is sending data to maybe you know one interaction it's only interacting with uh your uh backend cloud or your services versus multiple partners. So our view is okay that should be taken into account uh because it has it presents a larger attack surface for you and thus more risk surveillance capabilities. This is super unique to mobile apps. This is very hot around privacy. It's very topical particularly from regulatory industry about geolocation tracking and other such things. But this is really about can this app be utilized by a bad actor to basically surveil or to uh grab data and xfill data out of my organization that uh is super sensitive and that's can it track the geolocation of my people or my users. Can it record them uh video microphone uh can it get access to email contacts? So this is what we would look at and say dangerous permissions. Um if it is using dangerous permissions we think it's a high impact app for you because if that becomes a privacy issue that becomes a brand impact issue. So if you end up on the front uh page of the news article around hey you were uh your app was used to track geolocation or there was a data leakage to track geolocation of your customers. That's probably going to be a pretty significant brand impact for you. And that's where mobile apps are different because mobile apps can do that. Most other apps cannot. That's where we think your policies need to take that into account. And finally, is there a regulatory compliance issue? Right? Is there something where this app must have or going to be judged based on uh the uh regulatory environment that you got to clear that bar or that hurdle? And that's something that you know you would know for your business pretty quickly uh and clearly. And so this is what we would recommend high business impact. Any app that has these characteristics and attributes that would be in the high category. And then what you do is then medium is one step down from that. I won't go through it in as great a detail. And low is significantly less. But you'll notice with low it is, you know, minimal to no sensitive information, right? it has, you know, doesn't have your brand on it. Um, it doesn't do financial transactions, right? So, no access to dangerous permissions, right? So, low is truly pretty low and then, you know, middle somewhere in between. So, hopefully that's uh pretty straightforward. And again, I'll reiterate this is our recommended starting point. This is a best practice document. The reason we're doing this because we want people to think about this, we want to generate the thought around, well, what is your policy? what do you want to do? The good news for us is we've built a software platform that once you've made these choices, we can put this into practice and automate it and make it easier to go use. Okay, so now we're going to get into the piece of identifying the apps. Um, and this really breaks down into three categories. Uh, the first category is probably the most straightforward and easiest. Um, because those are apps that likely you're building, you know, you have an inventory of them, they have your brand on them. It's pretty straightforward to go and understand what they are. Sometimes in really large organizations it gets a little more complicated because there's multiple brands and you got to do some work to go find them. But generally you should know the apps that you're building that have your brand on them. The used and managed apps um actually also pretty easy to understand because these are the apps that in your mobile device management platform are going to be managed apps. These are the apps that you in essence have paid for. You have approved for your uh employees to put data in. So this is going to be the I'm using Teams, I'm using Slack, I'm using other third-party apps to conduct business, but you didn't necessarily build the app, but it does have intellectual property. It does have customer information in it. Therefore, it needs to be protected. And then the third piece and we see this really in high regulatory high-risk uh environments, high threat environments and that is folks will look and say even though it's a BYOD app and my employees are not allowed to put data in it, they're not authorized to do it. We view anything that touches our corporate network to be a risk and a threat. anything that is on the device next to our uh apps that we build or next to the apps where we put sensitive data that could you know cross uh a cross app attack uh we need to vet and understand and so many of our uh customers in high compliance uh or highly regulated environments where they have a high need for compliance, this is absolutely something where they need to do all three of these categories. And then uh some of our other customers that are maybe less regulated uh that bar isn't quite as high. The first two are where they would certainly start. And what we also expect is that this is going to be a crawl-walk-run for someone to come out and do a full MARM program from zero uh to uh 10 uh in one fell swoop. Probably not the right way to approach it. We believe that first you get it done and then you incrementally roll this out and go do it so that you can adopt, you can adjust um over time. So let's talk about step three. Step three um I would argue is the uh piece that is the easiest in practice because you've already done the two hard things is you've defined your business impact tiers and your app characteristics and then you've in essence now said now I have my asset inventory from step two. Um, but step three is actually kind of tricky because now you need to go figure out where to put the app uh in those impact tiers. And this is where now secure can help because we can actually tell you do we see that app uh having does that app have PII? Does that app have financial transactions? Right? So some of it we can't tell you. You can tell us how important it is to your business. You can tell us uh you know uh how many uh users and those other things. But there's pieces where does it have dangerous permissions? Does it have PII? Uh how many uh you know connections does it have to third parties uh other components outside of you? We can actually help with that and give you that data to help you do that characterization to then assign it uh to the right tier. So that's pretty straightforward. The piece about step three that's tricky is this. This never stops because let's just use dangerous permissions. Yesterday the app did not have access to precise geolocation but I made an update and so version three does have uh access to precise geolocation. Therefore it's going to move from medium to high. So this is also something that must be ongoing because the app profile it could move down it could move up but they're going to move as apps get new features and new capabilities as you roll more capabilities out or deprecate capabilities as it goes. So that's the big thing is that uh step one that's probably once you get it set it can stay pretty well set for a while. Step two, as you add and remove apps, continuously going to need to evaluate that. Step three, apps can move across your tiers, need to continuously evaluate and do that. And then you get to four. And four really is all about now that I know what my impact tiers are, now that I have my apps assigned to those impact tiers, right? from steps two and three. Now what I want to say is what is the appropriate testing regimen to mitigate the risk right to you know of that of having a business impact and then how do I implement that on an ongoing and continuous basis. So this again we're going to give you some examples of what we would recommend for um high, medium and low. So again I'll focus on high but you'll get the sense of it when we go through in medium and low. So this would be I want to do continuous automated testing for every version of that app that goes out and then I want to test to a given standard. Do I want to test to um OAS MASPS L1? Do I want to test to a uh company defined standard or policy that you say this is what uh production ready means to us? All of these things are questions that get answered for each of these testing regimens, right? So continuous automated, what is it you want to do? Then what we would also recommend is not only do you need the continuous automated piece, you also need to go and test things like MFA. MFA, the number one successful attack vector is compromised credentials. the your mobile app has most likely right authenticated uh access to your mobile app to get access to services. Ideally, you also have MFA that needs to be tested certainly needs to be tested. We recommend testing it four times a year. Um and then you would also test other critical workflows or such things. So those are the high risk factors. Maybe don't need to be tested every single time you go through the continuous automation, but need to be tested four times a year. And then what we recommend is once a year do that deep dive pen test. And that deep dive pen test should be informed by the testing from your continuous automation and by those four times a year checks of your uh MFA and the critical workflows to basically say let me go beyond where the automation went. let me go beyond where uh those uh you know critical risk factors piece went and let me go deeper and pull on threads that I can't pull on an automation and but our view is you don't need to do that every single release of the app every single version of the app that's something you would do once a year and you use the other automated testing as your jumping off point in guidance so you can go farther and deeper uh to make sure you got better coverage and all of these things should be done in the context of what is the frequency what is the uh basically coverage and by coverage I mean is it non-authenticated is authenticated what you'll notice here is we look at it and say well you should absolutely be doing authenticated testing because this is a critical app so I want to get past authentication and I probably want to do a critical workflow or two I want to test that financial transaction all of these things matter to go through but the depth that you would go to right in terms of depth of testing and type of testing for automation is going to be different than pen testing. So pen testing, I may want to test to a higher standard, right? I may want to do that once a year pen testing and say I want to test to OAS MASVS L2 plus R. Whereas in automation, I want to test the MASVS L1. And so these are all choices and decisions. We've laid this out here in this what we think those answers are, but obviously your mileage is going to vary based on your threat model, your risks uh to your business. And then what we also lay out is not just high, but what do we do with low? And what you'll notice is we start to back things off. Do I need to test MFA as much if it's not a impact to my business? We don't think you do, right? Still need to do annual pen testing. I can probably bring down some of the testing standards that I'm going to do in terms of how far do I go into the app and how deep. And then when you get to low, well, maybe I don't need to do uh that pentest because it didn't have any PII, didn't have any sensor information. So, I still need to do uh continuous automated analysis, but you know what? I can do anonymous testing. I don't need to do credentials. I don't need to log in. Why? Because it didn't have um sensitive information. So, this is our recommendation. And what's nice about when you get this done, you have a complete program that defines your business impact tiers, the attributes of an app. You've done your inventory. You've assigned your apps. And then you've laid out your testing regimen. And then you basically get into the execution mode of now how do you take all of this and automate as absolute much as possible. There are still places where human loop is absolutely essential. And our view is great. Now you've got it laid out. You can apply the appropriate resources and you can apply it more efficiently and you can make those resources more productive because they're not starting at zero. They're starting where the last automation analysis occurred so that they can go farther, they can go deeper, they can provide more value. So everybody wins because you get way better coverage. You get it way faster. And even the individuals involved doing the testing, they're not starting at zero. They actually get to go do farther, deeper, faster, more fun and exciting things that a pen tester would want to do. So, uh, this to me the the last piece that I'll talk about is all of this is built on a foundation of continuous support and continuous education. Uh, because what we know and see is that there's times when the developers, security analysts don't necessarily know what is this issue? What is why does it matter to my business? What should I do? Well, it's nice to have the support to be able to ask, hey, can you help me? Can you explain this? Why is this uh matter? Can you walk us through it? And then it's also important from a training standpoint, you know, the best uh defect is the one that never exists, right? So the best uh issue is the one that's not there. The only way to do that certainly for the apps you build is training. How do I get the developers? How do I get security analysts? How do I get everybody to a common understanding and a point where these things don't occur and we can build better software? Right? I would like nothing better than when this program executes, everything passes, right? That you pass MASBs L1 plus R on the first run. Uh because the developers were well trained, they understood the models, the architecture, all of it was laid out. And then that would give you the ability to go and say to the auditors, regulators, and everybody else, I can prove that we have taken reasonable care. doesn't mean perfect care because we know in cyber security perfect doesn't exist but it does mean we've taken reasonable care to protect the business and then impacted a business from a cyber security incident as it relates to mobile. So that's been a lot. I've moved through it uh as quickly as I could but hopefully this is something where everybody will now take a look go through and understand how does this best practice how does this recommendation how does it fit for your business? What matters to you? What do you want to change? What do you want to modify? We're happy to share this template. We want you to use this template and then make it your own. What works for your business. So with that, thank you. Appreciate the time. We uh are very passionate about this at nowsecure. We want to do as much as we can to automate the implementation of this and to just make this something that works and then you manage the exceptions and you manage the changes to your policy, the changes the apps, the changes to the impact tiers and everything else is completely automated. It's crazy easy and it's much more efficient than what you're doing today. So, thank you all. Happy to talk to you more about this. Take care. Hello and welcome to your MARM minute. I'm Alan Snder and today we're going to talk about the first step in the MARM program. We're going to talk about how you classify apps and put them into business impact tiers. The business impact tier is super simple. It's basically saying how important is this app to my business and what is the impact to my business if there is a cyber security incident. be that a data breach, be that a vulnerability, privacy issue, operational disruption, all sorts of things that can cause harm to the business. So, let's dive right in and let's take a look at some of the characteristics that we recommend.