Term
|
Definition
| Functionally Tested. Applies when you require confidence in a product's correct operation, but do not view threats to security as serious. An evaluation at this level should provide evidence that the target of evaluation functions in a manner consistent with its documentation and that it provides useful protection against identified threats. |
|
|
Term
|
Definition
| Structurally Tested. Applies when developers or users require low to moderate independently assured security but the complete development record is not readily available. This situation may arise when there is limited developer access or when there is an effort to secure legacy systems. |
|
|
Term
|
Definition
| Methodically Tested and Checked. Applies when developers or users require a moderate level of independently assured security and require a thorough investigation of the target of evaluation and its development, without substantial reengineering. |
|
|
Term
|
Definition
| Methodically Designed, Tested, and Reviewed. Applies when developers or users require moderate to high independently assured security in conventional commodity products and are prepared to incur additional security-specific engineering costs. |
|
|
Term
|
Definition
| Semi-Formally Designed and Tested. Applies when developers or users require high, independently assured security in a planned development and require a rigorous development approach that does not incur unreasonable costs from specialist security engineering techniques. |
|
|
Term
|
Definition
| Semi-Formally Verified Design and Tested. Applies when developing security targets of evaluation for application in high-risk situations where the value of the protected assets justifies the additional costs. |
|
|
Term
|
Definition
| Formally Verified Design and Tested. Applies to the development of security targets of evaluation for application in extremely high-risk situations, as well as when the high value of the assets justifies the higher costs. |
|
|
Term
| Target Of Evaluation (TOE) |
|
Definition
| the product or system that is the subject of the evaluation. |
|
|
Term
| TCSEC Divisions and classes |
|
Definition
| The TCSEC defines four divisions: D, C, B and A where division A has the highest security. Each division represents a significant difference in the trust an individual or organization can place on the evaluated system. Additionally divisions C, B and A are broken into a series of hierarchical subdivisions called classes: C1, C2, B1, B2, B3 and A1. |
|
|
Term
|
Definition
| a document, typically created by a user or user community, which identifies security requirements for a class of security devices (for example, smart cards used to provide digital signatures, or network firewalls) relevant to that user for a particular purpose. |
|
|
Term
|
Definition
| the document that identifies the security properties of the target of evaluation. |
|
|
Term
| Security Functional Requirements (SFRs) |
|
Definition
| specify individual security functions which may be provided by a product. |
|
|
Term
|
Definition
| A given block of plaintext and a given key will always produce the same ciphertext. |
|
|
Term
|
Definition
| Individual characters are encoded by combining output from earlier encryption routines with plaintext |
|
|
Term
|
Definition
| Adds an IV and uses a chaining method such that results of the encryption of previous blocks are fed back into the encryption of the current block. This is useful for message confidentiality. |
|
|
