Skip to main content

Assurance for low-risk sites

Use this framework to assess the privacy and security assurance of low-risk government websites and services. This framework may not be suitable for sites with sensitive personal information, and you should seek advice.

What you need to know

  • Do not leave responsibility for security or privacy to vendors.
  • Ensure developers are familiar with OWASP and that your websites meet OWASP’s top 10 guidelines at least.
  • Ensure in-confidence information cannot be accessed by anyone else.
  • Use monitoring and scanning services, such as Qualys, to detect any website abnormalities.
  • Apply all patches on a regular basis and ASAP.
  • Encrypt administration log-in and password pages, if not the whole site.
  • Use common techniques to make admin and authentication systems secure from password attacks.
  • Review SLAs or Hosting Agreements with your hosting providers to ensure they take a robust approach to network and server security.
  • Maintain adequate documentation for each site or service, such as Standard Operating Procedures, System Security Plan.
  • Evaluate the Risk Mitigation Framework (below) for low risk sites.

Conform with OWASP — the Open Web Application Security Project

OWASP is guidance, techniques and tools for achieving best practice web application security.

Make sure web developers are knowledgeable about OWASP, and follow OWASP principles for web development.

OWASP — Open Web Application Security Project

The New Zealand Information Security Manual (NZISM) recommends government websites meet OWASP principles and are tested for network and application vulnerabilities.

Security service providers from the Security and Related Services panel can be contracted for this purpose.

NZISM — NZ Information Security Manual

Security and Related Services Panel

OWASP's top 10

Every government website should meet all of these.

They should be used as the basis for discussion with developers.

Developers should be able to explain the implications of any aspect of it, and how they've addressed these implications.

OWASP top 10

Test methodology

Discuss testing methodologies, approaches and expected outcomes with your vendors.

OWASP testing guide

Strategies to mitigate cyber security incidents

The Australian Cyber Security Centre (ACSC) has more strategies to mitigate cyber intrusions, if agencies need more extensive assurance.

Strategies to mitigate cyber security incidents

Development contracts

Use the Secure Software Contract Annex when you write development contracts, to make sure service providers follow OWASP security practices.

You can read about the annex and copy a sample from the OWASP website.

OWASP Secure Software Contract Annex

Displaying in-confidence information

If you are displaying in-confidence information over the web — for example, displaying subscription email addresses for the simple purpose of allowing a user to verify or update subscription details — you should ensure this information can’t be accessed by anyone else.

If you're not using RealMe

If your department is not using RealMe for user log-in for simple functions, you must follow good practice and as a minimum ensure that log-in mechanisms closely follow OWASP guidance, and implement measures to protect them from attack.

Maintaining security

When you assess security-readiness, engage with your security staff or consultants to evaluate your practices in regard to:

  • patching procedures for servers and applications
  • monitoring and scanning services to detect abnormal conditions or vulnerabilities on websites
  • encryption
  • password management
  • Service Level Agreements (SLAs)
  • documentation.

Patching procedures

Patching procedures for servers (operating system, installed programmes and web server) and applications (such as a content management system) which run on the web server should be applied on a regular basis, and critical patches should be applied as early as possible after they become available.

Responsibilities for patching should be clearly documented in Service Level Agreements with your hosting providers (internal or external to the agency), and in the System Security Plan for the website or service.

Monitoring and scanning services

Monitoring and scanning services can detect abnormal conditions or vulnerabilities on websites, or offer additional protection against attack.

Example services:

  • Qualys — to scan sites or services for OWASP vulnerabilities
  • Sucuri.net — to scan sites or services for evidence of injected malware
  • Pingdom — monitors site availability (high response times can be indications of unwanted activity)
  • Hosted Web Application Firewall services such as Incapsula and Akamai.

Encryption

Encryption protects the integrity of traffic to and from a site and helps to mitigate other potential exposures.

At a minimum, administration log-in pages and any pages on which passwords are entered should be encrypted using SSL certificates from reputable Certificate Authorities.

Acceptable encryption algorithms are specified in the NZISM, and you should follow the recommendations of your IT Security Manager (ITSM) when choosing a Certificate Authority.

Extending the encryption to the entire site or service helps to mitigate a range of potential exposures.

Agencies managing SSL certificates should ensure they record them in a register which will alert them to upcoming requirements for certificate renewal.

Password management

Ensure your password management processes enforce strong passwords and strict password security.

All admin or user authentication systems should be protected from attack by techniques such as:

  • three-strikes lockout
  • escalating timeouts between log-in attempts
  • two-factor authentication
  • IP whitelisting.

Unused or expired accounts should be promptly deleted.

NIST’s Digital Identity Guidelines (800-63) includes guidance to help you select (and remember) passwords that are difficult for attackers to compromise.

The NZISM includes requirements for the management and protection of passwords.

Digital Identity Guidelines (800-63)

NZISM — Access control 

Service Level Agreements

Ensure your SLAs clearly lay out the division of responsibilities between providers and the department and give assurance that provider security measures are robust and comprehensive.

You should engage with your security staff or consultants to review your SLAs or Hosting Agreements with your hosting providers (internal or external) to be sure they take a sufficiently robust approach to network and server security, in alignment with the guidance in the NZISM.

The agreements should also address backup and recovery procedures, incident management processes, constraints on hosting providers’ access to in-confidence information, and destruction of information as necessary.

Documentation

Maintain documentation for each site or service.

Document What to include
Standard Operating Procedures
  • the site’s purpose and audience
  • responsibilities for monitoring site usage
  • compliance with required standards
  • procedures for the day-to-day management of the site
  • access to and use of collected information
  • user management processes
  • the operation and maintenance of any unique features
System Security Plan and Security Risk Management Plan
  • describing measures that have been taken to protect its security, privacy, availability and integrity
  • ongoing responsibilities for maintenance and security management
  • a description of monitoring mechanisms in place
  • a record of any risks or vulnerabilities identified and mitigations undertaken or planned
Incident Management Procedures
  • describe measures implemented to prepare for privacy or security incident handling
  • emergency procedures and contact details
  • ready-reference procedures for heightened awareness
  • ready-reference procedures for declaring an incident
SLA or Hosting Agreement
  • expectations of availability
  • network and server security
  • server maintenance and patching responsibilities
  • emergency procedures and contacts

Risk mitigation for low-risk web systems

Use the Risk Mitigation Framework to inform risk assessments for sites with a low risk profile — such as websites that do not deal with personal information beyond simple contact details.

Risk mitigation for low-risk websites

Utility links and page information

Was this page helpful?
Thanks, do you want to tell us more?

Do not enter personal information. All fields are optional.

Last updated