I’ve heard from various people working in IT and IT security that asset inventories are boring, unsexy and don’t have enough bite to them. They seem to have a bad reputation and are consequently hard to “sell”. Customers prefer current generation security devices instead.

This makes no sense to me. Any reputable IT security guide or standard starts out with an asset inventory that at least includes hardware and software assets. And rightly so. Aside from that, it is a logical and rudimentary concept that IT security requires a foundation. Without some sort of general framework, it’s impossible to be certain that efforts will actually be effective across the board and that nothing falls by the wayside.

An approach to Systematic Implementation

So what is the foundation, or how do you begin to systematically implement IT security controls once you have identified and ideally defined which of the countless potential cyber risks you are exposed to?

By documenting your hardware and software assets.

Starting with the network and its users, the question is who is using the network and do they actually have the appropriate authorization to do so? It is not just intruders with malicious intent who are unauthorized – but also any infected personal devices belonging to staff. After a certain period of time, all known devices are flagged as authorized in the hardware inventory, and any unknown devices will be detected relatively quickly and can be investigated. This is the first reason why it makes sense to implement automated mechanisms, which take an inventory of the population of devices operating on your own network.

Then you have the OS and software that are installed on the devices. On which devices? Yes, on those devices found in the hardware inventory. This explains the second good reason for having a hardware inventory.

The software inventory therefore comes next. It essentially consists of two lists: one describing the required and authorized software, i.e. a list representing a sort of ideal state, the other collected from the devices to determine what is actually installed, i.e. the current state. The discrepancies between the two should then be eliminated as appropriate.

In addition, the following security tasks are based on the HW and SW inventory or depend on them in one form or another:

• Process inventory
• Responsibility, data classification, criticality, etc.
• Vulnerability management (patch management)
• Application whitelisting
• Network management, i.e. the segregation of networks and network access controls

If you do not have a HW and SW inventory yet, focus on the following items, which will in any case make it easier to get started with the task.

Getting started with Asset Inventories

HW and SW inventories are tightly interwoven, which is why it is helpful to first take inventory of the hardware and then enrich the data in a second step by taking inventory of the installed software.

It also helps to begin with a few relatively simple tasks, particularly if you have little or no experience in this kind of undertaking.

But first let’s examine the following requirements rationally.

HW Inventory

1. Tool: Active inventory of devices on all networks and at all sites, including in the cloud
2. Tool: Passive inventory of devices on all networks and locations, including in the cloud
3. Tool: The inventory itself, which is used to manage the collected data and includes the appropriate reporting functions. Initial reports might include:
   • List of all unauthorized or unknown devices
   • List of devices with incomplete data
4. Process: Managing the inventories, i.e. adding/decommissioning authorized devices as well as including additional information about them. Ultimately, the following data should be provided from the start:
   • MAC address
   • IP address
   • Name
   • “Last seen on” [date/time]
   • Type (server, client, IoT, etc.)
   • Location
   • Responsible party
   • Department
   • Flag: Authorized/unauthorized
5. Process: Analysis and tracking of unauthorized devices. These must either be removed or authorized.

This list is not exhaustive, but it is a good starting point. Certificate-based Network Access Control (NAC) can be implemented here in the next step.

SW Inventory

1. Process: Create an “ideal state” list of authorized software, i.e. the inventory of the software required within the business context. This can sometimes be tricky, so you can also start with step two and use tools designed for creating an inventory of all installed software. This will then provide a basis for determining which software is authorized. The list should also include a support and licensing model, responsibilities, and manufacturer information.
2. Tool: Active inventory of all software and versions, as well as installation date (if possible) on the devices included in the HW inventory.
3. Tool: The inventory itself, which is used to manage the collected data and includes the appropriate reporting functions. Ideally, the data records in the hardware inventories are enriched with data from the SW inventory. Initial reports might include:
   • List of all devices running unauthorized software
   • List of incomplete entries
4. Process: Analysis and tracking of unauthorized software. These must either be removed or authorized.

This list is not exhaustive either. The next step is to address the issue of application whitelisting. Microsoft’s own solution AppLocker can be used for this purpose.

Tools

But let’s return to the topic of tools. Simple methods might include:

• Nmap for active hardware discovery
• Using scripts to compile log information and ARP tables from various network-specific devices for the purposes of passive discovery of hardware, such as:
  • Switches
  • Routers
  • Firewalls
  • DHCP servers
• Appropriate scripts for taking inventory of installed software
• Combining and analyzing the data in an Excel table

If adequate scripting capabilities are available, implementing these measures can be an interesting task. It should be noted that known data formats are used and that script maintenance should not be underestimated.

But ready-to-use open source or freeware solutions can be quickly deployed as well. For instance, these projects offer appropriate solutions:

• Spiceworks
• glpi-project
• OCS Inventory

Large and usually expensive suites from well-known software makers should only be considered later on – if at all. The requirements for taking an initial asset inventory are relatively manageable. If vulnerability management and other issues need to be addressed later, there are additional requirements that have to be met and a certain degree of dynamism and flexibility are helpful.

Metrics

Successes should be reported. The information collected in the course of managing a simple asset inventory is an excellent source of data that can be presented to management:

• Having real figures and being able to work with them is a step in the right direction
• How many unauthorized devices/programs have been detected/removed
• How many employees are violating internal policies and using personal devices on the company network
• Certain vulnerability management-related issues may also emerge in the process (e.g. forgotten Windows XP systems that are still active)
• If measures are taken (staff training, internal directives) to address problems that have been identified (many personal devices on the company network), their effectiveness can be measured
• Once the initial discovery and general problems are resolved, deviations from standard behavior can be quickly identified and then promptly resolved and reported

Conclusion

Ideally, the many companies that are increasingly confronted with cybersecurity risks without having established a proper, systematic foundation for security will begin addressing the problem by carrying out a basic asset inventory. It’s a relatively inexpensive way of getting good results, or systematically improving the security of your own IT infrastructure in the long-term.

About the Author

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)

Links

• https://nmap.org/
• https://www.cisecurity.org/controls/
• https://www.glpi-project.org/
• https://www.howtogeek.com/165293/how-to-get-a-list-of-software-installed-on-your-pc-with-a-single-command/
• https://www.iso.org/isoiec-27001-information-security.html
• https://www.ocsinventory-ng.org/
• https://www.spiceworks.com/