Skip to main content

How-to Handle Software Vulnerabilities

This guide describes the process for handling software vulnerabilities in products within PCP R&D. It includes instructions on everything from recording a description of a reported issue to documenting and communicating its remediation.

For guidance on different types of software vulnerabilities and associated threats, see Software Vulnerabilities and Threats.

A software vulnerability can be detected in many different ways, which impacts what steps to take in this process according to the following:

  • An external party, e.g. researcher, government organization, or customer (also ABB internal), reports a vulnerability in, or malware targeting, a PCP offering and expects a vulnerability handling process. See examples of communication of such incidents under Cyber security alerts and notifications.

    • The full process from first response to notification shall be followed.

  • An external party, e.g. researcher or customer (also ABB internal) reports a problem (e.g. a support case concerning a bug) but doesn't identify it as a vulnerability. If the problem turns out to be a vulnerability:

    • Sync with the ABB product security incident response team (PSIRT) (cybersecurity@ch.abb.com ) for a unique ID (CVE ID) to this vulnerability*.
    • Start the process at "Confirmation of vulnerability", under Initial triage.

  • A vulnerability is discovered, typically internally within PCP, and there is no specific reporter to interact with. If the problem turns out to be a vulnerability:

  • It is discovered that malware is affecting a PCP offering and there is no specific reporter to interact with.

Note: The ending of the process may differ depending on the life cycle status of the involved product(s):

  • For products in the "Active" and "Classic" states, the expectation is normally that software vulnerabilities are corrected.
  • For products in the “Limited” or “Obsolete” states, this will be determined on a case-by-case basis. One, but not the only, possible decision is to issue a cyber security advisory about the problem, but not to correct it.

* Use the CVE IDs reported for the 3rd-party software when handling vulnerabilities. Do not create new CVE IDs specifically for the ABB products.

Intended for​

Product managers, product owners, cyber security engineers, and L4 coordinators.

Prerequisites​

When a vulnerability is identified and reported to ABB the first point of contact is the PCP head of cyber security.

PCP head of cyber security appoints a lead person for the subsequent handling of the vulnerability, referred to as the vulnerability handling lead (VHL). This person will ensure that the vulnerability is handled according to this process. In the 9ADB005047 ABB Software Vulnerability Report, the person shall be entered as the “ABB lead”.

Activities​

SVH-0

Below flowchart with time requirements follows the ABB Software Vulnerability Handling Policy. The timelines are communicated externally and shall be considered customer commitments.

SVH-1

* The remediation phase can vary depending on the nature of the issue, e.g. severity of vulnerability and difficulty developing a correction, but in general as soon as possible. For high and critical vulnerabilities, an alternative mitigation should at least be provided within 10 business days.

First response​

Responsible role: VHL.

  1. Acknowledge receipt of the vulnerability report. This only applies when the vulnerability is reported from an external source. Security issues can also be identified from internal sources like product development, product tests, or L3 Support.
  2. Route vulnerability details to the appropriate product development team.
  3. Sync with the ABB Product Security Incident Response team (cybersecurity@ch.abb.com ) to create a unique ID (CVE ID) for this vulnerability.
  4. Create the ABB Software Vulnerability Report, complete section 1, and add an entry in the cyber security core team’s list of vulnerability handling cases. This report will follow the case until closed. Its document number does not need to be related to the document number of the security advisory.
    The ABB Software Vulnerability Report is recommended to be stored where the product team stores the other documents related to the case, preferably in OnePCP DMS.
  5. Notify Group Cyber Security Council (GCSC).

Initial triage​

Responsible role: Product owner for the concerned product(s)/system. The cyber security engineer for the concerned product(s)/system assists and shall at least be consulted.

  1. Create a bug in ADO for concerned products (can be one or several products). See also Bug Classification about security tagging of bugs. Add a reference in the ABB Software Vulnerability Report.
  2. Try to reproduce the vulnerability, if not possible try to get more information from the reporting source.
  3. Sync with the VHL, who should update the fields related to initial triage in the ABB Software Vulnerability Report.

The possible results are:

  • Confirmation of vulnerability.
  • Rejection, the first analysis gives that this is not a security issue, i.e. a false positive.
  • The reported issue is not relevant for PCP (products), forward it to the responsible unit. Involve the VHL for further advice. If the reported issue is in another PCP product, forward it to the responsible product via the VHL.

Investigation​

Responsible role: Product owner for the concerned product(s)/system. The cyber security engineer for the concerned product(s)/system assists and shall at least be consulted.

  1. Follow the defined bug management process described in How-to Manage Bugs.

    • Fill in the "Effect" field under "Security Analysis" as described in the Bug Classification guide.

    • Calculate the CVSS score (see FIRST's Common Vulnerability Scoring System calculator) and fill in the "CVSS" field under "Security Analysis".

    • Determine which product(s) is affected and the level of severity.

    • Determine the root cause and all affected versions.

    • Effort estimation and impact analysis for fix.

    • Consider if the same or similar vulnerability may exist in other functions or products and if so, create defects for those.

    • The product owner and product manager determine possible releases that should include the fix.

  2. Sync with the VHL who should updatee the fields related to investigating in the ABB Software Vulnerability Report.

  3. Decide on potential further actions together with the VHL.

  4. Notify GCSC via the VHL.

Remediation​

Responsible role: Product owner for the concerned product(s)/system. The cyber security engineer for the concerned product(s)/system is responsible for the security advisory/notification.

  1. Follow the defined defect process for fixing the bug and plan for the remediation in agreement with the VHL.

    • Identify if a workaround exists that can be used temporarily until the solution can be released.

    • Implement the solution (if the workaround is not sufficient).

    • Create a "security advisory" with details about the vulnerability and remediation. The security advisory is a field communication category that is described in 3BUL980146 Writing and Publishing Field Communications. See also the 3BSE071315 Cyber Security Advisory template.

    • If the vulnerability is in a 3rd-party product or in the environment where the ABB product operates or has a dependency, a 2PAA124139 Cyber Security Notification may be created.

    • Consider performing an analysis of the root cause to identify why the vulnerability was introduced, why it was not identified by the security development lifecycle process, and whether this process needs to be improved. For more information and guidance about root cause analysis, see 2PAA2024-115317 Root Cause Analysis.

  2. The VHL updates the fields related to remediation in the ABB Software Vulnerability Report and notifies GCSC.

Notification​

Responsible role: Product owner for the concerned product(s)/system.

  1. Distribute solutions or workaround to customers along with a security advisory as described in Writing and Publishing Field Communications.
  2. The VHL updates the fields related to the notification state in the ABB Software Vulnerability Report.
  3. Report to GCSC using the ABB Software Vulnerability Report.
  4. If decided by the extended review team (defined in Writing and Publishing Field Communications), make public disclosure at https://global.abb/group/en/technology/cyber-security/alerts-and-notifications.
  5. The ABB Software Vulnerability Report should be reviewed and approved by the PCP Cyber Security Core team when the case is closed.

Details​

Confidentiality of vulnerability information​

9AAD126846 Information Classification and Handling Standard describes that “lists of vulnerabilities in systems” shall be handled as “Confidential information”.

All departments involved in the vulnerability handling process should understand the sensitivity of the information involved and protect it accordingly. Information should only be transferred or disseminated to those with the need to know.

Sensitive customer information should be protected in transit and storage. Detailed information about vulnerabilities that affect customers should not be stored on insecure SharePoint sites or file shares.

The access control provided by ADO and OnePCP DMS is considered to be sufficient. Users who have access to the ADO and OnePCP DMS also have access to security information in cases related to vulnerabilities.

References​

Owner: L4 and Maintenance Team