Agencies often undertake security assessments of their websites on the Common Web Platform (CWP) to provide them with assurance. This page provides information to support agencies and explain the process the CWP team follows when asked to respond to an assessment. 

All systems come with risk, and public facing systems are targets for malicious attacks. Agencies need to understand and manage the risk associated with running a website. If this means undertaking an independent assessment, then the CWP team will advise them and take mitigating actions as required. The procedure for conducting and responding to assessments with the CWP team is explained in detail below.

For general information about security and privacy management(external link) for New Zealand Government websites, visit the Web Toolkit.

Why conduct a security assessment on your CWP website?

CWP has been setup to be a highly secure platform. Internal Affairs manages a security roadmap to undertake ongoing activities to keep checking that the platform is secure, and the risks understood. So why do participating agencies need to assess their websites still? The answer is that while the base website install is assessed, agencies have control to customise the CMS, modules and templates to build the website they want. They could introduce vulnerabilities during development. An assessment may also discover a vulnerability that is new or was previously undetected.

To request an independent assessment, use the All-Of-Government ICT Security and Related Services Panel(external link).

Expected results from an assessment

A security assessment should result in:

  • A list of risks found
  • The assessor’s determination of the level of risk
  • The assessor’s suggested remediation to reduce the risk to a more acceptable level

Risks are not necessarily required to be remedied - the purpose of a security assessment is to allow the agency to be aware of risks and mitigate those of particular concern, not to produce a list of things to fix along with the only acceptable method required to fix them.

Additionally, sometimes risks turns out to be ‘false-positives’ - remediations exist to reduce the risk, but they were not known to the assessor. For example, software is running on a version with known vulnerabilities, but patches to fix the vulnerabilities have been applied.

When a risk needs mitigation there are several possible methods, depending on the origin of the risk:

  • The agency’s development team can make an adjustment to code or configuration.
  • The CWP team can make a change to the infrastructure.
  • The CWP team can make a change to the underlying framework or supported modules. If this is severe and affects other agencies it is likely to result in an immediate security release. If it is not severe, the CWP team may decide to resolve the issue in the next recipe release - in this case the agency may choose to apply some other remediation in the meantime.

A process or non-technical control can be introduced by the agency

The CWP team is happy to help determine what risks are false positives, which are of particular concern, and what action is necessary. The procedure for assessing websites is explained in detail below.

The balance between usability and security

There is a natural tension between making a system as secure as possible, without affecting its usability. CWP aims to set a default that addresses this balance. For example open source Silverstripe doesn’t timeout CMS editors by default, but the CWP install will after an hour. An agency’s security requirement might be that the timeout is 10 minutes. In which case the agency needs to decide whether to accept the risk and make it easier for their editors or to configure their website to time out in 10 minutes. Read guidance about configuration changes to meet some additional security requirements.

Sharing information will benefit all agencies

Where-ever possible, agencies should share their security report with the CWP team and DIA as lead agency. This allows the knowledge gained from the security assessment to benefit all agencies on the platform. Supplying the full report also means that the CWP team can respond more accurately to an agency, as they understand the detail and the context. 

A secure folder can be setup on the CWP Workspace that only CWP staff and the agency can access. This also gets around the security issue of emailing security reports. Contact if you need one setup.

CWP Procedure for undertaking security assessments

1. Prior to undertaking a security assessment, the agency should discuss these topics with their assessor.

The type and level of assessment

Typically assessments are performed as “black box” assessments. The assessor uses standard public access while determining risk. This simulates real-world conditions, and is the most useful in terms of analysing the agency’s specific changes.

Some assessors may request to perform “open box” assessments, where the assessment is performed using administrative or special access to CWP systems. These assessments are not typically useful within the CWP platform (they duplicate work done by the assessors contracted by Internal Affairs) and are outside the scope of access to the platform granted to agencies. However in some rare situations they may be allowed. All such assessments must be approved beforehand by DIA, and performed under close supervision of the CWP administration team.

Note that “DoS protection overload”, “DDoS protection overload” or other deliberately destructive testing is never allowed.

CWP Shared Services (including the Platform Dashboard, GitLab, Graylog, Solr search, Varnish cache and nginx gateway servers) must never be included in scope of any security testing, as these services are shared with all agencies using CWP. Agencies can contact DIA to request information about when the most recent security testing of these shared services took place, and request access to any such test reports if additional clarity is required.

Where the security assessment should occur

Assessments are almost always performed against some running copy of the site. The agency will need to discuss with the assessor where this copy should be running during assessment.

Typically the agency’s UAT environment is used. This reduces the chances that the assessment affects the live server’s availability, but it is important to inform the assessor that some mitigations are different between UAT and Live. For instance, by default an administrator’s credentials can be used to switch the UAT server into development mode, where as this is not possible on a live server.

An agency may instead decide to perform the assessment on the live environment, or on an additional dev/test environment set up for this purpose.

It is up to the agency or agency’s development team to ensure that whichever environment is used contains the appropriate code and database to test prior to the assessment starting.

Where the security assessment will originate from

It is important to determine exactly where the assessment traffic will originate from in order to ensure traffic from those locations is not flagged.

If the agency is unsure, they should raise a CWP service desk ticket to ask for guidance.

2. A ticket must be raised with CWP service desk at least three business days prior to testing

The ticket must contain the answers to all questions above, along with the specific dates testing will occur.

The CWP operations team will then work with the agency to disable some of the threat mitigations on their stack to allow the assessment to occur.

If this step is not followed, the assessment will almost certainly look like an attack to the CWP Platform. Automatic systems will block access to the assessor, and the assessment will not be able to be completed.

Because some threat mitigations are disabled, it is important that the assessor be made aware of this, so that these mitigations are still taken into account in the assessor’s report.

3. After the assessment, and agency must provide the security report to the CWP Information Security Manager if they require a formal response or any mitigations to be actioned by the CWP team.

The ISM will endeavour to respond to any urgent risks within 3 business days, and respond to all risks within 10 business days (plus any time taken by the development team to respond). If the ISM is unable to respond within this timeframe, another CWP team member will respond with an informal response along with a timeframe to expect the formal response.

The response will include:

  • Any mitigations that the CWP team believes were not taken into consideration by the assessor.
  • An indication of any risks that originate within the platform itself, along with either any remediation the CWP team intend to perform (and the expected timeframe for availability of the remediation), or an explanation of why the CWP team consider the risk acceptable.
  • An indication of any risks that the CWP team believes are the result of specific configuration, which can be remediated by configuration changes by the agency.
  • An indication of any risks that the CWP team believes are the result of custom code, which can be remediated by code changes by the development team.

This response will be provided to the party who originally provided the report to us, or to the Stack Manager if it is unclear who should receive the response. Note that the response may not be complete, and care should be taken to ensure that any actions requiring input or action from the development team responsible for the website are handled separately by the agency.

It is important that the agency does not simply request mitigations through the CWP service desk. Without further context, it is unlikely that these changes will be accepted or actioned by the CWP operations team.

4. The agency should consider sharing both the security assessment and the CWP team’s response

This is discussed above in the section - Sharing information will benefit all agencies.

5. The agency’s development team should integrate any fixes or workarounds as required

When a particular risk originates within the platform itself, in many cases the CWP team’s provided remediation will be either a recommended configuration change, or a new release (either security or regular) of the basic recipe.

In both cases, it remains the agency’s responsibility to integrate these changes into the agency’s site code.

When a particular risk originals with custom code, it is the agency’s sole responsibility to remediate the issue. If the agency is unable to remediate the issues itself, the CWP team is able to provide support with a professional services charge.

If an Agency does not take the appropriate action within a reasonable timeframe to address issues that could pose a significant risk to the platform, Silverstripe may decide to escalate the issue to DIA.

Last modified: