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.
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.
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.
Discuss testing methodologies, approaches and expected outcomes with your vendors.
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.
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.
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.
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
- password management
- Service Level Agreements (SLAs)
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.
- 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 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 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.
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.
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.
Maintain documentation for each site or service.
|Document||What to include|
|Standard Operating Procedures||
|System Security Plan and Security Risk Management Plan||
|Incident Management Procedures||
|SLA or Hosting Agreement||
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.