Building the Technical Case for Validated Asset Profiles

As my colleague, Rick pointed out in “Inventory or Asset Profiles – Which is more useful to ICS Cyber Security”, sometimes asset owners need merely an Excel spreadsheet CSV of IP addresses and basic typing information (e.g., Windows box), and sometimes they need a detailed profile of an asset (e.g., configuration data, policies, installed software and more). The first level of satisfaction might do in a pinch, but to obtain a certain level of security and risk reduction, organizations need a bit more.

To second another one of Rick’s points, “a fundamental starting point for any ICS security program invariably starts with a discussion about inventory” is absolutely true, but assuming that we already decided we need an accurate inventory of physical, virtual, and logical assets, then a vendor agnostic approach using only passive network detection would probably look something like the following:

Network traffic is forwarded to a location where a passive network detection appliance can see the traffic. This could be on a network tap, spanning port, trunk, etc… In simple terms, this is the easiest way to get a list of MAC addresses (if not altered by networking equipment), IP addresses, and some basic information about the asset including unencrypted (clear-text) and well-known industrial protocols attributes (e.g., Modbus standard PDUs). And requires minimal effort to obtain network traffic (assuming networking exists), and no risk to any assets directly for the most part.

Using the same diagram as a reference, a distributed approach may be needed where multiple sensors are deployed in a passive sense and could potentially be used for active conversations with some assets. This active approach may be polling assets as best as they know, but these solutions have a few problems for the most part:

• Active polling still does not enable or action any remediation for vulnerabilities found
• Needs to have device/account credentials (or PKI in the future)
• It requires direct access to the appliances in order to communicate

Most organizations, business units and sites are, for the most part, largely separated, and so this idea of a distributed model makes sense, but the results still need to be sent upwards into a holistic platform that has access to all of the data that a site operator can make use of.

In response, many passive asset inventory solutions are becoming hybrid solutions, meaning they do have some active functionality, but I suspect it may be too little too late. Other solutions are capable of performing detailed asset inventory management not only for PLCs, Ethernet connected sensors, and commodity systems/Windows/Routers etc.. Or, these passive/active/hybrid types of tools are there to enhance other OT systems management (OTSM) platforms by providing another source of information.

OTSM platforms can be deployed, talk to devices in their native tongues (protocols), and integrate with a variety of solutions that provide other aspects to the NIST CSF beyond detection and alerting. This is increasingly important as industrial OEMs and asset owners look to secure implementations of industrial control system protocols.

For example, if we look at the following image of a standard EtherNet/IP (CIP) PCAP, the dissector is fairly well developed, and it is in its raw binary/ASCII form. In secure CIP, the traffic will look very similar to HTTPS/TLS traffic (encrypted mumbo jumbo unless you have a method to decrypt the traffic).

This example looks great. It is easy to read, in clear-text form and uses a well understood protocol (all of which are going away in the future). But in the below image, we see encrypted traffic with little-to-no identifiable information other than by making several assumptions (e.g., port, and some strings, because the rest of the data is tunneled).

Another challenge is whether operators and tools know what to do with those values. Passive tools guess what is occurring and provide heuristical functions such as: that packet is a Read, another a Write, or a firmware upload. All of which are prevalent use cases, especially when those values are put to use for creating benchmarks or steady-state baselines. Unfortunately, without active communication on a host, here is what you might see for a Windows host with interesting elements in bold (using NMAP):

Nmap scan report for 192.168.193.138
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
MAC Address: 00:0C:29:64:FB:1B (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|specialized|phone
Running: Microsoft Windows 2008|8.1|7|Phone|Vista
OS CPE: cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_8.1 cpe:/o:microsoft:windows_7::-:professional cpe:/o:microsoft:windows_8 cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1
OS details: Microsoft Windows Server 2008 R2 or Windows 8.1, Microsoft Windows 7 Professional or Windows 8, Microsoft Windows Embedded Standard 7, Microsoft Windows Phone 7.5 or 8.0, Microsoft Windows Vista SP0 or SP1, Windows Server 2008 SP1, or Windows 7, Microsoft Windows Vista SP2, Windows 7 SP1, or Windows Server 2008
Uptime guess: 0.205 days (since Wed Sep 4 09:33:06 2019)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: Host: WIN-2OG1GENRT1H; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: -1s, deviation: 0s, median: -1s
| nbstat: NetBIOS name: WIN-2OG1GENRT1H, NetBIOS user: <unknown>, NetBIOS MAC: 00:0c:29:64:fb:1b (VMware)
| Names:
| WIN-2OG1GENRT1H<00> Flags: <unique><active>
| WORKGROUP<00> Flags: <group><active>
| WIN-2OG1GENRT1H<20> Flags: <unique><active>
| WORKGROUP<1e> Flags: <group><active>
| WORKGROUP<1d> Flags: <unique><active>
|_ \x01\x02__MSBROWSE__\x02<01> Flags: <group><active>
| smb-os-discovery:
| OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
| OS CPE: cpe:/o:microsoft:windows_7::sp1:professional
| Computer name: WIN-2OG1GENRT1H
| NetBIOS computer name: WIN-2OG1GENRT1H\x00
| Workgroup: WORKGROUP\x00
|_ System time: 2019-09-04T14:28:02-04:00
| smb-security-mode:
| account_used: <blank>
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2019-09-04 14:28:02
|_ start_date: 2019-09-04 09:33:34

NMAP is active, not passive, but for a passive tool to get this information, various interactions between devices would have to take place. And again, they are in clear-text, which means passively dissecting packets is only useful as long as it is able to decrypt the traffic or actively communicate with a protocol that does automatic key negotiation (e.g., HTTPS from the client to the server). Alternatively, it would need to decrypt asymmetric and symmetrically encrypted network traffic providing it has they keys, which is similar to the IT-worlds TLS terminators.

Even so, NMAP found these vulnerabilities, in addition to the open ports and other info seen above, using the NSE vulnerability script:

Host script results:
|_samba-vuln-cve-2012-1182: NT_STATUS_ACCESS_DENIED
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: NT_STATUS_ACCESS_DENIED

If you’ve read this far, you may be thinking, what does this have to do regarding asset inventory and device profiles? Here’s what’s missing:

1. Largely not validated and based on a number of heuristic fingerprints, which are not deterministic and not particularly accurate
2. Missing information regarding applications that may be installed, but not actively listening for connections
3. Actual patching (or missing patches) are unknown
4.  Configuration information such as registry options are not known
5. Policies and users are also not known

Wow! Up until now, most tools looked at heuristics and red flags providing a good enough basic profile. Unfortunately, if this was your main strategy, you need more than a basic list to move forward to protect and prevent attacks.

In order to do this, you need an agent and authorized, valid communication while speaking that device’s language to obtain:

• Versions of software
• Patches that are applied (or missing)
• Configurations, logic and data stores
• Actual host settings
• Devices this host communicates with (matter of factly)
• Accounts, policies for users etc…
• And other compensating controls that align to NIST CSF & CIS 20

The above missing information when using only network detection is exactly why another approach is required to properly understand, maintain, prevent and remediate risks. Verve’s cyber security platform enhances and enables other capabilities for asset owners to keep plants and operations running, secure, and compliant. For additional information, please contact us.