¶ What is Digital Asset Awareness?
The concept of maintaining an asset inventory is not new, in fact almost every security framework or compliance standard focused on cybersecurity requires some level of inventory. We define digital assets as inclusive of hardware, firmware, software and data assets. Analog sensors and gauges fall within the category of Engineered Controls which we will cover in a separate article.
For instance, a Sharepoint server farm is made up of multiple physical or virtual servers (assets) that run Microsoft Windows server operating system (asset), supported by various firmwares (asset), SQL server (asset), Sharepoint server software (asset) and data (assets) hosted by the Sharepoint infrastructure. The reality is that in many large organizations, each of these components may be managed by different entities:
- Datacenter Operations - physical server, BIOS firmware RAID controller firmware, IPMI
- Networking Operations - routing and IP address management
- Virtualization Team - virtual server
- Windows team - Windows OS
- Business Application SMEs - Sharepoint
- Data owners
- CMDB team - hopefully capturing all the above details but its likely you have an IT CMDB separate from your OT CMDB
Additionally, digital asset awareness encompasses more than just the presence of the asset, but additional metadata about the asset such as stakeholders, location, ip address and hostname, Purdue layer, functions they support, dependencies they rely upon for functionality and even the operational state of the asset. This becomes the foundational bedrock for other technical controls we layer on top, as these assets are frequently what we are defending, in order to secure our critical functions.
¶ Video Summary - Digital Asset Awareness
https://www.youtube.com/watch?v=1qxVSJwjlCo
¶ Why is it important?
Without good inventory, we don't really know what it is we are protecting. Without knowing why it is important, we don't know if it's worth protecting. And when we see inbound attacks or lateral movement in our monitoring tools, if we are not sure what assets live there, it makes it incredibly hard to know what to do about it.
Take the log4j issues from late 2021. If you knew you had vulnerable log4j in a HMI, but you did not know where all instances of that HMI software were installed, it would be challenging to locate them all.
¶ Why is the asset itself important?
The asset exists for a business purpose, if not, then you should probably remove it from your network. So what happens when that asset fails? It does not have to be a cyber attack, it may be more likely to be normal wear and tear, natural disaster or user error. No environment is static though, so it's helpful to understand how many of the below risk conditions are acceptable and at what level before we sacrifice our ability to recover. We refer to this as a boundary condition. We will cover these concepts in more detail as we touch on Consequences Focused Design.
- Will it have a safety impact? This may be a direct safety incident such as causing an unsafe condition, or may be the removal of a safety control that can be triggered at a future date
- Will it impact productivity? Productivity can be measure along multiple dimensions. For instance your output may be unchanged but if quality is impacted and you have to recall product, or it is unusable, productivity is impacted.
- What are the financial implications? The cost of response to an incident, addressing customer support, replacing defective work product, lost productivity or work stoppage and other indirect costs such as legal fees or increases to insurance premiums can all be measured as financial impacts.
- What role does data confidence play? If you are making decisions based on sensor data and that data is not trustworthy, your decision-making may also be compromised
- Will it create a reputation impact for the company? How does this failure look in the eye of public opinion? Does this ultimately create business impacts such as customer confidence concerns?
- Are there other indirect downstream implications? For instance, perhaps a critical function relies on this asset. You may have to look several steps down the chain to know
- Will it foster deeper attacks? Its possible that the compromise of the initial entry point produces little to no risk, but fosters a secondary pivot deeper into your network where real harm can be caused.
¶ How do we do it?
Digital Asset Awareness requires a people, process and technology approach. There is no technology silver bullet to solve this for you, but we certainly love our vendors working hard to help make this easier.
First your organization needs to think about what you want to accomplish and define a scope. You will probably need an executive sponsor and a champion to drive this internally until it becomes part of your culture. This should naturally lead you into the creation of a program and governance structure to manage this process. This includes well-defined roles and responsibilities, setting expectations, identifying KPIs and training stakeholders.
Once you've designed your approach and communicated why this is important, you need to start thinking about how you will accomplish this. There are probably already great sources of data to help get you started
- (Electric Power) - NERC CIP-002 should have already captured a good chunk of your regulated environment
- CMDB - May only be IT, but its a start.
- Historian - Rich source of data that has information on every device that has logged to it
- Network IDS - You may not have these devices in your ICS yet, but they can be helpful for capturing ethernet based traffic for device identification
- Firewalls and boundary defenses - Similar to the network IDS, if they are OT aware may even be able to do some level of protocol identification but not as purposeful as a monitoring product built for the ICS.
- SIEM - Your SOC is probably already ingesting a ton of data sources in the form of netflow or logs that can be represented as discrete endpoints or in some instances, application traffic correlated to those endpoints.
- Active Directory - For any domain joined systems, AD should be a good source of data
- Security agents - if you have installed antivirus across your environment, these agents are managed by a management server that can run inventory reports
- Vendor-proprietary solutions - Many vendors provide management capabilities for the fleet of their own connected devices. If you are mostly running 1 or 2 vendors products at your site this can be pretty effective, but this is frequently not the case especially for sites commissioned decades ago still running legacy equipment.
- Business continuity - Business Impact Analysis is typically not something we consider as a valuable data source, but from a risk management standpoint this may be the most important risk document you look at. It defines the core mission of the business and what it needs to survive. Often asset and software dependencies can be found here which is an amazing source of context for your program.
- Engineering drawings - An as-built or other engineering and construction artifacts often have inventory information that was accurate from the authors perspective at a certain point in time. It may not be accurate now, but in the absence of any other data, sifting through thousands of PDFs may be your only option.
In addition to leveraging the above data sources, you can look to data aggregators to ingest multiple sources of data to provide a holistic picture of your network, but in our experience there will be significant gaps due to a few issues.
- Data quality - frequently CMDB data is stale, or weak governance has led to situations like hostname or IP re-use and commingled legacy and production records. Or records created for staging that do not get updated once they move to prod. Or missing metadata such as no MAC address. This makes correlation and asset deduplication with other security tools incredibly challenging.
- Incomplete inventory - Ethernet based technologies have limitations and most of what we have described above is the low-hanging fruit. Consider the server with a USB cellular card inserted, or the Zigbee or serial connected assets. To get really comprehensive inventory you need to perform walkdowns. This is the process of physically visiting the site and doing manual inventory. Its not feasible to do this often, but your risk appetite should inform the frequency in which you perform them.
- Change management - It is critical for incident response and understanding what normal looks like, and systems are not static. Their configurations and software inventory change over time, and its important that the CMDB remains in sync with changes. NERC CIP requires that any changes be represented in an updated baseline within 35 days of the change, and this is a pretty solid approach we think.
¶ Defining Digital Asset Requirements
In the design process, you may only know conceptually what types of assets are likely to be deployed. But you can use this activity to define the characteristics of assets that are to be acquired. You might determine that it needs to meet a specific IEC 62443 Security level, or specify that no hardware components can originate from a specific adversarial nation. Certainly the context about how the asset is to be used is part of the design process, but until it is acquired and implemented you may not be able to do more than specify the security, functional and compliance requirements for the asset that will ultimately satisfy that function.
¶ Where do we take it from here?
Hardware Bill of Materials (HBOM)
Software Bill of Materials (SBOM)
¶ When do we do it?
The answer to this is somewhat subjective based on your organizations maturity and the critical functions you are trying to protect. If you are just getting started, just try to get an inventory captured once as a starting point.
If you are in the design phase of your project, you may not be ready yet for a discrete inventory, but you should know generally speaking the types of assets that will be needed such as a router, HMI, Breaker I/O, etc. You will also want to have a plan to manage this post-implementation. Once you do get a bill of materials created for your site, make sure this is clearly documented.
Maturity models such as C2M2 in electric power provide some guidance on these activities within the ASSET domain, and while CIE does not adhere strictly to these concepts, it may be helpful for you to understand where to start and how to mature your digital asset awareness approach.
¶ What is the impact of not doing it?
Without an awareness of digital assets, it is incredibly difficult to understand what attacks are targeting and if it even matters. When new threats emerge, trying to understand how to respond becomes impossible without understanding what areas of your organization may be at risk, and who uses them. Lastly, when recovering from a cyber event, if you do not know where all your assets are, you will not know all the hiding places an adversary could have setup shop in. How will you know when you are “done”?
Asset inventory is one of the most foundational components of a cyber risk management program, but as we will explore in other sections, it may make sense to tackle this in tandem with gaining a more complete understanding of your critical functions and the consequences of failure.
¶ What resources can help?
As mentioned above, C2M2 is a great starting point to establish the capability for digital asset awareness, and there are a number of great open source and commercial tools as seen below.
¶ Free and Open Source
- [CIP Evidence Request Tool v6]( CIP Evidence Request Tool Summary Instructions - NERChttps://www.nerc.com › comp › CAOneStopShop) - (spreadsheet)
- Grassmarlin - (NSA tool)
- Zeek Network Security Monitor - (tool that backends many commercial solutions)
¶ Commercial
Passive Identification - Many of these tools fall within 2 or more of the categories below, for instance some passive identification tools have active capabilities, but perhaps only for certain vendor technologies. Most of the tools here are limited to what can be observed on an IP based network, but newer solutions have started to emerge to capture serial, zigbee and other technologies.
- Dragos
- Nozomi Networks
- Claroty
- SynSaber
- Tenable OT (Indegy)
- Forescout (Security Matters)
- PAS (Historian based)
Active Identification
- Automation Vendor provided tools (Rockwell Automation and others)
- OT-BASE
Asset Lifecycle Management