Common Criteria for Information Technology Security Evaluation
19. August 2024
An international standard
In Germany, the Federal Office for Drugs and Medical Devices (BfArM) is generally responsible for the approval of medical devices and is the formal point of contact when it comes to (patient) safety, which can also be affected by cybersecurity vulnerabilities. The competent authority responsible for IT security, on the other hand, is the Federal Office for Information Security (BSI), which also participates in the development of technical standards as part of its duties in accordance with Section 3 BSIG. These standards are also relevant for the organization and documentation of the security processes of medical device manufacturers because the BSI also provides technical expertise for the BfArM in accordance with §85(5) MPDG, i.e. it provides advice, proactively reports specific vulnerabilities to the BfArM if necessary and carries out technical assessments of circumstances, which then form the basis for decisions by the BfArM, e.g. for recalls or requirements.
The Common Criteria for Information Technology Security Evaluation (CC) and the supplementary Common Methodology for Information Technology Security Evaluation (CEM) represent an important standard of this kind. The CC and CEM are an internationally recognized standard to which the BSI has contributed, in corporation with authorities responsible for IT security in other countries—from Japan and Europe to the USA—as well as ISO and IEC. They are freely available in the current version from 2022 and will also be published as ISO/IEC 15408-1:2022 to ISO/IEC 15408-5:2022 and ISO/IEC 18045:2022, respectively.
The standards are intended to align the documentation of security-related product aspects in a way that promotes a common understanding between the manufacturer and other parties and that allows for an independent and standardized assessment. In this way, the standard can also help to avoid misunderstandings and improve confidence in processes and products.
Product and process requirements
The main content of the Common Criteria is a catalogue of requirements, which are set out in the second and third part of the standard. The second part [CC:2022(2)] deals with security-relevant product features, so-called security function requirements (SFR), i.e. technical measures that are intended to ensure the availability of system functions (e.g. in Section FRU: Resource utilization chapter) or the confidentiality and integrity of certain information and procedures, as presented, for example, in the chapters Stored data confidentiality (FDP_SDC) and Stored data integrity (FDP_SDI).
The third part [CC:2022(3)] describes requirements for the verification processes and the documentation by means of so-called security assurance requirements (SAR), which are intended to establish a minimum level of confidence in the correct implementation of the technical requirements and simplify auditing, e.g. for external test bodies. This is supported by a standardized presentation of the verification methods and results, as specified in the fourth part [CC:2022(4)].
Hierarchical structure and sub-catalogues
The requirements catalogue is organized by topic in a hierarchical structure. Both functional and process requirements are grouped as elements of so-called components, which in turn form families and, at the highest level, classes. For example, the requirements in the chapters mentioned above form the families FDP_SDC and FDP_SDI, respectively, and belong to the class FDP: User data protection.
The individual requirements groups are not free of overlaps; in fact, fundamental aspects are regularly repeated in the individual components. However, this structure supports a central concept of the catalogue, namely the definition and use of sub-catalogues. The manufacturer can tailor these sub-catalogues so that they meet the requirements of the specific product and internal processes. Part 1 defines several mechanisms, such as packages and protection profiles, for constructing complete and consistent sub-catalogues. This allows for focussing on key aspects, based on identified needs, threats, and risks, and for defining a scope that is appropriate to the context, but still practical. The first part also defines the basic terminology and concepts to which the requirements and dependencies repeatedly refer, such as the central object of investigation, the so-called target of evaluation (TOE), as well as the definition of the desired protection goals and the required level of protection in the form of the security problem definition (SPD). The latter is based on the threat analysis and describes relevant threats, corresponding objectives for protective measures and essential assumptions, e.g., regarding the operating environment or the capabilities of threat actors. These definitions ultimately determine whether the set of selected requirements is appropriate, their implementation is effective, and the verification methodology can provide sufficiently convincing evidence.
Figure 1: The so-called security target (ST) comprises all essential specification elements such as the problem definition, the protection goals, and the correspondingly selected requirements. It must be consistent and complete according to the logical dependencies (which in turn is itself the subject of certain security assurance requirements (SAR) that require the verification of this consistency). [CC:2022(1), Fig. 4]
The fifth and final part of the standard [CC:2022(5)] plays a special role in this context. It offers the predefined sub-catalogues Evaluation assurance level 1 (EAL1) to Evaluation assurance level 7 (EAL7) that ensure an increasingly rigorous verification methodology. While conformity with EAL1 (Functionally tested) only addresses a limited protection objective and assumes a low threat level, the implementation of EAL7 (Formally verified design and tested) is much more complex and requires significantly greater methodological expertise. On the other hand, it addresses high-risk scenarios and protection goals that justify considerable effort.
Composition
The standard also describes mechanisms for composing the documentation of individual product parts so that they can be organized in a modular way and integrated into different contexts as required. Criteria addressing dependencies, consistency, and revalidation thus support platform-oriented product development.
Benefits
Even if the standard is not fully applied and regardless of a formal certification by an accredited body, the requirements catalogue can be a helpful source and provide guidance for the evaluation and further development of a manufacturer's products and processes. For example, the test management may employ process requirements of the class ATE: Test to identify potential for internal improvement, which can contribute to better process control in the sense of quality management and strengthen the confidence to comply with the state of the art. Particularly for aspects that are difficult to assess and leave room for interpretation, such as the analysis of vulnerabilities, a comparison with the corresponding requirements (e.g. class AVA: Vulnerability assessment) can provide a certain degree assurance that the applied procedures are valid and acceptable also by other parties.
Moreover, demonstrating that and how specific criteria defined in the standard are addressed provides convincing arguments for auditing bodies and authorities to accept the manufacturer's evaluation and reasoning in otherwise disputable cases, especially if the bodies contributed to or recognized the standard.
References
- [CC:2022(1)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 1: Introduction and general model, www.commoncriteriaportal.org, 2022
- [CC:2022(2)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 2: Security functional requirements, www.commoncriteriaportal.org, 2022
- [CC:2022(3)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 3: Security assurance requirements, www.commoncriteriaportal.org, 2022
- [CC:2022(4)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 4: Framework for the specification of evaluation methods and activities, www.commoncriteriaportal.org, 2022
- [CC:2022(5)] Common Criteria for Information Technology Security Evaluation (CC:2022) - Part 5: Pre-defined packages of security requirements, www.commoncriteriaportal.org, 2022
- [CEM:2022] Common Methodology for Information Technology Security Evaluation - Evaluation methodology, www.commoncriteriaportal.org, 2022
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
