Software inventory is so important that it keeps a top rank on the SANS/CIS critical security controls for many years. This is easy to explain because at the end of the day, what any cyber attacker wants to achieve is to exploit software. If you don’t really know which exact software products you have, getting a clear picture of vulnerabilities and risk is impossible.
Software inventory benefits extend well beyond cyber security
However the case for software inventory gets even more convincing once you realize that OT security is by far not the only use case for it. A solid inventory is needed for lifecycle management, maintenance, plant planning, and audit/compliance as well. Think about the following requirements:
- You need to know which software products are no longer supported by their vendors, or will soon be.
- You need to know about any known problems and incompatibilities of specific software products for maintenance and plant planning.
- You need to be able to identify if a new/renewed control system actually comes with all the software versions that are in the specification, and match your requirements.
- You need to be able to verify the number of installed software packages of a specific product for license management.
- You need to verify that software and firmware deployments comply with corporate standards.
The bottom line is, you can get a whole lot of benefits out of a comprehensive software inventory, and demonstrate value way beyond reducing cyber risk — which is, let’s face it, always a bit hypothetical. So why is nobody doing it? The simple answer is, because it used to be hard due to a lack of tooling.
What you need for an evergreen software inventory
There is no way that anybody could manually build and maintain a software inventory. Automation is required. In IT, this is well understood, and practiced for many years. Admins all over the world use inventory tools that suck out data about installed software from Windows boxes using the Windows Management Instrumentation (WMI) interface, and store this data in a database that is usually part of a CDMB system.
However, that alone wouldn’t do the trick in OT due to the high number of non-Windows systems. Your PLCs, RTUs, protective relays, smart sensors and so on don’t run Windows (thank God). They run firmware which plays a similar role: It must be inventoried for the reasons pointed out above. You want to know if some of your controlleres run outdated firmware that comes with known vulnerabilities, is no longer supported by the vendor, or has some compatibility issues with other products you are using.
So how do we get that information from all the automation components? The simple answer is, by using the dedicated means that the vendor has provided for doing just that.
Virtually every major automation protocol includes functions for querying device metadata, including firmware version. Why wouldn’t we want to use that to our advantage?
Think about Modbus function 43 (read device identification) or Ethernet/IP (list device identity). Some of these functions are so elaborate that they even allow us to enumerate the firmware of I/O modules on the backplane of your PLC or RTU. And all of this with no “hacking” or guesswork involved, just by using legitimate protocol functions.
This is the approach that we take in our OT-BASE Asset Management Platform. Windows boxes are examined via WMI. Linux/Unix boxes via SSH. Ethernet/IP devices via Ethernet/IP. Profinet devices via Profinet. And so on. The result is a comprehensive and reliable list of the operating system versions, installed applications, security patches, and firmware you are running. No guesswork is involved because data is not extrapolated but directly provided by the device, which we politely ask to deliver that information using designed-in functions.
Putting the data to use
Collecting software/firmware product data is only the first step, because at an atomic device level, this information doesn’t help much. It needs to be consolidated so that we can see the forest rather than a bunch of trees. This is where our OT-BASE Asset Center comes in. It allows you to answer the following questions with a couple of mouse clicks:
- How many instances of software application X, operating system Y, firmware version Z do we have installed, and where?
- Where are all devices that are vulnerable by CVE X?
- On which machines is security patch X missing?
- Which systems are out of vendor support, or will shortly be, because they are running software version X?
- Could the reliability problems that we are experiencing with station X be due to a software configuration that is different from station Y, where everything works fine?
We could continue the list, but you get the point. The ability to analyze a comprehensive and accurate OT software inventory opens up lots of opportunities for saving unnecessary labor, getting results faster, and spotting issues before they turn into problems.