From 29bc08e78d86e3cada4f041e5f9ed88c61efcae3 Mon Sep 17 00:00:00 2001 From: Sven Seeberg Date: Sun, 2 Jan 2022 16:12:57 +0100 Subject: [PATCH] Update policy & add index --- index.html | 25 +++++++++++++++++++++++++ policy.txt | 47 ++++++++++++++++++++++++++++++----------------- 2 files changed, 55 insertions(+), 17 deletions(-) create mode 100644 index.html diff --git a/index.html b/index.html new file mode 100644 index 0000000..e9e26da --- /dev/null +++ b/index.html @@ -0,0 +1,25 @@ + + + + + + + Security @ verdigado / Netzbegruenung + + + +
+ +

Ressources

+
+ + diff --git a/policy.txt b/policy.txt index 4938e39..c98e4e9 100644 --- a/policy.txt +++ b/policy.txt @@ -8,28 +8,34 @@ Netzbegruenung). Services can be identified by the following means: - The reverse DNS of an IP address resolves to one of the following domains: *.verdigado.net, *.verdigado.com, *.netzbegruenung.de -2. Classification of Vulnerabilities +2. Acceptable Use -We consider vulnerabilities as relevant when they meet one or more of -the following conditions: +We generally invite security researchers to search for vulnerabilities +in our services. We kindly ask to not put any actual user data or +production systems at risk. + +3. Classification of Vulnerabilities + +We will consider a vulnerability report most likely as relevant if it +reports one of the following problems: - The vulnerability can be used to directly access non-public information that either reveals further security relevant problems or - contains user data. + contains user data, credentials, or sensitive data in general. - The vulnerability can be used to disrupt the orderly operation of a - service. + service (Denial of Service). - The vulnerability can be used to manipulate data within the service. - XSS, CSRF, RCE, authentication/authorization bypass, SQL inections, etc are considered relevant. -We consider reports of vulnerabilities not as relevant when they contain -the following information: -- A service is missing HTTP security headers or comparable "add-on security" - features. +We will consider a vulnerability report most likely as NOT relevant if +it reports one of the following problems: +- Missing security features, for example HTTP headers, if they are not + actually preventing a vulnerability. - Publicly accessible version strings of used software. - Security vulnerablities that can only be used within the scope of the used account. -3. Reporting Vulnerabilities +4. Reporting Vulnerabilities Report vulnerabilities via e-mail to security@verdigado.com. @@ -39,22 +45,29 @@ Please make sure that you include the following information: - Explanation of the risk Reports will be answered within 48 hours. If you have not received an -answer within that time frame, please make sure to contact us again. +answer within that time frame, feel free to contact us again. -4. Bug Bounties / Vulnerability Rewards +For used open source software, we recommend to file bug reports and/or +pull requests against the upstream repositories. This includes hardening +instructions in the installation documentation. + +5. Bug Bounties / Rewards The amount of reward payed depends on the severity of the found vulnerability. We usually do not pay rewards if vulnerabilities can be found in mass scans with of-the-shelf software. -5. Acknowledgement +Only responsible disclosures are eligible for rewards. + +6. Acknowledgement We list recognized reports of vulnerablities online if the reporting -security researcher agrees. The name, contact e-mail address, and type of -vulnerability can be included in the list. Our public acknowledgements -can be found at https://verdigado.com/security-acknowledgements.html. +security researcher agrees. The name, contact e-mail address, and type +of vulnerability can be included in the list. Our public +acknowledgements can be found at +https://verdigado.com/security-acknowledgements.html. -6. About this Policy +7. About this Policy This policy is MIT licensed. Feel free to suggest modifications and additions at https://github.com/digitalfabrik/security-policy.