 Okay. Well, everyone, thank you again for coming this afternoon. My name is Ian Deeson. So I am a vulnerability analyst with the U.S. Federal Government, specifically with the Department of Homeland Security. And my agency that I work for is the Cybersecurity and Infrastructure Security Agency, also called CISA. And I specifically specialize in many, many vulnerabilities that affect software and hardware and how the government needs to specifically respond to it and understanding their impact. So hence, understanding or finding the vulnerabilities in critical infrastructure might take a detective story. So some of the things I'm going to be talking about today are going to be what are these vulnerabilities? What are the types of endpoints? What's the type of end access that these things that these particular vulnerabilities are going to be affecting? What are we talking about by critical infrastructure? That is going to be something that's going to be highlighting specifically within this talk. And also, how do these particular vulnerabilities affect critical infrastructure? So what's at stake? What are things that we are doing at the federal government specifically at CISA? And what are some things that we can do within the open source community and developers and people that understand and can fix vulnerabilities? What are some things that we can do? What can we share? So first, I want to kind of highlight a little bit some of our partners that we work with. The particular group that I work with, we are actually the sponsor of the CVE program. So the common vulnerability is an enumeration. For those of you that are not aware, it's the large taxonomy that exists for identifying different vulnerabilities. This is something we work very hand in hand with with our sponsor, MITRE, just for making sure that the operations specifically for MITRE are working smoothly. And we also have good interface with them to make sure that we have a good idea of what's happening within the vulnerability ecosystem. We're also a co-sponsor of the National Vulnerability Database. So for those of you that aren't familiar with NVD, we co-sponsor that with NIST or the National Institute of Standards and Technology. And that is a large database that's able to be ingested into many vulnerability scanners, many tools rely on the NVD. We also have our two research partners at CERCCC, which is also through the Software Engineering Institute that does lots of our vulnerability research for us. They also do something for us called Coordinated Vulnerability Disclosure, also known as CBD. And we also have our partners at Idaho National Labs. So they are the ones that are going to be specializing a lot within our critical infrastructure, our operational technologies, as well as how that's going to be impacting those particular sectors. So one thing I did want to be able to bring in to frame when we're talking about vulnerability response, we have two different types of vulnerabilities that we are going to be responding to at the federal level. So we have CVD, so Coordinated Vulnerability Disclosure, that is going to be going through CISM. So for those of you that are not aware of how that works, essentially how CVEs are born, it's a lot of the negotiation that happens between a security researcher and a vendor where they are going to be able to come to an agreement to figure out is this product affected, is this software affected, and then understanding what mitigation managers might be and then coming out all at once publicly stating, yes, our software is vulnerable, this is what we are doing about it, maybe there won't be anything done about it, but it's just letting people know publicly that this is how this is going to be working. Through CISA under one of our authorities that we have under Presidential Policy Directive 41 that we are able to identify vulnerable, we're able to identify vulnerable critical infrastructure and let people know about it beforehand. So what we are able to do is we are able to see a lot of those vulnerabilities before they end up becoming public. So especially if they are impacting critical infrastructure, so power grid, energy, power grid, water sector, things along those lines. We also respond to, so if there is CVD that happens, but maybe we are not aware, so this is something that can happen without the government's intervention, these are things that we respond to, but we don't have as much thought beforehand. So there's many times if there's a vulnerability with Microsoft, that is happening on their own CVD. They have their own product security incident response team that is going to be vetting, triaging, and remediating these vulnerabilities before we end up knowing about them. So these are just two different things that we're able to work with. Also when we do have our personal coordinated vulnerability disclosure, we're able to create our own advisories. So I mentioned that we had two partners previously, both through the Software Engineering Institute as well as through our partners at INL. So we have some that are going to be more through what is happening at the Software Engineering Institute and all the ones that are ICS advisories, which is what I mostly work with, that's going to be happening here under ICS cert advisories. To go back a little bit to highlight what critical infrastructure means to us, so it's actually divided up into 16 different sectors where I am at the Department of Homeland Security. We own eight of the 16 sectors where we are going to be controlling the communications. We're going to be over the emergency services sector, critical manufacturing, commercial facilities, but there are some of the other critical lifeline sectors such as wastewater and water as well as energy. Those are under their own different departments. So we also have as well as government facility sectors. So if we're thinking about building access control mechanisms, so I'm noticing there's lots of HVAC systems, lots of human machine interface panels right there, that would be something that would be within the government facilities as well as commercial facilities. So when we are talking about vulnerabilities, whether it's both in these two camps that we have as both as coordinated vulnerability disclosure through CISA as well as stuff that is not through CISA, why is this so hard? So I'm bringing this as this has been a very, very large problem for us to face because we are trying to understand how are we supposed to react to something when we just don't have all the answers. So some of the examples that I have are one of the biggest things for us is going to be supply chain visibility. So when there are the OEMs, the original manufacturers of products, so if you're thinking of your C-manager Rockwells, those type of devices, they end up going downstream into a product integrator. They'll make something bigger out of it. Once that bigger mechanism is made, once that larger product is integrated, that'll go to a reseller. When that reseller sells it to the public utilities, they're done. That's the end of that conversation. That's when a maintenance contract comes in. So trying to understand who bought what and what specific device is implemented where becomes very, very difficult because we just don't have the right amount of data to be able to understand where these things are. And what I'll get to in a little bit is how do we understand if something is vulnerable if it's one little line of code that's going to be creating an issue in a small software package. One of the other issues that we have is with proprietary, if there are things within a proprietary product family, a lot of times the data doesn't move around. So what stays at one particular manufacturer is going to stay there. They are not going to be sharing data with us because a lot of times that's proprietary. They don't want to be sharing information with us. Even if we are in this position that we need to be protecting critical infrastructure, it becomes very difficult where companies don't want to be able to just hand information over to us because it's in their best interest to be able to keep that data safe because that is going to be providing market advantage to them later. Another thing that I'm going to highlight is the fact that control system architecture is not going to be something that is, that is not something that's going to be actively beaconing out on the internet or in some cases should not actively beaconing out over the internet where there are cases where people are able to see the HMI out on the internet and people are able to log into a local water utilities networks. But that's not the case often. Many, many times what ends up happening is just the way how there's so much isolation what's happening on the operational network compared to the corporate network. It becomes very difficult for us to be able to understand how these things are made. And once we do understand that information, a lot of times that's not shareable. That would be something considered under protected critical infrastructure information, which is something that doesn't get shared out. Another thing I want to be able to highlight is the fact that some of these utilities are not very well resourced. If you think of a, for example, I'm from the United States, there's a city called Jackson, Mississippi that recently has, they had a relatively large incident with their water system recently. And it was quoted, it would cost about $1.8 billion to fix. The sector risk management agency over the water systems, the EPA, has an annual budget of $2.8 billion. So if we're thinking about all of these very isolated incidents that are affected to how the water we drank keeping the lights on, a lot of times there just isn't the money involved because some sectors are better at having the funding where others are not. One thing I also want to highlight is just location has a lot to do with it. So if we're thinking about highlighting this lack of inventory, if you do try to be able to find those things and you have a wind farm, are you going to be able to figure out where a lot of these, where a lot of these remote terminal units are? If you have such a wide distributed network, are you going to be able to pay people to go find out what all of these different things are? Also when it comes to the locations, also understanding the nationality behind things. So for example, if we're trying to share a vulnerability with another country, they might not have the best language skills, or they might not understand what we are trying to do. I've had an instant where we are sharing a vulnerability report, we're trying to help them, we're trying to let them mitigate their things. The product vendor just said, well, we think our product is fantastic, thank you. And another thing too that was every single vulnerability affects things differently. It becomes very difficult for us to understand how one vulnerability can affect things. If we're talking in a critical infrastructure sense, we don't understand what the consequences could be. There are safety systems behind things. There are other systems that are operating as fail safes. Every system can be architected differently. So one vulnerability is not going to be the same across the board. And another thing that we also understand is that sharing information tends to be a very manual process. I'm aware of it, because that's when I have to share information with a lot of our both commercial and government partners. A lot of times it's through briefings, it's through PowerPoints. It's not going to be something that is automated. It is something we are working on. However, as it stands right now, we just aren't at the position to be able to share the information at the speed that we need it. But we're going to hold up really quick before I give some examples of where I have some of the things that I've seen in the vulnerability landscape, at least over the past few years that might I just as different use cases. One thing I do want to be able to be able to mention is the fact that the vulnerabilities we're going to be specifically talking about are going to be things that merit CVEs. So when it comes to misconfigured devices, bug bounty programs, we do have that capability within CISA, but that's going to be out of scope within this conversation. We also do have an admin subpoena authority, where we work with our Department of Justice, where they are actually able to serve an ISB to be able to understand what is running on the back end that might be vulnerable. So we can let them know, hey, you could fix your things. So one of the things I wanted to be able to bring up first is what if this vulnerability is everywhere? So this was a case that actually took me about nine months to coordinate. So this whole CVD process going back and forth, what if you have 27 different R tosses? How do you go about and letting them know, hey, by the way, your memory allocation function is vulnerable? How do you go about and how do you let them know? How do you let some of these folks know? So here's an example. Those are all the ones that were deemed affected. Some of these are proprietary. Some of these are open, out in the open. So when we are trying to reach out to someone just to let them know, it becomes absolutely so difficult. And hey, let's all let everybody know on the same day that all of your products are vulnerable by the same thing. Because if one vendor is left out, someone might figure out on their own. So as soon as this vulnerability information is out, it just becomes that's when people start asking questions. That's when people will start testing it. So it's really important that people get that information all at once. And just to make things that much more input. So these are all based off our public advisories that we do. So these are like official government documents that we're able to put out. But these are things that actually don't help. They're helpful for getting the word out. But when we have branded vulnerabilities like this, so you know, amnesia, amnesia 33, ripple 11, when we have things that have are being able to go out and saying, hey, everything is affected, billions of the devices are affected, it makes people will start asking us questions and go back to some of the points that I made. How are we supposed to know if something is vulnerable, if we have so many layers of disconnect? How are we supposed to know what medical devices is vulnerable? How are we supposed to give that right? How are we supposed to give that right data answer that people need? Here's another one that came out. So this is what if they get media attention? So this was the gentleman right before me actually just spoke about automotive industries. So this is actually an aftermarket GPS unit that is installed in cars. You're able to do a few things such as you're able to monitor fuel supplies, that type of things in these particular research security researchers research, they're able to show that they're able to remotely turn it off. Which if you think about it, of course, that's going to get a lot of media attention and it's sure to. So for those of you that are not aware, so the United States has the Associated Press. Once the Associated Press has something, it will generally be distributed to every single local media outlet. So I counted there are hundreds and hundreds and hundreds of reports on this. And again, going back to what I mentioned originally, how are we supposed to give people the right information if we don't have the right information ourselves? It's almost impossible for us to be able to say is your car affected. And when it comes to things being affected, so cars tend to get a lot of media coverage because people understand what cars are. We see them, we go inside of them, we drive them. If we talk about a PLC, an HMI, people don't really have that same idea. There's too many layers of disconnect. But what if it's in a medical device? What if we actually start talking about the safety critical systems where catastrophic damage of people losing their lives is a reality? People tend to react to these a little bit more. So we also did an advisory for one. So this was February of last year and that is on a ventilator. So if we're publishing, so for those of you that are aware of the CVSS score, not the most severe things. It's not a remote code execution over the open internet. However, if you're mentioning the fact during the pandemic that there is a software vulnerability in a ventilator, people are going to start getting a little worried. Another thing I want to mention specifically with medical devices is we actually do have a memorandum of understanding with the FDA. So when we do have vulnerability reports coming from the FDA, what we actually are able to share with them beforehand, they are a regulator. They have very strict standards of what is classified by as a medical device. And if those things do not meet those standards, they're pulled off the shelves. So we are able to make sure that we have this nice synergistic conversation with them and we are able to let them know what we know normally before these vulnerabilities are public so that way they can be able to address them appropriately to make sure that the products are safe. Another thing that got a little bit interesting, what if something is based off an open standard? So the distributed data services is normal. It's a middleware component. So this is going to be something that's going to be handling the reliability of control system architectures over wide distances. So this particular case was kind of difficult for us to understand what the potential impact would be when you have systems being made for reliability of control systems over a long distance. But we released an advisory on this. But one of the things that we learned that made it a little bit more scary is then we start seeing large pieces of critical infrastructure out in the open using these particular products. So Grand Coulee Dam's one of the largest dams in the United States. Something that would fail there is catastrophic and it's very difficult for us to understand a very large wide distance reliability protocol when it is just so difficult for us to understand how is this product used? How is it integrated? And then I would be remiss. I can't be talking about vulnerabilities. If we don't talk about, I feel at this point like it's just like a bingo card. You just mark it off. But one of the things, so as a part of CISA, so we're part of the federal response team for our log for J, I remember that's what I did this past holiday season was being able to enumerate as many devices as I could and being able to share that as many people. But with this particular vulnerability, for many reasons, active exploitation made things a little bit, made this very difficult, is still very difficult for some people, still had impact of critical infrastructure as well as we learned as many, many of the control systems within the industrial sector. They were also affected by this. But for this, we had we had alerts and more alerts and more alerts. Oops, we actually made a, we actually made an emergency directive for this where we, every single government agency in the United States would need to be able to find out where this particular product was used and they needed to find a way to path to remediate it. One of the things that we also did with that is we used GitHub to support our vulnerability response. So this was one of the first times that we as, so when you think of all of these documents we just put out, this was different for us because normally we have so many different layers of reviews that we are not able to react fast enough. By us using something that is already well adopted, it just helped our response where we were able to identify devices that were affected, not affected and we're able to do that in real time and we're able to use contributions from people all across the world. So I think at that point it really helped us leverage our response to that vulnerability by using people that exist within the community. So I thought that was fantastic. So this is all fantastic information Ian, but what are some specific things that we, I've learned over the past couple of years that I've been doing this, what are some tools I can be able to help out vulnerability response or yourselves as open source developers or product owners, what are some things that I can be able to share to help? So one thing that we do have is this is actually an open source product as well. So this is called Vince, this was made by the, this was made by Carnegie Mellons, the Software Engineering Institute. So this is our vulnerability reporting platform. So this is our way to be able to share, this is all available online, it's just a way it runs on AWS and you're able to, if you want to make some sort of vulnerability coordination platform, we have the backbone. It's already out there, it's made, I'll have the link at the end. One other thing that we're also working on is trying, we are trying to be able to, how can we best utilize GitHub as a way for us to be able to enumerate vulnerable devices? So this is something that there's a lot more tooling that is involved. It's a way to reach information faster. Many of the products that I shared, it tends to be human readable, but using platforms that exist can make us be able to respond faster. So those are things that we're currently working on right now. Here's another thing that this is actually something that we do for our day after day vulnerability response. So about 16,000, but we get hundreds and hundreds of vulnerability reports at any one time. So I know currently we are currently coordinating about 150 different cases at one time. So a lot of times there's not enough time for us to be able to just focus on a specific vulnerability. We just don't have the capacity to be able to understand completely what's at stake because we have a whole bunch of others working with. But this is also research that was done at Carnegie Mellon. If you notice it's actually CVSS felt backwards. So it's a stakeholder specific vulnerability categorization. So what that, what this is going to be doing, it's going to be using a decision tree in order to help out with vulnerability response. So with CVSS, it tends to be a scale from one to 10. What's the difference between a 9.1 and an 8.9? So there's a lot of times there's a little bit of just a margin of error for some of the numbering systems. But if the difference between an 8.9 and a 9.0 is what's considered critical, this is something that you're able to be able to use your organization, your assets, and you're able to be able to understand exactly what are the things that, what are the vulnerabilities you need to care about. And I guess for the not-so-cool stuff, policies, processes, and paperwork. Some of these things are super important, but they can also be able to help you out in case there is some sort of response that you need to do. So I'm mentioning here you can have a vulnerability disclosure policy. We do have, there is documentation available, but it's just letting people know that unlike some entities, that you will not try to prosecute you if they're trying to share a vulnerability report, that there are good faith researchers out there, but it also lets you know what your, it's just letting the public know. Also internally, this can be something whether you're developing code, whether this is something you're part of a product security team, a product management team, if you're part of a greater cybersecurity team, have a, have a vulnerable response process because it's really important to understand if those log for jays happen, what is, what are your steps? What are you going to do? What are the call trees that you have? It's just very important to kind of have that good, all the good pieces of information that way in case of an incident, in case of a disaster, people know what's going on. And I guess the last one's going to be a little bit of a, a little bit of me trying to get people to sign up for this. So we also have something called a CVE numbering authority, which is also called a CNA. What that specifically means, if you're a product owner, if you're a manufacturer, if you make code, so it's a way for you to be able to assign your own CVEs. So right now, some of the processes, if you find a vulnerability with a product, normally you can either send them to the CVE program, they can assign them from there, or you can let the manufacturer know they can be able to, they can be able to identify the CVE, let them know if things are correct, and then they can submit the records. One of the things that we always like to make sure people know is that product owners will generally, generally know their products the best. When people are asking us, like what, like, we don't think this vulnerability is that bad, and it's like, well according to the product manufacturer, they are saying yes or no, it isn't. So some of the things that you can be able to understand a little bit more, some of the paperwork. We also have different, different strategic initiatives for both SBOM, software bill of materials, CSAF, which a common security advisory framework as well as VEX or vulnerability exploitation. These are all covered on by a talk by my colleague. So these are all actually online right now. He has the slides. I don't want to steal his thunder because he already made the thunder. I'm not trying to, I'm not trying to take, take off from his good work. Highly recommend you take a look at that as well. We also have fantastic people within our organization. These are things that the US federal government are working on right now. And a little bit of a pitch at the end. So I just want to say all the security researchers out there, they're doing fantastic jobs. It's a very, very important part of the ecosystem because for us to understand the risk of using these different products, a lot of times the folks are just doing this as a hobbyist. Not all of them are professionals. So we, I just want to say thank you for making sure that we're having this continuous cycle of CVEs because that's how we know things are getting fixed. That's how we know we're getting better is just by identifying it and then putting out in the public. So just want to let them know. Thank you security researchers for the good work that they're doing. Some of the references and resources that I've shared based on vulnerability disclosure process. So some of our bold notes or advisories, that memorandum of understanding. I also put in the presidential policy if someone really, really, really likes to read stuff. You can look at presidential policy directive 41. Some more resources. So we have for the NVD, for the CVE program, something for CNAs. The next slide is actually CERTCC or our partners at the Software Engineering Institute. They essentially wrote the book. Well, they did write the book on coordinated vulnerability disclosure. That is a link for that. So once the slides get shared out, we'll make sure that is also out there. Also the two Githubs for both Vince and there's also a Github for SSVC. So again, thank you so much for allowing me come here, speak. If you do have a vulnerability to report, there's a link for that. If you do have, I love feedback. It's something that I, it's very, it's very hard for me to kind of get out of the government world. So any feedback that people might have, feel free to just write it, send it to me. There's my email. Or if there's something you just want to send to the general agency itself, that's our general, that's our public inbox, feel free to just send whatever you might need. And with that, I guess I will pause here if there's any questions. If anyone has any questions on any of the material I covered. Yeah. Yes. So some of the, some of the things that we recommend, if you, as soon as you do know there's a vulnerability, you can let us know. Those are things where we are able to, for example, if you, even if there's a chance that one of your projects could be integrated somewhere on critical infrastructure, it's better, it's always better for us to know, rather than us finding out the day of, or finding out three months later, oh, something's under active exploitation. It's just, it makes it easier for us to, if we know, even if it's just a heads up, friendly hello. So we have partnerships with Siemens and Hitachi Energy, they give us heads up on things. It's like, we're putting out these reports. We want you to know about this, because a lot of the way it's just kind of building a community of trust, as well as we're trying to be able to, since we have a very loud megaphone, and when, at least within the international cert world, people tend to listen, where if we are able to say, hey, we think this, or this is bad, this is good. A lot of that, a lot of that information we get is from community members. So any way that you want to contribute, if there's just vulnerability reports are kind of the biggest things for us. But if there's any ways of things that we could be doing better, we're, you know, we're all open. But thank you for the question. All right. Well, I'm not seeing any more questions. So again, thank you so much for your time. I appreciate everyone being here for the last session of the day. And I will still be around if someone has some other questions. But again, thank you so much. I appreciate your time.