Agencies often undertake security assessments of their websites on the Silverstripe Cloud to provide them with assurance. This page provides information to support agencies and explain the process our team follows when asked to respond to an assessment.
All systems come with risk, and public-facing systems are targets for malicious attacks. Public sector agencies need to understand and manage the risk associated with running a website. If this means undertaking an independent assessment, then we will advise them and take mitigating actions as required. The procedure for conducting and responding to assessments is explained in detail below.
For general information about security and privacy management for New Zealand Government websites, visit the Security and Privacy page on Digital.govt.nz.
Why conduct a security assessment of your website?
Silverstripe Cloud has been set up to be a highly secure platform. 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.
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 turn out to be 'false-positives' - remediations exist to reduce the risk, but they were not known to the assessor. For example, the 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 Silverstripe team can make a change to the infrastructure.
- The Silverstripe 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 Silverstripe 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 Silverstripe 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. Silverstripe Cloud aims to set a default that addresses this balance. For example, Silverstripe CMS doesn’t timeout CMS editors by default, but the recommended recipe install will after 28 minutes. 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 editors with a longer timeout period or to configure their website to time out in 10 minutes.
Sharing information will benefit all agencies
Where-ever possible, sharing security reports with other agencies allows the knowledge gained from the security assessment to benefit others on the same platform. Supplying the full report also means that the Silverstripe team can respond more accurately, as they understand the detail and the context.
A secure folder can be set up that only Silverstripe staff and the public sector agency can access. This also gets around the security issue of emailing security reports. Contact Silverstripe if you need help setting one a secure folder set up.
1. Prior to undertaking a security assessment, the agency should discuss these topics with its 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 Silverstripe Cloud systems. These assessments are not typically useful and are outside the scope of access granted to agencies. However, in some rare situations, they may be allowed. All such assessments must be approved beforehand, and performed under close supervision of the Silverstripe administration team.
Note that “DoS protection overload”, “DDoS protection overload” or other deliberately destructive testing is never allowed.
Shared Services (including the Silverstripe Cloud Dashboard, GitLab, Graylog, Solr search, Varnish cache and Nginx gateway servers) don't need to be included in the scope of security testing, as these services are shared services. Silverstripe can be contacted 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, discuss with the assessor where this copy should be running during the assessment.
Typically the 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, whereas this is not possible on a live server.
Instead, you may 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 development team to ensure that whichever environment is used contains the appropriate code and database to test prior to the assessment start.
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 Silverstripe service desk ticket to ask for guidance.
2. A ticket must be raised with the Silverstripe 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 Silverstripe operations team will then work with you to disable some of the threat mitigations on the stack to allow the assessment to occur.
If this step is not followed, the assessment will almost certainly look like an attack on the Silverstripe Cloud 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, an agency must provide the security report to the Silverstripe Information Security Manager if they require a formal response or any mitigations to be actioned by the Silverstripe 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 Silverstripe 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 Silverstripe 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 Silverstripe team intend to perform (and the expected timeframe for availability of the remediation), or an explanation of why the Silverstripe team consider the risk acceptable.
- An indication of any risks that the Silverstripe 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 Silverstripe 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 Silverstripe service desk. Without further context, it is unlikely that these changes will be accepted or actioned by the Silverstripe operations team.
4. The agency should consider sharing both the security assessment and the Silverstripe 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 Silverstripe 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 customer’s responsibility to integrate these changes into the site code.
When a particular risk originates with custom code, it is the customer's sole responsibility to remediate the issue. If they are unable to remediate the issues itself, the Silverstripe team is able to provide support with a professional services charge.
If customers do not take the appropriate action within a reasonable timeframe to address issues that could pose a significant risk to the platform.