Search the Archive

The Australian Government Information Management Office Archive

What Level of Authentication is Required?

"Which authentication solution is required?" This is an important question and there is no single right answer. The approach adopted should be determined by the outcome of a risk assessment and subject to the preparation of an associated business case. Agencies should also consider the needs and expectations of their customers.

4.1 A business decision

An effective approach to authentication is to understand that technology is not the sole solution. Authentication is as much about management and cultural issues as it is about technical solutions.

One of the early issues for consideration is that online authentication may be a costly exercise in comparison to a manual authentication process. Agencies will need to consider cost in relation to an identified level of risk associated with failure to properly authenticate a party to an online transaction.

The likelihood and consequences of such a failure, set against the cost of implementing authentication, should be fully analysed. The consequences may be measured in a number of ways including financial, legal/liability and political outcomes.

If managed as a business issue rather than a technical issue, agency authentication needs can be effectively addressed and implemented in a cost-effective manner as the benefits of transacting online are realised.

4.2 Comparing authentication options

In developing a risk assessment for their agency, managers may wish to include a narrative comparing some of the authentication options. The following information is provided to help managers with the development of their risk assessments.

Non-PKI models of authentication and security have the benefits of lower implementation and maintenance costs, and are particularly attractive to less sensitive, smaller or short duration projects. For example, the password and PIN/User ID model is generally cheap to implement and ideally suited to one-off use or use in circumstances where the data or system to be protected has a low security threshold. A weakness of this model is that passwords can often be stolen, accidentally revealed, shared, observed or forgotten. This will require agencies to support and manage clients throughout the period of activity.

Passwords are also susceptible to 'brute force' or 'dictionary' attacks. Passwords using a mixture of case/special characters have been shown to be harder to break. The important aspect to note is to base the number and mix of characters on the level of risk. If password requirements are too onerous, passwords are more likely to be written down or circumvented by users.

Stronger authentication may be required for privileged accounts or in areas of high risk. Stronger authentication includes:

• one-time passwords;
• challenge and response devices;
• conventional encryption; or
• public key cryptography (digital certificates).

Alternative authentication and security models are often based on combinations of measures such as passwords and PIN/User IDs, conventional or public cryptography tools and server authentication. These models allow choice from the simplest to the most sophisticated measures to be employed. While these measures form a generic set, the combinations used must be determined on a case by case basis to meet the particular requirements of each application.

Challenge and response can prove complicated in operation, and the development of management processes to deal with it may incur significant cost and ongoing resource implications for the agency. Agencies may wish to take this into consideration in their risk assessment.

Cookies. It should be remembered that cookies are linked to the machine on which they are placed. As a result, they cannot be relied upon to authenticate a particular identity and do not have a great deal of acceptance by users.

The use of cryptography can be an important adjunct to authentication. Strong security can be achieved by combining basic authentication measures with cryptography. Agencies are able to deploy conventional encryption, but the downside is management of the cryptographic keys. These keys are typically only used for relatively short duration and then need to be changed. These problems are expensive to solve using manual key distribution methods.

A less expensive solution is the use of server authentication. Server authentication using only a server certificate (a digital certificate that strongly authenticates a server and not an individual), combined with a password and PIN/User ID may be an acceptable solution.

Public key cryptography (digital certificates). A key factor for agencies to consider when employing digital certificates is to ensure that users are aware of the need to protect the private key securely. Lost or compromised private keys provide unauthorised users with the potential to severely impact an agency's security arrangements. If private keys are lost the fact should be reported immediately to the agency security officer and the issuing Certification Authority (CA) so that the key can be publicly listed as revoked.

One of the ways to reduce the likelihood of private keys being accessed by unauthorised persons is to ensure that the private key is held by the user on a hard token or smart card with access protected by a strong password.

Other factors in implementing digital certificates include initial and ongoing cost factors and ease of use.

Tokens, such as smart cards, magnetic stripe cards, physical keys and so forth, can be lost, stolen, duplicated or left at home. Such issues need to be considered when determining whether or not tokens will meet the needs of the agency.

Biometrics. A potential weakness with this technology is that unless the biometric is protected by a password or other suitable method, it can be copied and replayed at a later stage to authenticate an unauthorised individual. Timestamping or tying the biometric in some way to a document through a hashing technique are recommended protective measures.

Another issue to consider with respect to biometrics is the determination of 'false accept' or 'false reject' rates. The biometric technology provider should be able to provide this sort of information. Once known, agencies can assess the likelihood and consequence in their risk assessment. Other factors in implementing a biometric system include initial and ongoing cost factors and ease of use.

4.3 Risk management

The level of risk an agency accepts depends on a number of factors, including the correct identification of risks, the level of funding available to manage those risks, and the potential damage that could be caused to life, property and services.

Risk management consists of steps which, when undertaken in sequence, enable a systematic analysis of risk to which an agency is exposed and results in the selection of an appropriate mix of strategies to manage those risks. The entire process is repetitive and may be re-entered at any point when the inbuilt review mechanisms indicate such a necessity.

Risk management in organisations generally has three audiences:

• executives accountable for the management of an organisation;
• personnel who are responsible for initiating, implementing, managing and/or monitoring generic risk management systems within their organisation; and
• personnel who are responsible for initiating, implementing, managing and/or maintaining authentication within their organisation.

4.3.1 Risk assessment

To evaluate the suitability of authentication alternatives for particular applications, the agency needs to perform a risk assessment. The assessment identifies the particular technologies and management controls best suited to minimising the risk and cost to acceptable levels, while maximising the benefits to the parties involved. Often parts of the assessment can be quantified, but some factors - particularly the risk analysis - usually can only be estimated qualitatively.

Availability of data affects the extent to which risk can be reliably quantified. A quantitative approach to risk analysis generally attempts to estimate the monetary cost of risk compared to the cost of risk reduction techniques based on:

• the likelihood that a damaging event will occur;
• the costs of potential losses; and
• the costs of mitigating actions that could be taken.

Reliable data on likelihood and costs may not be available. In this case a qualitative approach can be taken by defining risk in more subjective and general terms such as high, medium and low. In this regard, qualitative analyses depend more on the expertise, experience and good judgment of the managers conducting them than on quantified factors.

Some factors, such as the value of deterring fraud, are difficult to quantify. If a new automated solution is less secure than an old paper-based process, attempts to commit fraud or to repudiate transactions may increase. It usually is not possible to quantify in monetary terms attitudes such as increased customer satisfaction and willingness to cooperate with an agency which may result from electronic processes designed to be user-friendly. However, many costs (design, development and implementation) and benefits (such as reduced transaction costs or saved time) can be quantified, as is the case for other IT projects. Clearly, then, the assessment should use a combination of quantitative and qualitative methods to judge the practicability of any electronic transaction method and should include a comprehensive risk analysis when warranted by the sensitivity of the data and/or the transaction.

Those alternatives that minimise risk to an acceptable level should be assessed in terms of net benefit to the agency and the customer in order to determine the authentication process most appropriate for the transaction. If the net benefits are negative, the agency may determine that using an authentication process is not practical at this time. All risk analyses are exercises in managerial judgment.

• Consider the costs of risk mitigation. The assessment must recognise that not all authentication solutions are totally reliable and secure. Every method of authentication can be compromised with enough skill and resources, or due to poor security procedures, practices or implementation. Setting up a very secure, but expensive, automated system may in fact buy only a marginal benefit of deterrence or risk reduction over other alternatives and may not be worth the extra cost. For example, past experience with fraud risks, and a careful analysis of those risks, show that exposure is often low. If this is the case a less expensive solution that substantially deters fraud is warranted rather than an absolutely secure solution.
• Conduct a cost-benefit analysis to determine if authentication is practicable. The primary goal of a cost-benefit analysis should be to find a cost-effective package of security mechanisms and management controls that can support automated solutions using electronic communications. In estimating the cost of any solution, agencies should include costs associated with hardware, software, administration and support of the system, both short-term and long-term.

4.3.1.1 What benefits should agencies consider regarding authentication?

Benefits from moving to electronic transactions and authentication include reduction in transaction costs for the agency and the customer. Transactions are quicker and it is often easier to access information related to the transaction because it is in electronic form. The electronic form often allows more effective data analysis because the information is easier to access. Better data analysis often improves the operation of the new electronic transaction. In addition, if many transactions are electronic and data analysis can be done across transactions the benefits can spill over into the rest of the agency as operational awareness of the entire organisation is improved.

Moreover, business process reengineering should accompany all attempts to facilitate a transaction through information technology. Often the full benefits will be realised only by restructuring the process to take advantage of the technology. Merely moving an existing paper-based process to an electronic one is unlikely to reap the maximum benefits from the electronic solution.

In order to account for all the benefits associated with electronic transactions, agencies should keep common information technology benefits in mind and look at the benefits realised by other agencies.

4.3.1.2 What are the benefits?

Agencies should identify all the benefits of automating program transactions and making those transactions secure, such as:

• Increased speed of the transaction. The customer and the agency may spend less time completing the transaction. The quicker speed combined with putting the transaction online allows real-time help to the transaction customer, providing a benefit not found in a paper-based transaction.
• Increased customer participation and satisfaction. Often a decrease in customer transaction costs leads to more customers completing the transaction. In addition, customers tend to have a more positive view of the process given its speed and ease of use.
• Improved recordkeeping efficiency and data analysis opportunities. If data is easier to access and store then program evaluation is enhanced and awareness of the effects of the government program in question is expanded.
• Increased employee productivity and improved quality of the final product. Electronic transactions tend to have fewer errors because often the system minimises retyping and automatically detects certain errors. These benefits allow the employees to concentrate more time on other matters.
• Greater information benefits to the public. Moving to electronic transactions and authentication can often make the related information more accessible to the public.
• Improved security. Designed, implemented and managed properly, electronic transactions can have fewer opportunities for fraud and more robust security measures than paper and envelope transactions.
• Extensive security for highly sensitive information. Even though implementing a more secure option is often more expensive initially than implementing less secure alternatives, there could be larger expected benefits if the information being protected is particularly sensitive.

4.3.1.3 What risk factors should agencies consider?

Properly implemented solutions can offer greater degrees of confidence in authenticating identity than manual authentication processes. These digital tools should be used to control risks in a cost-effective manner. In determining whether a particular authentication solution is sufficiently reliable for a particular purpose, agency risk analyses need at a minimum to consider the relationships between the parties, the value of the transaction and the risk of intrusion. In addition, agencies should consider any other risks relevant to the particular process. Once these factors are considered separately, an agency should consider them together to evaluate the sensitivity to risk of a particular process, relative to the benefit that the process can bring.

4.3.1.4 What is the relationship between the parties?

Agency transactions can fall into a number of categories, each of which may be vulnerable to differing security risks. The following are examples:

• intra-agency transactions (those which remain within the same agency);
• inter-agency transactions (those between agencies);
• transactions between a Commonwealth agency and State/Territory or local government agencies;
• transactions between an agency and a private organisation such as a contractor, business, university, non-profit organisation or other entity;
• transactions between an agency and a member of the general public; and
• transactions between an agency and a foreign government, foreign private organisation or foreign citizen.

Risks tend to be relatively low in cases where there is an ongoing relationship between the parties. Generally speaking, there will be little risk of a partner later repudiating inter- or intra-governmental transactions of a relatively routine nature, and almost no risk of the governmental trading partner committing fraud. Similarly, transactions between an agency and a publicly traded corporation or other known entity can often bear a relatively low risk of repudiation or fraud, particularly where the agency has an ongoing relationship with the entity. For the same reasons, risks tend to be relatively low within rule making contexts, as all parties can view the submissions of others so the risk of imposture is minimised. Other types of transactions, involving an ongoing relationship between an agency and non-governmental entities (both individual and businesses), can have varying degrees of risk depending on the nature of the relationship between the parties. The same would apply in the case of those government programs in which the ongoing relationship is between entities that are acting on behalf of an agency and such non-governmental entities and persons - e.g. transactions between a lender, agency or other institution participating in a loan or financial aid program and another program participant or a member of the general public, such as a borrower or grant recipient.

On the other hand, the highest risk of fraud or repudiation is for a one-time transaction between a person and an agency that has legal or financial implications. Agencies should also pay attention to transactions with non-agency entities, where the agency has a law enforcement responsibility but does not have an ongoing relationship. Transactions between an agency and a foreign entity may entail unique legal risks due to varying national laws and regulations. In all cases, the relative value of the transaction must also be considered.

4.3.1.5 What is the value of the transaction?

Agency risk analysis should attempt to identify the relative value of the type of transaction being automated and factor that against the costs associated with implementing technological and management controls to mitigate risk. Note that the value of the transaction depends on the perspective of the agency and the transaction customer. In general, authentication might be considered least necessary in very low value transactions and might not be used unless specifically required by law or regulation. Where authentication is necessary, the method of authentication should be appropriate to the level of risk.

4.3.1.6 What is the risk of intrusion?

The probability of a security intrusion on the transaction can depend on the benefit to the potential attackers and their knowledge that the transaction will take place. Indicators of agency transactions in this area are:

• Regular or periodic transactions between parties are at a higher risk than intermittent transactions because of their predictability, making it more likely that an outside party would know of the scheduled transaction and be able to intrude on it;
• The value of the information to outside parties could also determine their motivation to compromise the information. Information that is relatively unimportant to an agency may have high value to an outside party; and
• Certain agencies, because of their perceived image or mission, may be more likely to be attacked independent of the information or transaction. The act of disruption can be an end in itself.

4.3.2 Risk matrix

Having taken into consideration the issues identified above, agencies may wish to develop a risk matrix. The level of risk is determined by the relationship between both the likelihood of the event and the consequence of the impact, against the background of any existing risk reduction measures. Neither consequence nor likelihood should dominate the determination of the level of risk. The greatest risks to an agency are those which have extreme consequences and are almost certain to occur. Conversely, a rare event with negligible consequences may be considered trivial. An event which occurs rarely but which has extreme consequences could be considered a significant risk.

The risk matrix shown below is provided for illustrative purposes only. Agencies should develop their own mapping tables to determine the level of risk by mapping the relationship between likelihoods and consequences in a matrix.

CONSEQUENCE
LIKELIHOOD	EXTREME	VERY HIGH	MEDIUM	LOW	NEGLIGIBLE
Almost certain	severe	severe	high	major	significant
Likely	severe	high	major	significant	moderate
Moderate	high	major	significant	moderate	low
Unlikely	major	significant	moderate	low	trivial
Rare	significant	moderate	low	trivial	trivial

Definitions for the level of consequence

EXTREME: The consequences would threaten the provision of key services, causing major problems for clients and for government. VERY HIGH: The consequences would threaten the continued effective provision of services and require top level management or ministerial intervention.

MEDIUM: The consequences would not threaten the provision of services, but would mean the agency could be subject to significant review or changed ways of functioning.

LOW: The consequence would threaten the efficiency or effectiveness of some services, but could be dealt with internally.

NEGLIGIBLE: The consequences would be dealt with by routine operations.

Risk definitions and management implications

Severe: Must be managed promptly by senior management with detailed cost-effective continuity management strategies.

High: Continuity management required at senior levels.

Major: Senior management attention is needed.

Significant: Continuity management responsibilities must be specified.

Moderate: Manage by specific monitoring or response procedures.

Low: Manage by routine procedures.

Trivial: Unlikely to need specific application of resources.

Guidelines on risk management can be found in the following documents:

• Australian/New Zealand Standard AS/NZS 4360:1999 - Risk Management http://www.standards.com.au
• Australian Communications - Electronic Security Instruction 33 (ACSI 33) - Handbook 3 - Risk Management http://www.dsd.gov.au/infosec/acsi33/HB3.html
• Commonwealth Protective Security Manual (PSM) - Part B - Guidelines on Managing Security Risk http://www.ag.gov.au/publications/psm.htm

4.4 Developing a business case

There are several issues that should be considered when developing a business case for the type or combination of authentication solutions to implement in an agency. The points identified below are intended to provide managers within agencies with a range of issues that may require investigation. They are not necessarily exhaustive and additional issues not covered here may need to be considered and addressed on a case by case basis.

• Identify services to be delivered
  Specific services to be delivered online and requiring authentication need to be identified. Determine the value of the service and information being processed to the agency. Determine customer accessibility requirements. This will help to identify the type or strength of the authentication required.
• Risk assessment
  An assessment of the risk to an agency through not implementing appropriate authentication will help to strengthen a business case. The risk assessment should include different authentication options, and identify associated risks with each, for later consideration by management.
• Identify internal and external clients
  Identify the number of internal and external clients and how well they need to be known to the agency.
• Determine interoperability requirements
  This is dependent upon the number and type of clients and the possibility that clients will have different types of desktops and different applications on each desktop. As a result each client's technology implementation may respond differently to an authentication process. This issue should be identified and investigated early in the process because it may have cost and time implications.
• Identify registration of client requirements
  Prior to the issue or implementation of an authentication solution, agencies may wish to consider whether or not existing processes for authenticating or registering the identity or existence of an agency's clients need to be investigated or refined. Agencies may consider that existing processes for identifying clients will suffice. However, if moving to an online environment, agencies may wish to take the opportunity to implement a more rigorous approach to client registration.
• Identify privacy requirements
  Agencies will need to ensure that measures implemented to protect personal information comply with privacy regulations. The Office of the Federal Privacy Commissioner has issued a document titled 'Privacy in Australia' which will assist agencies in their decision making process. It can be found at http://www.privacy.gov.au/publications/pia.pdf
• Identify resource requirements
  The level of complexity involved in the application and ongoing management of the chosen authentication solution directly impacts the required number of resources. As a result, identifying resource requirements is an important part of the business case. Management will need to take into consideration the risks associated with each of the authentication options identified in the risk assessment, and availability of resources, to assist them in deciding which is the most appropriate authentication solution for their agency.
• Identify recordkeeping requirements
  Agencies should consider the need to make and keep records of their business activities to satisfy legislative obligations, accountability requirements and community expectations. These records must be managed in such a way that they retain their integrity and remain accessible for as long as they are required. The integrity and accessibility of records may be affected by the authentication solutions adopted by an agency. The National Archives of Australia can provide further advice at http://www.naa.gov.au/recordkeeping

4.5 Non-repudiation

Non-repudiation is emerging as an important objective of authentication. It provides irrefutable evidence that an action took place. It protects one party to a transaction against the denial of the other party that a particular event took place. It also protects all parties from a false claim that a record was tampered with, or not sent or received.

While non-repudiation is more of a legal construct than a technical process, agencies can take certain precautions to minimise the risk of a transaction being repudiated. However, agencies should determine the requirement for non-repudiation from their risk assessment. For example, agencies may decide that transactions involving non-verified signatures may not attract non-repudiation status.

Non-repudiation is necessary to:

• protect against abuse and/or misuse of e-transaction information and systems;
• indemnify an agency against loss;
• provide accountability of users; and
• guarantee user authenticity and right of access.

According to International Standards Organisation (ISO) Standard 13888 the key elements of a robust non-repudiation regime are as follows:

• Approval - proof of who is responsible for approval of the content of a message;
• Sending - proof of who sent a message;
• Origin - proof of origin derives from information provided in the approval and sending services;
• Transport - proof for the message originator that a delivery authority has given the message to the intended recipient;
• Receipt - proof that the recipient received the message;
• Knowledge - proof that the recipient recognised the content of the received message; and
• Delivery - proof that the recipient received and recognised the content of the message.

To achieve the above, agencies need to consider six fundamental requirements for any system that aims for a high level of trustworthiness and non-repudiation:

• Security policy - there must be an explicit and well-defined security policy enforced by the system;
• Marking - access control labels must be associated with objects;
• Identification - individual users must be identified;
• Accountability - audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party;
• Assurance - systems must contain hardware and software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces the security requirements; and
• Continuous protection - the trusted mechanism enforcing these basic requirements must be continuously protected against tampering and unauthorised changes.

In a legal sense all allegations put forward by a party to litigation may be disputed by the other party. As there has yet to be a judicial decision dealing with an interpretation of the electronic signature requirements in the Electronic Transactions Act, the choice of authentication provider and what they have to offer by way of non-repudiation is a business decision for agencies.

For more information on non-repudiation, visit: http://www.iso.ch/iso/en/ISOOnline.frontpage

4.6 ANAO Better Practice Guide

One approach to determining the level of authentication required for an online application is to consider the four-stage approach to delivering government services online, as outlined in the Australian National Audit Office (ANAO) better practice guide, Internet Delivery Decisions (available from the ANAO website at http://www.anao.gov.au). These stages can be summarised as follows:

Stage 1 permits an agency with a website to provide or publish information about its services to those who access it. Publications are available online and can be downloaded. There is a limited inquiry and search facility. The information is made available in a static display. There are no limits to public access to the information. A current example is the ANAO's website. Other examples are the Australian Taxation Office's placement of its tax determinations online, the Attorney-General's Department provision of considerable legal information and the Australian Institute of Health and Welfare's website.

An example of Stage 1 electronic service delivery
The Australian National Audit Office (ANAO) website at http://www.anao.gov.au provides information about the ANAO, links to other audit or government-related sites and the ability to read and download ANAO publications, including ANAO reports to Parliament. The ANAO does not have publicly available databases and does not obtain information from the public or business, except in the course of its audit activity.

Authentication requirements for Stage 1
Agencies may decide that no authentication requirements are needed in this stage.

Stage 2 permits an individual who visits a website to access or interact with the agency's database. The individual can calculate an entitlement, subsidy or debt, or conduct research using part or all of the database. Interactive facilities are limited. There are no limits to public access to information on the website. A current example is the Australian Bureau of Statistics' site, which gives access to much of its statistical information.

Other agencies with databases of publicly available information have made those databases searchable online. Agencies providing services at Stages 1 and 2 are not committing themselves to functions with significant risks of security, privacy or financial breaches.

An example of Stage 2 electronic service delivery
The Australian Communications Authority (ACA) website at http://www.aca.gov.au offers real-time information on radiocommunications and cabling licences. Users can extract details of who holds radiocommunication licences, technical aspects of those licences and the transmitter site details. Searches can be conducted by licence holder, licence number, frequency, site or postcode. Inquiries about cabling licences can yield details of the name, postal address, contact phone number if available, licence number, licence type and licence endorsements where applicable, of all current holders of ACA cabling licences. Licensed cablers are able to install, connect, remove or maintain all types of cabling connected to, or intended for connection to, a telecommunications network.

Authentication requirements for Stage 2
There are no specific authentication requirements for Stage 2 although agencies may consider that access to some interactive facilities should be limited and therefore require some degree of authentication and security by applying passwords, PIN/User ID, SSL or cookies. Stage 3 involves exchange of information between the agency and the individual Internet user once the agency has verified his or her identity.

Stage 3 requires authentication or verification of the individual's identity, used by the agency to control access to its data and to authenticate data being provided. The interaction can have financial implications. The major difference between Stage 3 and Stages 1 and 2 is that agencies embarking on Stage 3 need to authenticate the identity of the person or business entering the information.

This stage covers secure, authenticated financial transactions. In the future, financial transactions on the Internet are likely to be more secure and more agencies may advance to supporting them. An example of Stage 3 is the Australian Taxation Office's project for individual taxpayer's electronic lodgement of tax returns (e-tax), or the Department of Employment and Workplace Relations' (DEWR) Jobsearch site discussed below. These examples are major projects in which agencies are fully addressing the risks of security, privacy and financial obligations.

An example of Stage 3 electronic service delivery
DEWR's Jobsearch website at http://www.jobsearch.gov.au allows employment seekers to search a database of employment opportunities by location, occupation, postcode or suburb, and perform more sophisticated searches. The site is considered a Stage 3 because employers can lodge jobs for placement in the database. The employer is able to provide details of employment, which are screened for defamatory, obscene or discriminatory material before entry in the database.

Authentication requirements for Stage 3
Authentication requirements for this stage are aimed at ensuring the user(s) only gain access to, or have the ability to change, the information they are entitled to. Common methods of identifying and authenticating the user include passwords and PIN/User IDs over SSL and PKI using, for instance, Australian Business Number - Digital Signature Certificates (ABN-DSCs). The authentication solution will be determined by assessing the nature of the interaction: whether the transaction needs to be digitally signed; the sensitivity of the information; the risk profile; any liability issues; and the need to strengthen the chain of evidence for legal requirements.

Stage 4 involves government agencies exchanging information provided by individuals, organisations or businesses with their prior consent. For example, an agency notified of a change of address would recognise it as an event of which other agencies should be notified, and would do so with the prior knowledge of the original data provider. A few agencies have or are proposing interchange of information at this level. A future likely example of Stage 4 will be the Department of Industry, Tourism and Resources' Business Entry Point's Transaction Manager (www.business.gov.au/BEP/Transaction/). This web-based tool aims to ease the compliance burden on small business by providing a single entry point for users to discover, complete and manage their online transactions with Federal, State and local government agencies.

An example of Stage 4 electronic service delivery
The Australian Customs Service's CMR development will allow clients to submit documents online for clearance of transporting goods across Australia's borders. Clients will also be able to update personal information and business details via Customs' Client Register. It is proposed that client information amendments concerning information associated with an individual or business will be used to update the Australian Business Register (ABR) where appropriate. The ABR contains all the publicly available information provided by businesses when they register for an Australian Business Number (ABN). The ABN is a new single identifier for dealings with all government agencies, including Customs, and will be used to supply the core information for Customs' Client Register. Customs will appropriately seek clients' permission for the intended use of this information.

Authentication requirements for Stage 4
Authentication requirements for this stage match those for Stage 3. 4.7 ANAO Performance Audit - Internet Security within Commonwealth Agencies
In 2001, the ANAO completed an audit of Commonwealth agencies' management of Internet security with the principle objective of forming an opinion on the adequacy of those systems. The audit addressed:

• Internet security risk assessments, policies and plans;
• Agencies' Internet security management procedures to determine whether these were consistent with relevant Commonwealth guidelines and requirements, and with examples of industry better practice;
• Internet site management, including virus protection and detection strategies, prevention and detection of unauthorised access and incident response arrangements; and
• Test performances of selected sites.

While not specifically addressing authentication, the ANAO report should be considered as part of an agency's overall online business plan. The report can be found at: http://www.anao.gov.au

4.8 Authentication options for online transactions

The following table is for illustrative purposes only. It provides example Information and Transaction types, Identification requirements, Authentication and Confidentiality requirements and Non- Repudiation expectations against four stages based upon the ANAO stages discussed at 4.6. As indicated in Section 3, further work is being undertaken to take a whole- of- government approach to authentication to provide greater consistency for the government's customers. This may result in further enhancements to this approach in the future. Agencies should treat their authentication requirements for each transaction on a case by case basis.

STAGE	INFORMATION TYPE	TRANSACTION	IDENTIFICATION REQUIREMENTS	AUTHENTICATION & CONFIDENTIALITY	NON- REPUDIATION
1 This is the equivalent of a website that publishes information about the agency and its services.	Public This includes information that does not have any security implications and can be made freely available to the public.	Any member of the public can view agency services and publications.	Generally speaking, none required, but is dependent upon agency requirements.	Generally speaking, none required, but is dependent upon agency requirements.	x or þ (Dependent upon agency requirements)
2 This stage allows Internet users to browse and interact with the agency's database( s).	Agency Official Agency specific information whose compromise may or may not cause embarrassment to the agency.	Customers may be provided with browse or update of limited personal information privileges based upon their relationship with the agency.	Whether identification is required, or achieved online, or requires the physical presence of the customer at an agency shopfront is a decision for agencies to make.	Password and PIN/ User ID (and cookies) or challenge and response or one- time password.	þ
3 This includes stages 1 & 2 and permits users to enter information on the website, exchange or transact secure information with the agency.	In- Confidence Information whose compromise could cause damage to the Commonwealth, the Government, commercial entities or members of the public.	Customers may be given privileges to declare personal circumstances based upon their relationship with the agency. Agencies may decide that the physical presence of the Customer is required to confirm their identity.	Evidence Of Identity (EOI) documents should be provided by the customer and verified by the agency.	Password and PIN/ User ID with SSL or PKI.	þ
4 This is the same as stage 3 but in addition the agency, with the user's prior approval, shares that user's information with other government agencies.	In- Confidence Same as above.	Normally associated with the repayment of debts or payment for services.	Physical presence of the customer is required to confirm their identity.	- Password and PIN/ User ID with SSL or PKI; - PKI business requirements are 100 points of EOI for an ABN- DSC.	þ
	Protected or Highly Protected Information whose compromise could cause serious damage to the Commonwealth, the Government, commercial entities or members of the public.	Passage of Protected or Highly Protected information across the Internet.	Physical presence of the customer is required to confirm their identity.	PKI (Digital Certificate) requirements are determined by the agency.	þ PKI required for Protected/ Highly Protected