Common Criteria (CC) for Information Technology Security Evaluation

Abstract

Mead (2006) explained that Common Criteria (CC) is set of guidelines and specifications (e.g. ISO/IEC 15408) that are known internationally and developed for evaluating security products and computer systems to ensure that such systems and products meet the security standards requirements that are agreed-upon. Common Criteria is formally known as “Common Criteria for Information Technology Security Evaluation”. The common Criteria contains two key components that define such criteria, these components are:

 

  • A Protection Profile (PPro) – It defines the standards set of requirements for security that is required for a specific product (e.g. Firewall).
  • Evaluation Assurance Level (EAL) – It defines the levels that used for evaluating a product, and it indicates how thoroughly the product was tested. Such levels goes from one (1) – seven (7) where seven (7) being the highest-level of evaluation, and one (1) being the lowest-level of evaluation. With higher-level of evaluation means that product went through more tests than other products, however, it doesn’t mean that the product has a higher level of security than others.

 Mead (2006) also explained that for a product to be submitted for evaluation, the vendor must complete the Security Target (ST) description that articulates the following subjects:

 

  • An assessment of potential threat
  • A description of the product and product’s security features
  • What Evaluation Assurance Level the vender used to test against, and how the product comply with the relevant Protection Profile at the Evaluation Assurance Level.

The Importance of Common Criteria

Shimonski (2004) explained that the Common Criteria contains a number of Evaluation Assurance Levels (EALs) that indicate how far the security functional requirements have been met. There are seven levels that can determine the level of security the product has. The higher the level, the more the security requirements are met. The following are the details of such levels:

 

  • EAL1 (Functionality Tested) – implies that the evaluation of product against the basic assurance of the product functionality was reviewed however, no security issues were reviewed.

  

  • EAL2 (Structurally Tested) – implies that the code of the product was reviewed and no security issues were reviewed.

 

  • EAL3 (Methodically Tested and Checked) – implies that no re-engineering of the code were done, and the evaluation was done through low to moderate security assurance.

 

  • EAL4 (Methodically Designed, Tested, and Reviewed) – implies that the product code were reviewed where re-engineering can occur if flaws are found. Also, the vendor in this level proves that the product is safe to be used, and security assurance from moderate to high was achieved.

 

  • EAL5 (Semi-Formally Designed and Tested) – implies that the product security was achieved as part of the development planned without any significant costs based on the approach used to reach the required security level.

 

  • EAL6 (Semi-Formally Verified Design and Tested) – implies that the product were evaluated against a high-risk situations and additional costs are justified.

 

  • EAL7 (Formally Verified Design and Tested) – implies that security targets were achieved in this evaluation for application in a high-risk situations and the high cost of such evaluation was justified.

Common Criteria is a good idea however it is expensive, and with enterprise security management, vendor usually rewrites their own custom security target or the product requirements documents that are based on the security target. With today’s technologies, IT products are moving toward simplified evaluation process that can reduce the cost of the Common Criteria process by implementing a Protection Profiles where a set of standard features that consumers and IT professionals are expected to find in a certain product. The Protection Profile can also be called requirements document that can guarantee better informed decisions for the acquiring products. Under the implementation of the Common Criteria in enterprise security management, IT security professionals found that such criteria is hard to compare with, since each product has its own security target document (Brickman, 2010).

Ernst and Martin (2010) explained that Common Criteria is widely used approach that implements defined characteristics that are focused on flexibility, consensual approach to standardization, and the international standards for the information security evaluation. Such standards provide an important assessment of the weaknesses and the strengths of any product, and also highlights the possible implications of the flaws exist in any product. There are valid criticisms about the scheme where problems such as validity and effectiveness are valid issues. For example, the validity of assurance where Common Criteria can be constrained with the financial limitation; there is a trade-offs between assurance level, and the cost required to achieve the right evaluation level of the Common Criteria.

In addition to constraints that can be a challenge for the process, there is another challenge for the policy-makers where such trade-offs can create a systemic problem where an improvement in one dimension may effect another dimension, and as such; solving the trade-offs in information security regulations will not be easy fix (Ernst and Martin, 2010). 

The Benefits of Using Such Criteria

TechNet (2009) explained that as the result of the endorsement of the Common Criteria, and the  establishment of the universal set of standards in IT security that are implemented to improve the availability and security of IT products, such criteria contributes to the consumer confidence, improve the efficiency, and the cost-effectiveness of the product. Such criteria allowed customers to make informed security decisions in several ways:

  • Consumers can determine the level of security required in their product based on comparison against their requirements and the Common Criteria.
  • Consumers can easily determine if certain product is within their security requirements.
  • Consumers can rely on the Common Criteria since it is created by independent testing lab and not performed by the vendor.
  • Common Criteria is international standards that can work with consumers worldwide.
  • Common Criteria helps vendors build a better secure IT product.

Mead (2006) explained that great benefits to any organization can be obtained by using the system acquisition elements in conjunction with the Common Criteria features, and the following table indicates such relationship:

 

Common Criteria features

System Acquisition Elements

Results

CC Paradigm System Acquisition Paradigm Shows the common similarity between the CC and the Acquisition Paradigms.
Protection Profile (PP) Request for Proposals Provides details of the customer’s requirements.
Security Target (ST) Proposal Provides a good idea what will be provided by the suppliers that will satisfy the needs for the customer.
Target of Evaluation Delivered Systems Represents the physical supplier’s manifestation about what will be delivered to the customer.
Evaluated System Accepted System Proves the consistency of the above three preceding representations and that all are consistent.

Conclusion

Common Criteria is a framework where the security functions and assurance requirements that are required for computer systems or security products are specified by users. Vendors can then implement and make claims about the security Common Criteria evaluations that are performed against computer security product and systems (Ernst and Martin, 2010).

Bidstrup (2007) explained that Common Criteria (aka ISO 15409) is internationally standard and it is recognized by twenty four (24) governments where it can provide to consumers both the detailed information about the security of the products, and software they’re planning to purchase and also the confidence that such product met certain security requirements. However, Common Criteria (CC) has failed to gain the popularity required, and also the broad acceptance among private sectors or any organizations beyond the government agencies. Finally, when considering the software vulnerabilities that might occur, there are three general issues that can be potential vulnerabilities:

 

  • Design vulnerabilities – represents all the issues that were designed for software that don’t meet adequately the security requirements, expectations or needs. Operating systems and Smart Cards are a good example where the risks and the threat to product have been defined and were reflected in the protection profile.
  • Implementation Vulnerabilities – Where the software can expose certain risks that can be based on the implementation deficiencies. Common Criteria fails to meet the consumers’ expectations and needs that can provide the assurance that given product doesn’t contain implementation vulnerabilities that can expose consumers’ risks. In asking the questions about software “Is it Safe” the customer expectations for such software is that it can be securely deployed and maintained to operate.
  • Deployment Vulnerabilities – Where software can show vulnerabilities when it is miss-configured while such vulnerabilities can be prevented by other configurations.

References

Brickman, J. (2010) Common Criteria – a good concept in transformation [Online]. Available from: http://community.ca.com/blogs/iam/archive/2010/03/25/common-criteria-a-good-concept-in-transformation.aspx (Accessed: 24 December 2010).

Bidstrup, E. (2007) Common Criteria and answering the questions ‘Is it Safe’ [Online]. Available from: http://blogs.msdn.com/b/sdl/archive/2007/12/20/common-criteria-and-answering-the-question-is-it-safe.aspx (Accessed: 24 December 2010).

Ernst, D. & Martin, S. (2010) The Common Criteria for Information Technology Security Technology Security Evaluation [Online]. Available from: http://www.eastwestcenter.org/fileadmin/stored/pdfs/econwp108.pdf (Accessed: 24 December 2010).

Mead, N. (2006) The Common Criteria [Online]. Available from: https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/239-BSI.html (Accessed: 24 December 2010).

Shimonski, R. (2004) Microsoft Windows and the Common Criteria [Online]. Available from: http://www.windowsecurity.com/articles/Windows-Common-Criteria-Certification-Part-I.html (Accessed: 24 December 2010).

TechNet (2009) Exchange Server 2003 Common Criteria Certification [Online]. Available from: http://technet.microsoft.com/en-us/library/cc164327(EXCHG.65).aspx (Accessed: 24 December 2010).

 

 

 

 

 

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: