About the EPL

The Evaluated Products List (EPL) is the definitive list of certified information and communications technology (ICT) products for use by Australian and New Zealand government agencies in the protection of government information as required by the Information Security Manual.

The Information Security Manual (ISM), the authoritative source for guidance on ICT security matters for Australian government agencies, states the circumstances in which Australian government consumers should or must use products from the EPL, and also discusses product selection. New Zealand government consumers should consult the New Zealand Information Security Manual (NZISM).

EPL structure

The EPL has three logical components, appearing in the following order:

  1. Completed: this section lists products that have completed a Common Criteria (CC) or ASD evaluation, with an ASD Cryptographic Evaluation and ASD Consumer Guide where applicable.

  2. In Evaluation: this section reflects all Australasian Information Security Evaluation Program (AISEP) evaluations that are currently underway, along with associated ASD Cryptographic Evaluation indicators. Evaluations completed with a CC certification through a recognised overseas scheme can be recommended for evaluation by an Australian or New Zealand government agency, requesting ASD to write a consumer guide for the product and to evaluate the product's cryptographic functions where applicable.

  3. Archived: 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 archived EPL contact ASD to verify whether the product will meet their security needs. Products that have been moved to the archived EPL will be listed for at least one year before being withdrawn from the archived EPL. Australian and New Zealand government users should also note that products listed on the archived EPL may not be appropriate for government use. ASD and GCSB are able to assist respective government users with selecting appropriate products from the EPL to meet their security needs.

EPL process

When a product enters evaluation under the AISEP, it is listed in the In Evaluation section of the EPL with a description of the components of the product under evaluation. 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 the Completed section with links to its supporting documentation including a consumer guide where applicable.

A consumer guide will aid Australian and New Zealand government agencies in their choice of appropriate products and will contain the following information:

For further information about the policy surrounding government software, refer to the ISM or email ASD Advice and Assistance.

Common Criteria

The Common Criteria project was initiated to harmonise the ITSEC (Information Technology Security Evaluation Criteria, a superseded European standard), 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 two are recognised by the Common Criteria Recognition Agreement (CCRA).

Assurance levels

The Common Criteria have seven assurance levels: from EAL1, the lowest, to EAL7, the highest. At present, only assurance levels up to EAL2 have been incorporated within the international Common Criteria Recognition Agreement (CCRA). The seven levels are described below. The CCRA is moving away from EAL-based evaluations in favour of Protection Profile evaluations.

Level Purpose
EAL1 Functionally Tested. Provides analysis of the security functions, using a functional and interface specification of the target of evaluation (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 semi-formal presentation of the functional specification and high level design, and a semi-formal 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.