Articles on the subject of asset management in a cyber security context begin with the same observation –You Can’t Secure Something If You Don’t Know It Exists.
This common-sense statement cannot be challenged, so why is this fundamental truth often ignored? What are the impacts and what can be done to avoid them?
First, some definitions. An IT “asset” is hardware, or software owned or licenced by the organization, that has value for a product or as part of providing a service. IT Asset Management (herein referred to as ITAM) is the planning, acquisition, operation, maintenance and disposal of IT assets that the business is responsible for, and managing the security risks which affect them.
The goals of ITAM seem straight forward, so why do so many businesses struggle to do it adequately?
Speaking bluntly, ITAM is not sexy. It is an important support activity which provides a foundation for many IT functions, but it is not always seen as a core part of Cyber Security. The irony of ITAM’s wide impact across the IT landscape means is that responsibility for it could fall anywhere. Not being able to pin it on someone, means that nobody wants responsibility for it.
ITAM ends up being handled in a fragmented way, with individual teams or projects creating their own asset registers for specific tasks. Their informal nature results in incomplete snapshots which become out of date quickly.
Many readers will have experience of a project which, along the way, “discovers” previously unknown assets. Such discoveries are a clear sign that the existing ITAM needs improving. Relying on snapshotting to get a workable inventory for the purposes of advancing a project is not a solution, because you can guess what happens after the end of the project; the information gets lost or forgotten.
Another factor which can complicate ITAM is when third parties are involved. Businesses which have outsourced the management and or hosting of IT assets can find the conversations around improving ITAM challenging. Establishing responsibilities can require delicate handling if there is no clear guidance in partner contracts.
ITAM in the Cloud is notoriously difficult due to the dynamic nature of resource provisioning and the frequently weak governance around cloud use.
OT ITAM is probably one of the most difficult areas to manage. Concerns about critical infrastructure being run on unpatched, legacy operating systems have been around for a long time. A separation between IT and OT management has historically contributed to this problem.
The factors above contribute to a vicious circle of lack of ownership, multiple stakeholders and complexity.
What are the bad things that result from poor ITAM?
The two real-life examples below show the types of problem that inadequate ITAM can lead to.
A business has engaged a third party to provide SOC and Vulnerability Management services. The devices in scope are spread across multiple data centers managed by two different service providers. Problems hit both the SOC and VM projects due to new assets being brought online, or decommissioned without any communication to the projects. Time is wasted trying to manage the changing scope. The problem is exacerbated by the complexity of dealing with the third parties.
A business is running a DR and BCP test over a weekend. The tests end up being a very challenging experience for all involved. The IT Production team finds that their recovery procedures are solid, but the inventories that they rely on are out of date. Servers that no longer exist, clusters exist where single nodes are expected and other inconsistencies lead to delays in both simulating resource failure and subsequent recovery.
Both examples expose one clear deficiency: proper asset identification and management
As well as the problems mentioned above, what are the other impacts of inadequate ITAM?
- Unknown assets can fall behind on patching, thus increasing security risk
- Unknown assets fall out of scope of cyber security services such as vulnerability management, SOC and SIEM
- An incomplete view of assets can lead to capacity management problems.
- Poor certificate and license management can lead to budget and even system availability problems
- Shadow IT organisation can result in unauthorized access problems and provide a vector for malware and viruses. This in turn exposes the business to security, regulatory and compliance issues.
- Depreciation of unknown assets is wasted investment.
What can be done?
Assign an ITAM owner, who has responsibility for ensuring that enterprise-wide ITAM is executed correctly. This role needs access to a budget for tooling and authority to implement the necessary governance.
Ad-hoc attempts at ITAM (to satisfy short-term project needs), often revolve around building a quick list of assets and their basic characteristics in an Excel spreadsheet. There is no governance set up to guarantee the preservation and growth of this resource. The first task for the ITAM owner is to establish the necessary governance to support his or her new function. There are many methodologies and resources available which can provide the structure for governance development.
The ISO/IEC 27001 standard for an Information Security Management System (ISMS), defines controls, policies and processes, which must be implemented to minimise information security risks. Annex 8 of the standard specifically addresses Asset Management.
ISO/IEC 27002 – documents best practice recommendations for choosing and implementing information security controls as part of an ISMS. Clause 8 sets objectives to identify assets and define appropriate protection responsibilities, to ensure that the protections in place match the asset’s importance to the organization.
Responsibility is a key word here. Identifying who “owns” an asset and who is responsible for the securing it, ties back to the problems highlighted above: third-party involvement and ownership questions.
ISO 27005 – a guideline for information security risk management, contains Annex B – Identification and valuation of assets and impact assessment. Threats, vulnerabilities, likelihood of occurrence and resulting impact on assets are all assessed according to risk.
The very first category of NIST’s CyberSecurity Framework is Asset Management. This (naturally) begins with asset identification and also includes classification of business value and criticality, following up with the identification of roles and responsibilities (including for third-parties).
As you can see, these widely used and respected frameworks and standards put the governance of Asset Management at the forefront of their scope. Common themes of identifying assets, determining their value, managing risk, asset ownership and other responsibilities, point the direction that businesses should follow when embarking on the development of their own ITAM governance.
As ITAM impacts all aspects of IT from projects through to operations, ITAM tooling must interface with multiple IT systems and procedures. Examples include IT Service Management systems which need to hold user workstation details for troubleshooting, Change Management so that changes to assets and handled correctly (i.e. software upgrades or asset replacement), and SOC SIEM which consume and analyse asset logs in order to identify security incidents. Ease of interfacing is an important criterion when selecting the tool or tools used for ITAM.
Tool evaluation must consider business requirements from the most common functionalities offered by ITAM tools: Asset database, discovery capabilities, license and contract management, reporting and analytics, infrastructure modelling, automation and workflows. As with all tooling decisions, the tool must fit the business, not the other way around.
ITAM must be incorporated into contracts with third parties, such as hosting companies so that clear responsibilities are understood.
Don’t just focus on physical hardware. Licences and certificates need to be identified and managed throughout their lifecycle.
The goals of ITAM are clear, but achieving them is far from easy. Implementing ITAM as a project or part of a wider cyber security programme should start out small, with clearly defined and increasingly ambitious milestone deliverables. POCs should be held to trial potential tools, with an emphasis on flexible interfacing between existing (and potential future) systems.
Businesses will realize immediate benefits from the earliest phases of implementation of a coherent ITAM approach. Projects will have access to a reliable reference point for asset information, rather than having to divert project resources to gather an incomplete snapshot of in scope assets. Operations will be confident that patching and upgrading efforts are exhaustively covering all business assets. They will also find it easier to manage resource capacity in a more cost-effective manner and reduce the risk of availability and performance issues. Finally cyber security risk management can draw on an accurate asset reference point to ensure that adequate controls are in place, without worrying that unknown devices lie, unpatched and unmonitored, waiting to be discovered by a curious threat actor.