Asset Management

Introduction

In this episode, we will provide you with some advice in regard to the typical issues we see with organisations trying to implement Asset Management with eramba

Relationships

Assets in eramba are identified and used to give "Context" to something, they are meant to clarify something. Assets are "owned" by one or more Business Units, these relationship tries to associate a departmental owner.

• Invoices would be an asset typically associated with the BU "Finance"
• Roster would be an asset typically associated with the BU "HR"

Assets are mandatory in the following related modules:

• Asset & Third Party Risks: Data assets provide context to these Risks, is help people understand Risks better.
• Data Privacy: Data Assets are composed of "data" that moves around. Every time it moves creates a "Flow" which is analysed to understand if it is problematic (Risky) or not (typically it is).

If you are not using these use cases then chances are you do not need to use this module at all.

There are optional relationships with other modules as shown in the diagram above. These relationships are again simply to provide context. 

Scope

If your plan is to do Risk or Data Privacy then you will need to identify Assets. You will also need to review them regularly to ensure they are still relevant. The extent to which you need to collect them is determined by the scope of your Risk or Privacy scope.

If your Risk or Data Privacy framework covers the entire organization then you need to identify Assets organization-wide. 

Depth

We get this question oftentimes, is Eramba an inventory tool? The answer is a plain no.

As explained above, assets in eramba help provide context to Risks and Data Privacy issues.

• If we want to document a risk such as "Phishing could lead to problems", the input asset to that risk would typically be called "Email Accounts" or "Emails".
• If we want to document a risk such as "Laptops can be lost or stolen", the input asset will be "Laptops" or "End Points".

The point we are trying to make here is that having a full inventory of laptops or emails associated won't make those Risks more clear. When is clear enough then is enough. Let's review other examples:

• The risk of "Internet facing Windows servers hacked due to lack of patches" could have an asset called "Internet Facing Windows Servers". 

Let's say you report these Risks to the board and they ask (or you ask), how many websites are there? or how many Windows servers are there? The answer to that question is not going to be found in eramba, the answer will most likely be found in your IT department and the solution they use for Patch Management. Generally speaking, eramba might have a "link" to that solution. That solution will say many more things, such as % of missing patches, by severity, Etc.

GRC departments are statistically speaking in developed economies well below 1 FTE in every 100 employees. How can a GRC department maintain the inventory of the entire company? Every department knows what inventories they need and those should be made accessible to the GRC department if needed.

ISO 27002:2022 makes this point very clear:

"The inventory does not need to be a single list of information and other associated assets. Considering that the inventory should be maintained by the relevant functions, it can be seen as a set of dynamic inventories"

"The granularity of the inventory of information and other associated assets should be at a level appropriate for the needs of the organization. Sometimes specific instances of assets in the information life cycle are not feasible to be documented due to the nature of the asset. An example of a short-lived asset is a VM instance whose life cycle can be of short duration."

If you look at the older version of ISO (2013 and 2005) these requirements were far more restrictive in the sense that far more considerations were required. Those methods have been outdated for well over a decade now.

Automation

Some people wish to automatically "populate" the eramba Asset module using REST APIs.

Typically the idea is to take "Assets" from different sources and create them in eramba. While this is technically feasible (you can look at our API documentation) there are some considerations:

• Bottleneck: Assets in eramba are used for Risks, creating 1000 Assets will require a somewhat large amount of Risks. Risks require analysis, typically human. Risks also require multiple Treatment options (controls, policies, exceptions, etc.). Assets and Risks require reviews, those again are human interventions. This same situation applies to Data Privacy, every data asset will require data flows and that is typically a human task as well.
• Database Replication: in the world of databases duplicating tables is a capital sin. Indexes are used to relate different data sets (Risks and Assets in this example). If you already have an inventory of Windows Servers that are facing the internet in your Patch Management solution, is much wiser to create Risks in eramba and simply make a "reference" (index) to that system.