Doosan GridTech Product Security Incident Response Team (DGT-PSIRT)

1. RESPONSIBLE DISCLOSURE

We believe in responsible disclosure. This means that when a person or organization discovers (“discoverer”) a cybersecurity vulnerability in DGT’s products, we expect to be notified directly and confidentially to give 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 release an announcement (“Cybersecurity Bulletin” or “CB”). We will also give credit to the discoverer if they desire.

​

2. POLICY

• PSIRT will receive and disposition all product security reports in a timely manner, typically within 1-2 U.S. business days.

• PSIRT will not publicly disclose or discuss vulnerabilities until at least a temporary remediation is available.

• PSIRT will privately disclose vulnerabilities to all affected customers at the same time within 72 hours of verifying a reported vulnerability, except under extenuating circumstances such as human safety, 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 discoverer in its public and private communications if:

  • The discoverer wants to be identified.

  • The discoverer did not disclose the vulnerability to anyone except DGT PSIRT or take advantage of it prior to DGT’s remediation being in place and/or publication of a Cybersecurity Bulletin.

• PSIRT will use NIST CVSS v.4.0 to rate each vulnerability.

  • A CVSS 4.0 calculator can be found here: https://www.first.org/cvss/calculator/4-0

  • All CBs will include the relevant CVSS Score and Vector.

• PSIRT will use a vulnerability’s official (as assessed by DGT) CVSS Score to define the expected turnaround time for a fix:
   

​

​

​​​

• PSIRT places vulnerabilities into one of three Risk Categories:

  1. Not Vulnerable: The vulnerability does not exist. In this case, there is no risk to DGT or our customers. The DGT CVSS Score will be 0.0.

  2. Vulnerable, Not Exploitable: Similar to Not Vulnerable but in this case the vulnerability does exist but is not exposed to exploitation due to its location in the system and, in DGT’s assessment, there is no risk to DGT or our customers. The DGT CVSS Score will be 0.0.

  3. Vulnerable: The vulnerability exists and risk exists to DGT or its customers. The associated CVSS Score will be based on approved system configurations and can be used by customers to assess vulnerability severity.

• The CVSS Score explicitly includes impact categories of Confidentiality, Integrity, and Availability. To make it clear in a CB, DGT will also explicitly state what type of potential impact the vulnerability represents, typically along these same three dimensions. This will be documented and communicated through the CVSS Vector.

• PSIRT considers it to be a Crisis Situation when a Critical or Severe 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 distinguishes between vulnerability and risk. DGT will not use the reporter’s CVSS score to determine our response. Instead, DGT will investigate the reported vulnerability to produce an official CVSS score. In other words, DGT is communicating the true impact of a specific vulnerability with our CVSS Score (we will publish our CVSS 4.0 vector). Based on this assessment, a vulnerability may receive a score of 0.0 if there is no way for an attacker to exploit the vulnerability.

​

CVSS 4.0 breaks assessments into two main metric categories:

• Base: These are specific to the reported vulnerability. This component of a CVSS score considers the vulnerability outside of any specific deployment context. If DGT’s product uses a software component with the vulnerability, the Base metrics represent this component by itself as though it’s completely exposed to attack.

• Environmental: These capture characteristics of a specific operating environment. This represents the deployment context for the vulnerability such as which part of the application it is used in, how the vulnerable code can be triggered (e.g., specific code paths), and what extra steps might be involved to exploit the vulnerability. If there is no way to exploit 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/v4-0/user-guide

 

For Risk, we use the formula Risk = (Impact × Likelihood). Impact is the CVSS Score and Likelihood is a separate assessment. As part of any CB, DGT will also provide a risk evaluation using the Risk Categories as defined above.

 

4. REPORTING VULNERABILITIES

Please send an email to gridtech-psirt@doosan.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:

   • Email address (required)

   • Preferred Name for private communications (required)

   • Public Name (optional)

2. Summary of the vulnerability (required)

3. Assessed CVSS 4.0 Score (optional, please include your 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)

   • Software or Hardware Component(s)

   • Software or Hardware Version Number(s)

   • Component Location, such as:

     • Geographic Location

     • Network Location

     • On-site vs. Cloud

     • Internal, UI, or Web

     • Site Information, if known

7. Tool Information (highly desired, but optional)

   • Browser Product and Version (e.g., “Chrome 12.34, Linux)”

   • 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)