- 2 - 3 - 4-1

Building the Technical Case for Validated Asset Profiles

Inventory is a much maligned term - defining what is of actual value in profiling assets will help immensely
Ron Brash


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). Pending on your objectives, the first level of satisfaction might do in a pinch, but to obtain a certain level of security and risk reduction – organizations might just need a bit more.

To second another 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 that 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-diagram


As in the diagram, network traffic is forwarded to a location where a passive network detection appliance can see the traffic. This can 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, there 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)
  • And requires direct access to the appliances inorder 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 will 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 meaning 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.

After all, OTSM platforms can be deployed, talk to devices in there native tongues (protocols), and be integrated 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 screenshot of a standard EtherNet/IP (CIP) PCAP – the dissector is fairly well developed, and it is in it’s 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).

wireshark

Now the above example looks great - its easy to read, in clear-text form & uses a well understood protocol (all of which are going away in the future).  Then in the below screenshot, we can 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 tunnelled).

tls

But another challenge is knowing whether operators and tools know what to do with those values if they know at all.  In fact passive tools can only guess at 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 useful usecases, and especially when those values can be 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

Now 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 have to be able 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 only found these vulnerabilities (in addition to the open ports and other info seen above) using the NSE vuln 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

Alright, so if you read this far, you may be thinking – what does this have to do regarding asset inventory and device profiles? And from the above evidence – here is what is 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 right? I know – so up until now, most tools have been looking at heuristics and some obvious flags that provide a good enough basic profile. Unfortunately, if this was your main strategy, you need more than just a basic list to move forward and actually protect, and prevent attacks. 

To do that – you need an agent & actual authorised/valid communication while speaking that device’s language to obtain:

  • Versions of software
  • Patches that are applied (or missing)
  • Configurations, logic & datastores
  • 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

To end my article and to circle back, the above missing information when using only network detection is exactly why another approach is required to properly understand, maintain, prevent and remediate risks. And shamelessly, one of these solutions is of Verve’s platform, which also enhances/enables a number of other capabilities for asset owners to keep plants/operations running, secure, and compliant. For additional information, either comment below, reach out directly, or email us at sales@verveindustrial.com 


Learn more

Verve's Industrial Security Solutions
Verve Security Center Brochure

More Posts

Subscribe to Email Updates