DEFRA security.txt

[brendanarnold]

security.txt is an emerging practice on deployed websites which lets security researchers know how to properly disclose security issues related to a website. More details at https://securitytxt.org

The MoJ is the current gold standard for this and has clear guidelines for sites on what to do - see https://ministryofjustice.github.io/security-guidance/contact/implement-security-txt

There is interest from other departments including DWP and MetOffice. It would be good to get some similar guidance for DEFRA projects.

More information...

• Example file: https://raw.githubusercontent.com/ministryofjustice/security-guidance/master/contact/vulnerability-disclosure-security.txt
• The MoJ department wide disclosure policy https://mojdigital.blog.gov.uk/vulnerability-disclosure-policy/
• @joelsamuel on the #security Slack channel wrote the disclosure policy for MoJ

[Cruikshanks]

I feel if nothing else going through the process of working out what would go into our security.txt file(s) has worth, even if we never end up with one.

I group this along with external contributions to a repo; we've so far never faced the situation of someone wanting to contribute or tell us an issue. But I also wouldn't want to be left scrabbling around and keeping someone waiting for weeks whilst we tried to figure it out what the actual process would be. Not only would it not be fair, but it also wouldn't look great for the organisation either.

That said, I do think there is value in having this. This is not just an idea replicated by others but is based on an actual draft standard to the Internet Engineering Task Force (IETF).

It's also endorsed by 2 folks I often refer to on security matters Troy Hunt and Scott Helme.

So it gets a 👍 from me!

[paulsimonandrews]

This might be relevant: https://technology.blog.gov.uk/2023/08/10/advocating-security-txt-across-uk-government/

[ben-sagar]

@johnwatson484 will look into this

[johnwatson484]

I've captured this in Confluence as a working document to support the discussion going forward internally.

However in the interested of being open, will share my thoughts here too.

---

Security.txt describes a text file that advertises the organisation’s vulnerability disclosure process so that someone can quickly find all of the information needed to report a vulnerability. It is a voluntary standard for internet users set by the Internet Engineering Task Force (RFC 9116).

Security.txt will serve the government in its aim to become more resilient in its online security by making it easier for anyone to report vulnerabilities they have found. Quick, easy and secure reporting directly to the affected department speeds up the triage and remediation time and reduces the risk of compromise, such as reporting of a vulnerable web server so it can be remediated before being exploited. The security.txt was endorsed by the Data Standards Authority in March 2023.

Advocating security.txt across UK government

Format of Security.txt

A Security.txt file is published to the /.well-known/security.txt directory of a service and includes the following instructions should a vulnerability be identified in the service.

• who should the person contact
• what should the person provide
• what should they person expect to happen

The file should be plain text and contain three fields.

CONTACT: How finders should report vulnerabilities. For example, email or secure web form.

POLICY: A link to the department’s vulnerability disclosure policy.

EXPIRES: Indicates the date and time after which the data contained in the "security.txt" file is considered stale and should not be used. The value of this field is formatted according to the Internet profile of [ISO.8601] as defined in [RFC3339]. It is recommended that the value of this field be less than a year into the future to avoid staleness.

A fourth ENCRYPTION field is optional and should link to the PGP public key you wish to be used for encrypted communication.

How to respond to a vulnerability disclosure

NCSC provides guidance on what to do when a disclosure is reported as well as additional support for creating the file and policy.

Vulnerability Disclosure Toolkit

1. Don’t ignore the report. Respond promptly to the finder, and thank them. Feedback encourages engagement and they'll be more inclined to help you again in the future.

2. Pass the report to someone in your organisation who is responsible for the affected product or service. If it is managed by a third party, discuss the report with them.

3. Avoid forcing the finder to sign documents such as non-disclosure agreement as the individual is simply looking to ensure the vulnerability is fixed.

4. If you need more information to confirm and fix the issue, you should politely request that additional information from the finder.

5. Once you have decided on a course of action, let the finder know that the issue is being managed. You don't need to provide lots of technical information or commit to timescales.

6. If the issue takes time to fix, you should send periodic updates back to the finder.

7. Once the issue is fixed, let the finder know. They might be able to retest the issue to confirm the fix.

8. Consider publicly acknowledging and thanking the finder as this creates a sense of trust and transparency.

Should we implement Security.txt in Defra?

With the ever evolving cyber security landscape, it would be naive not to consider any opportunity that improves Defra’s ability to identify vulnerabilities across their services.

There have been a few previous alerts raised about vulnerabilities in Defra code. In those scenarios, reporters have typically scrambled through GitHub commits and users to try and find a contact email. The recipient within Defra then in turn tries to find an appropriate person responsible for the code if it is not themselves.

It is not unrealistic to assume that there have been willing reporters who were unable to find an appropriate contact or the Defra recipient was unable to progress the alert.

Although implementing Security.txt is not expected to lead to a high volume of inbound alerts, it gives us an opportunity to formalise an publicise a clear process.

How could we implement this in Defra?

If we were to implement this within Defra, there are several pre-requisites and several implementation options.

Vulnerability disclosure policy

NCSC provides a GitHub hosted policy that UK Government organisations can reference within their Security.txt files → Vulnerability-Disclosure/UK-Government-Vulnerability-Disclosure-Policy.md at master · ukncsc/Vulnerability-Disclosure

We can either reference or self host our own based on the template on GitHub, CDP or GOV.UK.

For the GOV.UK option we could link from the Defra organisation page

Add /.wellknown/security.txt path

The Defra software development standards Defra Software Development Standards can be updated to mandate this for new web services. Although not all services end up on the public internet, we shouldn’t restrict internal users from being knowing how to report a vulnerability in an internal service.

CDP also provides an opportunity as the majority of new services will be developed using scaffolded repository templates. These templates can be updated to include the Security.txt route and file as standard.

For existing services, we can publish the new standard to our Slack and Teams comms channels to encourage retrofitting to existing services.

Who to notify

There are a few options for who should be notified. We could allow individual teams to have their own contact information. However, there is a risk this data would become stale as teams and individuals change. Levels of responsiveness and tracking may also be inconsistent with this approach.

It seems more logical to have a consistent entry point to the notification.

Another advantage of making it consistent is each service just needs to redirect to a common Security.txt file and only host their own if there is justifiable variation in progress.

This could be as simple as an email address or it could be a webform, similar to MoJ

If we go with the webform approach the end result could still be an email sent to Security, but the advantage is the process can iterate and evolve in one location to avoid needing to keep individual files in process. The service hosting the webform could also host the disclosure policy and common Security.txt file.

Options for developing the webform could be:

• Power App
• CDP hosted service
• third party app

Developing an application requires funding, so it would be worth engaging with Cross Cutting Technical Services (CCTS) to see if this is something they could take on as they have several similar services for Service Manual, Service Assessments all hosted on CDP.

The ultimate notification location is likely to be within DDTS security. Much like other security alerts from SoC are processed.

What do to on receipt of a notification

If DDTS Security are the central recipient point, then a process needs to be agreed beyond acknowledging the report to the sender.

DDTS Security will need to identify which Delivery Group is responsible for the service and notify them accordingly.

An agreement should be made between the teams and Security teams for an investigation and potential resolution.

Other opportunities

We could publish a GOV.UK blog, similar to MoJ, to publicise our approach. This will not only help users using search engines to find our disclosure policy but continue MoJ’s encouragement for other governments departments to consider adoption.

Proposed next steps

• Refine this proposal with Defra Principal Developers
• Engage with DDTS Security for their thoughts. They may have similar initiatives ongoing or from the past we can align with
• Engage with CCTS to discuss ownership and hosting of potential web form and policy

[johnwatson484]

Captured on Principal Developer backlog -> https://eaflood.atlassian.net/browse/PDEV-274