Asset management is the collection of processes that relates to how you track and protect the data you care about. “Asset” is a broad concept–it is often used to describe any thing of value to an organization that requires some level of protection (including people). But when we talk about “asset management,” we are usually referring to protecting our data and the systems they are stored on, processed by, or transmitted through. Thus, in order to protect data, you need to protect your assets.
Asset management is an integral part of any security management program because it gives teams the ability to:
easily understand where their data are stored and which of their assets are most important;
quickly triage and respond to security incidents and disruptions;
simplify audits and security assessments by aggregating information in one place;
provide their management and security teams with an easy way to track assets; and
improve the quality of their risk assessments by accurately summarizing their attack surfaces.
For more information, check out the NIST’s Special Publication 1800-5, IT Asset Management.
In order to ensure that your assets–and thus, your data–are secured, there are a number of processes you should implement, including:
Identify and analyze your assets to define their importance to your organization;
Inventory (document) your assets;
Restrict how your assets are used;
Make backups of your important data;
Log interactions with your assets; and
Appropriately dispose of and reuse your assets.
In order to secure your data properly, you need a complete understanding of your organization’s assets–all of the things of value to your organization that can connect to your data in any way. At a minimum this includes, but is not limited to, your:
Networks (VPCs, subnets, etc.)
Load balancers, bastion hosts, and other ingress points
Third-party services (logging tools, analytics tools, etc.)
Physical assets (laptops, smartphones, etc.).
Once you’ve identified your assets, you should then document their importance/ valuations. While there are lots of criteria that could be used to determine the relative importance of your assets, we recommend identifying at least the following information about each of your assets:
The owner of the asset (i.e., the individual or team responsible for the protection and management of the asset)
A description of the asset and its purpose
The types of information the asset stores or processes (including the Data Classification of the information and the specific types of information ( HIPAA PHI, EU personal data, PII, etc.)
The impact your organization would suffer on occurrence of a loss of security or privacy of the asset
The asset’s business continuity metrics (maximum tolerable downtime, recovery time objective, and recovery point objective)
Information related to backups of the asset (frequency and location)
The asset’s vendor (if applicable)
How data is encrypted by the asset
How you log interactions with the asset
While this process of inventorying and analyzing your assets is time-intensive to start, it is worth its cost when, down the road, you experience a problem with an asset and have all your information in one place.
The importance of an asset will usually depend on the kind of data stored on or processed by the asset. Thus, to make determinations about the value of your assets, you usually need to start by classifying your information. While there are lots of right ways to categorize information, we recommend breaking your data into four categories:
“Public Information” is information that is publicly available. For example–information on your public website.
“Confidential Information” is information that can be viewed by anyone at your organization, but should not be viewed by individuals outside of your organization. For example–conversations in your #general Slack channel; slide decks from your team’s all-hands meetings.
“Restricted Information” is information than can be viewed by some people at your organization, but not by everyone at your organization. For example–salary information; Social Security numbers.
“Sensitive/Regulated Information” is information that is subject to the requirements or protections of some statutory, regulatory, or contractual requirements. For example–HIPAA protected health information; personal data of EU residents.
Categorizing the types of data you have will help you determine the importance of your related assets, as well as which safeguards you should apply to them.
Next is the laborious but easy part: You need to consolidate all your information in one place. Called “Asset Inventories,” these logs should act as the single source of truth for all information systems and assets your organization values.
You should update your Asset Inventory whenever you have a change related to an asset (e.g., a database is de-provisioned, a new device is issued, a vendor tool is deprecated, etc.). The responsibility for updating the inventory should rest with the asset owner–that is, the person who will be in charge of that asset.
In addition to updates to the Asset Inventory, you should also perform a sweeping review of the Asset Inventory once a year. This review should involve all asset owners reviewing the information about their assets to ensure that the Asset Inventory is accurate and complete.
Once you have a handle on what your assets are and how important they are to your organization, you should implement safeguards to ensure your assets are used the right way. These run the gamut and include everything from implementing encryption to restricting access. But here, we want to focus on two broad categories of protections: limit how your assets can be used.
These restrictions are usually described in Technology Acceptable Use or Information Transfer Requirements policies. No matter where they live or how they’re grouped, the important thing is to define the permitted and prohibited uses of your assets.
Broadly, these will be based on the data stored on or processed by the assets. For example, you may prohibit workforce members from storing Sensitive/ Regulated Information on mobile devices. Or you may prohibit them from emailing Restricted Information. Whatever decisions you make about how to interact with your assets, make sure your workforce members are privy to your requirements.
In order to ensure you have your data when you need it, you should implement a backup policy under which you routinely make backup copies of your databases and data stores. In determining which systems you back up and at what frequencies, we recommend considering the following properties of your assets:
the data’s criticality/importance to your organization;
your statutory, regulatory, and contractual requirements; and
your operational requirements.
Further, ensure that your backups have appropriate protections in place ( physical and environmental protections; access restrictions; etc.) and that you routinely test your backup processes to ensure that they are properly running.
Logging is the process of recording events. According to NIST, an event is “any observable occurrence in a system or network.” In order to fully secure your assets, make sure you consider three things when you set up logging: (1) log the right events and information; (2) protect your logs; (3) retain logs for a sufficient amount of time; and (4) review your logs (on set intervals or in response to alerts).
A natural question is, Which events should we log? Well, there’s no single right answer. However there are certain events that can help you determine whether your systems are protected from improper use, including (but not limited to) the following:
login attempts (successful and unsuccessful);
access to sensitive files;
changes to sensitive files;
changes to logging configurations;
uses of privileged accounts; and
interactions with sensitive systems.
Moreover, log a sufficient amount of information about the events you’ve identified. This includes (but is not limited to) the following.
the user ID;
the time and date of the event* (in a standardized format);
the name of the file or system accessed;
the location of the user; and
the event type (i.e., the reason the log was created).
* With assets in different locations, it’s important to make sure that your systems (and thus, logs) are all on the same time–a process called “clock synchronization.” A common method is to choose a master clock (such as an Internet time server), and then pick a timing protocol to synchronize the time across all your assets. For more information, check out NIST’s Computer Time Synchronization.
Because your logs are the source of truth as to how users have interacted with your systems, it’s imperative to protect them to minimize potential tampering. At a minimum this means:
1. Transmit them securely. Only transmit your logs over encrypted channels so that they cannot be intercepted.
2. Limit access to them. Make sure that you have a sufficient separation of duties such that the individuals who have access to the systems with sensitive information are not the same individuals who can edit your logs. Generally, access to logs should be granted on a need-to-know basis.
3. Ensure they are working. Make sure you have notifications/alerts configured to warn you when you are nearing the storage capacity of a logging destination.
Make sure you keep your logs for as long as needed. It’s not always the case that you’re immediately aware of possible security incidents–sometimes there may be years between an actual incident and your learning of it. In light of that reality, you’ll want to make sure that you retain your logs for a sufficient amount of time to investigate incidents that occurred months–or years–ago.
You may also be subject to regulatory requirements related to your log-retention practices. For example, check out our documentation on How long should I retain HIPAA audit logs?, which describes the issues related to HIPAA’s retention requirements and how you think about logs.
Setting up logs is not enough–you also need to use those logs to ensure that your assets aren’t being improperly used or accessed. To that end, you should review your logs.
There are lots of tools available for log review. But no matter what you choose, manual review of raw log files is never the right way to go.
Instead, find a solution that works for your organization–this can include anything from setting up alerts for particular events (like Yelp’s ElastAlert), to using AI-based log-analysis tools (like PagerDuty’s Event Intelligence).
No matter what tools you use, your objective remains the same: Your team should be able to identify–and quickly respond to–any interactions with your assets that are not expected or permitted.
When an asset is no longer needed for its purpose, you have two options: (1) destroy the asset, or (2) sanitize the asset for future reuse.
If you plan to never use an asset again, you can destroy it. But do so in a way that ensures none of your data is recoverable, such as by physically destroying the asset.
If you otherwise intend to reuse the asset, you should first ensure it is sanitized such that the information formerly on the device cannot be read. There are a number of methods that can be used to sanitize an asset, such as “zeroing” the device–i.e., overwriting all the data on an asset with zeroes.
For more information, check out NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization.