5.3 Derivation of Intrinsic Security Requirements
Based on the assessed risks, identified threats, and the organization-specific risk appetite, appropriate intrinsic security requirements are synthesized using patterns, formulated in the unified security requirements data model, and prioritized based on the associated security risks.
While the derivation of high-level requirements such as “Confidentiality of the Com-ponent Key-storage must be ensured” is straight-forward, the selection of specific imple-mentations, considering the overall structure, is a more delicate task. The first step to automate this process is to develop a threat mitigation catalog that assigns a mitigation to each relevant combination of threat and the base system model object classes.
While an experienced security expert balances the impacts of the risk with possible security measures, an automated activation of security controls bears the risk of mis-judgments. Therefore, decisions to take active measures that could negatively affect the functionality of the system shall remain the responsibility of a human controller.
However, actions without such risks and preparations to support the decision of the controller should be implemented immediately. The shown approach proposes such measures based on a model of the SuE and pattern for recommendations to support the operator in making proper decisions. In contrast to static networks where it was sufficient to assess the infrastructure once and then inherit security goals from the data, this process should be triggered on each update of the model. Especially for dynamic structures, attack, and impact vectors from which a specific risk was derived should be considered when choosing and prioritizing an appropriate security risk mitigation.
5.3.1 Implementations per Security Objective
The type of appropriate implementation depends on the relevant threat and object classes.
In addition to the following description of possible measures and their interaction, Table 5.3 provides exemplary security controls for each of the four basic system object model classes. Furthermore, sets of hierarchical ordered threat mitigations are provided in the Figures 5.2, 5.3 and 5.4.
76 5 Derivation and Management of Security Requirements
Table 5.3:Examples of Security Controls and Measures against a targeted Asset
Threat Function Component Connection Data
Spoofing Cryptographic
Repudiation Logging Digital Identity Logging Logging
Information
Disclosure Obfuscation, ACL Storage Encryption Encryption Encryption, ACL Denial of
Privilege Hardening, Testing ACL, Sandboxing
Supplementing security controls with specific information enables the automated gener-ation of rules for network- or host-based monitoring that may be applied immediately by an Intrusion Prevention System (IPS). However, while ACLs are recommendable in most cases, further firewall rules and active intrusion handling measures should only be automatically prepared and suggested to the operator.
Confidentiality: Confidentiality is threatened by information disclosure. For data, this is avoided by encryption on the producing functions, the transferring connections, and the storing components. Functions containing valuable know-how also have inherent protection needs that can be maintained by obfuscation, by controlling access to binaries and preventing runtime analysis, e.g., via encapsulation. Simi-larly, protection of the operating parameters and details about components can be achieved by access control or sandboxing. Information about routes, technolo-gies, and performance of connections can be obfuscated, e.g., by making them transparent to high layer applications, or by hiding them in side-channels.
Integrity: The integrity of connections can be ensured by network monitoring [144].
Validation can ensure the integrity of data [127]. For functions, performing reviews and software tests can be a viable measure to initially ensure their integrity. At runtime, their correct execution can be protected by isolation or hardening, which is also a measure to protect the integrity of components.
5.3 Derivation of Intrinsic Security Requirements 77
Availability: The availability of data can be ensured by fallback values, or redundancy in terms of a secondary connection. Therefore, information about the availability of a connection can also be gained by link detection. For functions and components watchdogs, and timeouts are technical controls, while Service Level Agreements (SLA) are administrative measures, especially for functions provided by third-parties.
Authenticity: The authenticity of data is typically ensured by signatures or by appropri-ate asymmetric encryption. To validappropri-ate the authenticity of connections, certificappropri-ate- certificate-based authentication methods, as well as Virtual Private Networks (VPN) are widely used. The authenticity of specific functions might be initially validated by functional tests and by appropriate fingerprints during startup and runtime.
Similarly, components can use HSMs to validate their authenticity.
Non-repudiation: Non-repudiation of data is typically ensured by asymmetric cryp-tography, especially cryptographic signatures, and by tamper-secure protocols like a blockchain.
5.3.2 Selection and Prioritization of Security Controls
Cataloging and rating of security controls enables their automated assignment to security goals that exceed a defined security risk threshold. In addition to the applicability as per se, their effects on the RAP and CILs as well as the dependencies introduced by the security control must be considered. Common dependencies are for example a secure keys management, secure implementations, and a secure network configuration.
Since the automated intrinsic security requirements deduction process considers the protection of each security goal individually, it fully supports the defense-in-depth principle. In practice, this can be appropriate for critical assets, but should, usually be adjusted to the delta of the risk level between protected and unprotected implementations.
Practically speaking, adding content encryption for a data that is solely transmitted by an end-to-end encrypted TLS connection between secure components rarely provides a substantial increase of security. While the additional content data encryption complicates the execution of confidentiality threats, the resulting marginal delta in the RAP hardly justifies the resulting costs for more powerful components. Furthermore, each additional function increases complexity and may in turn allow for attacks.
78 5 Derivation and Management of Security Requirements