Security Framework Annex A: Industrial Security Standards
A. 3
METHODOLOGIES TO ASSESS SECURITY PROGRAMS
Several methodologies exist to assess security programs, the security posture of organizations and their process for secure development and maintenance of their products. They include the Cyber-Security Capability Maturity Model( C2M2) 1 and its vertical-specific variants( ES-C2M2 and ONG-C2M2 for energy and oil and gas subsectors, respectively), the tiers of the NIST framework focused on critical infrastructures, the CERT Resilience Management Model( CERT-RMM) focused on operational resilience management and the Building Security In Maturity Model( BSIMM) focused on secure software development. They work best when tailored for the organization. 2
A. 4
STANDARDS FOR EVALUATING SECURITY PRODUCTS
Common criteria and Federal Information Processing Standard( FIPS) standards, briefly discussed below, focus on certification of security products rather than evaluating security processes or policies. Within this context, these standards allow technical evaluations by third parties such as trusted labs.
Use of such evaluation approaches requires extra care, especially in terms of how they adapt to change and respond to the progress in attack technologies. There are many products with practically meaningless evaluations, because they’ ve been evaluated in very restricted configurations, or because only some of their basic features have been evaluated.
A. 4.1 COMMON CRITERIA
Common Criteria for Information Technology Security Evaluation, a. k. a. Common Criteria( CC), is an international standard( ISO / IEC 15408 3) used to evaluate security capabilities of IT products, including secure integrated circuits, operating systems and application software. CC is used to assess a product’ s ability to meet security requirements utilizing two key notions: evaluation assurance levels and protection profiles.
The rigor with which an assessment is carried out is referred to as the Evaluation Assurance Level( EAL), which ranges from EAL1 up to EAL7. As an example, functional testing is sufficient to meet EAL1 requirements but to achieve EAL7 thorough testing as well as formally verified designs are required.
A protection profile consists of security requirements and their rationale as well as an EAL. A protection profile should describe objectives, assumptions and both functional and assurance requirements. When customers( i. e., owners or operators) plan to buy a product that has Common Criteria Evaluation, they should ensure that they understand and agree with the protection profile against which the product has been evaluated.
1
See [ ENER-C2M2 ] and Annex B
2
See [ CERT-RMM ] and [ BSIMM ]
3
See [ ISO-15408 ]
IIC: PUB: G4: V1.0: PB: 20160926- 128-