All right. Um, my name is Adam Schaefer. Uh, I'm a senior director of solution engineering here at Now Secure. Um, we're gonna have a little talk today with CB. Uh, CB is one of our partners over at Warner Brothers Discovery. Um, so CB, before we um jump into all the fun nitty-gritty stuff, how about if you tell us a little bit about yourself? How did you get into AppSAC and what made you um kind of go in towards mobile? I know you've been mobile focused for a bit now, right? Yeah. Um I started out as a developer like you know three decades ago. So uh after about 15 years I got an opportunity to start uh to basically go into the u application security space. So I started out in the web world and then slowly I migrated to the uh mobile apps world probably around uh 2018 or 2019 and I've been doing mobile apps uh mobile apps ever since. Awesome. Um yeah I know we've been partners in a couple different roles. Uh so great to have you here today. Uh appreciate your time. Um just real quick kind of what we're going to cover today uh for those listening in is we're going to talk about a little bit about um Warner Brothers Discover Warner Brothers Discovery uh and you know how they've designed and implemented their approach to evaluating evaluating risk in their mobile apps. Um they have hundreds of them. Um so CV is always trying to figure out how does he provide the right level of security investment based on the risk of those apps. Um so that's what we'll be talking about. Before we get to that, one more thing. Uh, our icebreaker that we always like to do is talk about your passion. Something outside of work. Um, so for me that's very much cooking. I love to cook. Uh, I love shopping for it, finding ingredients, um, preparing stuff, spending time with it, and then obviously presenting wonderful, great food to family and friends. Uh, so outside of work, like that's my passion. Can you share a little bit about what you're passionate about? Oh, sure. So I live very close to the Washington and Old Dominion Trail. You know, it's right behind my house. So I like to go biking, running, and hiking. And you know, that that's my passion. So whenever I get any free time, I like to get on my um my bike and then start biking. So you know, it's a big um like uh 64 uh 65 mile uh W trail. So I I've done it a couple of times already. So I live around the 30th uh you know 30 30 I live between the 30 and 35 uh mile marker. So sort of in the middle. So on the on the west side I can go to Persville. That's about 20 miles. On the east I can go all the way to uh I think Sherlington. So it's a very fun uh bike ride especially when the weather is nice. And then, you know, once in a while I also try to go running, although I'm not very good at it. I'm trying to get I'm trying to get in a better physical shape to be able to run um at least a half marathon in the next six or seven months. So, that's pretty much that's my passion outside of work. Awesome. Road bikes or mountain bikes? Uh in between gravel bikes. Okay, got it. Uh yeah, we'll have to talk a little bit more. I was I was in the bike business for 15 years and I used to I used to race bikes when I was very much much much younger. Nice. Thinner. All right. So, let's jump into this and uh let let's figure out what Warner Brother uh what Warner Brothers is doing today. So, when you talk about um business risk, right, for all these mobile apps that that Warner Brothers has, how do you quantify or categorize the risk? Um right how do you make it a cornerstone of your of your security investments? Right. Yep. So uh the business risk we define by certain uh several key elements. Uh the first one obviously is the data sensitivity. We include uh the handling of PII uh financial data view analytics etc. And then the next uh area is the uh application uh context. So this refers to the scale of the user base and you know Warner Brothers Discovery is a global uh corporation. So we have uh content that is specific to geographical areas etc. So uh so the scale of the user base and the global distribution of services is quite important to us and after that we have the technical risk this involves the uh you know vulnerabilities in the authentication uh API integration third party components and obviously device permissions and then given that we are spread all over the world uh we're going to be subject to various compliance requirements uh uh you know that are going to be specific to the geographical areas and then also the data protection regulations and lastly the organizational impact. This covers damage to potential damage to the uh brand reputation uh revenue impacts from breaches and organizational disruptions. So essentially these risks are quantified and categorized to basically inform us about the security investment decisions. For example, our risk assessment framework uses weighted risk categories to generate risk scores and then we use the risk scores to basically inform us as to where we need to uh turn our focus and attention to. Oh wow. Like how did like that framework how did how was that design like what about the apps kind of built out or helped you build out that framework? So we started know we started with our inventory of apps and we looked at uh the ones that were uh used most heavily and then we basically started to look at the volume of the apps and then we started to classify them based on uh volume of the apps and then um you know if the apps have any kind of uh in-app purchases uh uh subscription different subscription tiers etc. So that's how we started to uh build our uh framework. So uh we have quite an exhaustive list of categories and attributes that we go through to determine whether an app is essentially uh you know uh high risk or medium risk or low risk. So that's basically what we do and we also use the uh MASVS uh MASVS standards to uh help us with the determine the category scores with the individual weights and then we calculate the base risk by summing up all the category scores and applying an MASPS multiplier to uh adjust the final risk. So this framework is consistently applied across our app uh portfolio. Uh and then we incorporate uh expert input into uh generating the actionable risk scores. Wow. That's awesome. Um so with those risk levels like what might trigger different I don't know securities tools team engagement like what do you have in there that that makes you do more right so as I said um at a high level our risk different this risk levels trigger specific security activities tools and engagement for example the high-risk categories uh where we made uh we make significant security investments in this uh high-risk category. So we do regular monitoring alerting and then we do annual semiannual type assessments and also annual pen test uh and also we do continuous uh assessments of these high-risk apps. We use the uh NoSQL platform to do uh uh continuous assessments of these high-risk apps and then we also use uh the uh uh workstation to do our uh sort of ondemand and then you know sort of semi semiannual assessments and we also conduct uh pentest as as necessary. And for medium risk apps uh we go through some periodic monitoring and assessments and then quarterly sort of and then you know again the medium risk apps also go through continuous uh assessments through the platform and then for the basic risks you know again same things uh same parameters hold true but uh you know we go a little bit uh easier so you know on the uh on the workstation assessments and also pentest we we're not as rigorous uh as with the high-risk or even the medium risk. All right. I think I think you were kind of getting towards this, but like what's an example of a security measure that you that you apply to high-risk uh that's not or a high-risk app versus a low-risk app? Yep. Great question. For example, for high-risk higher risk uh applications, we what we do is um the yeah, for example, the high-risk uh applications undergo a comprehensive suite of security activities and then the the assessments uh mainly the assessments are more frequent. Uh they uh uh we do quite a few um uh uh automated assessments are essentially done um frequently uh anytime there's a code change or anytime uh anytime anybody makes a code change in the in the repo. Uh and also if whenever there's a major upgrade uh we go through the uh uh workstation assessments and we also try to do u uh a manual penetration testings at least uh once or twice a year for these high-risk assessment uh for these high-risk applications and then it's basically the increased frequency uh more than anything else uh for these high-risk assessments. Uh, okay. So, I'm guessing like one of your large streaming services that that recently went through or announced a brand change. I assume that's one that you kind of pay a lot of attention to. Oh, yes, absolutely. Correct. Yes. So, um, what about a unique risk like um what's unique to Warner Brothers you have to manage that other than the you know the normal risk such as authentication authorization is the content. So the content is a extremely important intellectual property for us. So we make sure that the content is not uh the content is protected at all costs. We make sure that the content is encrypted. you know it we ensure that the content's not you know downloadable or you know people can't uh download the content and also we need we make sure that the content's not sort of duplicated or pirated in any way in in any way shape or form and also we make sure that the uh subscription tiers that the uh customers uh opt into are maintained. So these are some of the uh high uh these are some of the unique categories of risk that we see at WBD that we protect against. So a lot of copyright obviously right with the content you guys are doing and sounds like privilege escalations. You don't want somebody paying a $5 subscription and they're getting $25 worth. Correct. Yes. Awesome. Okay. Um, so I know you talked a little bit about about us and and the solutions um that we have here, but how are how are you how are you managing, you know, automated assessments versus manual reviews uh for those deeper penetration test and like I I hear a lot of our customers do penetration test obviously we do penetration testing as well but um with that second part like how much time do they actually give you for pentests? Right. So yeah, continuous assessments, manual reviews. So um what we do is uh with with penetration testing, we usually we typically get about uh 2 to 3 weeks uh depending um but we augment that with the now secure workstation assessment. So that's been very useful to us. So uh we depend on the workstation quite a bit because we are able to uh actually install the application on a physical device and then uh run the application through from a user standpoint and then uh the workstation does the uh uh so it it it goes through its uh built-in scripts etc to determine uh the vulnerabilities and then provide a results uh provide results for us and based on the results that we get from the platform and the and the workstation. We're able to sort of uh narrow our scope of penetration testing and focus on areas that we feel are uh sort of we try to fill the gaps with the penetration testing from uh from the reports of the workstation and the uh uh platform. So we find that a couple of weeks is uh good enough for us with the reports that we get from the automated testing and the uh workstation testing. Does does that two week does it ever um does it ever cause friction or kind of your teams are are ready for that and they know that hey security's going to step in here and spend a couple weeks with our app. uh I haven't found any friction so far because we tend to do our uh workstation assessments and penetration testing sort of in parallel. So um so you know we've spent the first uh half not even half no first 10 15% of that time with the workstation assessment. So once we complete that assessment, we have we'll have a pretty good idea as to what we need to focus on and then you know so uh it's not been that. So we don't typically advertise that as a pentesting although pentesting is noted as a separate category. Uh but um this sort of uh approach uh you know this hybrid approach allows us to allow that allows us that flexibility to be able to uh produce results within those uh sort of uh two weeks. Okay. Um All right. So this doesn't have to be about now secure but like technical capabilities tooling enhancements you've gone through obviously you you've implemented you know these risk tiers um that Warner Brothers is using but like what was there anything that was really impactful that helped you achieve success with your risk evaluation or your or your investment in mobile apps? Yes absolutely. So uh the technical capabilities you you know the the tooling that we have and you know OSM OASP uh MASPS and the MASTG uh those are very good resources for us but the one transformative paradigm u process shift for us is the shift left paradigm. So what I mean by that is that uh we have been able to integrate the automated um uh assessment automated scanning into our development pipeline into a CI/CD pipeline. So you know we the benefit of that is that we get to see the results uh throughout the development cycle before it goes into staging or pre-production. So most of the vulnerabilities are going to be addressed before we get to the uh staging uh staging or pre-production environment where we start working on the workstation or the penetration testing. So the shift left moving this uh automated scanning process into the CI/CD pipeline has been an in incredible uh strategy for us. Uh so effectively what it does for us is that you know we are going to be efficient in re resource allocations and then obviously since the uh automated scanning uh provides a whole bunch of uh findings that are sort of low hanging fruit that developers can address during their uh development cycle. So you know it's and then you know this contributes to the fast to faster development cycle. So the shift left integrating our uh automated scanning into the CI/CD pipeline has been transformative uh for us. That's wildly cool. How did that go with the dev teams? I know um I've had many partners that similar size and uh sometimes I'll say there's a little bit of push back to get into pipelines that people don't want security in there. Um so I'm just wondering how it is with you. I've seen ones where it's hey let's start with three or four good really good teams and show them that they can have success and then get the other ones to come along like how are you handling that or did you just handle it all at once? So uh some of the apps were already in the pipeline when I joined. But what we're doing to encourage that in fact that's a great question actually. What we're doing to encourage that further is that we're starting to to uh uh we're starting to approach dev teams uh to uh and we're starting to uh do some brownbag sessions to basically inform them as to what it is that we do and you know and then uh emphasize the benefits of integrating their application uh pipelines into this process so that you know it is going to be uh useful for them in the long run because they'll be spending uh less time fixing the bugs in the uh final phases of the project whereas you know they can build this uh remediation into their uh you know project plan from the beginning. So uh there's not been a whole lot of friction but you know this brownbag sessions that we are planning on doing seems to uh seems to resonate well with the development teams that have spoken so far. Yeah, it's a really cool way to do it. Kind of show them how better their lives can be if they just give you a little bit of help. Exactly. Love it. All right. Um, so we're about to I think we're about to wrap up here, but like how do you measure how do you measure success of the approach you're going down? Like are you measuring it? Are you are you doing KPIs? Um, are there any certain metrics that that you're looking to track? Um, you know, and you know, as you go through this, have you had to change anything? So the main metrics that we try to measure are um you know the meantime to remediate vulnerabilities. So we like to see a gradual reduction in uh financial findings and this is a crucial indicator for us. So this basically shows that the vulnerabilities are being addressed more quickly reducing the window of opportunities for uh a potential exploit. And then the uh we also uh measure the uh reduction in the severity of the findings. For example, uh you know uh we tend to strive towards uh zero critical vulnerability findings. And then uh you know as they represent the most immediate and severe threats to our application and then we on a monthly basis we try to uh we we monitor the number of high and medium se uh medium uh severity findings and then we basically aim to we aim for a consistently downward trend. So uh and of course the we measure our success with the MASVS compliance limits as well and then uh you know and also finally the security investment efficiency. We are looking at how our broader security efforts align with our tangible risk reduction. It's you know it's less about the individual tools and more about understanding whether our overall approach you know in terms of how we allocate resources prioritize incentives is actually moving the uh the needle on key risk indicators. So uh these are some of the uh measurements that we uh look for to uh basically uh determine the success of our program. Awesome. How long have you been there now? Uh, a little over six months now. You're getting a lot done in six months. That's awesome work. Um, so that was it for me today. Um, really good seeing you. Uh, are you going to be at a black hat? Maybe. I'm sorry. Are you going to be at a black hat this year? Uh, black hat probably not, but Defcon most likely. Yes. Okay. So, we always seem to run into each other at one of these shows. So, yep. Looking forward to maybe we bump into each other out there. Um, but I really appreciate your time. Thanks for thanks for putting up with my weird questions. I know these are all great questions, by the way, and I'd love to, you know, this was a great opportunity for me to present what we do at WBD. Awesome. I appreciate it. Thank you. All right. Thank you. [Music] 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 performs 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 assigned 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. [Music] Hello and welcome to your MARM minute. I'm Alan Snyder 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 uh 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 end points, the number of third.