Transcript
I am so happy that Sarah Flukes is my guest. Sarah is one of the most well-regarded and influential security and technology professionals out there, and she's done a lot of excellent writing and presenting on a number of topics, including the Cyber Resilience Act, Secure by Design, and how to bring cybersecurity closer to engineering and asset operators, all topics that are definitely very pertinent to you, the listener. As I mentioned, this is our 100th episode, and I just want to take a second to thank every single guest who has given their time to share their expertise with you here. We started this show a few years ago, and it's really become a fascinating snapshot of how OT and IoT cybersecurity has really matured and matured rapidly during that time. So my sincere thanks again to every guest and to you all for listening. I can't tell you how much I appreciate all of you who listen and subscribe. I listen to a lot of podcasts, and I know how competitive and challenging it is to get your attention. So trust me, it's very much appreciated. So with that said, let's start today's episode and bring in Sarah. How are you, Sarah? Well, thanks. Great. Thank you for having me, and congratulations on your 100th episode. That's really an achievement. Thank you. Yeah. I get a lot of support for this from Clarity and the team here, and obviously the guests like you. So I really appreciate that. It's fun. I really enjoy doing it, and I really enjoy bringing people who are a lot smarter than I am in security to the show and let them share what they know and their experiences, and it's been fun. Well, then let's dive in. Yes. Let's dive in. All right. So let's start with the Cyber Resilience Act. And I know you're kind of intimately involved with it, and you've done a lot of presenting on it. Just to kind of recap, it's obviously a regulation, promises to improve product security, introduces a lot of requirements aimed mostly at manufacturers of products with digital elements, and kind of focuses in on the design, the development, maintenance of these products. Just curious, just from your experience in kind of getting this off the ground and seeing how it's grown, how do you characterize the importance of this regulation? I mean, what, in your opinion, was it a reaction to? Is it just kind of like a reaction to the hyper-connectivity of all these products or something else? Just give me your kind of overall characterization of the reg. Well, it's interesting. When it first came up, I think that was back in 2022, and I kind of stumbled into the Cyber Resilience Act and was like, okay, the EU Commission has released this draft regulation that I should probably look into that because, I mean, I was at that time full-time occupied with security by design research, more or less full-time. So that was exactly my thing, and I was like, okay, there suddenly is a government putting out a serious security by design regulation. So that's something worth diving in, and the deeper I got into that, I realized that that's going to be something pretty big, and I think that's with, of course, a bit of delay. Manufacturers now are also realizing. For a lot of the times, I have the feeling that the CRA compared to other regulations and also other security by design initiatives, for example, by CESAR, kind of flew under the radar. So everybody was talking, at least in Europe, about NIST 2 and critical infrastructure regulations and all these things, and nobody talked that much about the Cyber Resilience Act. And I know that the people at the EU Commission that wrote the Cyber Resilience Act and negotiated the Cyber Resilience Act with the Parliament and the Council and the European Union, they were even surprised that it went through with so little discussion because just the attention wasn't really there. But now I think people are starting to realize how big it is, and I think the big difference to the critical infrastructure regulation that we're used to is if there is an asset owner that is not compliant to critical infrastructure regulation, then, well, maybe they could sometimes get a fine, and I don't really think there have been many fines. And for the Cyber Resilience Act, that's really a difference because manufacturers feel that it's where they're starting to get very nervous about that, that this could really be revenue stream disrupting because if you don't comply, you're simply not allowed to place your product on the market anymore in the European Union, and that's, I think, what makes it so big. Do you think that their hope or their objective here was to kind of have the CRA do for product, product security, say what GDPR did for privacy? Is that a fair kind of comparison of the outcomes that are hoped for? I hope not, actually, because GDPR was, here in the European Union at least, it was really, there was a big hype before it was there, and everybody said, oh, we need to do something about GDPR, and there was going to be huge fines. And in the end, it wasn't that big, at least for most. And also, it's a bit more like infrastructure regulation because it's more business of, you could get a fine if you don't comply, that's different than you need to do something before you even place your product on the market. So I'd say it's decidedly different than GDPR in a way that it's really more strict and more impactful for manufacturers potentially. But also, I'm not aware of any other part of the world where there was a regulation like this on product security. I mean, there are a few on smaller scopes, on IoT and on vehicles and things like that. And there are a few voluntary labels or things like that, but not for such a huge scope. So for all products with digital elements, a label or a marking or requirements that you have to meet cybersecurity requirements, and otherwise, you really can't put that product on the market for really virtually every digital product. So the combination of really this big impact and this strictness in combination with the huge scope, I think that's what makes it pretty unique. And we should probably clear up that this applies to B2B products and not just consumer-facing products. That's correct, right? Yeah, that's correct. And I think that's also the problem that B2B products often have because, of course, there are many more consumer products compared to B2B products. And I too sometimes have the feeling when I read the CRA legal text that it was written more with consumer products in mind. So sometimes it doesn't make much sense. I wouldn't even say that, but it's harder to do for B2B products. Because take, for example, there was a requirement on a factory reset. So you have to have a factory reset for your products. And then, of course, for B2C products, that's a no-brainer. I mean, most digital products that you have probably have this small button where you can factory reset the product. So that's completely normal. So it wouldn't be a big thing to put that into a regulation. And then for B2B products, no product has that. And if you would imagine, sometimes it's even adding risk compared to the security benefits that they could have to add a factory reset. If you have a PLC and there's a factory reset button, well, that's a pretty big risk to add to a component, actually. So it doesn't really improve the security. And that's just one example where I think that's the reason why B2B products and the industry sometimes struggles with the CRA. So maybe it'd be good to level set and explain where things are today. I know that there was an expert group meeting scheduled recently. Can you update us on what came out of it and where things stand today with the reg? Yeah. Well, the expert group is consulting, just consulting the European Commission on implementation guidances and things like that around the CRA. And I mean, the most questions I think I get about CRA recently are questions about when are requirements finally going to get more specific because they are pretty vague in the Cyber Resilience Act. And when do we get guidance on so many questions? What is due diligence exactly? And what kind of products are remote processing solutions? What kind of remote processing solutions count to the product and which ones don't? And what is a substantial change? Because if legacy products undergo a substantial change, then they also fall under the CRA and otherwise they don't. So these are all really follow-up questions on the requirements regarding wording and definitions and requirements and interpretation of requirements where people are trying to get more specific guidance. And that's also always a big topic in the CRA expert group meetings because the EU Commission explains what kind of guidance they're planning to do and they also get the feedback from the experts to see what should they prioritize and where else may guidance be necessary. And of course, there's also an update on harmonized standards, but the EU Commission really can do only so much about that because harmonized standards are now in the hands of the European standardization organizations. So they can report and they can set deadlines and due dates, but they can't really influence how fast it's going. So are the vagaries in the standard, what are they doing to compliance efforts right now? Is that slowing things down for companies? And do you expect more specific language to be added to the regulation? Well, it's adding to the insecurity of manufacturers because they say, okay, there's so many uncertainties and things that are yet to be defined. How do we even start? And there's, in their minds, there's this big elephant of the CRA with this many requirements and for some things they don't even know exactly what to do. So that obviously is a challenge and at the same time, especially B2B products, but for COSIMA products, it's not much different. I mean, product life cycles and the time it takes to build new features into a product are long. So it's not like you just decide today that you want to be more secure and tomorrow your product is more secure, but it takes time until you have changed processes and features and you need to make strategic product decisions about what are you going to sell after 2027. So after the due date of the CRA and what can't you sell anymore and where do you do an upgrade so that you're compliant and which products you maybe take off market. And that's why manufacturers know that they need to act now and they are nervous because there are these uncertainties and they feel they can't really act. And the answer that I always give them when they have these uncertainties is, well, focus on what you do know. And we do know that there are the essential requirements. That's the Annex 1 requirements in the CRA. These are there. They are not going to change and you can take them for granted. And we know that these are, there's a very important sentence above these essential requirements saying you need to do that based on risk. So you really, and you are allowed to do your own risk assessment that helps you with interpreting how you interpret these requirements for your product. And they are really, they are allowed to do that. They don't have to wait for a standard doing that for them. And they're also encouraged to do that from the side of the EU Commission. So that definitely is the encouragement to get started and to have the courage to do the risk assessment and interpret the requirements because they are there. They won't change. I mean, the essential requirements, everything in the regulations seems pretty expansive. And I would imagine that some of these manufacturers are facing some significant costs. How hard do you expect them to push back against this? I mean, they really have no choice in the end, but what are you hearing from their end? Well, they can't really push back because it's there. So the elephant is in the room. What they can do is, what they also are doing is to see that the interpretation of the requirements, so what that means for a certain product category, that this goes into the right direction. And many have started to be involved in creating these harmonized standards because they do this requirement interpretation and see that something useful comes out of that. And there's also debates about what kind of, I mean, there are the product categories in the Annexes 3 and 4, the important critical products in the CRA. And for these, they don't have any strict requirements, but they have higher requirements regarding conformity assessments. So that's also, of course, it matters which kind of products fall into these categories or not. And this is also something that's currently debated. But the good news is that manufacturers really can contribute to the discussion there. So for these descriptions, for this important critical product descriptions, for example, the EU has put out a draft description and that was open for comment. And I think a second version will come out in June and be open for comment. So there are ways to, and my experience is that the EU Commission has always been very open to getting input from the industry on details that they may have overlooked or things that are hard to do in practice or things like that. And it's after all, it's good news that some things are still vague because that still means that they're open to be defined. And I think any regulation with such a broad scope that wouldn't have a lot of room for interpretation would do a pretty bad job because you can't really preemptively answer all the questions and all the special cases that are out there. Do you see a changing attitude toward regulation overall from the security community? I mean, I can remember not too long ago that, you know, a lot of companies were pushed back against regulation. They wanted to self-regulate. But has that time kind of passed? Are they welcoming some kind of prescriptive guidance from government when it comes to cybersecurity? Well, I think that really depends on whom you ask. In case of the CRA, asset owners, operators are definitely welcoming the CRA because they have to regulate it all the time. And now finally, they have this blind spot with all the components that they have to buy from manufacturers and they have to trust that there's security in there. So now for the first time, manufacturers are regulated as well. So they definitely welcome that. Manufacturers obviously tend not to welcome it because, of course, I mean, it's additional regulation. It costs money. And it's some kind of documentation that you need to do on top. But working with manufacturers and with the product cybersecurity teams, they in turn often say, well, finally, I have a reason to direct some attention and money to all the things that we've been trying to convince people of doing in our companies anyway. So it really depends a lot on who you ask. And also, I think it depends a lot on who you ask, like, regionally, because, I mean, it's no secret that people in the EU are generally more open to regulating things than in the US, for example. And it's probably also no coincidence that the CRA is a EU regulation and not a US regulation. Right. Let's talk about the essential requirements for a little bit. I find it encouraging that there's a lot of security by design discussion there. A real focus on resilience and kind of maintenance of the product over its life cycle in terms of vulnerabilities and so forth. Just love to get your thoughts on kind of the way that the regulation is structured. And those are the kind of like what everyone should be aiming for. Do you think that they hit the target with those essential requirements? Or should it be a little broader? I think the best answer to that is that they're really... I mean, I've discussed the CRA with really many people over the last years. And I've heard, of course, I think all kinds of criticism that you can have around it. But all this criticism, and that's the same experience for people in the EU who have negotiated and written the CRA, they have also said all the criticism that they received about the CRA was really about the essential requirements. There was really... I don't remember a single debate being about any essential requirement being wrong or missing or being worded the wrong way or things like that. Debates were in other fields. I come to that in a minute. But that is for me a pretty good sign that these requirements really are industry consensus. So I don't think... Of course, you can always debate about details and requirements. But in general, I think these are the requirements that we need. They are not that many. It's just two pages of essential requirements, but they hit the right spot. And I think that they really do reflect a broad industry consensus that's long been there and that's now under regulation. I mean, even the S-bomb made it in there. We hear so much about security by design and by default and so forth, especially from CISA. You just hope it's more than words, that it's actually enforceable and it's able to be put in practice over the long term. The good thing is that they don't just write, do have any, I don't know, any kind of software development, security development life cycle, but they really have requirements more on the side of product characteristics that need to be in place. So in comparison to many other standards or regulations that say, okay, here's a life cycle that you need to follow for your product. You need to do all these things that in the end, your product becomes more secure. The CRA is more about, okay, this is the outcome. This is what needs to be in your product. And you care about how to do that, how to make sure it is in your product, but make sure this is the outcome. So the first point is make sure that there are no exploitable vulnerabilities in the product. You care about how you do that, but ensure that this is the outcome. And I think for regulation, that needs to be some kind of testable. That's the right approach to say, okay, the product has to be, these are the features and the characteristics that the product is going to have, because otherwise it's going to be yet another standard where you have some processes in place that don't guarantee you that there's good security in the end, because you can always do it good or bad. I think that it makes sense to achieve the CRA outcome. If you want to achieve that, then it makes sense to take any of the well-known security development lifecycle approaches. I think that's pretty clear, but companies and manufacturers are free to choose how they want to do that. And I think that's the right approach. As we come up on 2027 and the ultimate compliance date, just how do you think, what are some of the milestones we should be looking for in the meantime? And ultimately, how do you measure success for this? How do we measure success for, like as a manufacturer working towards CRA or for the CRA regulation? Okay. Well, if you're a manufacturer approaching CRA, I think there is an intermediate milestone you need to be aware of, that's the 11th of September, 2026. That's when the reporting obligations start. So you need to be able to report actively exploitive vulnerabilities and severe incidents for your products. So that's really, I always like to read it, it's actively exploitive vulnerabilities. So it's not a CVE coming up in a scan. You don't need to report that, but you need to report if there was an incident. So someone exploited a vulnerability in one of your products. So you need to be able to report that there's going to be a platform set up by ENISA, I think by the EU, where you have to report these incidents. So that's the first thing. And that you need to do for all products, not just for new products or products that fall on the CRA, but simply all your products. So that's the first milestone. And the second milestone, then of course, 11th of December, 2027, is where the CRA applies in full. So all products that you sell after this date need to meet all the CRA requirements, regardless of if you have sold them before. So if you sell them on 10th of December, they don't have to meet the requirements. If you sell them after 11th, they have to. And I think the, I always see four areas that people or manufacturers need to focus on based on how we work with manufacturers towards CRA currently. So that's first is product design. So really take these NX1 part one product characteristics and work towards, or maybe first build a product roadmap and say, okay, what kind of products do we have? What kind of products fall on the CRA and where do we stand regarding our products? And then pretty soon make the decision, which products you want to bring towards compliance and which ones you don't. Because that's like your roadmap for the next two years until 2027. And if you say, okay, you want to bring them towards compliance that they have some weak spots in this NX1 characteristics and essential requirements, then first really important thing to do is to do the risk assessment and to say, okay, here's the product. It doesn't meet this requirement, I think, or it has, I don't know how it should meet this requirement. So do the risk assessment, see what the actual risks to your customers are using that product. And then based on that, decide if and how you need to meet that requirement and then move towards that. And of course, see that your development process is changed in a way that your products can meet them in the future. Then there's the whole block of, so that was product design. Then there's the whole block of vulnerability management. So that's also the reporting obligations, but also for your products, you need to have some mechanisms in place to be aware of vulnerabilities and you have to have certain, at least you have to know how you distribute security updates to your clients. You also have to do that for free and how to write good security advisories because you have to publish those. And then there's the portion of procurement that I think is often overlooked, but also very relevant. And that's because most products, I mean, we all know that the whole supply chain issues, you probably have products in your products that also need to be CRA compliant and you really need to find a way to identify your suppliers and to make sure that your suppliers meet the CRA in a way that's usable for you. So for example, if they publish security advisories, it helps if you can use them for your own security advisories or if they meet security features, such as requirements a certain way and you want to integrate them into your product, then maybe you have certain requirements how to do that so that it makes sense for your whole product and things like that. And also have an idea on what existing suppliers are, how important for your product and how to make sure that you, because you in the end are responsible for the entire product, not just for the parts that you build yourself, but also for the parts that you procure from third parties. And then there's the fourth pillar is documentation. And that sounds simple and mostly it is because for a large part is simply documenting everything that you can show to market surveillance or to notified bodies in order to make sure that you're compliant and to prove that you're compliant. But then there's also, and I think that's also often overlooked, the information instructions to the user. So that really is a kind of cybersecurity handbook that you hand out to every buyer of your product that contains everything regarding security that matters to your customers. And I think that really, for consumer products, it doesn't matter that much, probably no one is going to read that apart from a few security nerds. But for B2B products, that really can be a game changer because that can really make your B2B customers very happy and it's really actually useful for them and save them money if you do that in a way that helps them to do their own security risk assessment faster. For example, critical infrastructure regulated customers. So if you sell a control system or PLC to a water utility, then they need to do their own security risk assessments. And if you deliver to them the information in a way that they can really efficiently use in their own risk assessments, then it will really save them time and money. Yeah, it's a huge baseline. Yeah, it is. And that's why these... And it's something completely new. If you buy a digital product right now, you don't get a cybersecurity handbook. You need to get all this information by hand, by requesting, by asking the manufacturer. I've spent so many hours on the phone with manufacturers on behalf of asset owners asking about basic security features or which protocol do you use for what or how does the architecture look like in this case? And this is all information. If you really provide that in the cybersecurity handbook in an easy-to-digest way, that's a game changer, I believe. Right. Yeah. So these are the four pillars, basically. So product design, vulnerability management, procurement, documentation. And that's the things that you need to work toward as a manufacturer. Sounds like the industry has a lot of work to do in the next couple of years. That's right. But to be fair, many of these things, it's not like they've been living under a rock. So vulnerability management, most manufacturers do that in some way or the other. Most that I've talked to are not very nervous about vulnerability management, for example. All right. So before we wrap up, Sarah, I definitely want to talk a little bit about some of the thought leadership you've been doing around bringing security to engineers and asset operators and not necessarily security people. And you've done a lot of work on like, I know at your S4 presentation this year on the cyber decisions diagrams, there's a really kind of interesting way to talk security to non-security people, if that's a fair characterization. I'd love to hear more about kind of how you came up with it and, you know, how successful you've been in kind of using it or sharing it with others. Yeah, absolutely. It's probably also a good timing because I think the video has been released this week, last week or something. I think so. Correct. Yeah. I actually watched that. We, I mean, to be honest, it's something I've been working on ever since I've been in the industry. So how to, you summarized it pretty well, how to communicate cybersecurity to non-security experts. It's also about how to get the expertise from non-security experts for security. So the input and the output. So how to get the knowledge from non-security experts that's really relevant for your cybersecurity engineers, for example, and also how to communicate it to people that need to work with the cybersecurity results. And I think the reason why I've worked so much on this is because one group, one large group of non-cybersecurity experts is engineers in OT cybersecurity. You always need to work with engineers because they have all the knowledge that you need in order to do good risk assessments. And I don't think we've done a good enough job in getting their knowledge in there so far. And that's why we've worked on that so much. And the approach we've come up is pretty visual approach. So you actually create basic diagrams on the basic functions that your product or your system has. And then we have some ways to lay out about these functions, risks that you may have and the tech scenarios and also requirements. So things that you change about your architecture, about your product, about your system because of cybersecurity. And if you have all this information on top of your functions, then you have three things that you can really easily communicate to everyone if you have a diagram like that. So it can really easily communicate how does my system work and why and what are the bottlenecks, for example, even for non-technical people. And how could I easiest attack it? What are the things that I need to change about it in order to improve its security? And you see all that more or less on the first look and you can make it easy to communicate. And we've been working with that, frankly, I use it every day. So we have a software tool that does it, that's pretty efficient in doing that. We do our entire risk assessment based on that. So in getting the information from engineers into the risk assessments, making them accessible and digestible for cybersecurity teams, and also in communicating the results of all these risk assessment and decisions that you make based on risk, for example, for the Cyber Resilience Act, that's really important. But also for critical infrastructures to communicate these results both to your own management and also to authorities and auditors and things like that. And these are really all these use cases from getting deeply technical people's knowledge into risk assessment, getting their opinions on the results and also communicating the results to people that are not involved with the technology in depth. That has proved really useful. Yeah. I mean, what I like about it is not only that it's the visual representation, as you mentioned, but you're eliminating a lot of complexity, a lot of the jargon that comes with cybersecurity. And I think in the end, a lot of that just ends up confusing people and steering people away from what they need to know. And this really brings it to engineers and asset operators on their terms, which is really important, I think. Yeah, we always say it needs to be their picture in the end. So it needs to be what they feel at home and say, well, this is what we actually do. And at first, because we're all used to doing it too complicated, at first, we always have those discussions on, well, but there's still this detail that needs to be in there as well. And we say, well, stop, because based on this picture that you're creating here, this diagram, you don't have to be able to build the system. You don't have to be able to run the system. You only have to be able to see whether cybersecurity or the overall resilience of the system, what matters for that and what measures you need to take for that. That's all. And then you can really leave out a lot of details and have a high level diagram that even people use that actually need to run systems and build systems in the end, as a first overview. And then they have more detailed diagrams on details, but what really struck me is that even engineers that are deeply in technology miss something like that, that really gives them an overview of what they have, like their whole systems and their security problems and their resilience requirements on one page. Yeah. I would imagine the engineers who see this are really appreciative of the approach. I'm just curious, have you heard much feedback from actual engineers on how useful it may be to them? They are the reason why we're doing that. And they often say, well, finally, cybersecurity always feels so like not really an exact science for us, right? So, I mean, engineers are used to having methods and calculations for everything. And cybersecurity is often a bunch of best practice that you somehow need to do. And risk assessment always feels a bit like not really scientific enough and also too far away from the reality, from the systems that they see every day. And they often say, well, this is finally something that speaks our language and something that we understand and that we feel good as being the foundation for an informed decision. Sarah, I think that's a good place to leave it. I really want to thank you for coming on the podcast. I think this was a really great discussion and I know people are going to enjoy listening to it. And I'm happy you were my 100th guest. So thank you so much. I appreciate it. Me too. Thank you. And soon again, I guess. Absolutely. We definitely need to do this again. All right. Have a great day. Thank you so much. Same for you. And congratulations on the 100th episode. No doubt. Thank you. Thank you. All right. Bye-bye.
