Более чем достаточно - это слишком много | Точный анализ потребностей в защите при управлении активами позволяет избежать чрезмерной защиты
Точный анализ потребностей в защите при управлении активами позволяет избежать чрезмерной защиты
Protection needs assessments are essential for efficient protection of all corporate assets—naturally, there is a strong overlap with asset management. Our authors show how organizations can reasonably cluster assets and assess their protection needs, what advantages this brings, and what requirements a software solution used for this purpose should fulfill in order to avoid both too low and too high protection needs being assigned to assets.
The goal of a protection needs analysis is to assign a need for protection measures to all corporate assets that are represented in information, so that they are protected with optimal use of resources. To this end, corporate assets should be grouped into classes in asset management so that methods can be used to individually assess and determine assets and the protection they actually require. Because of its particular relevance for the protection of an organization (up to and including existential protection), a functioning asset directory is required, for example, in ISO 27001, in VDA ISA and in BSI Standard 200-2.
Protection needs analyses are a component of numerous management systems that deal with the information security of an organization and are mandatory, for example, for certification according to ISO 27001. In order to protect information-based corporate assets, these must first be identified and classified by rating their criticality.
The next step is to model in which (IT) systems, at which locations or in which form assets are to be found, and to describe their protection requirements in terms of relevant protection goals—at least confidentiality, integrity and availability. Since all protection involves costs, organizations must strike a balance between sufficiently high protection and the lowest possible use of resources—excessive protection of assets (overprotection) must be avoided.
In the process of the asset identification, for example, the person responsible for the process could be asked what the consequences would be if information were to fall into the wrong hands (confidentiality), if data from an automated control system were to be falsified (integrity), or if a system were to fail (availability). The need for protection can then be derived from the query of such potential damage cases and appropriate measures for protection can be defined.
Assets include corporate values such as information, know-how and processes, as well as additionally all software and hardware elements that contribute to their processing or protection. If the scope (organization, infrastructure, IT systems, applications, personnel) is also defined, the completeness of the asset inventory can be estimated and checked.
As a rule, management should be able to quickly identify assets that are particularly critical to the existence of a company. It is then a good idea to ask the respective officers of each department to add their information assets. Those organizations that have already introduced quality management with a turtle diagram in the context of ISO 9001 certification can use the existing process descriptions here—provided, of course, that the quality management is also lived in practice and was not just used as a sham facade for a certification audit. When transferring assets on the basis of the process descriptions, interfaces and thus initial efficiency potentials can usually be identified if the same asset has relevance across processes.
Differentiation between assets and configuration items
Assets of the processes as well as the information values are called primary assets—secondary assets are all those that have a supporting effect. The latter can be subdivided into further levels if one secondary asset supports another.
However, it is also possible that primary assets (e.g., information) are subordinate to other primary assets (e.g., processes).
With secondary assets, the trick is to limit their number and thus their complexity in a reasonable way while maintaining the highest possible degree of completeness. It is often suggested that a configuration management database (CMDB) be adopted from IT service management. Although this would be quickly at hand, it has too high a level of detail, which unnecessarily complicates asset management. In addition, not all secondary assets are included, since there are other types of supporting assets that IT does not usually list there—such as vaults, buildings or turnstiles. In short, asset is not configuration item (CI). Nevertheless, it doesn’t hurt to take a supplementary look at an existing CMDB to identify or evaluate any dependencies within your own IT structure. In order to provide action-oriented data, it is worthwhile to assign the configuration items to the assets.
Structuring asset classes
Relevant for the creation of an asset class are the protection needs assigned to it and a similar implementation of the protection measures: All assets with the same or very similar protection requirements then fall into a class and are clustered in this way. Whenever there are differences in the protection requirements of the assets to be classified or in the type of security requirements and measures to be implemented, an asset group is split.
For example, in the case of devices, a distinction could be made as to whether it is a notebook or a workstation, since hard disk encryption is only considered necessary for notebooks, for example. For workstations, a further granulation can be made depending on whether it is a feedback station or a training computer, for example, which could possibly result in differences in the authentication method. Once again, possible overlap between assets and CMDB should be noted here.
As a result of the collection of assets, a network or tree structure is created that describes a subordination of the supporting assets to the supported assets and can now be used to assign the protection requirements.
One possible method is the inheritance of the protection requirement (for example, in BSI Standard 200-2, chap. 8.2.2). Here, the maximum protection requirement of all information assets contained in the secondary assets is considered to be the protection requirement of the primary asset (see Fig. 1). The idea behind this is that the need to protect information is naturally transferred to the systems in which it is processed, for example, and from there in turn to other supporting systems which store it. Depending on the application used, this inheritance is also automated.
However, this approach contains some “softeners” (compare BSI Standard 200-2, IT-Grundschutz methodology, version 1.0, chapter 8.2.2):
Dependencies: If an application relies on the results of another application, its protection needs transfer to that delivering application—this is not taken into account with vertical inheritance.
Accumulation effect: If an asset supports many others (e.g., server with many dependent systems), its individual protection requirement may be higher than the protection requirement of the supported assets.
In practice, this means that an individual assessment of each asset becomes necessary. Inheritance according to the maximum principle tends to mean that the highest protection requirement of an asset is inherited downwards, which means that lower levels may be overprotected. This effect increases the more levels the secondary asset structure comprises.
On the other hand, there are also factors that reduce criticality, as two examples may illustrate:
- Distribution effect: If an application is distributed across several systems, the protection requirements of the supporting assets may be lower. If, for example, a cluster is used for highly available information because this should still be accessible even if a node fails, then the nodes themselves (e.g., storage systems) no longer need to be highly available. The protection requirement is therefore lower due to the distribution effect.
- Encryption: If, for example, an email program encrypts messages sent, highly confidential information can also be transmitted securely over unsecured lines.
In order to supplement the mechanisms described so far, it is therefore useful to evaluate the supply, demand and requirement of an asset (see Fig. 2):
- The supply indicates the protection requirement for which an asset is intended and, in the best case, also secured with measures. It is, so to speak, the actual state of the asset that the person responsible for the asset has planned and knows.
- The demand, on the other hand, is the need for protection that an asset requires from its supporters. So, if there is a reduction in the need for protection through measures such as redundancy or encryption, a lower value is passed on here to the underlying assets. The question of such mechanisms reducing the need for protection can usually be answered quickly.
- The requirement is the maximum of all the needs of supported assets, i.e., the layer above. This is usually the specified protection requirement.
This splitting of protection requirements has various consequences. To illustrate this, consider a critical asset supported by a normal asset. Passing on a critical need then has the following impact:
- Automatic passing through the levels no longer takes place, since initially only the requirement on the next level changes, but not automatically the demand.
- In the case of the supporting asset, a mismatch between the requirement and the supply becomes apparent—this can be reported to the person responsible for the asset via a trigger. In this way, communication between the persons responsible for the parent asset and the supporting asset is encouraged.
Exchange between asset managers
Such communication could cause processes to be adjusted or other assets to be brought in. This can make sense if the requirements are only one-off or if costs can be saved as a result. For example, one conceivable scenario would be to transmit highly confidential information that is usually sent as an email via a secure exchange platform in the future instead of upgrading the email system. It would also be possible for the person responsible for the “cost driver” to take measures to reduce the requirement if this is cheaper overall—for example, by securely encrypting strictly confidential information of the superordinate asset already there and thus reducing the protection requirement of the supporting assets.
The supporting asset’s supply can, of course, also be adapted through further security measures so that it meets the new requirements. All in all, it becomes clear here that the simple inheritance of an (expensive) protection requirement can be broken with a case-by-case decision. This procedure has proven useful in practice, for example, during implementation for first-time certification to ISO 27001, precisely because the guidelines are designed to prescribe staggered security measures for different protection needs.
Benefits for ISO/CISO and IT
In terms of protection needs, deviations in both directions - i.e., overprotection and underprotection—are associated with costs and risks: This is because security measures that are too high are easily ignored in everyday work. Such behavior is also at the expense of protective measures for really important information assets. Inheritance, which continues to be used in principle, is still used to determine a maximum of all requirements in order to assess the requirements for an asset—but there is no longer any fully automated and uncontrolled inheritance through all levels. This leads to trying to solve the problem where it arises first. With the help of this approach, cost benefits can be discovered by specifically identifying cost drivers of protective measures or protective mechanisms that are too weak.
The security measures taken for an asset’s supply can be checked against the necessary measures from the guidelines. If requirements and needs differ, (IT) security measures must be in place that can be checked—uncontrolled deviations should be prevented without exception.
Last but not least, those responsible for secondary assets also benefit from asset management and this approach: They learn in which processes their technology is used and who is driving up the requirements. Changes are no longer passed on automatically and sometimes unnoticed, so that they can communicate with the users of their infrastructure in order to have a say in the decision-making process. Especially in large organizations, it can be difficult for IT departments to assess the relevance of their systems—it is precisely this transparency that the asset management described above creates.
In practice, a system is needed in which information about assets can be clearly entered and maintained. In principle, an asset inventory can also be implemented with a spreadsheet, although there are some limitations compared to good specialized solutions, which Table 1 lists as an example. Conversely, it can be used to identify useful requirements for software developed specifically for the assessment of assets.
Although the table is not exhaustive, it is easy to see that from a certain complexity and size of the asset landscape, a software solution developed specifically for this purpose is likely to be profitable in order to map all essential requirements. In this (asset) management system, it should be possible to flexibly define asset classes. It is also advisable to integrate the solution as far as possible into the existing IT infrastructure and business process landscape so that centralized access to information, processes and data is possible. Ultimately, only this reduces the manual maintenance effort and increases the reliability of the protection requirement analyses due to the higher transparency.
|Spreadsheet software||Asset management software|
|Limited scalability||Sustainable solution even with growing corporate structures|
|Asset classes must be maintained separately—changes do not result in automatic adjustments to included assets.||Cross-connections between asset classes and the respective assigned assets result in a lower maintenance effort.|
|Data security and documentation of changes are limited.||Access rights should be implemented via assigned roles, documentation via history entries.|
|Strong limitation with “if-then” rules||Should support flexible adjustments of rule definitions and automatisms.|
|Fine-tuning according to supply, need and requirement is difficult, as a panoramic view of the asset landscape as a whole is missing.||Relevant information as well as cross-connections to other assets should be clearly recognizable, so that well-founded decisions about supply, need and requirement become possible.|
|Creating, maintaining and (re)valuing assets mean manual effort.||Assignment of an asset to a class should automatically result in the assignment of the protection goals set for that class.|
|Communication between those responsible for the assets is not easily possible.||There should be an overview of all stakeholders with automatically triggered notifications.|
|Processing of information related to risk assessments usually requires a change of tool.||Derived risks should be able to be handled further in the integrated risk management.|
|Usually only provides a picture of the current status, making it difficult to draw conclusions about how individual assessments came about—this makes periodic reassessments within the asset lifecycle difficult.||Cross-process dependencies of assets should be easily identifiable to track additions and changes during the asset lifecycle.|
|Maintenance-intensive; tends to be an error-prone isolated solution that is detached from other business processes.||Should enable a process-spanning ecosystem as a platform architecture to achieve synergy effects through centralized databases and the use of already existing process and IT infrastructure.|
Table 1: Comparison between spreadsheets and asset management software reveals useful features/requirements of specialized solutions.
If a hazard or damage really does occur, or if risk assessments change, it is quicker and easier to check whether there are cross-connections or dependencies with other assets that could also be affected. Decisions about supply, demand and requirements can also be made more accurately thanks to the structured availability of information and improved transparency of process structures. Isolated solutions do not achieve their goals here. All in all, an integrated asset management solution is needed that is based on a business process platform—this is the only way to ensure reliable protection needs analyses from which risks and measures can be coordinated. An integrable risk management system is also highly recommended.
Finally, it should be mentioned once again: Asset management is not used for certification audits, but is the basis for protecting a company’s information assets that are critical to its existence. Organizations should keep this in mind when deciding on an (integrated) asset management system.
Dipl. Ing. Andreas Chlebnicek worked for a long time in the automotive as well as PKI environment as a Software Developer before he switched to consulting—since 2021 he is Head of Governance, Risk and Compliance (GRC) Management at OMNINET.
Dr. Thomas Kaufmann was the CISO and Data Protection Officer of a publicly traded automotive supplier for many years and is now an independent Consultant and Managing Director of DatenSchutzBeratung Dr. Kaufmann GmbH.