How we handle and publish security issues
This is how we handle a Vulnerability Disclosure
- Co-ordination with our client to define the most efficient approach
- Contact the vendor and share information to assess and mitigate the issue
- Establish a 90 days deadline to minimize the window of opportunity for malicious attackers
- Disclosure of the issue on the appropriate channels to reach out to the defensive community
Since scip was founded back in 2002 we have worked with several organizations to successfully analyze, mitigate, and disclose vulnerabilities. This includes but is not limited to well-known and public companies like:
Microsoft ⋅ Apple ⋅ Cisco ⋅ IBM ⋅ Oracle ⋅ Mozilla ⋅ Sun ⋅ Novell ⋅ CheckPoint ⋅ Palo Alto ⋅ Trend Micro ⋅ Finjan ⋅ F5 ⋅ Dell ⋅ SonicWall ⋅ D-Link ⋅ Netgear ⋅ Sony ⋅ Facebook ⋅ Dropbox ⋅ Skype ⋅ GE Healthcare ⋅ Fujifilm ⋅ Draeger ⋅ B. Braun ⋅ Daimler ⋅ Mercedes
The cyber security experience of our specialists ranges back to 1996. We see it as our professional and ethical obligation to practice Responsible Disclosure to improve security and safety:
- Vendors shall have the possibility to address issues as early as possible
- Customers shall have the right to know about risks to handle them properly
This document describes our vulnerability disclosure policy and process. We follow a Best Practice approach that has been established in the cyber security industry and followed by other organizations for years. We prefer a responsible and coordinated disclosure. If you are a vendor working with us on a vulnerability disclosure, steps 3 and 4 are the most important for you.
Vulnerability Disclosure Policy and Process
Step 1: Coordinating with our Client
If our teams at scip suspect or determine a security vulnerability or weakness within a customer project, we discuss the matter with our client and the legal teams to define an appropriate approach to handle the issue.
Step 2: Contacting the Vendor
We then inform the vendor as soon as possible via official mail addresses, web forms or even, if necessary, social media accounts. This initial contact will contain basic information about the finding which helps the vendor to assess and address the issue. As we share vulnerability information with vendors on a voluntary basis, we are not willing to invest time in proprietary forms or submitting issues on a telephone hotline.
If the vendor needs more information we are willing to share all the data we have compiled during our testing (e.g. screenshots, stack traces, packet capturing). Just contact us with the web form or via email if there is something unclear. We encourage secure and encrypted communication with PGP, S/MIME or via our secure transfer server. Additional technical verification and research might require a monetary compensation which will be negotiated beforehand.
If a vendor demands additional information about our customer (e.g. customer name, product serial number) we are asking our customer first if we are allowed to share such details. If the customer does not want to share personal information we keep up the desired and legally expected level of customer relationship confidentiality. This shall have no impact on the vulnerability disclosure process as we report vendor- or product-specific vulnerabilities and not customer-specific issues.
If our specialists report multiple issues in the same submission, each issue will have an unique ID. Please refer to this ID during communication to prevent any confusion. As soon as there is a CVE assigned the issues might be referred to this identifier instead.
We expect cooperation from vendors. They shall respond with a formal confirmation of our reporting, a technical confirmation of the reported issue, and a declaration and timeline of the next steps regarding countermeasures and disclosure. Involving lawyers and announcing legal actions does not affect our vulnerability disclosure process in any way.
All communication is protected and kept confidential until public disclosure. The copyright of the vulnerability finding and exploitability details remains with scip AG all the time (Copyright Act CopA, SR 231.1). This right will be enforced worldwide. The exclusive jurisdiction and venue of any action with respect to the subject matter are the courts residing in Zürich, Switzerland.
Step 3: Establishing 90 Days Deadline
There is a 90 days deadline starting on the moment we contact the vendor (step 2). Once this deadline passes, the issue is disclosed to the defensive community (step 4). This deadline might change if one of the following happens:
- Deadline Expires: The deadline expires on a weekend or public holiday in Switzerland and/or the country of the vendor contact. The disclosure will happen at the earliest on the next working day. Please inform us early about such events.
- Countermeasure Release Date: The vendor communicates a release date for a countermeasure within 30 days following the initial deadline. The disclosure will happen not earlier than the release date of the countermeasure as long as the promised availability is on time.
- 0-day Exploitation: The involved parties are made aware of or identify active exploitation of the 0-day vulnerability, directly impacting unsuspecting victims. The disclosure deadline will be brought forward to 7 days from that point, in order to minimize the window of opportunity for the attackers.
- Vendor Declining Cooperation: The vendor voicing the fact that he is not willing to accept our bug report formally or technically; or there will be no official countermeasure. This does also include strict submission requirements which we cannot or do not want to fulfill. In this case an immediate disclosure might happen.
- Disclosure without Coordination: The vendor or a 3rd party disclose details of our vulnerability finding without coordination with us. In this case an immediate disclosure might happen if necessary.
We reserve the right to move the deadline as necessary in unexpected or extreme circumstances.
Step 4: Disclosing the Issue
As soon as the deadline has passed (step 3), the vulnerability will be disclosed publicly or semi-publicly. Approaching external channels is the task of scip, whereas some releases are handled directly without an intermediate partner. The disclosure will happen on the appropriate platforms which usually include but are not limited to:
|Advisory and/or Countermeasure||Vendor||Vendor||indirect||–|
|CVE and NVD Entry||MITRE or other CNA||MITRE/CNA||indirect||MITRE|
|Alert, Advisory, or Report||Authorities (if necessary, e.g. ICS-CERT, FDA)||Authorities||indirect||–|
|Database Entry||Vulnerability Databases||Database Vendors||indirect||VulDB|
|Posting||Security Mailing Lists||scip AG||direct||Bugtraq, Full-Disclosure|
|News||scip Web Site||scip AG||direct||Web Site|
|Article||scip Blog (optional)||scip AG||direct||Labs, smSS|
|Post/Tweet||Social Media (e.g. Twitter, Facebook)||scip AG||direct||Twitter, Facebook|
The primary goal is to reach the defensive community and customers as quickly and professionally as possible. Under certain circumstances this might even make full disclosure necessary.
We never sell vulnerabilities nor exploits, and we also never participate in shady exploit markets.
Level of Professionalism
scip AG is commited to treat all vendors, manufacturers, partners, and customers equally. We provide the highest level of professionalism to help to defend against malicious exploitation and abuse of security issues. We expect the same level of cooperative professionalism from vendors, manufacturers, partners, and customers alike.
We are working together to bring the industry, community, and society another step forward. A non disclosure, hiding vulnerabilities and not talking about risks helps the wrong people. Security is our business.
(Letzte Änderung: 03. November 2020)
Sie haben Fragen zum Thema?
Unsere Spezialisten kontaktieren Sie gern!