Asset identification and testing approach

[bin-to-hex]

I need advice on how to classify the security and network “assets” of a device so that tests required by standard EN 18031-1 can be defined and executed.

Background:

• The standard tells us to “validate” or “test the assets.” I’m unsure how to interpret “asset” in this context.

• For a Wi-Fi-enabled firewall, I can list individual secrets such as passwords and private keys as assets, and network items such as firewall rule configuration and open ports as assets.

• If I include the SBOM (libraries) and firmware functions discovered during analysis, the list explodes into thousands of “assets.” It seems impossible to manually test every single item.

• But I could treat higher-level components — Multiple libraries combine to form functions, functions together form systems, and these systems in turn make up the interfaces. Therefore, can I consider physical interfaces (such as buttons or ports) and wireless interfaces as assets, since each of them encapsulates a complete set of libraries and functionalities?

Questions:

1. What is the practical / standard-aligned way to classify assets for testing so an OEM can fill in the required information?
2. For the Wi-Fi firewall example, what should count as assets? (concrete examples would be helpful)
3. Who should be responsible for identifying assets — the tester or the vendor/OEM?
4. How do we handle SBOM entries and hundreds/thousands of libraries — do they each become individual test targets, or are they grouped somehow?

[zealience]

Hello @bin-to-hex,

1. You can refer to our articles on security/network/privacy assets available on our website. We propose our interpretation of the definitions of assets and a pragmatic approach on the thought process to adopt to identify them. We know that classification of assets is a challenge in the industry currently, and consensus is still to be found across industry players. See the TIC Council's paper From Testing to Policy (https://www.tic-council.org/publications).

2. For the firewall example, we include this example already in our article on security assets. At a minimum, I would list out the following security function and parameters:

• Security function: The binary of the firewall. This is aligned with the standard's definition of security functions: "Functionality on the equipment that is relevant to protect it from harming the network or its functioning or misusing network resources".
• Security parameters: Any of the firewall's config files. Security parameters are defined as "data processed by the equipment that defines the behavior of the equipment's security function". As you suggested, the firewall rule configuration fits perfectly as security parameter.

Regarding open ports, I would not regard them as assets since they don't fit any of the definitions as is. Rather, I would declare their respected network service exposed over that port as network/security function.

Note

The standards don't dictate the level of granularity when documenting assets. Since the number of assets declared affects the documentation & testing effort (e.g., for each asset type there can be multiple Decision Trees to document) we recommend trying to group assets where possible. Taking again the firewall as example, its config files could be grouped as one security parameter as long as they all have the same access control(s), are stored on the same storage and are communicated over the same communication mechanism.

3. The manufacturer is responsible for the identification of assets, as he is responsible for the creation of the technical documentation and its completeness. When the tester performs the assessments (in particular the functional completness assessment), he or she may identify assets that have been overlooked by the manufacturer. These assets will be outlined in the assessment report, and the manufacturer can then update the technical documentation by including them. One challenge we often hear in the industry is the misalignment of EN 18031 definitions between manufacturers and testing laboratories. If possible, I would suggest to align prior to testing on the definitions with all stakeholders to ensure common understanding and interpretation.

4. Not all entries in an SBOM have to be regarded as assets, but only those that can considered security/network/privacy/financial assets (depending on the standards applied). It is important to keep in mind the definitions of EN 18031 and to evaluate whether a given library needs to be regarded as a (security/...) function. If no, then it is out of scope of EN 18031. You can refer to our articles mentioned above for more information on the thought process.

I hope this helps you, do not hesitate if there's anything unclear.
Guillaume