Search
Results will appear here...

ABOUT THE PRODUCT SECURITY INCIDENT RESPONSE TEAM (PSIRT)

Contact PSIRT at psirt@powin.com

1. Responsible Disclosure

We believe in responsible disclosure. This means that when a person or organization (“security researcher” or “researcher”) discovers a security vulnerability in Powin’s products, we expect them to notify Powin directly and confidentially to allow us an opportunity to respond. For our part, we will immediately respond to the submitter, begin investigating the report, and, as needed, notify our customers and publish an announcement (“Cybersecurity Bulletin” or “CB”). We will also give credit to the security researcher if they so desire.

2. Policy

  • PSIRT will receive and disposition all product security reports in a timely manner.
  • PSIRT will not publicly disclose or discuss vulnerabilities until at least a temporary remediation is available.
  • PSIRT will privately disclose vulnerabilities to all customers at the same time within 72 hours of verifying a reported vulnerability, except under extenuating circumstances such as human safety or specific threats to critical infrastructure or due to legal requirements. In this case, some customers may be made aware of the vulnerability sooner than others.
  • PSIRT will publicly acknowledge the security researcher in its public and private communications if:
    • The researcher wants to be identified.
    • The researcher did not disclose (publicly or to another entity) or take advantage of the vulnerability prior to Powin’s remediation being in place and/or Cybersecurity Bulletin publication.
  • PSIRT will use NIST CVSS v.3.1 Scores to rate each vulnerability.
  • PSIRT will use a vulnerability’s CVSS Score to define the expected turnaround time for a fix (response listed is desired and will be used if feasible):

    CVSS Score Classification Priority Remediation CB Type
    9.0-10 Critical 1 Hot fix ALERT
    4.0-8.9 Severe 2 Patch NOTICE
    0.1-3.9 Minor 3 Release None; Release Notes
    0.0 None Won’t Fix N/A N/A

  • PSIRT places vulnerabilities into one of four Risk Categories:
    1. Not Vulnerable: Either the vulnerability does not exist or is not exploitable due to system design. In this case, there is no risk to Powin or our customers.
    2. Vulnerable, Not Exploitable: Similar to Not Vulnerable, but in this case the vulnerability is not exposed to exploitation due to its location in the system (e.g., an accessory component with no open interfaces) and, in Powin’s assessment, there is no risk to Powin or our customers.
    3. Vulnerable, Low Risk: The vulnerability exists, and may be exploitable, but doing so provides no benefit to the attacker. In Powin’s assessment, the vulnerability represents negligible risk to Powin and its customers in approved system configurations. CVSS Score of 0.0 due to zero impact.
    4. Vulnerable: The vulnerability exists and risk exists to Powin or its customers. The associated CVSS Score will be based on approved system configurations and can be used to assess severity of the vulnerability.
  • The CVSS Score explicitly includes impact categories of Confidentiality, Integrity, and Availability. To make it clear in a CB, Powin will also explicitly state what type of potential impact the vulnerability represents, typically along these same three dimensions.
  • PSIRT considers it to be a Crisis Situation when a vulnerability becomes known prior to an CB publication. In this case, PSIRT may provide incomplete information as soon as it becomes available so that customers are able to react immediately to the threat. This information will be refined and re-published as more details become known.

3. Determining Risk

CVSS 3.1 distinguishes between vulnerability and risk. What Powin is communicating with a CVSS Score is the potential impact from a specific vulnerability. Based on our assessment of a vulnerability, it may receive a Score of 0.0 if there is no way for an attacker to exploit it in any useful way. In other words, if the vulnerability is not exploitable, the CVSS Score will be 0.0.

CVSS 3.1 breaks the assessment into three metric categories:

  • Base Score: These are specific to the vulnerability itself. For example, if the Base Integrity Impact was “High”, the Base Score might be 4.6.
  • Temporal Score: These account for the evolution of a vulnerability over time. For example, if a vulnerability initially receives a Score of 4.9 due to no remediation being available, that Score might drop to 4.6 when an official fix is available.
  • Environmental Score: These capture characteristics of a specific operating environment. For example, if there is no impact from the vulnerability (i.e., all the Environmental Impact Metrics are “None”), then the Overall Score will be 0.0.

For more information on how CVSS Scores are calculated, please reference: https://www.first.org/cvss/user-guide

Risk, on the other hand, we describe using the formula Risk = (Impact × Likelihood). Overall impact is the CVSS Score and likelihood is a separate assessment. As part of any CB, Powin will also provide a risk evaluation using the Risk Categories as defined above.

4. Reporting Vulnerabilities

Please send an email to psirt@powin.com. Someone will respond to you in 1-2 business days (determined by the United States calendar and Pacific time zone business hours).

PSIRT requests that the following information be provided in the report:

  1. Your contact information:
    1. Email address (required)
    2. Preferred Name for private communications (required)
    3. Public Name (optional)
  2. Summary of the vulnerability (required)
  3. Assessed CVSS 3.1 Score (optional, please include vector text)
  4. Reproduction Steps (required). Can be text, screenshots, videos, or other information as needed. Please be explicit in your report.
  5. Identified Vulnerabilities (required)
  6. Identifying Information (highly desired, but optional)
    1. Software or Hardware Component(s)
    2. Software or Hardware Version Number(s)
    3. Component Location, such as:
      1. Geographic Location
      2. Network Location
      3. On-site vs. Cloud
      4. Internal, UI, or Web
      5. Site Information, if known
  7. Tool Information (highly desired, but optional)
    1. Browser Product and Version (e.g., “Chrome 12.34, Linux)”
    2. Attack Tools (e.g., exploit name and application name, if relevant and available)
  8. Your disclosure plans, if any. We need to know to whom and when. (required)