The Australian Government Information Management Office Archive
The content on this page and other AGIMO archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.
Guide to Minimum Website Standards - Security
|
This guidance has been superseded by the Australian Government Web Publishing Guide and should be used for reference purposes only. |
April 2003 edition. Contact details updated July 2004.
Chapter headings:
What is the standard, and which agency issued the standard? - Implementation Requirements - Background - Key things you should know - Further Assistance - FAQ
Security
What is the standard, and which agency issued the standard?
This standard for website security is the Australian Communications Electronic Security Instructions 33 (ACSI-33) issued by the Defence Signals Directorate. This document is available at www.dsd.gov.au/infosec.
Implementation Requirements
All agencies were expected to comply with the standard by the end of December 2000.
Background
The Protective Security Manual (PSM) directs Commonwealth Government agencies to consider the security implications of their electronic information systems and to devise policy and plans to ensure the systems are appropriately protected. Even unclassified systems with no special attributes or financial implications should have some degree of protection if a reliable or accurate service is to be maintained. The Australian Communications-Electronic Security Instructions 33 (ACSI-33) has been developed by the Defence Signals Directorate (DSD) to provide guidance to Australian Government agencies wishing to protect their information systems.
The installation of web server technology creates a 'window' into an agency's network that can potentially be misused by attackers. A poorly organised or poorly maintained web server is likely to introduce problems that allow unauthorised attackers to perform actions outside the scope of legitimate activity, impacting on confidentiality, integrity or availability.
Key things you should know
Internet security mechanisms will necessarily vary from agency to agency. The nature of the system, the data requiring protection, the level of threat, and the level of residual risk that the agency is prepared to accept will affect the choice of security mechanisms.
The following outcomes are important to the viability of security management:
- The creation of both operational security and security management positions - for example - agency security adviser, IT security manager, firewall administrator, etc, each with clearly defined responsibilities;
- The conduct of a regular security Threat and Risk (TRA) review;
- The creation of a viable agency security plan that describes the necessary security mechanisms and security procedures;
- A regular review of the security plan, and the introduction of security mechanisms and features; and
- The introduction of a computer system auditing and review capability that informs operational staff and is useful to agency senior management.
Effective IT security plans usually rely on several layers of protection and apply equally to internal arrangements and external service providers. There are specific security requirements described in the PSM for each level of government classified data.
Every Internet system will always carry some residual security risk. Effective security management includes the reduction of risk to an acceptable level, and acknowledged acceptance of the residual risk.
A range of firewall products, gateways, authentication mechanisms, access control mechanisms and encryption facilities can be used to protect sensitive, unclassified information at the Internet boundary. The marketplace offers much choice and complexity, at a wide range of cost.
Standard "out-of-the-box" systems usually have inadequate default security mechanisms. Good configuration practice and good security management is often required to gain optimal benefit from such security products.
Some simple operating-system configuration mechanisms can be used to reduce the effectiveness of attacks against a web server. They include the following:
- Privilege reduction - the web server should be run as a non-privileged user, with limited access to system resources;
- File system limitation - the web server should have limited access to the host server's file system;
- Limited interactive system access - all non-administrative users should be removed from the computer that runs the web server to decrease further the risk of circumventing any web server access controls;
- Data and command validation - under some circumstances there should be validation of expected data and command strings. An attacker may take advantage of a lack of validation checking by entering unexpected commands and unusual character strings, in an attempt to elicit an unusual response and a possible security compromise; and,
- Sterile environment - unnecessary files and executable's should be removed from the web server environment, to deny an attacker any potential opportunity to bypass established security.
It is possible to monitor the security of networks via audit logs. Audit log monitoring is especially important when any risk reduction strategy in force includes procedures and specific configuration settings to reduce risk to a manageable level. If a system could become less secure because of an accidental or deliberate change in configuration setting, or through a lack of attention to established procedure, then it is reasonable to audit and review the system regularly to be assured that this has not occurred.
Audit logs have two main uses - statistics and security. In particular:
- Logs can identify the source of some hacking or denial of service attacks;
- Logs can pinpoint problems with the web server configuration;
- Usage statistics can identify when an upgrade of network bandwidth is likely to be required;
- Usage statistics can identify the most or least popular pages on a site; and,
- If access controls are in use on a web server, audit logs can be distributed to owners of the data within the restricted area, in order to distribute the audit analysis responsibility, and to potentially identify situations where unauthorised users can access sensitive data.
A checklist, that can help agencies improve their website security is provided at Attachment D.
Protecting Government Classified Information
Many commercial grade products do not provide sufficient security features to adequately protect Government Classified information on the Internet. In the case of Non-National Security information, Agencies should either use Defence Signals Directorate (DSD) approved security products that have been evaluated under the Australasian Information Security Evaluation Program (AISEP), or agencies should consult DSD for further advice.
DSD should definitely be consulted regarding any requirement to protect National Security information that is being transmitted over a lower classification network - Government Furnished Equipment is required in this case.
Guidelines and Grades for Web Server and Client Security
Handbook 10 (Web Security) of ACSI-33 contains a list of security grades for Web Server systems. The Handbook can be used to assist Agencies to determine the type of security mechanisms and procedures that may be required. The grades are not definitive and should be used as a guide only.
The DSD Gateway Certification Guide can also be used to assist Agencies to comply with the requirements of the Protective Security Manual.
Further Assistance
Websites - www.dsd.gov.au/library/acsi33/acsi33.html
Contact - DSD Information Security Group Customer Service Team
Telephone - (02) 6265 0197
Fax - (02) 6265 0328
E-mail - assist@dsd.gov.au
Address - Defence Signals Directorate Locked Bag 5076 Kingston ACT 2904
FAQ
Q. Why is there such a strong focus on security for Internet systems?
A. Any Government Agency or Department that collects, generates or displays information via the Internet is obligated to protect it effectively - see the Protective Security Manual, and the Privacy Act 1988.
There has been a tremendous growth in the number and complexity of Government Internet systems over the last few years. In some cases developers paid little attention to security aspects, and it is now evident that it is a lot easier to design security into a system at the start rather than attempt to fit it later.