Documenting service assets
Teams building and managing digital services should understand what physical and virtual assets they need to protect.
This includes anything of value to the organisation such as information, applications or infrastructure. By identifying and documenting the assets that form part of your digital service you will be able to:
- get a comprehensive overview of what is valuable to your organisation and what you need to protect from cyber threats
- know where you need to manage vulnerabilities and other security risks throughout the service life cycle
- understand who is responsible for each asset so you know who is accountable for protection
- prepare for assessing the importance of your assets so you can qualify the impact of loss or compromise
- contribute to your organisation’s overall asset documentation processes
Asset documentation should begin during the discovery or requirement gathering phase of your project. This will allow you to accurately assess the extent of your responsibility to protect the assets identified. Reviews should take place as the business requirements and service evolves, including decommissioning any assets that are no longer part of the service so any associated vulnerabilities can be removed from consideration.
Completing this activity will help you to achieve the outcomes included in the following Secure by Design principles:
- 3. Adopt a risk-driven approach
- 7. Minimise the attack surface
Who is involved
You should appoint the appropriate person within your delivery team to coordinate with those responsible for each asset, such as information asset owners (IAOs), to deliver a comprehensive list of assets related to a service. Support for cataloguing asset attributes may also be available from your organisation’s data protection officer (DPO) and information assurance team.
To ensure every area of the service has been considered, including data that may be required in the future, you should also collaborate with your:
- service owner
- technical architects
- product managers
- business analysts
Your senior responsible owner (SRO) should sign off the output of this activity.
How to document assets
Step 1: Check existing processes
Your organisation may already have tools or templates in place that you can use for identifying, documenting and managing assets.
For example, Configuration Management Database (CMDB) software may be available. This automates the task of collecting and maintaining information about components and the relationships between them. It can be used alongside manual asset identification to streamline the process.
Where appropriate, make use of any templates and support that’s already available rather than developing your own methods. It will save you time and allow you to feed the information you gather back to the organisation so it can benefit other teams.
For example, on this page there’s an Example Service Assets List you can use as a template to collate and catalogue your service’s assets and their attributes.
Step 2: Collate the assets
Create a list of information that is processed, stored and transmitted as part of the service, along with information used to support technology operations and the components that allow the service to function.
Examples of service information assets might include:
- user’s personally identifiable information (PII)
- employee’s personally identifiable information
Examples of technology information assets might include:
- system user credentials
- configuration files
- event logs
Examples of service technology component assets might include:
- databases
- applications
- Platform-as-a-Service (PaaS)
Step 3: Catalogue asset attributes
For each of the assets that have been identified, expand your list to include the attributes that will be required for assessing the importance of assets and performing threat modelling.
This should include:
- asset name
- description: a list of database fields or a summary of what the asset does
- government security classification and handling caveats: OFFICIAL, SECRET or TOP SECRET (with additional markings like EYES ONLY or SENSITIVE if required)
- category: such as data, software or hardware
- sub-category: such as data, identity, infrastructure, service information, service technology component or technology information
- life cycle stage: whether the asset is related to the input, processing, transmission or storage of information
- technology component: a summary of where the asset sits within your service’s technical architecture
- asset owner: the person or team responsible for the asset
A clearly defined labelling system will allow you to organise and filter this information and make it easy to be assessed. For example, it may be useful to be able to see all OFFICIAL-SENSITIVE assets involved in the transmission of data when performing a threat modelling exercise.
Example data asset entry
- Asset name: Grant application data
- Description: Company name, company address, business case, bank account information
- Security classification: OFFICIAL
- Category: Data
- Sub-category: Data
- Life cycle stage: Storage
- Technology component: Database
- Owner: SRO
Example infrastructure asset entry
- Asset name: VPN portal
- Description: Remote login capability made up of an internet gateway server and authentication mechanism.
- Security classification: OFFICIAL-SENSITIVE
- Category: Hardware
- Sub-category: Infrastructure
- Life cycle stage: Transmission
- Technology component: Remote access server
- Owner: IT Department and SRO
Download an Example Service Assets List
This assets list is an example created for a fictional organisation, which we’ve called the Department of Artificial Intelligence and Robotic Technologies (DAIRT). To view or download it, select your preferred format.
In the discovery and alpha phase worksheets, the life cycle stage and technology component columns are blank. This is because, in our example, the information was not known at the time. By beta phase, the information had been identified and added to the beta worksheet.
If you’d like to use this example as a template for documenting your service’s own assets, make a copy, delete the existing entries and tailor it to suit your organisations. The example entries are not intended to be an exhaustive list.
Step 4: Protect your documented asset list
The list of assets also represents a list of potential vulnerabilities. It should be considered highly-sensitive and only be shared with those who need it to perform specific functions.
The people accountable for service delivery and ensuring the security of assets (such as SROs, senior officers (SOs) and IAOs) should know who has access to this information and what they are using it for.
People working within data protection, business continuity and information assurance teams may find this information valuable and should be granted access where necessary. This may also apply to those working on system design and those responsible for implementation such as security architects and engineers.