The 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. http://www.commoncriteria.org 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, * Owners * Assets * Vulnerabilities * Threats * ThreatAgents The second step: Understand how the TargetOfEvaluation aims to protect the owners and their assets. This is done through the use of a catalog of commonly understood security issues. 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. * EAL1 would, for example, test the APIs. * EAL5 would, for example, require tests to ensure complete code coverage (ie: the tests must pass and every line of source code must be tested). The EvaluationAssuranceLevels are composed using a catalog of assurance techniques. More evaluation implies more assurances. ---- 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. -TimTwelves (again, i will flesh this out once i have more time) ---- CategorySecurity