Assurance for low-risk sites
- 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 the least.
- Ensure In Confidence information cannot be accessed by anyone else.
- Use monitoring and scanning services e.g. Qualys, to detect any website abnormalities.
- Apply all patches on a regular basis and asap.
- Encrypt administration log-in and password pages at a minimum, 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/service e.g. Standard Operating Procedures, System Security Plan.
- Evaluate the Risk Mitigation Framework (below) for low risk sites.
Government agencies operate many sites that are primarily informational, but may collect some user contact details, e.g. for the purpose of communication or notification. Development is often outsourced to vendors, but it is not acceptable to leave responsibility for security and privacy to vendors.
If you are a business owner/manager or administrator of a low-risk government website or service you may find the following framework suitable for assessing privacy and security assurance over such sites. This framework may not be suitable for sites dealing with more sensitive personal information, and you should seek advice.
Conforming with OWASP
OWASP – Open Web Application Security Project – is a collection of guidance, techniques, and tools intended to achieve best practice web application security. Agencies should ensure web developers are knowledgeable about OWASP, and follow OWASP principles for web development.
The New Zealand Information Security Manual (NZISM) recommends government agencies ensure their websites meet OWASP Principles and are tested for network and application vulnerabilities. Security service providers sourced 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.
- OWASP has developed a comprehensive test methodology. You should discuss with your web vendors their testing methodologies, approaches and expected outcomes.
- ASD Top 35 strategies to mitigate cyber intrusions is useful if agencies need more extensive assurance.
- OWASP Security Contract Annex (MS Word, 44kB) – sample attachment to development contracts to ensure service providers follow OWASP security practices.
- Also, if you are displaying In Confidence information of any type to users over the web – e.g. 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 your department is not using RealMe for user login for simple functions, you must follow good practice and as a minimum ensure that login mechanisms closely follow OWASP guidance, and implement measures to protect them from attack.
Ensuring your web application conforms with OWASP is just one aspect of a positive security posture.
In assessing security-readiness, you should 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 (Content Management System etc.) 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. Examples of such services include:
- Qualys, which can be used to scan sites or services for OWASP vulnerabilities
- Sucuri.net which can scan sites or services for evidence of injected malware
- Pingdom which 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 login 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 shouldfollow 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 login attempts
- two-factor authentication
- IP whitelisting.
Unused or expired accounts should be promptly deleted. NIST’s Guide to Enterprise Password Management (SP800-118) offers 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.
You should ensure you maintain an adequate suite of documentation for each site or service. At a minimum, this should include:
|Standard Operating Procedures||
|System Security Plan and Security Risk Management Plan||
|Incident Management Procedures||
|the SLA or Hosting Agreement||
Risk Mitigation Framework
You may find this risk mitigation framework (MS Word, 97kB) a useful starting point 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.
It presents a framework to reference when assessing measures to protect such sites and the information they contain.
The chart is intended as a quick reference and time-saver to inform a formal risk assessment which would go on to consider risks that are unique to the service being delivered.
The framework plus a risk assessment can be used as input to a streamlined Security Certification and Accreditation process (as required by the NZISM) for low-risk websites.
- Last modified: