Two viewpoints on the National Cybersecurity Strategy.

Dave Bittner: The Biden administration recently released their national cybersecurity strategy, which, in their words, aims to secure the full benefits of a safe and secure digital ecosystem for all Americans. In this CyberWire special edition, we speak with two special guests about the National Cybersecurity Strategy. Adam Isles is a principal at the Chertoff Group, a security firm founded by former secretary of the Department of Homeland Security Michael Chertoff. Previously, Adam served as the deputy chief of staff at DHS. Our second special guest is Steve Kelly. Mr. Kelly serves as special assistant to the president and senior director for cybersecurity and emerging technology with the National Security Council. We begin with the Chertoff Group's Adam Isles. 

Adam Isles: There is very loudly and clearly an emphasis on a fuller use of existing regulatory authorities and maybe the need for some new regulatory authorities to apply a set of kind of minimum expected cybersecurity practices across critical infrastructure sectors. There is a sense, you know, that what's historically been largely a voluntary approach isn't generating the outcomes that we need to defend the country and make it cyber resilient. 

Adam Isles: And so what we're seeing here is certainly a focus around - we have existing - whether it's safety or security regulatory authorities, let's make sure there's a cyber component to those. And in fact - right? - we saw, not even a day after the cybersecurity strategy was released, the Environmental Protection Agency come out with new guidance to state EPAs basically saying, when you're doing inspections of public water systems, here's what you need to be asking about from a cybersecurity perspective. And I expect we'll see that trend kind of percolate across into other regulatory agencies as well. I mean, TSA has already come out and announced - and they haven't divulged the specifics of it, but - an emergency amendment to aircraft and airport regulations to add in additional cybersecurity expectations. 

Dave Bittner: I think something that's caught a lot of people's eye is this notion that we're going to see an emphasis on liability for software. 

Adam Isles: Yes. And, again, this is not a new thought, but it is the administration saying in a formal way, you know, we stand behind this. I mean, the Cyberspace Solarium commission talked about it. And, you know, you can think about, you know, even, you know, news items over the last days and weeks around, you know, the kind of the dumping of LastPass password files or, you know, the zero-day, you know, vulnerability and outlook, you know, that's been disclosed within the last day or two. You know, the sense of - what we really want software providers to be doing, particularly the providers of security technologies, is to be, you know, designing their systems to be secure by design and to incentivize them to do that by having them own more of the liability if, for whatever reason, they aren't. 

Adam Isles: You know, the interesting thing in this space - right? - is there are lots of compliance frameworks that are out there and best practice frameworks. And we think, you know, in the context of federal agencies around things like, you know, Special Publication 800-53. When we're thinking about, you know, compliance frameworks that are, you know, well-known in the private sector, we think about, you know, ISO 27001, you know, SOC2. Those frameworks don't really necessarily get to the level of detail on what good software lifecycle security practices look like. 

Adam Isles: And so we're talking about, you know, a potential liability shift coupled with, well, let's think about what a modern, you know, software security lifecycle framework looks like, and let's try and get people to conform to that. And so you see, you know, coupled with this idea of liability shift, you know, also the focus around using procurement authorities to try and drive, you know, for instance, the software providers that are selling to the federal government to, you know, kind of attest to conformance with, you know, a framework like the SSDF. 

Dave Bittner: I found it interesting, perhaps in the the spirit of not letting the perfect be the enemy of the good, that there's talk of having some kind of a safe harbor provision in here. Can you unpack that for us? 

Adam Isles: Yeah, I think - look. I mean, it's a great question - right? - because the safe harbor provision is almost - it's almost conditioned on, well, there will be an incident, right? I mean, there is no such thing as risk elimination where you've got criminal minds, right? The day we end, you know, cyber threat actors is the day we end crime. And so the question is kind of, you know, what's reasonable? What's good enough? You know, this, again, I think, is where you may see the flipside of something like, you know, how the SSDF - that is, in this secure software development framework - could be used not only to set a kind of minimum expectation, but also to say, if you've aligned to this and particularly if you've had someone validate that you've aligned to this, will - you know, will that be kind of a safe harbor? And, you know, we've seen that in a privacy context, you know, with HIPAA and the anonymization of PII for research purposes. We've certainly seen, you know, kind of a safe harbor equivalent in the form of the safety act, you know, that's been in place at DHS for 20 years, you know, to provide some level of liability protection for people that provide anti-terrorism capabilities. You know, it'll be interesting to see how this all plays out. 

Dave Bittner: To what degree does the Biden administration have the ability to execute on these plans themselves, you know, through the existing regulatory agencies? And to what degree will they have to go and ask for cooperation from Congress? 

Adam Isles: Yeah. So on the one hand, look; to have - I mean, the SAFETY Act at DHS took an act of Congress to put in place. On the other hand, the administration has a pretty - I mean, any administration has a pretty fulsome set of enforcement authorities, you know, particularly vis-a-vis, for example, people that are selling goods to federal agencies. And so I think what you may see is the use of existing authorities to say, you know, if you don't do this, you know, this is going to be evidence of a failure to align to minimum practices. And we'll be thinking about it in the context of things like, you know, the Department of Justice's Cyber Civil Fraud Initiative, you know, where they're going after federal vendors with substandard security practices. And so you may also see it, you know, to your question on the safe harbor, around - you know, if you have conformed to the software security framework, particularly if you've had it validated, that will be, you know, kind of prima facie evidence that would militate against an enforcement action. So you've got both, if you will, the stick and the carrot at play through the use of existing authorities and, you know, statement around forbearance as well. 

Dave Bittner: So what are your recommendations for organizations? You know, now that we have this statement of intent... 

Adam Isles: Yeah. 

Dave Bittner: ...From the Biden administration, how should they be preparing themselves for what's to come? 

Adam Isles: So I think we've got to bucket organizations into three categories. Category 1 would be the providers of software. Category 2 would be critical infrastructure operators. And Category 3 would kind of be everyone else. So for the first category, for providers, if they're not already, they need to be understanding the NIST secure software framework and conducting readiness assessments on, do they actually conform to it? They need to be also thinking about, you know, the software bill of materials concept and responsible disclosure of vulnerabilities, which are related concepts, and how they might eventually implement those. If you're a critical infrastructure operator, you need to be thinking about, OK, well, what regulatory expectations do I have to meet now in kind of a physical security or food safety context that I may be staring down, you know, a future set of cyber questions? 

Adam Isles: I mentioned earlier the example of public water systems and airlines and airports. I think you're going to see that more broadly across the critical manufacturing sector. So the strategy refers to something called the Cyber Performance Goals that were released by the U.S. Cybersecurity Infrastructure Security Agency in December of last year. If I were one of those companies, I'd be familiarizing myself with the CPGs because when EPA put out its guidance, it basically copied CISA's cyber performance goals almost whole hog into the guidance that went out to state EPAs. For everyone else, I'd be looking at these new kind of expectations from the point of view of, what does it mean for me? And so if, for instance, I'm a retailer, I'd be looking at what's happening in the software space from the perspective of being a purchaser of software. So how can I take advantage of, you know, the NIST secure software development framework to improve my own third-party risk management program? Or how can I look at the cyber performance goals as maybe, you know, instruction on what emerging best practice for defending my own environment against cyberattacks may look like, even though it might regulate it itself? So that's what I'd be doing. 

Dave Bittner: As you look at this, I'm curious on your personal take on it. I mean, was there anything in here that surprised you either in its inclusion or it being left out? How do you feel about it? 

Adam Isles: Well, so in terms of surprises, I - there was this reference to an executive order that President Trump signed literally on his last full day in office that imposed know-your-customer expectations on cloud infrastructure providers. And so not only did the strategy reference it; it kind of embraced it and basically warned, you know, other internet infrastructure providers, you know, domain registrars, hosting providers, email providers, that they may be staring down, you know, a sort of KYC requirements in the future themselves. And I think that's interesting, right? Because you've got, you know, threat actors, historically, you know, using, you know, domain registration, domain registration algorithms, other forms of internet infrastructure to kind of cover their tracks. And so I think this is an attempt on the administration's part to try and shed some transparency on that. I think the other thing that will be interesting is for everything we're talking about here, what is our diplomatic strategy on all of this stuff? So it's great that we're doing these things here, but to what extent are we talking to our allies - Canada, the U.K., Australia - you know, about aligning to similar standards, taking similar actions? 

Dave Bittner: Do you think, in some ways, we're lagging behind? I mean, we often - you know, we get dinged for not having privacy legislation in place ala GDPR. 

Adam Isles: Yeah. Look. I think we're leaders in understanding the problem. I don't know that we're always leaders in doing something about it. The European Union - right? - has had the NIS directive in place for some period of time. You know, the GDPR has been in place since 2018. And we still don't have, you know, a kind of a national set of, you know, baseline privacy practices that are codified in law. So I think it's - you know, in part - right? - there are larger issues in terms of, you know, realistically what can be accomplished in Congress. You know, thus, you know, our earlier conversation around what you can do with existing authorities. So I think - but I also don't think we should be, you know, apologetic about looking to best practice in terms of what other countries have done. And I think that, you know, the work, for instance, that the U.K. has done and the guidance that comes out of the National Cyber Security Centre there is very much, you know, something we should embrace. I think that, you know, the testing requirements, you know, the threat-based testing requirements that Britain's Prudential Regulatory Authority requires, I think, are things to look at. 

Dave Bittner: Our second special guest is Steve Kelly. Steve Kelly serves as special assistant to the president and senior director for cybersecurity and emerging technology with the National Security Council. 

Steve Kelly: What we've experienced in the past is that building a complex software product like an operating system, for instance, is incredibly cumbersome. It involves, you know, an incredible volume of code that's being written and assembled. Creating secure software is no easy feat. We recognize that. But this administration, under the executive order that was signed early on, 14028, doubled down on making sure that we have secure software development practices being used in creating software that the government is buying for its own uses. And that includes things like some foundational work done by NIST on creating secure software development practices and standards around that and then also making sure that we've got transparency into what components are in software because software maker doesn't just write brand-new code. Oftentimes, there are components that are borrowed and adapted from other places, including open-source software projects. And so it's important to make sure that you understand what's under the hood in a software product and that all the pieces that are in there are being updated and security flaws are being addressed over time. 

Steve Kelly: And so one thing that has been problematic in the past, especially for small users and small businesses, is that when you purchase a software product, you click through an end user licensing agreement, which, in many cases, waives your ability to seek redress if there's a flaw in the product, and it causes a harm. We want to make sure that that the software makers are using all of the industry-standard best practices for creating secure products and that as a result of that, then that would create kind of a liability safe harbor for them. And so we want to encourage people to use best practices in creating software products from the start and to do all the right things to make sure that these products are as secure as they can reasonably be at the time of the release and that over time, that those products are being patched and maintained in an appropriate way. That's the theme behind that section. And frankly, it's a strong message, and it's caused a lot of interest and concern by some. And it's kind of an opening of a conversation on, how do we make sure that our software products are safe and secure by design and that they are maintained over time and that, you know, that that helps to manage - that's one big piece of managing the nation's risk. 

Dave Bittner: To what degree do you think the administration considers this to be a collaborative process between themselves, other government organizations and private industry? You mentioned that that this could be, you know, an opening of a conversation. 

Steve Kelly: Well, it clearly is a collaboration. I mean, the - most of the infrastructure, most of the software that's written, most of the telecommunications networks are being created and maintained and are owned and operated by the private sector. The government has the ability to influence the marketplace through its own purchasing. And so you've seen that as a major theme in the first half of the administration, where we're trying to make sure that the products and services that we buy are safe and secure by design. And we think that that will actually make products safer for everybody, even those that aren't government purchasers. As well, we have a commitment to making sure that we are working with industry to share information that we have about what the cyber threat actors are doing so that they can better protect themselves, and then also understanding that the space that these product manufacturers are operating in is a global environment. We want to make sure that the requirements that we're putting on these products or the ideas that we're trying to get into industry will actually make their products more secure and more marketable globally. 

Steve Kelly: So I'll give you an example of that. The White House hosted in October a meeting to talk about and Internet of Things security labeling program so that small devices that are all throughout your homes like smart speakers and baby monitors and Nest doorbell cameras and toasters and refrigerators everything imaginable that now has computer functionality and are connected wirelessly to your home network, that these devices are safe and secure, and that the security posture of that device is transparent to the consumer who's buying the product, so that if you want an online commerce site and you try to choose a product, that it's easy to tell that it is a secure product and it has a label or some sort of marking that indicates that, kind of like Energy Star for cyber, you know, the Energy Star logo for energy efficiency and home appliances. 

Steve Kelly: So that's an example of an opportunity where there's an appetite in industry to make sure that their products are safe and secure, that they're adopting industry best practices in that, and that their products will stand out on the global stage. And so we've had a lot of interest by the private sector in how that might work. We're working towards finding ways to implement that process. And more to come on that, but that's an example of where the private sector and the public sector and the government are on the same page that it's a valuable thing to do to increase the security of the ecosystem and to make sure that quality products in the U.S. are - stand out in the global marketplace. 

Dave Bittner: You know, I think it's fair to say that we're in an era right now where it can be challenging, to say the least, to get things through Congress. I'm curious. To what degree does President Biden feel as though he can execute on this strategy through the authority he has, through the regulatory agencies? And to what degree is he going to have to go to Congress for some collaboration and cooperation here? 

Steve Kelly: That's a great question. We think that cybersecurity is - presents a great opportunity for bipartisan collaboration. I think it's one of the few remaining topics that there's an openness to working together on this topic. So there are going to be areas where we need Congress to act. It might just be to remove ambiguity or to give us the necessary authorization to place a new program within an agency. For instance, like the thing that I described in IoT security labeling, that's the kind of thing that when it was created for energy efficiency and the Energy Star program, Congress passed a bill to make that happen. So that's an example of where we very well may need some help from Congress to assign a responsibility and make sure that there's a clear path, as well as appropriations, to make that type of a program happen. 

Steve Kelly: You referenced, I believe, the area of critical infrastructure, cybersecurity and how do we make sure that our critical infrastructure is safe and secure? These are also areas where there are existing authorities, and we are leveraging those to the maximum extent possible. But there may also be some areas where there are gaps that we need to work with Congress to close. So let's talk about that a little bit. So we have been taking - this strategy makes a pretty bold statement that the voluntary approach to critical infrastructure cybersecurity has not gotten us to the level of security resilience that we need to be at. And so as a result of that, you know, we are going in the direction of more minimum requirements for cybersecurity and critical infrastructure and taking a sector-by-sector approach to that. 

Steve Kelly: I don't think there's going to be a major bill that's passed that creates a new regime, you know, for all critical infrastructure of cybersecurity. Instead, we're looking at each of the 16 critical infrastructure sectors, and there's many more subsectors below that, and seeing, you know, who is the sector risk management agency within the government? Who are the regulators that have a role in this? What are the authorities that we currently have to regulate? And there's plenty of sectors like electricity grid, as one example, nuclear as well, that there's pretty robust regulatory mechanisms to require security across a range of areas, including cyber. 

Steve Kelly: But then there's other sectors for which it's a voluntary approach. And our viewpoint up to this point, especially given some of the major incidents that we've had - you know, ransomware incidents affecting fuel pipelines, food processing, hospitals - there certainly seems to be a need to increase the baseline, to up our game to make sure that these critical services are secured. And so we're going through this approach sector by sector looking for what we can do. I'll give you some examples of where we've actually done that. The Transportation Security Administration has issued security directives for pipelines, rail and aviation, and those started with some basic requirements like having a cybersecurity plan and having a point of contact for cybersecurity incidents and reporting incidents to the government. And those were built upon. And so that's an area where we acted very quickly. 

Steve Kelly: More recently - it was earlier this month - EPA released an interpretive rule memo on cybersecurity for drinking water facilities. We think it's critically important that as state regulators oversee drinking water facilities in their states, that in addition to things you would expect them to do - like making sure that these facilities have fences around them and that the chemicals are safe and that they've got quality processes to make sure that what's going into the water is right and that the drinking water coming out of the other end of the treatment plant is clean and safe to drink - more and more industrial control systems and computerized processes are making all of that happen, so we need to make sure that we build cybersecurity into these approaches. And so this is an area that we're just starting on with the water sector, is requiring cybersecurity to be an element of the biannual sanitary survey process. So that's going to be a new process. These facilities will be looking at cybersecurity as just one additional area of security that they would be evaluating through that program. 

Dave Bittner: You know, Director Kelly, our audience is primarily made up of cybersecurity professionals. And a lot of these folks, I think, consider themselves on the front lines of many of the things that you address here in the policy. What would be your message to those people, to those professionals out there who are - who want to play their part in defending the nation and indeed making the world a safer place when it comes to these cyber issues? 

Steve Kelly: Well, to the professionals out there that are creating software products or creating also hardware products, I think that the key is that we've reached a point where the knowledge base for how to create secure products - what are some of the best practices and how do you evaluate a product or a program to make sure that it's safe and secure by design? - that knowledge is now out there, and it's just a matter of adopting that. For new startup companies that are just creating a software offering or a software as a service type of offering, the only way that they're going to find buyers is to make sure that they can also provide, you know, proof that they've adopted cybersecurity best practices, because increasingly, the way that a bad actor can get into additional victims is through some of these service offerings where I can get into one particular product or one particular managed service provider, and that's going to give me a venue and avenue into a whole population of organizations that are dependent upon that product or service. 

Steve Kelly: So it's important that security be built into the program because these customers are going to want to make sure that that's safe and secure and that by contracting with them or by adopting that software product, that they're not introducing new risks in their organization. So each organization, at every step in the process needs to be understanding risk and managing risk. One thing that seems uncontroversial now is that when you buy an automobile, it's safe and secure by design. It comes with seatbelts, and seatbelts aren't a premium add-on. You didn't have to pay extra for that, although clearly the cost of the seatbelt was included in the overall cost of the car. That's similar to other safety features, like making sure that in a crash test that, you know, the car behaves properly and the airbags go off and the passenger in most ordinary circumstances isn't going to be crushed or that if your car's rear-ended, the fuel tank doesn't explode. I mean, these are not things you pay extra to have a nonexploding fuel tag. These are things you would expect. 

Steve Kelly: I think the new expectation is going to be that software and hardware technology products need to be safe and secure by design, and we need ways to - and there are ways to evaluate that, and increasingly that's going to be something that buyers are going to be asking for, some sort of proof, a security label, an attestation, some sort of an audit. And I think that that's something that is going to be built in and factored into the cost of everything that we do. From clean drinking water to the operating system on your computer to the baby camera that's in your home, everything is going to need an appropriate level, an appropriate risk posture, based on the product itself and that we can all be much more secure all the way across the ecosystem. 

Dave Bittner: That's special assistant to the president, Steve Kelly. Our thanks to him and to Adam Isles from the Chertoff Group for joining us for this CyberWire special edition. I'm Dave Bittner. Thanks for listening.