Hello and welcome to Nowhere Connect. We're here today to talk about the connection between mobile app risk and business risk. And I'm extremely excited to have uh two folks join me who are in industries that are incredibly sensitive. They understand this risk really well. And equally importantly, they've been dealing with and uh solving this challenge uh for years. So, they're going to bring their experience to bear to help everybody understand uh how to address it, but also to look forward in terms of we'll have some fun discussions around what's going to happen in the future. So, with that, I'm excited to welcome uh Matt Anderson from uh Humanana and Garrett Schumacher from Valentium here to join me. So, let's uh get started. I'm going to toss it over to you guys to introduce yourself, maybe get a little background in terms of just how mobile apps are used for you, what they mean, just kind of what the uh just how they fit into your uh environment to give the audience a bit of a sense of your perspective. So Matt, why don't we give a start with you? Sure. Matt Anderson, um associate vice president of product security here at Humanana. And you know, we roughly secure a billion lines of code. And most of the ways that our members and associates interact with our core business is through uh our mobile app ecosystem. And so that's really important for us to serve our members and deliver um care and other services back. So um obviously when we're dealing with health data and very other sensitive data, we've got to take mobile app security very seriously and we've got to understand the life cycle of that data all the way from our core infrastructure out to that mobile experience. And so uh excited to talk to you guys today. And Matt, before we move, It's not that you had a rough night last night. It's you are security conscious with your uh glasses. I'm trying to make it fun. I'm trying to make it fun. But yes, very very security conscious. Yes. All right, Garrett, how about you? Yeah, my name is Garrett Schumacher. I'm the business unit director of product security at Valencia Medical. Uh we are a contract development and manufacturing organization. So we will build a full medical device system and get that concept to market uh for someone manufacture that post market. Um and uh the way that we use mobile apps in those is might be something to control a medical device or to gather data connect something to a backend. Um so Valencia medical is building uh mobile apps for other people other manufacturers every day. Um and then my team is overseeing the security of that as well as offering just external consulting and testing and architecting services um to other manufacturers as well. Yeah. And so it's safe to say that mobile apps in the context of what each of you are doing for your respective organizations, it's not just protecting the integrity of the data for the organizations you're working with and supporting. It's the consumer as well. And it's their uh medical and health information, right? Absolutely. Absolutely. Yeah. Patient safety is first. Yeah. I want to drive that home because to me that is that's a huge responsibility uh to make sure that nothing goes wrong there. So let's start with um just what is your um you know when you look at mobile apps what are the risks that you worry about? So let's uh start with you Garrett. Yeah, I mean so as a manufacturer uh there's a couple of regulatory concerns and considerations here. So we have safety risk as defined in uh in ISO standards somewhere FDA and other groups um other regulatory groups in across the world. Their entire goal is to take away quality and uh safety assurance from the manufacturers. So a manufacturer has to say hey FDA you know can I submit this device and and sell it on the market uh get this in the people's lives um and and the FDA is going to take the burden of of quality and safety away from them by saying we will validate whether that is safe effective or not and if we say it's it's it is then now you can sell it. So there is the good old safety risk and that's that's what's paramount here that that you were just mentioning is that uh patients lives are at stake and that comes fundamental to everything we do every day. Um so you have that aspect and then there is standards and per these same regulatory groups there is security risk uh which is a whole separate risk. So you can have security events lead to safety risk you can have safety events lead to security risk vice versa. Um and security risk though what I like to think of it is then the impact. So beyond patient safety then you have patient privacy you have which could lead to um you know uh violations and penalties especially if you're in Europe to a manufacturer. So now we're talking about reputational um and financial impacts and and so safety risk and security risk are kind of the two worlds I live in uh for medical and the security side and both the safety side can have then these drastic business impacts and we've seen groups uh manufacturers that do not get approval and so now they're they're not generating revenue and they either are losing out on revenue that they could have had or shut down entirely. Um so yeah, lots of different types of risk and then impacts uh that can happen in this world. Excellent. And Matt, mobile app risks that that worry you. Yeah, I mean if you think about our our core business, it's really requires a lot of exchange of very sensitive data across boundaries that we may or may not control. And so if I think of you know um a traditional app I can go you know look at that server or I can go pull down that container or I can investigate kind of all the different things associated with it. When I think of mobile app app risk I have to do the best I can to send this thing out into the world on this device that I don't control that could be in various states of um you know security or not security. It could have other different problems with it. Then I have to trust that the thing that I'm building can still kind of talk back to the mothership in a secure and protected way. And then the nature of my business assumes that I have this trusted relationship, this relationship of trust with the consumer to say, "Hey, look, I understand that this ecosystem that I'm engaging in uh is inherently secure and that I can trust it because I'm putting a bunch of sensitive information into it to actually facilitate um that transaction or that support." And so, you know, unlike a traditional app where I can I can go put a bunch of stuff around it, I got to make sure that this thing gets right when we get it out the door and I've got to be able to uh have a very high level of assurance associated with it. So, for me, it's all around the data risk uh and that sense of trust with our consumers and our members. Got it. I'm going to poke on the data risk piece a little bit because I think to me that's such an interesting topic. what we see and I suspect you guys are exactly in the same thing. Many of the market our customers prospects it kind of almost comes down to the same thing. Where's my data going? What data where's my data going to? What data is going there? And is it going there securely? So I'm curious to get a thought when you go through and look at mobile app risk. Where does that rank in the priority of things that you look at? I would say that's number one, you know, in terms of the data risk. Yeah. For us, it's all about the data, right? You know, if we were um not to u minimize other industries, but you know, if you have a mobile app game, um no one is ransoming your scores, right? no one is is stealing your points or your credits and then you know ransoming them in public or trying to damage your brand. Sure, there could be some issues. Um but uh a massive data breach or leak or some kind of insecurity um that involves real data that you can't change by yourself, which typically is PHI. Uh that's where my head goes first. So Garrett, where does uh where does that risk fit into you? Is it number one? Is it somewhere in the stack? So where does data rank? Yeah. Um so even in the medical devices uh integrity is usually the most important thing that we consider and ultimately controlled data um command request response that is still data that you're communicating from one device to another usually originating in something like a mobile app to a medical device. Um so in general data integrity data protections is foremost. Um um but now if you just think of general data information PHI um in medical it might be somewhere in the middle because uh patient safety is usually not directly impacted by let's say the disclosure of information. It's not good but I'd rather make sure the device is functioning correctly before data is disclosed in terms of priority. Um, however, another world I work in is genomics. Um, and genetic data, like you just mentioned earlier, Matt, is it's unchanging. It's PHI. It affects you and it affects your posterity for many generations potentially. So, in that world, um, genetic data or data protections are paramount. They're first and foremost. Um, still maybe from an integrity perspective, but from many perspectives. And why I bring this up is that even nowadays there are DNA sequencers that you plug into a mobile phone. There are mobile apps that generate analyze and mess with your genetic data. So um it's still relevant to mobile apps as well. Got it. So so along the data trend, right? And what I find fascinating about this is static analysis is just that it's static analysis. It's not going to see data in motion. So many of the issues around data leakage, be it over the wire, the local devices, other things, the only way to really fully be comfortable that you've addressed it is to actually run the app. And so let's dig into the data piece a little bit more because Matt, you brought up something when we were talking earlier that I think is worthy of going deeper in and that is the third party components and the third party components that have access to data in the mobile apps. So do you want to maybe go into a little bit about when you look at the third-party components what concerns do you have and then what is it that you guys are doing to address those concerns? Yeah, great question. Well, I think first of all, you know, you don't want to depend on any one tool, team or activity, right? And so I think, you know, for us, we try to ensure that we're using a defense and depth approach. And then you're dealing with a physical device and that physical device exists in the world in a way that sometime is non-deterministic. And so if I'm using a suite of SDKs or APIs that either have some injection of functionality or can be dynamic in nature, I actually need to run through that test. There's nothing that really beats real world testing. And then in addition to that, we use other feedback loops throughout our secure SDLC to ensure that we're getting the full feedback of it's not just one person that have signed off on it, but there's a a an orchestration of folks who are working together to build this secure mobile product. And we do that in a variety of different ways. But one of those is making sure that we're not just using static analysis that we're using dynamic analysis. And then we're also testing the APIs. And then we're also even doing other things like bug bounties or more offensive kind of worst case scenarios in terms of what happens if and then we go test that. Yeah. And then Garrett thoughts on components third party risk. Yeah. Um, so I usually think about especially when we're in the earlier stages of new product development that that there's kind of like you know you do threat modeling and risk assessment to identify and assess and manage um security risks, design risks, sorry, design vulnerabilities. Uh we do a lot of testing whether it's static analysis as well as dynamic analysis um penetration testing all the all the forms of testing to identify and assess implementation vulnerabilities. And then we have this whole other um subset of issues related to third-party and supply chain risk. Um whether that's the usage of third-party software and components uh which we might manage through things like software bills and materials. Not just that, but it's one great way. Um we have other you know than vendor risk and and all that sort of spectrum. Um, and you even brought up something earlier about, okay, then we have now artificial intelligence and all these other kind of things that are being added into these components. And when you add someone else's components to your component, um, your software, you know, you inherent the risks that they've built into their product. Um, you don't necessarily always get um, insight into that. So, it's kind of one of the big the big things that we're trying to solve and work on right now is this whole concept of supply chain risk. Got it. Well, yeah, just just to touch on that just real quick, there's we recently discovered something in which our testing came back good, but some external data off of the vendor or the platform did not. And so I think one of the things that we're doing now is we're also incorporating both the supply chain risk from software supply chain perspective but also how trustworthy are some of our partners right and what what can we do about it in some cases we we can influence them uh and we've been successful in that and in some cases we may need to find a different partner yeah I I one comment what I find interesting about this is the developers that are adding third-party components don't really have a good way to know the security posture of that component. And in many cases, until after it's been added and gone through and been tested, right? There's not a good way to test a component until after it's added to the code, right? Most we don't see most people testing those components in advance. I'm sure some do, but most of the market does not. And then you get into this catch 22 of once it's been added to the code and I find an issue, then what do I do? because now it's actually work to do it to remove it or to change it. Uh and we also see the fact that there's no real providence of understanding of who built it with this issue with push bush with was a Russian SDK that was marketing analytics and they made it look like they were a US-based company. So it's a really interesting uh challenge but that I'm gonna after my little silk there I want to jump into the Garrett you mentioned it with AI I find it fascinating because I think many of these third party components are going to have AI. You're going to add AI into your app. So, what do you think AI is going to do as it relates to mobile app security? Make things easier, make it harder, make it more complex. Just what do you guys think? Where's what's the future with AI and mobile apps? Yeah, I mean it's all the above. So, I I like to think of it in uh for our use case, it's kind of there's two. It's AI in medical or AI on medical. So if it's it's on right, we're using it to improve the efficiency and capability of maybe our developers or even like our our product security team might be using it to improve our our documentation so that we can just become more efficient. Um I think we've seen a lot of this these discussions happen across the industry the last couple weeks of efficiency driving um AI driving efficiency changes and considerations, you know, top down. Um and then if you have AI in that presents a whole another you know risk category and and set of issues where um you know is that a fixed model or a changing model in the field and how does that then you know all those impacts we were just talking about with patient privacy data PHI um trustworthiness and then uh how how you know how do we vet such uh the third parties that these things come from uh you know do we know um so it it does do all of the above. I think it will make our jobs, our lives as developers and security engineers or just other engineers easier. Um but obviously we're then seeing that the sophistication um I I just came back from the health ISAC conference a couple weeks ago and there was this great talk about how you know foreign actors are using AI to um get a lot of jobs here in the US and to do certain things and and AI is fundamental to how they're doing it. Also AI can be now fundamental to how we identify that and uh a lot of pattern based stuff that we can do to identify when someone is using AI for that reason. So I don't know Matt, what do you think? Yeah, you know, I I think the question sometimes is um AI this or that, but really it's it's coming. It's everywhere. And on some on some level there's a tremendous amount of opportunity and promise. We're already seeing really strong productivity gains from integrating AI into our uh development processes and even some of our business processes. But I think you know Alan you had mentioned a little bit around trust around supply chain. there are problems that we haven't solved in in the supply chain risk and we're just carrying those forward in AI and you know we don't always have assurance of what what data was the model was trained on where that data goes and then to some extent it's not always apparent where it's being used and so you know we talked a little bit about SDKs and some of the third party APIs um I recently discovered a vendor who on the surface would have not uh triggered any review or process but underneath after they had gone through all those processes, they began incorporating a lot of AI in a way that was uh novel and and not necessarily obvious. And so I think the big thing with AI is not whether it's good or bad. It's making sure that you understand where it's being used in the ecosystem. And I think when it works really well, it's going to change the way we work. It's going to you know, we're seeing the first wave of developer productivity, but that's going to now go to security productivity. It's going to be integrated into your SR tools. It's going to inter integrate into your sock. And so you have to understand how it's how it's working and then you have to understand you know again I always go back to the data how's that data being used and where is it flowing. Do you think that the development teams the security teams and basically the organization at large knows where AI is in a mobile app? No. No chance. Why is that is not looking the tools aren't there? Like I'm curious of what's leading to that blind spot. I don't know that the blind spot is an interesting term. It definitely is a blind spot, but it's not it's not a mobile app question by itself. It's AI is in our SAS tools. Uh AI is integrated into Office and Windows. AI is getting integrated into browsers if you watched some of the recent announcements from Google and OpenAI. Um, so I don't know that it's necessarily a blind spot as much as it's the velocity of change and the deep integration of the technology in places that we don't expect. Yeah, any thoughts? Yeah, I I think Matt nailed it on the head um earlier when he said that we we especially in in my world of medical device security with guidance only coming out in 2014 16 and most recently 2023. Um it's a pretty new concept, new field, new requirements. Um that's also drastically changing and Matt mentioned how uh we have some issues that we've had for a long time and we're just carrying them through to this uh new world. So, um I I think that as Matt said, the pace of change is the biggest concern there. Got it. All right. So, I want to change a little bit because I think we've talked a lot about the risks. You know, it's all about the data, what it, you know, what data is present, where is it going, who has it, the third party components, things like that. Let's talk a little bit about the solution, right? And I think to me both of you guys have alluded to it um in terms of defense and depth which to me talk a little bit about if you would uh to address that uh and obviously to the degree you could talk about your program because to me it's an ABSSEAC program that like defense and depth is not an accident right you guys have thought through what to do when to do it how to do it So maybe share with folks how you think about implementing a program to address these issues. So Matt, why don't you uh take the lead? Sure. You know, earlier I mentioned integrate into your product team's flow. That'd be the first thing, right? Um security should be baked in at every phase of that process. And you know, uh we talked a little bit about catching some of the supply chain issues earlier, right? If if we have essentially some security practitioner who's working through the ideas of that product, who understands where they're going and what is trying to happen, that's a really good way to catch it early. The other thing I would say is as you're as you're moving through it, try to both reduce friction, but then automate gates. And so if we when we automate gates, we reduce that cycle time to get feedback on is it good or bad. And so one of the things that we've done a lot of is trying to make sure that we have education tools and capabilities folks who are embedded in partnering with our product teams. And then we put automated um gating or checking in place so that it's not dependent on humans doing something right. And then look at the total cycle time of delivery because if security becomes too uh provides too much friction then people will try to find ways around it. And so we try to make uh make it as as much as a partnership as we can and then we we go back to machines making decisions on on good or bad and that takes a little bit of the opinion or the personality out of it. Right now Matt, it also sounds like in addition to the automation piece, you'd mentioned bug bounty, you'd mentioned uh I think uh manual pen testing. So so you're doing more than just the automation, right? In terms of that defensive Absolutely. So we try to use the best combination for machines and the best combination of human brains and when those things are working together uh that's when we get the best results. Got it. And Garrett, when you look at kind of how to solve the problem, right, how do you guys approach it? Yeah, I I really like that answer in terms of um you know, new product development, having the appropriate design and architecture phases and having um our our testing and then good product labeling, you know, communicating with the end user, the whether that's the hospital using the product that that we're helping to build or whether that's, you know, ultimately a patient or or whomever. Um and all of those procedures, the third party um software. Yes. But then also I think one of the biggest things that we're trying to get into is then okay being ready for what if something does happen because we're we're never going to get products out that are 100% secure. Um, and so if we have appropriate ways to patch and update and fix issues in the field and then to respond to issues and disclose those issues and report them to everyone and do the proper things. Um, and that's all got to be reinforced by all all the typical stuff, your policies, procedures, but training. I mean, training is one of the biggest things and that as Matt alluded to, that that is the human element, right? And if you don't get that into um developers and engineers and you properly train them and then have good communication pathways um you know both directions from developers to the product security team um so that's how that's the only thing that I could add to Matt's answer. Yeah, it was perfect. Yeah% on the education communication part. That's yeah I that's exactly where I was going to go because I think yeah Matt you brought this up before. So how do you do all the things right you address all the risks we talked about we do the defense and depth and absc program how do you do that and have the developer excited about it how do you how do you make that work you know I think for us um we have a internal security champion program uh that we try to make fun um we try to use real world stories uh in terms of of how things can go wrong uh and then we try to again make that experience um much cleaner and much more effective to understand what's happening in their in their world because at the end of the day they're trying to deliver on business functionality and they're trying to deliver a great experience and when we can um we can be both the good guys and the bad guys uh sometimes as security practitioners and so I think being a little empathetic to kind of what that looks like and also being able to clearly articulate the why uh Garrett mentioned some of the remote IT worker threats that we're seeing some of the other different things that AI has used in kind of a malicious Okay. Sometimes it's just about sitting down and talking through like, hey, here's what's happening in the world. How do we partner together on a shared outcome of creating a great secure product experience for the folks who are using our apps, right? And Garrett, how do you how do you find the how do you make the developers life better so they're excited when you show up? Yeah, I mean, just uh Valencium has three core values and one of them is humble charisma. So, just be that person that you want to work with. Um, so I kind of take that to our core and usually 75% of the time we're working with external developers, not our internal development team. That's our biggest um uh customer base. So with that, I we we offer training and we're trying to just make it the latest greatest um you know, online modularized um with a hands-on kit so that it's it's very engaging. Um and it's not just, hey, go watch a video, watch a look at the slide deck. it's um you know here's little tidbits and pieces reinforced um with hands-on learning and and assessments. Um so that that's one way that we're trying to make it very fun and engaging because it's one thing to say there's this issue right this can be done. Um it's another to say hey do this right and now now you know does that make your assessment of how difficult or exploitable or or if you want to even go there in terms of a lot of people use likelihood is something to say oh that that won't that'll never happen. Um someone does it now they better understand it. So I that's I I tend to think that and then also um Matt in your introduction you brought up that we like to go to the what if the worst case scenario. So, I think actually walking through some of those things, doing some of that incident response simulation, you know, having days or a day where you can sit down and do those that are really well played out. Um, it can be both fun and extremely educational cuz cuz you've been there, done that sort of. Yeah, absolutely. Table topping that out, especially with a red team or a blue teamer, makes it real for the product team. And if you can invite them in to those exercises, it just builds a a great bridge and sense of trust and folks working together. So that's the perfect jumping off point as we bring things to a close. Any recommendations for the audience in terms of definitely do this. And on the flip side, definitely don't do that. So what final words of advice would you leave the group with around how to address mobile app risk so that it doesn't become a business risk? Yeah, I would say uh back to the whole secure development life cycle, the total product life cycle kind of concept. Um you know use standards and and uh best practices out there to threat model and do risk assessment and do the design and architecture. do the testing, use the automated tooling, do the static analysis on source code, but also do you know static and dynamic analysis using tooling like now secure um test according to the OWASP, the community standard around mobile application security. Um and and it's going to carry on into that third party software and risk assessment um and and then ultimately have the process and structure and policies around that to guide it um with the training and communication pathways to reinforce it. Excellent. Yeah. And I would say if you can do anything, you know, there's probably some folks who are who are listening or watching and they probably have a very small budget, a very small team and and at first when you first start out, it may be overwhelming, especially if you're coming from a world in which you're used to just looking at web apps because mobile is a very different space and sometimes it can be a little intimidating. So if you can establish good education and good communication and invite those devs into the the tooling or processes with you, then you're you're scaling your team, you're scaling your voice and you're you're turning folks um who may be outside of your core security team into advocates for security. And so I would say if you if you have limited budget and you have limited other things, focus on giving them some great tools and giving them the uh the education and build that bridge. And then I think um you guys can go be great together. Humanize it. Yeah. Excellent. Well, thank you guys both very much. I think this will be very uh helpful to folks and we uh sincerely appreciate your contribution to the community and your time today. So, thank you. Thank you.