Create a Security Policy

[joycebrum]

Hi again (previous issues: #1717), I'd like to suggest a security policy for publicsuffix/list project.

GitHub recommends that projects have a Security Policy (SECURITY.md). This is a simple document that explains how the project wishes to receive and handle responsible disclosure of potential vulnerabilities.

There are a few ways to receive such disclosures:

• have an email or website available to receive such reports; and/or
• use GitHub's private vulnerability reporting feature.

If you're interested in GitHub's feature, it must be activated for the repository:

1. Open the repo's settings
2. Click on Code security & analysis
3. Click "Enable" for "Private vulnerability reporting (Beta)"

I'll send a PR with a draft standard policy along with this issue.

Thanks!

[dnsguru]

it is an amazing virtue signal, but the challenge may be answering the quesion, "Who's gonna receive these reports?"

If we're doubling down on pressures for the already wafer-thin volunteer resources, it might be better to not set reporting parties expectations higher than they should be.

[joycebrum]

Yeah, it makes sense. The current version I've suggest try to not increase the preassure by claiming responsability. The report will appear in the Security page, if it is not possible to solve it in 90 days, you can just make it public to wait for a solution from the community.

If the text still seems to be claiming too much responsability, let me know and I'll try to lighter it a little.

[dnsguru]

We really don't have "versioning" per se to work from in a classical sense (see #1808 ) so that scope might need to be thought through

I think this is good to be doing and thank you for the start of this conversation and attempting to put anything in place.

I am concerned that given the breadth of the use of PSL - pehaps it is too light... there is more to consider once we'd crack open a security policy in general, as this has some wider context, potentially. security-folk are often drawn to the security tab before wikis and there's quite a lot of things that are done for integrity and security that should probably have their initial eyeballs.

I only state this after losing 100s of vounteer hours to the ICANN Security and Stability Advisory Committee on the efforts around their SAC-070 document. I had the opportunity to talk with dozens of security professionals who would lead off the conversations as if this list were some alt-root project, and I had to start each time at square 1 in a conversation that they'd begin by inviting me to explain to them why this is not a security risk. Aint nobody got time for that, especially when it was n+1 loops.

Additionally, factoring things like the discussion around continuous improvement ideas and potentially starting to require abuse contacts per section on new submissions might be important,

Might be worth documenting how this project requires validations-verification (ex: github account + the _PSL TXT record proofs)

So, maybe we can leverage such security policy document some of this to help proactively advertise the many many things that are part of the project that are adding security and trustability to the list helps get ahead of that. This is perhaps my PTSD from that volun-torture, but if it helps keep others from having to endure that disposible effort for low benefit, let's please do so.

Also, in the context of security, mentioning the SSAC review, the SAC-070 document, and some of the ICANN Office of the Chief Technical Officer ("OCTO") reviews and reports are also helpful as part of fortifying that there is some integrity to the PSL, yet we should offer very strong caution that the PSL should be considered to infer any form of trust or security due to our very light-touch reviews like DNS _PSL TXT somehow replacing thorough vetting by those who include or use the file.

[joycebrum]

Yeah, in this case we should make sure the security policy don't leave many doors open for false positives.

One way I can see of doing it is following a similar format as the CONTRIBUTING.md file and ask that, before any report is made, to carefully read the Security Considerations and other relevant files.

Other idea is to have a section defining what IS NOT a vulnerability (I saw a project that did something similar sometime ago but I couldn't find it again now to share the example).

Besides, to customize more the information needed, we can also consider the possibility of receiving this report through email with some "required information" that helps on ensuring that the finding is not a false positive (not really a security concern).

currently the format provided by the GitHub for Security Advisory Reports is not customizable (AFAIK).
you can try see by accessing my fork: https://github.com/joycebrum/list/security/advisories/new

[dnsguru]

Really appreciate all the effort @joycebrum - let's leave this here to let others weigh in if they will, as this project is not operated by the 'federal commission of jothan' to proclaim right or wrong on things.

I do struggle with what we'd possibly see reported, aside from where Github introduces new features or permissions or reorganizes stuff in a way that changes things unexpectedly.

Let's fly open the doors now and hear what others describe. We don't have a particular deadline for introducing this security policy, other than a bias for improving standards, so if you'd like to suggest some 'flag day' or deadline for comments that the community here can add their inputs, that might be good.

[dnsguru]

I am wondering about how #1699 should be considered in documenting a security policy before we implement something.

We're seeing PRs that could benefit from SECURITY REVIEW not getting it, and there are a few which are identifying that google safe browsing have blocked their apex, impacting all subdomains. Seems like if we are going to have a security policy, per se, that #1699 and this kind of request be included

[joycebrum]

IIUC what you suggested, we can add considerations about these safety checks, but it is not mandatory for a security policy.

The security policy is, at least, to guide users on how to report vulnerabilities safely. But it can contain more informations regarding security. The best example I've seen of this type of security policy is the tensorflow's security policy.

It extensively describes the security recommendations and risks. We could do the same for the publicsuffix security policy:

1. Include the information that is currently on the wiki page
2. Include considerations about Adding Review of PR domains in #PRIVATE against virustotal or other safety checks #1699
3. Include the "What is (and is not) a vulnerability" and "How to report" sections.

Though, we can also decide keeping the "security considerations" as it is in the wiki page and creating the security policy with only the third topic. Both are valid options.

Let me know which one would you rather do. And if you opt in to have a more complex security policy, I might need help to better explain the #1699 conclusions.

[dnsguru]

this is on the backlog - probably behind pull request reviews