About the EPL
The Evaluated Products List (EPL) provides Australian and New Zealand government consumers with a set of products that perform as claimed, and supports agencies in their compliance with ACSI 33/NZSIT 400. ACSI 33, the authoritative source for guidance on IT security matters for Australian Government agencies, is available from the DSD website at www.dsd.gov.au/library/infosec/acsi33.html. ACSI 33 contains the circumstances in which Australian Government consumers should or must use IT products from the EPL, and discusses product selection.
Evaluated Products List structure
The EPL has three logical components:
- The first component, Table 1, shows the results of evaluations completed using Common Criteria, ITSEC or some other DSD approved evaluation methodology, that have also been assessed against DSD Cryptographic Evaluation (DCE) entry requirements. Where applicable, entries for DCE and DSD Consumer Guides are included.
- The second component, Table 2, reflects all AISEP evaluations that are currently underway, along with associated DCE indicators.
- The third component provides the results of evaluations completed
using CC or ITSEC by a mutually recognised scheme (MR scheme). Where
required, entry to the DCE process may be requested by Australian or
New Zealand government agencies for these products.
When a product enters evaluation under the AISEP, it is listed in Table 2. This simply indicates that the product has been accepted into the evaluation process and provides 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 successful completion of the evaluation. Upon successful completion, the product is moved to the appropriate technological section in Table 1.
The historical EPL contains listings for products that have been evaluated 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 in the historical EPL may not be automatically appropriate for Government use. DSD and GCSB can 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 ACSI 33 or email: infosechelp@dsd.gov.au.
On 29th September 2006 changes were made to the EPL.
To view the old EPL please click here: www.dsd.gov.au/infosec/evaluation_services/epl/epl_old.html
Any comments or feedback on the changes to the EPL can be emailed to infosechelp@dsd.gov.au.
To assist in understanding the changes to the EPL, please find the following information.
A letter from Assistant Secretary, Robert Campbell to introduce the new EPL and the reasons behind the changes.
For your convenience here is further information about the EPL and some Frequently Asked Questions about the changes to the EPL.
Here are the relevant excerpts from the 29 September 2006 release of ACSI 33 to assist you in choosing a product from the new EPL.
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 a 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. |