Hello, good morning and good afternoon everyone and thank you for joining us today at now Secure Connect. In this session today, we're going to be talking about how we can support you in your mobile app risk management program. If you haven't already, you're going to see a little bit of a theme today um where many of our sessions are focused around uh mobile app risk management programs that our customers have developed that we've worked with them to um to to progress along the way. And the parallel track to this one, um, our Allen, our CEO, is going to be talking through at a high level, what is a mobile app risk management program, what are the key components of it, um, and how can we help support you from more of an executive and and managerial angle. So, if you get a chance and you want to go take a look at that afterwards, you're more than welcome. Um, but in this session, I'm going to be focusing more from a practitioner angle on how now Secure can support you today in some of your efforts and maybe help address some of the common challenges you face and also going to be getting a little bit into some product updates that we're working on for this year. So, first and foremost, introductions. I'm Katie Bochnowski. I uh run our services and customer success teams at Secure. Many of you I've probably already met, but um others I have not. So, welcome. And I will be presenting today, but I did want to include Ed Collins, our director of product, as he helped me pull together some of the content for this. Um, but you'll you don't get a chance to meet Ed here today, but you should if you haven't already. So, uh, please reach out. Ed is awesome to work with. Today, as I mentioned, we're going to be going through just a very brief introduction of mobile app risk management. And um I'm going to be diving right into some of the most common MARMM program challenges that our customers face. In my role at now secure, I've been here for over 15 years. I work very closely with our customers in guiding them and listening to um what they are focused on in their programs. And oftentimes I hear about those challenges. And so I'm going to be highlighting some of the most common that I hear about and then how now Secure can support um you with th with some of those challenges and um we'll be wrapping up then with our 2025 focus areas for our product. So at a high level um mobile app risk management really just means what is what is the program that you have defined that says what are you going to do to secure your mobile apps. Um the components of a mobile app risk management program really consist of four primary things. One is defining the mobile app impact tiers of your applications that you oversee in your organization. So if you have 20 applications, maybe five of those are high business impact um as they handle sensitive PII and other critical pieces of information, whereas others may be medium or lower um impact tiers to your organization. It's critical to define your app inventory and then classify those applications accordingly. Um, so identifying those apps and then assigning those mobile apps to impact tiers to determine what level of analysis do you need to do based on those different impact tiers. Obviously for a highly critical application that handles PII, you're going to want to do continuous testing. You're going to want to do um maybe multiple pen tests throughout the year depending on the application versus a lower impact application. you may just want to do something you know automated and and um you know scan it throughout the year but you may not want to do that deep dive um that is dependent on the organization it's dependent on your requirements um but essentially that is what um consists of a mobile app risk management program. So diving straight into some of the common challenges that we hear day-to-day. Um one is that there is absolutely the desire for continuous security testing that isn't noisy. This is the number one thing we hear um a lot of due to the nature of static analysis. Um not necessarily even tools but the nature of static analysis in and of itself. Static analysis only tends to be fairly noisy. It flags anything it sees in the code even if it's not in use and it doesn't necessarily mean that there is an executable vulnerability. Um so the thing we commonly hear is um we on the security side want to protect our developers time and only send to them um true vulnerabilities. So we don't want um analysis that is noisy, that has lots of false positives, that has a hundred um vulnerabilities that get sent to our developers. Um we need to easily map to industry standards. So how can you help us if for example our auditors require us to test against OASP or MASVS or um you name the standard, how can we easily map to that? Um, one that is rising in popularity that we hear a lot about is the need to answer to AI governance groups regarding not even necessarily vulnerabilities um, related to AI use, but tell me which mobile apps are using AI components or libraries and highlight those to us and just let us know what is being used. Um that's certainly something now secure um is is helping our customers with, but it's just something that I've absolutely seen rising popularity as I'm sure many of you have um in the last call it 3 to 6 months. Um another common challenge that we hear about is that um customers require the ability to customize findings to map to your org's policies. Now, secure may come to you and say, "Hey, here's a set of of findings and vulnerabilities that we test for, and here's how we classify the the risk for each of those vulnerabilities, but you as the customer may say, I disagree with all of that. I want to customize that or these aren't important to us and these are um the ability to have that that pol customized policy and ability to set that for your organization is um very important to a lot of our customers and I would say is crucial for any sort of um security analysis tool to have so that it doesn't um circle back to number one which is a noisy product right so or noisy results. You want to be able to customize and filter out the things that don't apply um to your organization. Um and finally, and I'd say finally, but really there's a lot more than this. I tried to just um come up with what I I felt were the top five that I hear a lot about um more recently. Um and that is the desire to understand what changed between app versions. So in this world of um agile and continuous testing and you know testing every new mobile app build uh as it comes out when a new finding is flagged um in one version to the next uh security teams and developers want to understand quickly okay what changed is it something in my app that changed is it a new vulnerability that that you know now secure added but either way I need to understand what changed so that I can go figure out, okay, did we just release um was was there a regression? Did we just release a new feature that um triggered this vulnerability? Um understanding that comparison um is important to customers as well. So, um I'm going to be covering on this slide um how can now secure support you in some of those challenges I just talked about um today. meaning what do we have available today? And then um the next slide we'll wrap up with is what are we what's on the horizon? What are some of the bigger things we're working on based on what we've heard all of you know ask for and show interest in. So um we'll be covering those couple of things here this morning. And so today I I tried to categorize these for you guys um into again what I I felt were the top um four areas that we hear a lot about. one is uh improving efficiency and value in devsec ops workflows. So what does that mean? That means helping um drive efficiencies and make the jobs easier of both developers and security analysts when it comes to finding and remediating mobile app security vulnerabilities. Um talked a lot about policy management in the previous slide. Uh we do have a policy management solution that allows security teams to only route um higher critical issues to developers for remediation as an example. You can choose to route um others as well, but if you it's it's critical that your security teams and your development teams and and now secure collaborates with with you all as well to come up with that custom policy that will work for your organization that will drive those efficiencies that when something gets sent to the developer, they know and understand what it is and they remediate it and there doesn't need to be a lot of back and forth. So that policy management and configuration is critical. Um I want to also make the point that a lot of our customers choose to just use the default policy because that's you know what we have there and that's okay too. Um and that works for people that um that necessarily don't have um you know very specific requirements that kind of contradict maybe what we have. Um, but I did want to say that as well that we maintain and update our default policy to be as um representative as we can across all of our accounts. Um, the second thing we have is um this was recently launched earlier this year is the ability to compare between assessments. This was a very commonly asked for feature and um I'm very excited about it. I love using it. Um and this does allow customers to compare um from one version to the next. Um in order to understand that change of risk between the different versions. Um so this was something like I said that was recently released and it's um we're seeing a lot of utilization there. Um I also want to highlight if there's any customers on here uh that want to learn more about any of these things, please don't hesitate to reach out to us. Um the last one under this category um is the ability to integrate seamlessly into the way in which your teams work um by utilizing our existing integrations um to ticket management systems and um build systems. So we have integrations with tools like Jira, GitHub, um certain Service Now modules, um Jenkins, you name it. And um because we're API first, we can really support almost any integration. Um but we do try to make it easier for those common tools um to create those kind of plug-and-play integrations. Um today, um also today we're able to report on AI use within your mobile apps. We also have a handful of findings that we flag. Um when we when there's a finding in um one of those LMS or or libraries um and this is something that was released end of last year and we are continuing to build on just because we see that that continued demand there. Um audit and regulatory requirements. So again, mapping to industry standards like OASP, MASVS, we have um spin-off reports that that um report on directly that. Um we also have other um other uh regulatory mappings that we do. So if you have something unique to your organization um that you want to know if if we map to, we very likely do um and we can help you kind of create that pivot um via the API if needed. And finally, um, kind of on the other side of the house, these first few are were more primarily focused on apps you build, right? Apps you're developing and you need to secure your own mobile apps to make them um, safe and secure for your end users. Um, this last one really is kind of the other side of the coin, which is mobile app risk intelligence for apps scale at scale app vetting. Um, say that three times fast. Um so Mari like as we like to call it is really more geared towards mobile app um security and privacy risk in apps you use. So think about those third party apps, those public apps. This is um we work with a lot of organizations that you know export and pull um apps from their MDM system to make sure that their app portfolio in in that area is um secure and uh safe to use. So this um really is at scale if you think about how many applications are used on devices in your organization. And so this is um a very similar testing engine that we're using for the apps you build. Um but it's of course a different view. It's not, you know, we're not telling developers how to fix vulnerabilities. we're highlighting and addressing the risk um of security risk and privacy risk in those applications so that um MDM and and GRC groups are aware. Um and again I I'm trying to keep it to um some of the most common or most popular uh capabilities that we've either recently released or have coming. There's a laundry list more um of for anyone interested in doing kind of a deeper road map. We're always available for that. Um but I'm going to switch gears here and focus a little bit on what's coming the rest of this year. Um so we are focusing on having greater ability to control and manage risk through granular evidence dismissal rules. Um, that's a bit of a mouthful, but basically comes back to that ability to customize what comes back to you um in a way that supports your organization's requirements. So, let's say a vulnerabilities flag that um is uh in a library that your developers don't have control over and so they want to accept the risk for that that vulnerability. They can do that today at the findings level. But what um what we're continuing to work and build out in the near term is the ability to um filter that at the evidence level. So if the vulnerability applies to 10 libraries and you want to have one library, you know, be the exception, you'll be able to do that at the evidence level um at the line item level there. Um, this helps reduce kind of some misunderstandings and back and forth between security and dev on what needs to be remediated. So, you're not constantly bombarding developers with this vulnerability in this library that they can't do anything about. Um, they won't be able to or they won't um have that sent to them in the future. Um, the second area is enhancements to existing integrations. So of course we're continuously building here based on demand and things we hear about. So we're um supporting working to support an additional Service Now module that we're hearing about. Um we are working on many Jira enhancements given that that is a very popular um integration that our customers utilize and the enhancements that work that we're working on will help confirm and close remediated issues. Um they'll help prevent duplication of ticket creation. So, we don't want to create duplicate tickets for your developers. We're working on um remediating that. And I highlighted this in bold because this is a common thing that um we hear about as well. Um our enhancements will help you understand some key metrics that we know all of our customers focus on. One example is that meantime to remediation. Um so that is something that we heard many of you and we are focused on. And finally um we are working on similar to the pivot that we have today for the MESVS um report we are working on we have actually um a version of this already and we're working on enhancements to um pivoting data into a privacy report and providing a different view into app risk. So, um, if you look from a strictly CVSS scoring perspective, if it doesn't have a high CVS score, it's not going to be a high-risk security vulnerability. But if you have um PII being sent to an endpoint or a country or a location that you don't want it to go to, um, even if it's sent in a highly secure way, you want to know about that. So, we are working on making sure that we highlight those privacy issues as well as potentially high risk even if they aren't high security risk. Um, this is something that we've um collectively gotten feedback on and we completely agree and that's um a direction that you're going to see us headed um throughout the rest of this year. So, uh that's essentially all I have for you for this morning. Um, today we did walk through some of the col common challenges that mobile apps professionals face in their day-to-day operations as well as many of now secures capabilities that can help support you in your initiatives. If any of these sparked additional ideas or questions um on your end, please don't hesitate to reach out to us for further discussion. Um, I know everybody says this, but it's so true. Your input really is critical to um our combined success here. We only want to work on the things that we know people care about. So, please um don't hesitate to reach out and have those conversations with us. I really appreciate your time. I'm really happy you guys are here. There's a lot of awesome sessions coming up. You're going to be hearing from our researchers, Oola and Pancake, and I think um our head of research is doing a panel. Um, we've got lots of customers um, speaking on either panels or presenting and talking about their MARMM program. So, I'm personally looking forward to hearing uh, the rest of these and I thank you for joining us today. What does a healthy DevOps regimen look like? How should my security team and my development team work together to limit business risk and ensure the safety and security of business critical applications? The answer by implementing an efficient workflow that allows all teams to work together continuously without impacting the productivity of others. Let's walk through this example. Developers complete code review on a new feature and automatically kick off a scan via the CI/CD pipeline. Now secure platform performance static and dynamic binary analysis in minutes. In this example, the automation produces 42 finding. These findings are then filtered through now secures policy engine which the security team customizes to ensure that all high and critical findings immediately and automatically generate tickets into the developer ticketing system. Assuming five findings were high and critical, the remaining 37 findings are then manually reviewed by the security team to triage and assign to the appropriate queue for remediation. This workflow assures that high severity tickets are provided as soon as they are discovered and less severe tickets are triaged appropriately by security teams. Using the integrated workflow with now secures policy engine is the fastest way to prioritize and remediate issues in your mobile application suite. [Applause] [Music] 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. Now what's important to understand about what we're going through here is that each company is going to come up with what is appropriate for them. We've created a best practice document to help you define these and serve as a template, but based on your threat model and based on your operations organization, it's probably going to vary a little bit, but you need to look at things like sensitive information. Does it have PII, health information, financial transactions? Does it have your brand on it? Is it the primary path to business? Does it collect geolocation data? Maybe have access to contacts and microphone and camera. So, it's collecting information that you have an obligation to protect. How many uh connections and endpoints does it have? In essence, where could that data that it's collecting be distributed to with or maybe without your knowledge? All of these things go into that factor in terms of how much of an impact, therefore, how much of a risk is it to your business. So, this has been the MARM minute. Super quick, but hopefully it helps you put together a better program. [Music] Hello and welcome to the MARM minute. I'm Alan Snyder and today we're going to talk about the second step in the MARM program. It is basically asset inventory. It's understanding the mobile apps that are in your environment that need to be secured and protected. It comes in a couple different groups. The first relatively straightforward to uh understand a little bit harder to identify that is all the mobile apps that you or a vendor develops on your behalf typically is going to have a brand usually going to be in uh public app store maybe in your internal enterprise app store. The second category is uh apps that are approved for use. So this is one that you didn't develop but a third party vendor developed with their brand but you're putting your intellectual property or uh PII or other such information that needs to be protected in it. So think of things like maybe Slack or some other uh messaging uh platform teams that you didn't build it but you're using it. It's super sensitive. Uh those are typically going to be in your MDM and they are approved for use apps that get pushed out to new employees. The third category is going to be BYOD. And this really depends on your security posture about how important it is to protect. But that's your big categories there to go and find. So really one group you're going to do with your MDM, the other group you're going to do with your development teams and vendors. This has been your MAR minute. [Music] Welcome to the MARM minute. I'm Alan Snyder and we're going to talk about step three of the MARM program. This is where you bring together uh step one where you defined your impact tiers and the app attributes that matter to you to make it a high, medium, or low impact to your business. And step two where you did the asset inventory of understanding all of the mobile apps whether ones you built or ones that somebody else built and you use and you put sensitive or critical information in and you start to categorize and put things together. This is super important to the program because how do you know what level of testing you should apply unless you understand what category that app should be in. Now this requires you're getting information about the app. You need to understand uh whether the app has PII, whether the app has critical information such as IP uh financial transactions. You need to understand does the app have the ability to track geolocation, how many endpoints, how many downloads. So, you're going to need a lot of information. Highly recommend you use now secure. We can actually tell you uh pretty much all of those items, right? We can't we can't tell you brand uh impact, but we can certainly tell you all of the other attributes of that app and how we would categorize whether it's high, medium, or low impact to your business. So once you have that, it's also important to keep in mind apps will change over time. Sometimes they will lose functionality and be downgraded. Sometimes they will gain functionality and information and be upgraded. So this is a continuous process that needs to be applied. This has been your MARM minute. [Music] Welcome to the MARM minute. I'm Alan Snyder and we're going to talk about step four of the MARM program. This is the part where you really now that you've got your apps uh categorized and classified in terms of business impact, you need to give some thought to what is the appropriate level of testing and what is the frequency of testing and what is the depth of testing that is appropriate to protect your business from risk at that level that impact tier. So what we do in the MARM program is we give you our recommendations. Again, I would caution everyone. This is a best practice recommendation. It's a template to get you started. Your own threat model, your business risk, your challenges are going to define the appropriate level of testing and the frequency and the depth of testing for you. But what we thought would be helpful, and this is particularly true given that mobile apps have different characteristics uh from uh web apps, it's important, don't assume they're the same. Don't treat them the same. the way they leak data, the way they function, the number of endpoints, the number of third-party components, all highly highly different from what you're going to find in web apps. Therefore, your testing regimen and your assumptions also need to be adjusted to make sure it's with mobile. What we recommend from now secure is that you do that uh regular and annual uh pentest and then you supplement it must test MFA and then you also do the continuous automated testing. Don't forget training because you're always going to need to make sure that your teams, both the development teams, security teams are trained. This is what we recommend for the high impact apps. You may have your own choice and that's what's good about the program is we're here to help you define a program and then implement it as best suits your business. This has been your MAR minute. Hi, I'm Michael Krueger and here to talk to you about traditional pentesting versus pentesting as a service. Standalone pen testing is our traditional application of pentesting for mobile apps. Experts uh conduct rigorous security testing against the application, provide a final report and then ultimately remediation consultation. However, there is a problem with that. Uh in this example, there may be an application that has uh three major releases throughout the year as well as a number of minor releases. Uh and we're conducting an annual pentest as well. The annual pen test in March, as you can see, may catch one of four bugs throughout the year. However, those other three bugs may introduce vulnerabilities that may not be caught until the following annual pen test if it's not uncovered during other rigorous testing. How do we fix this sort of application? Well, that's where we bring in pentesting as a service. Pentesting as a service modernizes the pentesting approach by utilizing SDLC integrations to allow and reduce developer friction by uploading binaries directly into uh a software as a service platform. Allow you to dynamically request pentest on demand from experts. Go through that typical expertled pentesting cycle. export reports on demand but also feed that report information back into a more continuous monitoring program. Can also conduct retesting. But as we as we ingest into the continuous monitoring continuous testing program, we start this continuous cycle of uploading new releases for assessment automated assessments occurring throughout the year.