Cybellum’s Left to Their Own Devices podcast spoke with Dale Peterson, founder of the S4 conference and creator of many of today’s standard ICS security tools and techniques
Dale Peterson is one of the most experienced individuals on the planet when it comes to industrial cybersecurity. After a few years at the NSA as a cryptanalyst, he spent a decade focusing on financial cybersecurity before becoming fully engrossed in protecting the critical industrial control systems (ICS) in facilities like power plants, pipelines, medical facilities, and fresh water utilities.
We caught up with Dale on Cybellum’s Left to Our Own Devices podcast to discuss his views on the cyber-hygiene trend, getting budgets for OT ICS security, legacy infrastructure vulnerabilities and even extract some pro tips for product security teams.
ICS cyber risk management should balance cost vs. consequence
The recent cybersecurity goals published by the DHS are the latest addition to a growing global trend of ‘cyber-hygiene’. Everyone from governments to private industry alliances and cyber insurance companies are producing their own lengthy checklists. In turn, asset owners and manufacturers across all industries are demanding compliance from their vendors and suppliers.
“All these security controls aren’t a bad thing,” reflects Dale, “but they might not necessarily be what we should be doing to address cyber risk. We seem to have lost our risk based focus in this pursuit of cyber hygiene, and I really think our big wins could be in consequence reduction. We keep thinking that if we layer more and more protection on, we’re going to prevent attacks from succeeding, even though all the experts say it’s not a question of if, it’s a question of when.”
Dale emphasized how valuable it is to assess the realistic consequences of an ICS becoming completely unavailable or corrupted, especially for cyber-poor companies with very small budgets for security professionals and tools.
“They should spend their money making sure they have the ability to run manually, and putting some security controls in place to reduce the likelihood of having to run manually every week. But if they have to run manually once a year for a day, how much of a disaster is that? No impact on customers, minimal impact on expenses. Probably the biggest impact is to reputation, and with the right incident response planning and media strategy, even that can be addressed.”
CISOs have the opportunity to manage the risk-cost equation by prioritizing vulnerabilities within the understanding that there is never 100% secure.
Getting the Chief Risk Officer and CSO involved will unlock budgets for OT security
When asked who should be responsible for cybersecurity in industrial products, Dale points to OT security because they own the rest of the asset’s life cycle. The challenge many operations teams face today however, is that while they’re good at getting big CAPEX budgets, their ability to get OPEX budgets for security is weak.
One way for OT to unlock resources is to get the CSO to take ownership of the operational security, too. If that’s not relevant, Dale suggests OT looks at the IT security budget. “You’ll see it’s massive… Operations are responsible for the reason the company exists in most cases, right? Manufacturing the product or service. It shouldn’t be hard to get some money because, as a percentage, it’s a small amount for the critical thing.”
The next step is convincing the board and executives. This is where Dale recommends bringing the Chief Risk Officer onboard: “Cybersecurity isn’t an end goal. Cybersecurity is designed to address risk, and we see all the time that operations, even IT and IT security, don’t really understand what matters to the company.”
“You need to look at [the board’s] risk matrix and considerations,” explains Dale. “A board is worried about things like customer impact, financial loss, environmental loss, safety, and so on. If you can make your case properly, in relation to their risk matrix, [with a roadmap, milestones, and real plan,] you’ll get funded.”
We’re still a long way away from completely secure legacy devices
Years of IT/OT focus on network security has resulted in the neglect of security for legacy devices and systems, many of which are still at the core of modern civilization’s critical infrastructure, automotive components and medical devices.
“Protocols, level-one end devices and PLCs, that are actually communicating with the sensors and actuators, are oftentimes insecure by design,” says Dale, “They’re working exactly as they’re supposed to work, but have no authentication. Once you get access to the devices actually running the process, access is equal to compromise.”
Although there is hope for change with new secure versions for protocols like Ethernet/IP and MODBUS (which was first released in 1979 and is still used today!), the main question for ICS vendors, according to Dale, is will clients use them. “We’re two decades in now and we’re in the same place… It could be another decade before the ‘insecure by design’ problem is solved.”
The pressure is on asset owners to take control of their vulnerability management and gain visibility at the very least.
Pro Tips – Be humble, don’t ignore secure deployment guidelines and keep SBOMs updated
To wrap up, we asked Dale to share some tips for product security professionals.
“As security professionals, we understand our field so well. We go to places that have little or no security and kind of shake our heads wondering ‘What are these people doing? Don’t they understand the risk?’… [But] we have to have a little humility. They might be not where they need to be in security, but boy, they’re really good at the engineering they’re doing. These things are running the world.”
Every vendor today delivers their software or hardware components with a detailed Secure Deployment Guide. “Unfortunately,” Dale says, “I’m amazed at the amount of times those are just completely ignored.” In most instances it’s because the teams installing these systems have been doing it that way for years.
As a consultant, Dale conducts factory acceptance tests and audits the security development life cycle. He always checks if SBOMs exist and are maintained.
“[I’ll ask] Do you have an SBOM? Show it to me, scroll through it. Are the components really old? Are they running 10 year old versions? If you ask to see an SBOM that’s a few versions back, you’ll get a feel as to the level of control the product vendor has.”
Maintaining and monitoring up to date SBOMs is something everyone should and can be doing. “It doesn’t take days,” says Dale, “it takes minutes or a few hours.”
Listen to the podcast here to learn more.
