 Hello and welcome to OWASP and CSA IoT impacting medical security. My name is Aaron Guzman. I am the product security lead at Cisco Maraki in charge of all things hardware, firmware and IoT security. I also lead the OWASP IoT project along with sub projects co-chair for the cloud security Alliance IoT working group. I've co-authored the IoT penetration testing cookbook. I'm a technical reviewer with packet publishing and no starch press. Practical IoT hacking is the latest publication released in March of this year 2021, although right on its heels is bug bounty boot camp which is soon to be released in the coming months. In practical IoT hacking, you will find some medical device oriented attack techniques for network protocols such as DICOM. So make sure to check them out. I will promise you, you will learn a thing or two. So really happy to be here, you know, presenting on OWASP and cloud security Alliance. I will first, you know, talk about some of the hats that I wear multiple depending on the day. And we'll get started with OWASP for those who don't know. For those who have who are familiar, you may have come across OWASP if you are trying to remediate a software security vulnerability. But for those who do not know, OWASP is a an acronym for open web application security project. OWASP is a nonprofit started in, started up in 2001. And it's actually the 20th anniversary this year. So it's a big milestone. OWASP has great, very smart experts from all paths around the world. There are regional and global events. And what I mean by events is conferences and hackathons. So there's global apps like USA's, Europe, APAC, Latin America, but also regional and states, you know, chapters, right? Like apps at California is one that is near and dear to my heart and one that I help organize, you know, pre pandemic at this point. Essentially, OWASP is an authoritative source for software security. So if you get a chance, check out the OWASP flagship projects. Won't be a waste of time. You might be surprised and find anything or two that you didn't know before, whether it's a piece of knowledge or a tool or guidance. So I'm here to talk about the OWASP IoT project Internet of Things. This project was founded in 2014 and designed to help manufacturers, developers and consumers better understand IoT security issues. And now the idea was to kind of cast a net wide and apply our knowledge and education, you know, to as many as many paths and areas and audiences. So that's the way we've kind of approached some of our projects with projects or tools and guidance and best practices. And when you think about medical device security, right? Medical device security, you know, the platforms that they run on it could be embedded Linux, it could be Windows, it could be bare metal, meaning, you know, microcontrollers without operating systems. And software is controlling, right, is the crux of controlling that the functionality of those devices. And what the IoT project is, is, you know, some of the projects that we work on is, you know, to help the security and the awareness aspects of, you know, developing and deploying, right, and building. So we've been cited in numerous publications and information security standards. The most recent one that I've stumbled upon was the FTC had cited us for building security into Internet of Things in 2021 to our surprise, which is awesome. We collaborate with alike organizations, whether that's Anisa, Cloud Security Alliance, you know, other other companies, you know, around the world. You know, we're looking to collaborate more GSMA, other folks in the space, especially in the medical, right. We'll talk about, you know, some of the, the work in the medical space, obviously. So the project, we've broken it up into a couple of different categories, namely, see, can understand that we'll talk about today, and also talk about the validation. And so, see, can understand, we have a couple, couple projects that we'll talk through today, the top 10, the IoT top 10, and IoT go, and to make the IoT top 10 kind of more applicable for some groups. So we created a mapping project and map them to a number of sister projects in the industry. IoT top 10, this is essentially our flagship project. It's meant to create the awareness and supposed to be, you know, top 10 things to avoid when building, deploying and managing IoT systems. And when we developed this list, you know, we have a methodology to which we use and, you know, we gather data from different sources, right, and we look at sister projects. And the theme was simplicity, again, casting that net wide to, you know, manufacturers, consumers. And the enterprise as well who are who are using these devices in their network. And we wanted to highlight, essentially, what are the highest priority issues, you should be aware of. Now the list isn't necessarily ranked from the most critical to the least critical. Although, from the prevalence, you'll notice, you know, the, you know, ranging from one how common and pervasive some of these issues are, and the impact that attackers can, can gain. And, and, you know, once exploit once exploited into an environment and when talking about medical that game could be someone's life, right. What is IOT go. I think it is a deliberately vulnerable firmware. And what we did is we based it off of open WRT and open WRT is, is and build system. And what build system is it makes it easy, easier, essentially to, to compile and build firmware. And it does that in a way right that's that's open source and which is why we chose open WRT. The other reason why we chose open WRT is it's compatibility with all devices that you may have. Let's say laying around old routers or old networking equipment or, you know, devices that are compatible with open WRT and give you that flexibility to flash IOT go and to practice finding and identifying and exploiting vulnerabilities within firmware. So when we developed IOT go we incorporated as much as we could have the IOT top 10. And when I say as much as we could. I mean, everything aside from the hardware and, and kind of process base well actually everything aside from the hardware and that's that's actually in our roadmap as well. And so what we wanted to do is, is use this vulnerable firmware as a you as a learning platform for professionals researchers software developers. And so who is looking to get into firmware hacking IOT hacking and and give them that playground to let loose and to practice and to level up and gain that confidence. If you've ever gotten started into IOT hacking, I'm sorry, firmware hacking. It's, it's, it's a tall, it's a tall order, right. If you have no previous exposure or visibility. And this is meant as, as a platform to help enable folks, you know, get more confident and familiar with the types of vulnerabilities that are within firmware. So I'll show a few screenshots. Here's the login page. By the way, this is IOT go is up on GitHub. If you want to have a play, you're more than welcome to. Here is the secret developer diagnostics page. You'll find these somewhat common or uncommon maybe leftover from debug code for from devices. Usually, right. It is not a good sign when you find these types of diagnostic pages that allow access, you know, by other means that you know elevated capabilities. So we develop challenges to, to walk you through how to find the vulnerabilities and a part of a roadmap is how to fix the vulnerabilities as well. What you see here on your screen is the back door for IOT go. Essentially a, a service that is running on startup. You can connect to that particular service and get root access. And practice post exploitation if you'd like. Meaning going from device to device inside of a network, or keeping it simple. Simple is always the best right especially when you're getting started. So here is the listening network services from NMAP. And you'll see the common HTTP. UP and P as well as a couple of services that run on high ports that are unknown, which might be fruitful if you poke at them and you find out what they're running. Who knows, you may get access to a device, you may exploit a vulnerability. So good luck. Have a play. IOT code is there, is there as a resource for you all. And we'll talk a little bit more of, you know, what, what you can use in conjunction with IOT code next. So our other category is validate and test. And this is validate and test and invalidating tests. We have the IOT security verification standard for more security testing methodology and bite sweep, which is a tool for more analysis tool for more security testing methodology was meant to lower the barrier of entry for IOT hacking, including medical devices right. So this is just could be used hand in hand with IOT go. And the idea is to enable more professionals or more, more folks who are interested in getting into firmware hacking and providing those guide rails and providing the guidance and kind of a systematic, you know, in a systematic way, all in, you know, one resource. And if you're like me, you know, you, you, when you get started in firmware, you're like, ah, there's so much going on, I don't know where to start this is this might be for you. And like any other methodology, right, you can jump from step to step. And what we've done is we broke it down into nine steps. Right. And the nine steps, again, depending on your, your scope and your expertise. And the foothold you may already have, you know, you can jump around as mentioned. We've went ahead and provided tool usage examples, walkthroughs, right, again, to be able to help and show and teach essentially, you know, the common techniques, the common tools. And what we've done is create a companion virtual machine with preloaded tools, vulnerable firmware such as, you know, iot go but also a few others that the industry has provided, and even some that have known vulnerabilities for, for products and manufacturers out there. You know, zipped up and, you know, trying to keep the space minimal. So again, really trying to try to enable more folks to get going and get some help with with firmware hacking and start poking around into, you know, iot devices medical devices right iot security verification standard. So is vs what it consists of is is three verification levels. And we have five chapters, or if you want to call them domains with the total of 138 controls, don't pay attention to the controls so much. But the aim of the project is to create a basis for for testing iot application software and their technical controls but also to develop contextual requirements for secure development and design. So you can use it as part of the hardware design for medical devices use as a set of product security requirements to be included into product requirement documents prds if you're a manufacturer. If you're buying devices you can use them for procurement of medical devices, developing medical device security training. This is the security posture of a medical device and provides a basis right to define verification levels based off of the medical devices risk. You know, today, there isn't, you know, a standard to help normalize, you know, the coverage of how well my iot device my medical device has been has been tested. There's potentially, you know, tribal knowledge or maybe there's an overview of a methodology, but this this this aims to plug those gaps and help clear the ambiguity there. And so we followed our sister sister projects within OWASP. The ASVS is for the web, the MASVS for mobile and the SCVS for software composition. I'll think about it like supply chain and building building software. This project is still, I'm sorry, is in release candidate stage. It's been a rough year. But we are hoping to get it out fairly soon for you all and we're just tidying things up. So we are open to additional feedback and contributors and we'll we'll get to how you can reach us later on. Some honorable mentions that that affect the medical device security, the embedded application security best practice best practices will previously released around 2016 timeframe. And we are doing a refresh with newer, newer techniques, newer guidance, different formatting. Right now we have a base set of seven that you see on the screen here with sensitive data management down to cryptography. Initially, we had 10. And again, this is still a work in progress. Right. And and if you notice Yachto and open WRT these are, these are very popular embedded build systems for for devices. You can see directly, you know, your medical device that you that you purchase, if it has a Linux operating system is built with one of these, one of these built systems here. And the hardware security testing methodology is something that it is that is a work in progress. And again, you know, kind of taking that that that step even even lower from firmware or actually stage lower. Where you have the hardware and let's say you need to pull the firmware and to find vulnerabilities and then exploit them. This hardware methodology testing methodology will help you in that endeavor, when you're embarking on those types of assessments those hardware analysis, the tools, you'll need to have in your toolkit. The techniques you'll have to keep in mind when to try which technique. And again, it's for those for those folks who again need that that guide rail a little bit of a kickstart or something to, you know, kind of keep you honest and reference as like hey, you know, I am ensuring I'm covering these certain areas for these vulnerable hardware debug interfaces, these, these you are these serial interfaces these J tags. So what do I connect to these. What do I do afterwards. How do I gain root access and gain persistence. So we hope to get these resources will be helpful to you all. But you might be asking, this is all lost these are all lost projects. Why is all wasp involved in iot and then hardware and then embedded. Well, the end of the day. Everything is software right without software hardware would not be able to function from where we're not be able to talk to the hardware the drivers right wireless protocols. All software zeros and ones right if you want to take it down even to the slowest switching hats now to my cloud security Alliance hat. Brief intro about cloud security Alliance, the global organization with a similar structure than a wasp free to join and participate resources best practices and events as well. I guess that the large the larger differentiator would be the cloud security certifications that they offer, and a wasp is does not offer such certifications they are 501 3C. Both great groups, I give 100% of credit to to both of these organizations, and where I'm at, without either these organizations I would have not had opportunities to edit books and write a book. So, keep that in mind as, as you're pondering whether I should get involved throughout this presentation. Cloud security Alliance iot working group. I've been a part of this group since the beginning and it was originally part of the mobile working group in 2014. When we spun when we spun off. We've also, you know, work with with industry regulatory and corporate and corporates as well, you know, from from the collaboration perspective and we've been lucky enough to be incited and RFCs and different standards as well. So we have a couple of screenshots there with one of our RFCs RFC 8576. We put out a number of different publications throughout the year specific to industries specific to the, to the enterprise right, and, you know, to two medical publications have been public have been released, and we're working on a third which will, we'll talk to talk about today. You know, with the collaboration in mind, you know, oh wasp and cloud security Alliance work together to release the secure medical device deployment standard. If you may be wondering so there's a lot of cross pollination again we're all saying the same thing, and we should all be working together so a few are in similar groups and you want to collaborate. Let's do it. Now the iot controls matrix. This is the flagship project for our iot working group is modeled after the cloud the cloud control matrix the CCM. There's 165 controls aimed at enterprise iot that incorporate multiple layers of connected devices cloud services and networking technologies. So we have 21 domains security domains, and that's ranging from asset management, like you have to know what you have to get started from governance, even legal down to vulnerability management and security testing activities, whether that is web application or hardware testing firmware bug bounties, even included so it's really holistic. So it should be a helpful resource for health, health wear, I'm sorry healthcare delivery organizations, and any organization deploying connected devices and their networks. So what we're doing out controls matrix is who want to glue the process policy infrastructure ecosystem controls with the device itself. And you know a part of that is you know the industry is changing we have you know zero trust zero touch provisioning, you know supply chain issues are, you know, I don't want to say at its height but it is it is up there and it is on top of everyone's especially in 2021 and the day in remote working now. Right and people are sending these appliances and the networks and these iot devices and they're just connecting to corporate environments and you know managing and you know the whole complexities that come with that. And so for the next version we're looking to not only involve evolve and refine our controls, but introduce a shared responsibility matrix. Taylor towards iot. And again to kind of expand the applicability, we create mappings to their sister projects, such as, you know, Anisa's iot, you know baseline security baseline and the variousness standards out there. And of course, cloud security Alliance projects like CCM as you may have noticed securing iot is not an easy task. I think medical device manufacturers must trust their supply chain partners and the supply chain partners must do their due diligence and that cascades down. Right. Even further to the enterprise and consumers, which they must trust the connected products that they meet minimum minimum standards and controls. So trust is obtained through, you know a series of questionnaires and back and forth the interaction with with each group, or each party, or some sort of trust portal that satisfies procurement requirements so when you're purchasing things. At the end of the day, right, given the complexity of iot and the scope. I think that there is not one size fits all solutions and controls must be interoperable was provide automation scale. And they have to be validated right there has to be, you know, internal and external validation to ensure these controls are are working, and that the lights flicker, you know the alarms, the alarms are going off when they should be. The ongoing project is zero trust for iot. And this this is really important for those medical devices that you may be plugging in and hey now all of a sudden they are paired and they are working. They are on boarded with, you know, again zero zero zero trust or touch I guess you can say. And, you know there's there's a methodology to the architecture in which you know we're wicked down from the onboarding the authentication and the authorization. And then how you monitor those types of devices and the different policies you want to employ. And you know, if there is a root of trust hardware root of trust, how do you leverage those for that kind of secure identity. Otherwise, you know if the identity could be tampered with. So could that trust right cloud security alliance medical device incident response playbook. So this project is to establish the best containment eradication and recovery practices for for each category, while minimizing the risk those practices have on patient care. So we've modeled this playbook after you know the NIST SP 861 R2. So we created our own kind of differentiators here in the sense of, you know, we're defining incidents in this context as a vulnerability disclosure and one or more a CBEs affecting medical devices within a health health care delivery organization inventory, or the discovery of malware ransomware or loss of availability of a medical device. So this might sound all too common. You'll you may have heard all the vulnerabilities reported for medical devices in the past. Or what about the novel want to cry a few years back, three, four years back now, which took down a number of hospitals and was devastating for some and cost cost lives. So it's supposed to be used as a basis as a starting point to incorporate into an HDL health care delivery organizations program. And so we've defined these seven clinical scenarios. And these clinical scenarios range on based on the, the types of devices that are being used. For example, number one would be, you know, if it's safe to connect from the patient and the network. Is it safe to connect from is it safe to disconnect from the network. Can the devices be shut down safely and remove from the patient is a disconnection possible. But with clinical impact. So we'll go through a couple of these or I'll just show you the, the workflow that example workflows again these will be contextualized or should be contextualized to internal processes. But what is always step one with an incident response right you can see, you can see the list here, right, the five phases. The most important one of the most important is, is to prepare. We've helped, we've helped kind of shape, you know, high level activities that that medical facilities can can employ, you know, kind of expanding on on some of these activities. You know, again, you have to know what you have so starting with inventory, classify the clinical impacts and the data impacts, what happens when, you know, patients are affected devices are affected. You know, a list of stakeholders, not only within the medical facility their health delivery organization but also with the device manufacturers and anyone else, but also, you know, backing up and monitoring, so on and so forth. So, check out the playbook we have some great details in there. So after preparing, right you have to be able to detect, analyze and contextualize. And within within this phase, you'll have to maintain a number of different initiatives and programs. What I mean by programs are your threat intelligence programs. Communication and relationships with information sharing and analysis centers, ISACs, vulnerability management program. How do you define vulnerabilities, how do you, how do you remediate vulnerabilities internally and externally. Are you asking for software bill of materials for devices for devices to understand their software composition what they're made out of their essentially their nutritional facts, you get their versioning information and and compare them to databases, CVE databases, so you can understand the risk that they're they're introducing into your network. Other considerations for programs are to maintain a catalog of IOC indicators of compromise and having a SIM and monitoring for for security events using that SIM. So incorporating a behavioral profiling mechanism, and whether that is something that a vendor provides or something internally, but it is it is it is needed. And this is this is part of detecting analyzing and contextualizing according to your organization contain eradicate and recover. The activities and in this phase of the process are dependent on a set of incident response classifications. So these, these are sponsored classifications taken to account the clinical considerations associated with the usage of each device. And you'll understand what what I'm saying in just a moment right so this is that the scenarios I was mentioning. So safe to disconnect from the patient and network. There are no patient safety issues with immediately removing the device from the patient or the network. An example could be wireless blood pressure cuff disconnection from the network possible, but with clinical impact. While the device can operate independently of the network is disconnection will have clinical impact. Another which is often used to constantly collect and monitor the vitals of patients and ICUs and other critical units is an example of this scenario, shut down or disconnect from the patient with safety implications. So the medical devices is providing a clinical clinical necessary functions and devices required to be online to performance function. So an example of this could be a CT machine. Right, these are very real relatable, maybe, you know, some, you know, you or someone in your family has interacted with these types of scenarios. And one scenario that is near to me and I didn't mention it here is you know the implantable scenario. You know what happens, you know when a pacemaker is incident there. And what do you do, and what do clinicians do and how do they loop in the third parties, the manufacturers and, and how do you respond right. So I found this, this image quite funny. Cut a virus from your computer. And we had to erase your brain. I hope you've got a backup copy. And the in the age of ransomware and the whites, you know, exploitation of ransomware and wearables and implantables. You're, you know, it is not possible to back up right in those cases but you can back up your, your IT infrastructure and and, and, you know, telehealth devices or maybe not even telehealth devices but other devices within a hospital network. The next phases are analyze a post incident sharing and updating with stakeholders and stakeholders could also be the information sharing groups to I sacs. And then you're looping back around to prepare and incorporating the lessons learn into the playbook into your processes and helping right with that sharing part you're helping others learn from what you learn so that they can incorporate into their programs as well. So if you're not familiar, they do have, you know, a sort of confidentiality agreement, which is, which is beneficial right and in these cases and obviously probably needed right wrapping up wanted to provide a table to help illustrate medical device security activities and applicable projects we talked about today. So if you're developing medical device software, you can take a look at the top 10 is vs embedded apps like best practices and zero trust for iot. Identify medical device vulnerabilities, you can use it go as as a playground and replicate that into a real device, the former security testing methodology. By sweep as the tool to help you with your framework analysis is vs. Right to figure out which, which test cases, I should be incorporating into my workflow into my assessment. Is vs not, I think I may have skipped over this it is written in a way that what it is written in and verify that so every, every, every control is verify that. Obviously verification levels, there's three of them. So when you're purchasing deploying managing and maintaining connected medical devices, use the iot controls framework, the secure medical device deployment standard. You can also use the medical devices that are response playbook, because there are some good bits in there from the kind of managing and purchasing as well from the preparing detecting containing and post medical device security incidents. The medical device IR response playbook, right. One that we just spoke about how to get involved hopefully one of these excited you or you've you found that you know there is room where there is a gap perhaps and some of the work that we've performed, or you want to be a fly on the wall and you want to get involved and just listen in to learn. You were available on slack for cloud security lines and oh wasp for oh wasp to get access to slack, but oh wasp.org and go to about, and there is a slack section there just input your email you get an invite. You can also reach out to project leaders, whether they're active project leaders, or current project leaders like myself, I will help you, I will help you route. To the appropriate person, if it's not me. We're pretty easy to get a hold of on on socials, you can see, you know, my Twitter at the bottom right hand corner, you know, linked in as well with cloud security Alliance we do have a monthly meeting again free to attend and join and keep in mind with contributing and getting involved. You don't have to be technical and non technical opportunities, you don't have to be an expert. You don't have to be a super hard work, you know, a super hacker or anything like that. User experience design format, viewing editing those are all needed skills. So again free and open to all who are interested. Here is my contact info if you want to reach me directly. Thank you for your time. Have fun at biohacking village and def con if you're there. Thanks for your time. Take care all