The foundation of an effective operational technology (OT) Cybersecurity strategy is documented knowledge about the specific process control environment including the assets that form the automation system. OT asset management enables end user organizations to visualize the industrial control system (ICS) assets they have including where they are located, ensuring that all assets are tracked so they can be secured properly. But more importantly, the best solutions provide details on how the assets are connected physically and logically to form the holistic automation system backbone of the ICS. Want more reasons to consider this a crucial benchmark step in your ICS Cybersecurity strategy? Ok, fair enough. Here are 5 more no fluff, real reasons to include operational technology asset management into your cybersecurity strategy. Just 5, certainly not the only 5, but nonetheless 5 good reasons (especially number 5).
1. Vulnerability Awareness
We can think of vulnerability as one of the three ingredients of the risk recipe, the other two being consequences and threats in most modern Cybersecurity risk models. Manufacturers, the US government, and Cybersecurity professionals spend significant effort and resources to make vulnerability information available to end users, integrators, engineers, and the ICS community at large. But what is a vulnerability in the context of automation assets like a PLC CPU module for example? When we think about a PLC module, there are a lot of details that would be needed to effectively characterize this asset. For example, there might be a hardware version, firmware version, multiple communication interfaces with specific protocol capabilities and characteristics, a serial number, maybe a removable media slot for a flash device of some specific format, and of course the manufacturer, model, and model line details. Any one of those categories of information could be linked to a vulnerability that is published. There are two worlds and a lot of gray in between that represent the reality. World 1, you have a solution to managing assets that allows you or someone within your organization to easily reference these details and perform ongoing checks of your assets for vulnerabilities, end of life information, known functional issues, etc. on a frequency, schedule and method of your choice. World 2, you don’t have this. You believe that perhaps a vulnerability you are aware of may apply to an asset you have in your system. You will have many options, but none of them very appealing nor sustainable. Most people have many other things battling for their time. Consequently these vulnerabilities often go unchecked and undocumented in many systems and in many industries. We are generally living in World 2 as a collective, but that can change with a new emphasis on automation asset management in these OT systems. What method? Any method that will be sustainable. Pick a method that works that will be maintained. Write a procedure for it, audit it, maintain it and make it policy moving forward.
2. Provides Control System Software Cost Control
When organizations know what software they have, they can often upgrade it to avoid purchasing a new license for the software when systems are modified like during a hardware refresh or when additional license features are needed. Not only the organization but also the integrators and design consultants who work to continually evolve these systems can benefit from this approach. This software is often reasonably expensive, and without details simple upgrades like hardware refreshes become unnecessarily costly when you factor in a software purchase outright vs. an upgrade discount offered by many manufacturers. Many times there are reconnaissance methods to determine this license information, but often it is at this point that the end user becomes aware that the software was never licensed in their name to begin with and/or the upgrade path is tied to an integrator that is no longer in business. The manufacturer would love to help but doing so would violate some policies put in place for a good reason on their end. This often means repurchase and can easily double, triple, quadruple or more the cost of something straightforward like a SCADA hardware refresh. Managing too many software applications without a systematic approach increases the security risks that come from outdated software or software that hasn’t been patched which falls under the Vulnerability Awareness category of good reasons to do this. With proper OT asset management, organizations are better equipped to control software requests and software purchases and can easily provide this information to the smiling faces of 3rd parties working on their systems like integrators and consultant firms. Do this and everyone wins…except maybe software manufacturers one could argue but, these platform providers don’t have any interest in making lives difficult or selling software products unnecessarily in my humble opinion. On the contrary software manufacturers and vendors are of great help in these instances. Nevertheless, it seems reasonable that responsibility to keep this information documented and organized fall in large part on the end user.
3. Helps Ensure Control System Software is Updated and Patched, or at a minimum indicates the current patch level
Older versions of software and software that isn’t properly patched can be a security risk for an organization. This is not a new thought; however, effective asset management provides details on assets in the automation system as well as spare ICS assets in storage and should be treated like critical information. With accurate and complete inventory data indexed in this way, OT administrators and 3rd party organizations working for end users can verify that all automation system assets are accounted for and the current status of their updates and patches is apparent. The process and frequency of updating ICS software platforms is a much larger one with many perspectives, but again in this case knowledge is power and provides the ability to make informed decisions about your course of direction in this regard.
4. Must have this for a Detailed Cybersecurity Risk Assessment
One of the first steps in developing a Cybersecurity strategy that is effective and specific enough to make a real impact to an organization’s security posture is a Detailed Cybersecurity Risk Assessment. A Detailed Cybersecurity Risk Assessment is more than a Gap Analysis. A Gap Analysis approach does not typically require an automation asset inventory because it doesn’t consider the specific systems architectural design or specific assets within that design. Nor their configuration or version characteristics. Nor their specific control capabilities. The output of a Gap Analysis is therefore limited to set of security controls and recommended policies that should be established based on the SME user input and general characterization of their system and are rarely specific enough to enter immediately into implementation. In a Detailed Cybersecurity Risk Assessment, the asset inventory is a critical starting point. Not just for the Cyber Vulnerability Assessment where this information helps verify the existence of exploitable vulnerabilities in your system. But also, for examination of the configuration details, network addresses, VLANs, network segment information, and quantification of the assets security level capabilities to provide the necessary controls for a network zone or conduit. An organization cannot be effective in identifying and quantifying risk without a complete, accurate, and detailed automation asset inventory and a management strategy for maintaining this information. It is arguably step 1 in many risk assessment methodologies.
5. Because this is a security control in and of itself!
There are many security controls for many different applications. However, ISA/IEC 62443 is one of the primary sources of ICS Cybersecurity standards and guidelines for OT systems. I offer that 62443 Foundational Requirement category 7, Resource Availability, is hinting at the importance of having an asset automation inventory in security requirement control SR 7.8 – Control system component inventory, but I am open to other interpretations of this. 😊
Comments