The podcast features Mike Lennon and Rod Locke from Fortinet discussing IEC 62443-4-1, a standard for secure product design in operational technology (OT). Rod explains that 4-1 defines practices for integrating security throughout a product’s development lifecycle, from design to field support. Fortinet recently achieved maturity level 2, meaning they systematically follow these practices, offering more confidence than level 1, which only indicates defined but inconsistent practices. This certification helps differentiate vendors by providing an auditable standard, saving customers from performing their own extensive security assessments. For OT environments where devices may remain in the field for decades, the standard ensures vendors have processes for vulnerability management and security updates, though the duration of support depends on vendor commitments. The standard is becoming a de facto global benchmark, with sectors like energy, manufacturing, and maritime increasingly adopting or referencing it in regulations. Rod notes that while 4-1 certifies development practices across all Fortinet products, 4-2 is product-specific and will be pursued for key lines. Overall, the certification streamlines trust and compliance, helping operators prepare for regulatory changes.
Hello and welcome to the Security Week podcast. My name is Mike Lennon. I'm really excited about this conversation. As many of you know, OT security is near and dear to me. As I head up our ICS Cyber Security Conference and these type of topics are always ones that I enjoy. This particular session, we're going to dive into kind of decoding IEC 62443 -4-1 standard for OT and I've got Rod Locke from Fortinet today. We're going to dive into, again, my favorite topic of industrial cybersecurity. So as IT and OT environments converge, the focus has shifted from kind of the bolt on security to ensuring that security is baked in during the development cycle and managing, you know, managing more, coming from the vendors, I guess, in companies like Fortinet's sense. But Rod, I'm going to kind of turn it over to you, you know, some of these standards can be a little bit confusing. So to kick things off, can you kind of dive into what is the IEC 62443 -4-1? Yeah, so 6243, there's a lot of stuff in 6443, there's a lot of sections that apply to different things. And yeah, we're talking today about 4-1 and to some extent 4-2, which is the product certification. 6443, 4-1 is on secure product design lifecycle elements. So think of like, you know, the security of the product, security capabilities in the product, how the product is designed, how you verify those things through development. So that's really the focus. There's other sections of 62443 covering specific products, covering systems, covering services. So it's definitely a broad standard. But yeah, 4-1 is really the kind of practices that you need to have in order to be able to deliver a secure product. Okay. So getting a little bit deeper, I saw that recently Fortinet achieved that IEC 62443 -1 start at the maturity level 2. Can you kind of break down for our listeners what that means specifically to the OT space and what maturity level 2 signals about this, about kind of the engineering discipline that goes into this? Yeah, that's a great question. So part of the maturity levels are, it's a little bit chicken and egg with doing the product certification. So we actually expect to be moving up once we have some 4-2 product certifications in place. Maturity level 1 means that you have some practices defined. You're not really following them systematically. So it's not really that terribly reassuring if you're a CISO or you're a notesecurity person. If a product just has that level 1 because you're not necessarily doing it, you know, 5 days a week in your design practices. So 4-1 really covers, again, the hardening of the product, security hardening of the product, the security features of the product, and then all the verification that you're doing that. And all the practices that you need to have in place to support that going forward in the field as well. So all of you know, being able to make sure you have a practice to provide security updates for the product. Okay. And so, you know, diving into secure by design, you know, hear that a lot secure by design. How does this certification change how the product is actually built specifically regarding threat modeling risk assessment before you guys even write code? So what it's looking for, it is looking for something that is a secure by design kind of approach, which is what you see from, and I mean vendors like for that have been doing this with under other standards. We signed the early sign of the CISO secure by design pledge. So, secure by design means that you have all that hardening and security features available. It's often related to secure by default, which is more about how the product ships and what things are turned on. But especially for some of the automation vendors building PLCs, if you've been in the OT security space for a long time, you would have seen this that, you know, like the early days of, you know, PLC and DCS design, there wasn't a lot of thought put into security. So, having the ability to, you know, the four dash one of four dash two standards really built for those systems more so than the network security components like fortenet. But we've gone through the same certification. So, I'd say four dash one and four dash two are really help kind of codify a bunch of expectations that a lot of those automation vendors are now thankfully meeting in the new systems, right? Absolutely. Okay. And so that kind of brings me to my next question, which is kind of addressing that sales versus reality gap. You know, being on the media side, you know, I can say that almost every vendor claims to be secure, right? But how do these, you know, certifications and independent validations, you know, how do they help? Sister is differentiated when it comes to, you know, marketing versus having documented repeatable processes and, you know, gets more trusted. And the end is just more trusted product. Yeah, it's, I mean, there's trust in your, your vendor, which is one thing, but then, you know, verifying at a fairly final level of detail, a lot of these, that a lot of these security practices are being followed. You know, I've, I've been in the product space for a long time and before you had standards to point to it's the same thing you would see with, like some of the ISO standards, where if you don't have the ISO standard, okay, now as a C, so I need to send you a questionnaire with like maybe 400 items on it to say, do you do this, do you do this, do you do this. And show me evidence that you're doing all these things. What this does is an is an auditable set of those capabilities controls practices that the C so can go, okay, I know that anything coming through the door with this certification is going to have all of these things in place. Somebody else has gone through the trouble of auditing it and I don't need to do that exercise myself for every vendor for every project. So it's a huge, it greatly streamlines things from the C so perspective and from the vendor, whether it's for net or one of the automation vendors, gracefully streamlines what they need to target, right, they're not trying to figure out the kind of super set of, you know, 50 different C so's question areas that they're targeting a few different international standards that cover all the areas and most people are going to be concerned about. So that's really kind of upping the maturity game for everybody in terms of what they're expecting. And I would assume many of those assessments can be quite lengthy and take some time and resources as well during the process. Many hours that I'll never get back. Yeah. Yeah. From what I went through those processes. Yeah. All right. That's that's a quite a benefit itself. And so it's kind of shifting over to the long term security of assurance. OT hardware often stays in the field for years, you know, not not too. It's not unfrequent. I infrequent. I guess that you hear these devices out in the field for 20 30 plus years. You know, how does this certification address the kind of long tail of security to ensure that secure engineering kind of extends. So the lifetime of these devices, you know, extends the updates and maintenance as kind of threats of all. You know, how how is that lay apart? Yeah. So there's kind of two parts that some of it's covered by the certification. Some of it is covered by what you have from a particular vendor, whether it's for or not or someone else. So the the standard does include provisions for how you're going to handle. You know, security weaknesses. So you find vulnerabilities in the product or you need to make updates for. To do further hardening. It's got processes where you're going to. Basically, you're committing to. To care and feeding of those products in the field. Once they've been deployed for, you know, well into the future and making sure that they get those security patches. They need to stay secure because we don't. You know, secure by design doesn't mean that you've achieved perfect security that when you ship a product at the door. But it does part of the 64 for three. 4-1 is looking at, okay, you know, you're doing your best due diligence. You continue to do that due due diligence as new types of attacks and techniques come up. And when you find issues, how are you going to update devices in the field? So being able to ship those firmware updates well into the future and the. You know, how far into the future is maybe a different question, right? That's more down to the. That's more down to the the commitment from the vendor in terms of their lifecycle commitment. And you'll see different things, whether it's an automation vendor. The cybersecurity vendor. Yeah, networking vendor. They might have different commitments there. But if they're achieving 64 for three, they've got something in place that says yes, we're doing. The security patch as well into the well into the future for these devices in the field. So that is a huge issue with your. So do you see this kind of helping? I guess the end of life cycle for some of these devices, right? You know, for support at least on the software side. You see a lot of end of life and support. They're not going to patch it is does kind of having this in place address that or is that a completely. I don't think it necessarily changes it actually. So you. If I come up with you know somebody might ship you.
piece of equipment now, whether it's 62443 certified, they're committing to continuing to offer these security patches, but eventually it's going to head into some level of obsolescence where they just cannot put the latest protections on or they need to stop supporting it at some point. So I think eventually you buy something today, 20 years from now is every vendor still going to ship you a firmware update to fix 400 buildings, you know, possibly not if they haven't committed to 20 years. So I think those are kind of different questions. Yeah, eventually too. I think you're still going to have, you know, that kind of, okay, somebody found something in a device that's 20 years old and the vendor says, yeah, we're not really supporting that anymore. We really need you to upgrade. Yeah, that's a little bit. Right. How about just kind of thinking about regulatory and compliance requirements? I'm assuming that does this help in that area, those areas? Yeah, and I think what we're seeing kind of looking back at how some of these standards evolved and where the market and different verticals have evolved, we started off the first sort of mandatory cybersecurity standard was NERC CIP with fairly serious teeth behind it in terms of enforcement and auditing and very prescriptive requirements in terms of how you architect your system to achieve NERC CIP. 62443 is a little bit, a little bit more open ended, you know, if your NERC CIP compares more to 624433-3, which is on your really your deployed system and the NERC 624433-3 is much more about, you know, you've rather than NERC CIP say you have this security perimeter and these are all the things we expect to see. 3-3 is a little more open and says, okay, well, you need to define some different security zones and define what needs to move between those zone and conduit model from, you know, taken out of IAC 99 originally. And the, so it is a little more open, but I think kind of the benefit to having some of these standards, whether it's this or whether it's the NIST standard, it gives people who aren't in a regulated environment, something to kind of target. And you can kind of see which way the winds blowing. If you're in a, you know, if you're in Europe in a manufacturing environment, you know, two years ago, maybe you weren't critical manufacturing. Right now, maybe you are critical manufacturing you're under NIS2 and you could probably figure out that, okay, it would be good to look at what the NIS requirements are and the related 6244-3 requirements that people expect. By the same token, we started to see some sector specific regulatory requirements for things like maritime where they're basically just mapping back to 6244-3 and saying, okay, these are the set of standards we're going to apply for equipment on maritime vessels. So it is kind of becoming the de facto global standard, you know, for, and people have their criticisms of 6244-3, but there's a lot of great things that it's targeting that's sort of raising the, you know, raising the bar where you don't have the sort of like, you know, new device comes onto the market, move fast and break things, get it shipped, you know, no security by design, no security by default. And then we're going to try and add that all on later, meanwhile you've deployed millions of these devices, right? So we've, we've run into that problem enough times that we know, you know, it's, you know, I'm happy with the opposite approach of people kind of realizing, okay, like 6244-3 is kind of a great thing to at least track to as a product company. It's a great thing to kind of model my OG security program around if I'm an operator, you know, model my program around 6244-3 and hopefully be ready when a new regulatory requirement comes in. So you're sort, you know, working with customers in the field, you know, are you seeing certain sectors that are getting more pressure to adopt these type of standards? Is it mostly, yeah, it's in other industries as well. Yeah, and it's really the more critical the sector, the more there's some kind of regulatory pressure around the world. I would say the one that is kind of because of, because it's global, the energy and oil and gas industry have, have kind of, there hasn't been a lot of markets haven't put a lot of regulation on them, but they do, most of those companies are operating in enough environments they have to meet regulatory requirements in a bunch of jurisdictions. So they've got operations in Singapore, they've got to do something there. They've got operations in the GCC countries. They've got to meet some regulatory requirements there again in Europe. So obviously the North American utility sector with Nick Stip has been doing this for quite a while. I would say the one that is kind of on the cusp has been manufacturing, you know, manufacturing like paper clips, nobody considers it, you know, critical. There are kinds of things that are manufactured in countries that are governments have realized there are certain things that are critical to their economies and that they've started to regulate the more like they do some of the other critical infrastructure. So that's the one that's really kind of kind of rising. And then I would say, I would say maritime, the way maritime is regulated has tended to be a little bit top down. So they've just gone straight to one of these international standards and said, you know, year 2627 for the, for the systems on these vessels, they're mapping back to the 6443 standard, you know, pretty directly here where there really wasn't much of a requirement a few years ago. Interesting. Okay. And in terms of, you know, as a product company, what can you, and I don't know if this is kind of beyond the scope of this conversation, but out of my own curiosity, you know, is this a point in time certification for a specific product? Or is it something that you guys need to do in an ongoing basis to maintain that certification? Yeah. So it will be, it does require renewal. What we get certified on is our practices as they apply to, I think in our case, we apply them to basically our, you know, we have a uniform set of practices across all of our products. And Fordnet has a lot of named products. When you go through 6443, 4-2, that one is product specific. So if you're a automation vendor, you'd have one PLC or line of PLCs because you can apply it sort of to a family rather than a specifically single model or skew. But that certification applies to, it does have to apply to specific products. And they're going to look at all the things you said you were new, how to do really well in 4-1 are being applied when you ship products under 4-2. But for 4-net, we will, we're going to pursue 4-2 certifications on certain key products to start with and then build out. But the 4-1 for us, because we're using the same practices across everything we have a set of policies and security practices that we follow, the 4-1s really covers all of that and then we sort of go through the 4-2 process for specific product lines. Okay. Next up, that helped me on my end. So that's really certifying the secure product development, best practices that you guys are doing. Exactly. Yeah, the 4-1 is and then 4-2 is the product itself secure and that's where you, that's what, you know, the C-Store or the OT security buyer ultimately wants to see is you have these in place on the products that we're installing and under some of the regulations that's becoming expected. Okay. Excellent. Well, I appreciate that. I appreciate the update and the education on that. So I hope everyone found this useful, I'd like from 4-net. Thank you very much for listening today. All right. Great chat with you Mike. All right. Thanks, bud.
Podcast Summary
Key Points:
IEC 62443-4-1 focuses on secure product design lifecycle practices, ensuring security is integrated from development through field support.
Fortinet achieved maturity level 2, indicating systematic adherence to these practices, which provides greater assurance than level
The certification helps close the gap between vendor marketing claims and verifiable, auditable security processes, reducing the need for lengthy customer questionnaires.
It addresses long-term security by requiring vendors to have processes for vulnerability handling and security updates, though lifecycle support duration remains vendor-specific.
The standard is becoming a global benchmark, influencing regulations in sectors like energy, manufacturing, and maritime, and helps operators prepare for evolving compliance requirements.
Certification requires renewal; 4-1 certifies development practices across all products, while 4-2 is product-specific and will be pursued for key Fortinet products.
Summary:
The podcast features Mike Lennon and Rod Locke from Fortinet discussing IEC 62443-4-1, a standard for secure product design in operational technology (OT). Rod explains that 4-1 defines practices for integrating security throughout a product’s development lifecycle, from design to field support. Fortinet recently achieved maturity level 2, meaning they systematically follow these practices, offering more confidence than level 1, which only indicates defined but inconsistent practices.
This certification helps differentiate vendors by providing an auditable standard, saving customers from performing their own extensive security assessments. For OT environments where devices may remain in the field for decades, the standard ensures vendors have processes for vulnerability management and security updates, though the duration of support depends on vendor commitments. The standard is becoming a de facto global benchmark, with sectors like energy, manufacturing, and maritime increasingly adopting or referencing it in regulations.
Rod notes that while 4-1 certifies development practices across all Fortinet products, 4-2 is product-specific and will be pursued for key lines. Overall, the certification streamlines trust and compliance, helping operators prepare for regulatory changes.
FAQs
IEC 62443-4-1 covers secure product design lifecycle elements, including how a product is designed, verified, and hardened for security. It focuses on the practices needed to deliver a secure product.
Maturity level 2 indicates that a vendor has defined and systematically follows security practices for product development. It provides more assurance than level 1, which only means some practices are defined but not consistently followed.
The standard codifies expectations for hardening and security features, requiring threat modeling and risk assessment before code is written. This ensures security is baked into the product from the start.
Certifications provide independent validation of documented, repeatable security processes, reducing the need for lengthy customer questionnaires. This builds trust and streamlines procurement for CISOs.
The standard includes provisions for handling security weaknesses and providing updates over the product's lifecycle. However, the commitment duration varies by vendor and may not cover devices beyond their support period.
Yes, it is becoming a de facto global standard, with sectors like energy, manufacturing, and maritime mapping it into their regulations. It helps organizations prepare for new requirements like NIS2.
Chat with AI
Loading...
Pro features
Go deeper with this episode
Unlock creator-grade tools that turn any transcript into show notes and subtitle files.