About the EPL
The Evaluated Products List (EPL) is the definitive list of certified information technology products for use by Australian and New Zealand Government agencies in the protection of official information as required by the Information Security Manual (ISM).
The Information Security Manual (ISM), the authoritative source for guidance on IT security matters for Australian Government agencies, contains the circumstances in which Australian Government consumers should or must use IT products from the EPL, and also discusses product selection. The ISM is available from the DSD website at www.dsd.gov.au/library/infosec/ism.html. New Zealand Government consumers should consult NZSI 400.
Evaluated Products List structure
The EPL has two logical components:
- The first component, Table 1, lists products that have completed a Common Criteria (CC), Information Technology Security Evaluation Criteria (ITSEC) or an approved DSD evaluation, with a DSD Cryptographic Evaluation (DCE) and DSD Consumer Guide where applicable.
- The second component, Table 2, reflects all AISEP evaluations that are currently underway, along with associated DCE indicators.
Products that have completed a CC or ITSEC certification through a recognised
overseas scheme can be sponsored by an Australian or New Zealand Government
agency requesting DSD to write a consumer guide for the product and to
evaluate the product’s cryptographic functions where applicable.
A consumer guide will aid Australian and New Zealand Government agencies in their
choice of appropriate IT products and will contain the following information:
- The product’s functions that have been evaluated;
- ISM policy relevant to the product;
- Any findings that may have occurred during the course of DSD’s cryptographic evaluation (where relevant); and
- Any additional product settings that will enhance the security of the device.
When a product enters evaluation under the AISEP, it is listed on Table 2 with a description of the components of the product under evaluation and the assurance level against which it is being assessed. The AISEP makes no claims as to the likelihood of the successful completion of the evaluation. Upon successful completion, the product is moved to the appropriate technological section in Table 1.
The historical EPL is a list of evaluated products that may no longer be available in the original evaluated form, are no longer supportable, or the environment that they are designed to operate in has changed. It is recommended that customers considering the use of a product on the historical EPL contact DSD to verify whether the product will meet their security needs. Products that have been moved to the historical EPL will remain listed for at least twelve months before being withdrawn from the historical EPL. Australian and New Zealand Government users should also note that products listed on the historical EPL may not be automatically appropriate for Government use. DSD and GCSB are able to assist respective government users with selecting appropriate products from the EPL to meet their security needs.
For further information about the policy surrounding government software,
please refer to the latest version of the ISM available in the library or
email: assist@dsd.gov.au.
ITSEC and Common Criteria
What are Criteria?
The Information Technology Security Evaluation Criteria (ITSEC) and the Common Criteria (CC) are 'standards' against which an evaluation is carried out. They define several degrees of rigour for the testing and the levels of assurance that each confers. They also define the formal requirements needed for a product to meet each assurance level.
ITSEC
During the 1980s, the United Kingdom, Germany, France and The Netherlands produced versions of their own national criteria. These were harmonised and published as the ITSEC. The current issue, Version 1.2, is accompanied by the IT Security Evaluation Manual (ITSEM), which specifies the methodology to be followed when carrying out ITSEC evaluations. The AISEP continues to use this standard for some high-level security evaluations. The Assurance Level Page contains detailed information about the seven ITSEC levels.
Common Criteria
The Common Criteria website is available at www.commoncriteriaportal.org
The Common Criteria project was initiated to harmonise the ITSEC, CTCPEC (Canadian criteria) and the US Draft Federal Criteria (FC) and TCSEC (Orange Book) into a Common Criteria for Information Technology Security Evaluation (CC) for use in evaluating products and systems, and for stating security requirements in a standardised way. Its aim is to replace national and regional criteria with a worldwide set of standards. The CC has seven assurance levels, however, only the first four are recognised by the Common Criteria Recognition Agreement (CCRA). The Assurance Level Page contains detailed information about the seven CC levels.
Assurance Levels
Common Criteria
The CC has seven assurance levels: from EAL1 the lowest, to EAL7 the highest. At present, only assurance levels up to EAL4 have been incorporated within the international Common Criteria Recognition Agreement (CCRA). The seven CC levels are described below.
Level |
Purpose |
EAL1 |
Functionally Tested. Provides analysis of the security functions, using a functional and interface specification of the TOE, to understand the security behaviour. The analysis is supported by independent testing of the security functions. |
EAL2 |
Structurally Tested. Analysis of the security functions using a functional and interface specification and the high level design of the subsystems of the TOE. Independent testing of the security functions, evidence of developer "black box" testing, and evidence of a development search for obvious vulnerabilities. |
EAL3 |
Methodically Tested and Checked. The analysis is supported by "grey box" testing, selective independent confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environment controls and TOE configuration management are also required. |
EAL4 |
Methodically Designed, Tested and Reviewed. Analysis is supported by the low-level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management. |
EAL5 |
Semi formally Designed and Tested. Analysis includes all of the implementation. Assurance is supplemented by a formal model and a semiformal presentation of the functional specification and high level design, and a semiformal demonstration of correspondence. The search for vulnerabilities must ensure relative resistance to penetration attack. Covert channel analysis and modular design are also required. |
EAL6 |
Semi formally Verified Design and Tested. Analysis is supported by a modular and layered approach to design, and a structured presentation of the implementation. The independent search for vulnerabilities must ensure high resistance to penetration attack. The search for covert channels must be systematic. Development environment and configuration management controls are further strengthened. |
EAL7 |
Formally Verified Design and Tested. The formal model is supplemented by a formal presentation of the functional specification and high level design showing correspondence. Evidence of developer "white box" testing and complete independent confirmation of developer test results are required. Complexity of the design must be minimised. |
ITSEC
The Information Technology Security Evaluation Criteria (ITSEC) provides
seven evaluation levels: from E0 the lowest, to E6, the highest. These
seven levels are described below.
Level |
Purpose |
| E0 | Inadequate Assurance |
| E1 | A security target and informal architectural design must be produced. User Admin documentation gives guidance on Target of Evaluation (TOE) security. Security enforcing functions are tested by evaluator or developer. TOE to be uniquely identified and to have Delivery, Configuration, Start-up and Operational documentation. Secure Distribution methods to be utilised. |
| E2 | An informal detailed design, and test documentation must be produced. Architecture shows the separation of the TOE into security enforcing and other components. Penetration testing searches for errors. Configuration control and developer's security is assessed. Audit trail output is required during start up and operation. |
| E3 | Source code or hardware drawings to be produced. Correspondence must be shown between source code and detailed design. Acceptance procedures must be used. Implementation languages should be to recognised standards. Retesting must occur after the correction of errors. |
| E4 | Formal model of security and semi-formal specification of security enforcing functions, architecture and detailed design to be produced. Testing must be shown to be sufficient. TOE and tools are under configuration control with changes audited, compiler options documented. TOE to retain security on re-start after failure. |
| E5 | Architectural design explains the inter-relationship between security enforcing components. Information on integration process and run time libraries to be produced. Configuration control independent of developer. Identification of configured items as security enforcing or security relevant, with support for variable relationships between them. |
| E6 | Formal description of architecture and security enforcing functions to be produced. Correspondence shown from formal specification of security enforcing functions through to source code and tests. Different TOE configurations defined in terms of the formal architectural design. All tools subject to configuration control. |