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 -