Documenting service assets

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 lifecycle
• 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 Secure by Design principles to adopt a risk-driven approach and 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.

You should also collaborate with your service owner, technical architects, product managers and business analysts to ensure every area of the service has been considered, including data that may be required in the future. 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 that automates the task of collecting and maintaining information about components and the relationships between them. This 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.

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

• User’s personally identifiable information
• Employee’s personally identifiable information

Examples of technology information assets

• System user credentials
• Configuration files
• Event logs

Examples of service technology component assets

• 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 title
• Asset description – a list of database fields or a summary of what the asset does
• Asset type – such as data, software or hardware
• Asset owner(s) – the person or team responsible for the asset
• Government Security Classification – OFFICIAL, SECRET or TOP SECRET
• Handling caveats – security clearance level and any additional remarks such as EYES ONLY or SENSITIVE
• Lifecycle stage(s) – 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

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 Title: Grant Application Data
• Description: Data fields including; company name, company address, business case, bank account information.
• Type: Data
• Owner: Senior Responsible Officer
• Classification: OFFICIAL
• Handling: SENSITIVE
• Component: Storage

Example infrastructure asset entry

• Asset Title: VPN Portal
• Description: Remote login capability made up of an internet gateway server and authentication mechanism.
• Type: IT Hardware Asset
• Owner: IT Department and Senior Responsible Officer
• Classification: OFFICIAL
• Handling: SENSITIVE
• Component: Transmission

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, 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.