Keeping track of all ICS asset history and accurate status in a global inventory is critical not only for purposes like maintenance, cost management, and environment optimization but also for the system’s security. Well-implemented and maintained inventories are key to ICS security programs, since you can’t protect what you don’t know about. Knowing what is on the ICS network, and what should normally be there at any instant, is very important to take action toward any unexpected events.
The ICS inventory should contain all the OT assets with their basic attributes, such as the static information about the manufacturer, model, serial number, etc., as well as the dynamic information, such as the physical location and geo-location, IP and port configuration, alarm settings, software update version and patch status, and so forth.
The inventory should also include metadata that can provide more context about the assets, to be used for maintenance and security such as known deficiencies, possible compatible replacements, known vulnerabilities and exploits, and related threat intelligence. This information reduces the investigation time — especially in ICS field networks, which are usually operated by small teams that may have IT or OT knowledge gaps — and increases response efficiency in emergency cases.
Creating the ICS inventory in Elastic makes it possible to search and find relevant information about the assets we want to secure quickly and at scale and in the same place where security data is being ingested and alerts are triggered. It also enables an exceptional graphical view in Kibana via Maps, Graphs, and Canvas.
It is usually impossible to build and maintain the ICS inventory manually. The more effective method is to use the data flowing to Elastic, particularly the network data, to capture any new assets and update the information of the existing ones. Elastic can transform time-series data into an entity-centric view that helps track each asset and summarizes its configuration — for example, to automatically list a device’s open ports and the source and destination IPs it is trying to communicate with. This way, the inventory also automatically stays up to date.
The inventory information can be also automatically enriched with other data from various internal and external sources (e.g., other data indices, external databases, CMDB). Below is a screenshot of an entity-based view of the sample Modbus data. This view summarizes critical information, such as all destination IP addresses and ports that the device communicates with, and the protocol addresses for the Modbus communications. This information is continuously updated by the transform job and can be used to create alerts in case of pattern changes.
Leave a Reply