Common Criteria
Common CriteriaThe CommonCriteria (CCV2.0) provides a process to understand the issues around security and the products that it aims to certify. Many developers understand what they don't want users and ThreatAgents? to do, but they don't understand other issues around securing their product.
The CommonCriteria is a merge of various security standards (US, EU, etc) to ensure that products are more secure and that security issues are understood by a wide audience.
The first step: In an implementation independent situation, understand the,
The third step: Developers must then justify why their countermeasures protect the assets.
The fourth step: Developers must produce tests and evaluations that aim to prove that their countermeasures work. This 'proving' of countermeasures gives end uses assurances that the countermeasures work as indicated. There are different EvaluationAssuranceLevels? (EAL1..7) that are developed from easiest to most difficult to achieve. Typically, they indicate levels of testing, documentation, code coverage, etc.
I will come back and flush this out further.
Er, do you mean "... flesh this out ..." ??
I know time flies, but I hope you return soon.
Some resources on Common Criteria:
http://www.iso15408.net - The ISO 15408 Toolkit
The Common Critera is a process that tries to ensure that the developers have achieved the level of security the claim. When a product is certified to level EAL4, it does not indicate that the product is secure. EAL4 is a level of assurance that the product is as secure as the developers claim. The actual level of security is defined by the SecurityTarget which is composed of many smaller security definitions. These definitions are typically reusable and available as part of a catalog. The Security Target, the implementation and the process used to achieve the SecurityTarget is validated by a security center to provide EvaluationAssuranceLevels?.
The SecurityTarget is unlike some security standards that define a level of security. You would typically find that those security standards have CC Security Targets defined for them. The benifit of the SecurityTarget is that a business may evaluate a product and ensure that the businesses security needs are met, while the development company may develop a product that may be simpler than some security products (not meeting various security definitions) but cater for a businesses needs.
The downside of the SecurityTarget is that it is cumbersome to put one together (I was learning the whole process, so it may actually be simpler the better you understand the process). It would be easier to use predefined Security Targets for a particular product. Those definitions are reusable across products. For example: You should be able to find/purchase various Security Targets for hardware switches, software firewalls, database application products, etc. These definitions may define different levels of security based on the type of product. Various security standards may not define security levels for a standard database application, whereas, there may be a couple of Security Targets of differing levels of security for a database app.
Security standards for embedded hardware modules are not typically applicable to typical software applications and only highlights the need for a common secuirty standard define when focusing on different modules.
(again, i will flesh this out once i have more time)
EditText of this page
(last edited October 18, 2005)
or FindPage with title or text search