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.
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).
A security assessment should result in:
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:
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.
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.
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 email@example.com if you need one setup.
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.
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.
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.
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.
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:
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.
This is discussed above in the section - Sharing information will benefit all agencies.
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.