Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add differentiation between PSIRT and CERT contact #199

Open
tschmidtb51 opened this issue Feb 24, 2021 · 2 comments
Open

Add differentiation between PSIRT and CERT contact #199

tschmidtb51 opened this issue Feb 24, 2021 · 2 comments

Comments

@tschmidtb51
Copy link

Is your feature request related to a problem? Please describe.
The "security.txt" aims to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. In section 3.1 it states that "[it] MAY also apply to products and services provided by the organization publishing the file." Products are usually dealt with at Product-CERT / Product Security Incident Response Team (PSIRT). Infrastructure vulnerabilities are usually CERT business.

Many SME can effort to hire security experts. Therefore, they use service providers. As the IT is usually outsource the CERT function is outsourced as well. The product related vulnerability handling might be done in the development department or also by an external party. Since security experts are expensive, we see PSIRT service providers (e.g. non-profit PSIRTs at industry associations like https://cert.vde.com/) becoming more popular.

The "security.txt" of Company X might now look like:

Contact: mailto:[email protected]
Contact: mailto:[email protected]
# ...

A security researcher has now the problem of identifying which contact to use.

Describe the solution you'd like
The standard should introduce mandatory categories (ALL, CERT, PSIRT) for the Contact field.

Example:

Contact[CERT]: mailto:[email protected]
Contact[PSIRT]: mailto:[email protected]
# ...

Describe alternatives you've considered

  • Keep the current state. This makes it harder for security researcher to find the right contact and might disclose vulnerabilities to the wrong parties.
  • The information could be provided by giving comments. However, a comment (if not explicitly specified in the standard) might be machine-parsable but can't be automated since it will be different for each instance.
  • The categories could have different names, e.g. "any", "infastructure", "products", "services". I'm open to that. However, it requires a definition of the different terms which I can't provide at the moment.

Additional context
None.

@nightwatchcyber
Copy link
Contributor

This is probably going to be deferred after the initial draft is approved. But I am wondering, in any case, perhaps the current "Contact" field can mean "any", and we can define a more narrow set of fields for specific use-case like:

`Contact-CERT:

Contact-PSIRT:`

@tschmidtb51
Copy link
Author

I like the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants