Building and maintaining an accurate inventory of your systems, devices, and applications is critical to ensuring that your technical security controls operate effectively across your entire organization. This is simply because you need to know what you have before you can begin to secure it adequately. Having an accurate inventory when you develop your security program enables you to know what machines to scan for vulnerabilities and subsequently patch. Also, you will likely query your inventory for which specific devices to include in your advanced security-information event-manager platform. Without a solid inventory, you might inadvertently exclude devices from your security controls that could give an attacker a foothold into your network.
The most basic inventory is a list of systems and devices found in your organization or environment. Enhance this list with security-relevant metadata including the make and model of the device and distinguishing characteristics such as:
More sophisticated inventories include additional metadata about a device such as:
Logical assets should include information that makes it easy to find the device or manage it in case of an incident. Examples of when you would use this information include:
The purpose of the inventory metadata is to aid in planning when designing new security controls as well as reduce the response time to discover impacted assets during a security incident.
Make sure your inventory is usable and accessible. For even the smallest inventories, give thought to the best data structures that organize and store your inventory that allow you to easily filter and query for specific devices based on the metadata. In some cases, a simple web frontend to your inventory database might be a good solution to abstract users from more complicated database schemas.
If you are not yet formally collecting an inventory, start with a simple list—a spreadsheet works fine—and evolve to a more sophisticated inventory management program as your needs expand. You will find there are many commercial and open-source inventory and asset management applications for all sizes of businesses and many offer demonstrations to test drive the features that best suit your purposes. Larger applications require maintenance and upkeep. It is important not to let the complexity of these programs overshadow the accessible and immediately usable benefits that even a simple, effective inventory list can provide. For example, a spreadsheet with data filters and pivots can quickly transform and present data into usable and actionable results without a lot of development. Of course, larger organizations that require multiple teams to regularly access and update inventory information might require a more sophisticated approach.
Consider leveraging inventory repositories already set up by other teams to uplift your own efforts. Finance, datacenter, or facility teams may already manage physical inventory for their own capital asset tracking, and this data may be a great starter to seed the data collection for at least a subset of your own data needs. Through cooperation with these other teams, you may be able to add assets that they might not collect—e.g., virtual machines—and augment their records with security-relevant metadata that enriches the larger repository.
Dynamically subscribing to another inventory repository might net you a treasure trove of inventory data already collected and managed by others. Be careful of one-time data extracts that could go stale over time. As your organization and own program grows, do not forget to scale your inventory processes as well lest they obsolesce. Store your inventory in an extensible and exportable format to facilitate sharing with other programs and systems. Even for smaller efforts, this will become important as your program grows from a simple spreadsheet into a custom database or commercial or open-source inventory application. Where possible, extend and integrate your inventory management processes into your move-add-change and change management processes to allow these programs to update your inventory data in concert with real changes to the environment.
A complete inventory that supports most security controls will represent both the physical and logical systems and devices in your environment. It is important to include the cloud assets as many of the same challenges to secure on-premise hosts also affect infrastructure as a service (IAAS) guests as well. Capturing cloud assets will require additional steps than those used to collect assets on your own managed network because the cloud assets might reside across multiple cloud subscriptions. However, the major cloud providers supply queries and application programming interfaces (APIs) that you can use to create dynamic reports or data extracts of your cloud assets given the right subscription authorization.
I often think of the inventory count as the denominator for measuring the overall effectiveness and reach of your security controls. Think about your security scorecard. Your security scorecard might include a metric representing the percentage of systems patched for known vulnerabilities. You might feel pretty good thinking you patched 85% of your systems, but you might not feel so good if you later find out that this metric only represents half of your total systems. Showing the denominator for security metrics is essential and helps tell the whole story. Take for example these made up metrics. If only 134 out of 200 devices connect to the newest logging system, then that might suggest that there is more work to do to enroll the remaining 66 devices. The dashboard on your commercial vulnerability scanner might report that it scanned 3,462 assets for vulnerabilities last week. Is that a good thing? It is tough to tell without the denominator. What if you are responsible for securing 4,000 assets or possibly 10,000 assets and the scanner only evaluated 3,462 assets for vulnerabilities? Having a complete inventory provides this denominator and completes the story of the overall effectiveness of the security control. Let's take one of the prior examples a bit further. Regardless of how many vulnerabilities are found on the 3,462 scanned assets, it is also essential to understand how many assets were not scanned and why. For example, was an IP range mistakenly left out or was it a conscientious financial decision attributed to license costs? Knowing when a control is operating for only a subset of assets and knowing why it is not operating for all assets is important. This ensures you do not have any gaps in your security coverage and helps design mitigating controls where necessary.
A good inventory will also help you meet your compliance and audit obligations. For example, in the past, the Payment Card Institute Data Security Standard (PCI-DSS) considered systems that held or processed credit card data as in scope of the PCI-DSS controls and audits. Identifying and tagging the systems in your inventory with PCI-DSS relevant metadata ensures you apply the right security controls for very in-scope system. When requirements are updated, such as when PCI-DSS expanded in-scope systems to include all connected systems, you can update your inventory to reflect these changes and always have confidence that your controls are applied to the right assets.
Lastly, consider taking your inventory management to the next level by recording asset dependencies. For example, you might link a web server asset to the database asset that it relies upon in the inventory database. More advanced inventory management systems help manage these dependencies, and these relationships will help inform your security decisions. For example, patching a database server for a critical security vulnerability might require it to restart. Knowing which web servers this restart will affect enables others to prepare in advance.
Building and managing a complete inventory of all your physical and logical systems and devices will prove useful to your day-to-day security and operations. With an up-to-date inventory, you will have fewer blind spots and more confidence that your security controls are appropriately scoped and deployed to just the right assets.
Jeff Fellinge has over 25 years’ experience in a variety of disciplines ranging from Mechanical Engineering to Information Security. Jeff led information security programs for a large cloud provider to reduce risk and improve security control effectiveness at some of the world’s largest datacenters. He enjoys researching and evaluating technologies that improve business and infrastructure security and also owns and operates a small metal fabrication workshop.