In a rapidly digitizing world, the importance of cybersecurity in safeguarding manufacturing execution systems (MES) is becoming increasingly crucial. Sung Kim of iBase-t recently sat down for a detailed conversation with the Industrial Cybersecurity Pulse Podcast about the multifaceted components that contribute to a robust cybersecurity framework. The conversation shed light on the comprehensive and proactive approach needed in today’s global cybersecurity landscape, emphasizing that cybersecurity is not just about technology but also about people and processes.
The following has been edited for clarity. To listen to the full podcast, click here. To read part one, click here.
ICS Pulse: Could you discuss the role of employee training and awareness in mitigating cyber risk in MES systems?
Sung Kim: Absolutely. When we talk about breaches, we often refer to mandated training. We’re all familiar with password policies and how to protect them, but it’s more than that. It’s about a cultural shift. This isn’t just for the MES system, but for all tools and technologies. People often refer to this as cybersecurity hygiene. The moment you become complacent with this hygiene, things can go awry, much like with personal hygiene. There are some best practices that are quite simple. I would identify maybe four or five of them, such as basic protection.
For instance, do you know if there’s MFA, or multifactor authentication? Your password can be compromised, and people tend to use the same password across different websites. That’s why you need to challenge the password with something you know and something you are.
Many companies are moving toward password-less systems. They’re tracking your devices, your location and even your biometrics. Multifactor authentication is key for end-user authentication and for devices, including edges, tools and sensors. This is where the OOP, or the protocol, comes in, enabling the authentication of the device that’s trying to access. That’s basic protection.
Another key aspect is the encryption of data. Do you encrypt your data at rest and in transit? I’ve read articles about sensors, thermostats and other Internet of Things (IoT) devices that can be subject to hundreds of random attacks. Attackers don’t necessarily target you specifically. They scan IPs and ports all over the place because many vendors use default administrator usernames and passwords. We often use the same default administrator username and password when we deploy or install something, like a camera or a phone. Attackers use these default usernames and passwords to scan everything out there, much like phishing.
Encryption is key. In your enterprise application, because you cannot trust anyone coming into the facility, do you have encryption at rest and in transit? As you said, the zero-trust access control model allows only authorized persons to have access. Just because you’re a manager or a CEO doesn’t mean you should have access to everything. That’s a significant compromise factor.
Another important factor is whether you can restore your system to the same state after a compromise. Ransomware is a prime example. Do you have a practice of proper backup? We used to use it and we still do, for disaster recovery strategies. How quickly can you return to the same state once you detect a compromise? I believe these are the four main aspects of cybersecurity hygiene that we need to follow.
ICSP: How do you effectively prioritize and address these critical vulnerabilities or manage the flood of CVEs?
Kim: The most basic strategy is to stay with the latest and stable version of everything you use. With CVEs, due to the increased attention to cybersecurity, we have many people, like cloud engineers and security engineers at different companies, looking at different components and trying to find attack vectors or exploiting factors. For example, Log4j had a security engineer at Alibaba who discovered an issue, which became a big deal. The numbers that get reported when you scan your software, such as the number of criticals and highs, are a moving target. The same piece of software, scanned today versus next week, will yield different numbers. This is because there are many diligent security engineers and developers trying to find and fix things.
You should ask your vendor about their scanning process and how they identify CVEs. Do they have a proper scanning mechanism? Do they do it regularly? For instance, it should be done every build cycle. Let’s say a developer has a sprint of two weeks. Every two weeks, they do official builds. Some companies even do a daily build. Whatever the build cycle is, because you are introducing new components or new code into the system, you should perform a scan. Then, not only do you scan and identify the CVEs, but those CVEs should be reviewed by the component owner in the application development team. There may be a dedicated application security team, but they may not understand the impact that the CVE has on that component. So the component owners should review and address it.
They should also be diligent in reaching out to vendors or the open-source community to get the fixes. Sometimes, there are no fixes available. Then, you must push by ticketing, letting them know that this is important for us, and asking them to fix it so we can apply it.
My main recommendation for manufacturers looking at enterprise application CVEs is not only to look at the number of CVEs, but also to look at the mitigation plans from the vendors. Usually, there are three categories. The CVEs that you fixed within the patch or releases, those are the CVEs, highs and criticals, for which fixes are available from the vendors and open-source community. You upgrade, test and fix.
The second category is CVEs that do not apply to that application. This means that the CVE says, “Oh, if you’re using this component – and by the way, you are using this version of that component – then you are affected.” But the application itself does not use the regular expression from that component. So it doesn’t apply, and you can categorize it as such. But as a vendor, you must do your due diligence to prove that it doesn’t apply. You have test cases of using that component with a regular expression within the code and see, yes, it doesn’t apply.
The third category is, “Yes, the CVE is there, it’s critical, it does apply, but we don’t have fixes for it.” So what do you do? The vendors should provide a mitigation plan. You should ask your vendor, “What’s your mitigation plan?” It could be as simple as turning off that feature because we don’t have a CVE. We don’t want to open that exploit or do this workaround. And then until the next patch, when the fix is available, we’ll apply the fix. That’s the best thing you can ask for, those three categories, and especially the mitigation plan because many manufacturers want to know what to do when there’s an exploit. We need to guide them on how to address those, how to mitigate those.
ICSP: Where do SBOMs, or software bill of materials, fit into all this? How can they help with this process?
Kim: That’s a good question. This is where a lot of vendors like us sometimes struggle because we have been using a lot of components. You don’t have hundreds and thousands of developers working on a particular application. We use a lot of open-source components. We find things from commercially available components. Instead of building, you buy things. So that’s where you have a lot of dependencies. You should have a software bill of material, meaning [covering] all the dependencies that you use. There are a lot of tools out there that can generate those.
As I see it, it’s more important than just the dependencies and security-related issues. It’s also about license management. Are you using the licenses correctly? Some licenses restrict our customers from opening things, and we don’t want that. So we need to monitor all the components that we use. For example, a single developer might find a particular component very convenient, and it solves everything they need. However, they might not pay attention to the licensing and just include it. We need to monitor those and scan them.
The second thing I would recommend is to pay attention to the end-of-life of components. We’re seeing a lot of components reaching their end of life. When that happens, there are no more fixes available for the component. It’s important to manage the lifecycle of the component. As a software development team, you should have a comprehensive software bill of materials, at least internally, and make sure you have all the dependencies, both direct and transitive, with their versions.
I would also recommend keeping up with the open-source community. If there’s open source attached to it, then you need to look at how active the community is. If it’s just one person developing everything, even though it’s the top-of-the-line component that solves everything for you, you cannot really depend on your entire application on that one person. If they go on vacation, there are no fixes coming out. So all this information must be managed and monitored.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
