Skip to main content

Cyber Security Assessment

All ABB products or system offerings which are software-related need to fulfill some mandatory cyber security requirements as described in the CFS-CP-02 Information & Cyber Security Policy.

ABB cyber security standards​

The ABB cyber security standards are mandatory and must be fulfilled by ABB products, cloud solutions & operations and also by ABB suppliers.


More information about the different standards, can be found here.
Under each standard you can find FAQs, e-learning and other information about the standard.

Cyber security assessment​

Assessments to help detect cyber security issues in the design of a product shall be done at various points in a product lifecycle.

  • Why

    The purpose of the assessment is to analyze the product design from a security perspective and to find security weaknesses at an early stage. It is also used to prove that the cyber security requirements are fulfilled before the release.

  • When

    Assessments are performed twice for a release: the final assessment the initial assessment is done before G2/during planning to evaluate the initial security status to be able to plan the security activities for the release and
    before G5/release to prove that all security gaps are closed, and the product is ready for release.


For Cloud Operations, an assessment should be done at least once every year.

  • Who

    The cyber security engineer is responsible for collecting the information and filling in the cyber security assessment report or the lightweight security assessment checklist. The PAPCP head of cyber security appoints an assessor to asses the compliance and then approves the assessment report or the lightweight security assessment checklist before the release.

  • Where

    The assessment can be done on product level, or it may be done on component level if the project decides that it is suitable, e.g. if a component is security-wise complex or critical. If a group of products or components are very similar, they may also be grouped into one security assessment.

  • What

    The initial assessment for a release shows the gaps that need to be handled by the project and provides input for the project planning.
    It is recommended to update the assessment when new information is available. The final assessment should contain links to evidence or argumentation which is provided by or reviewed by the proper audience.
    For a full release two assessments are needed; the security development life cycle assessment (SDLC) and either the product security assessment (PSA) or cloud security assessment (CSA).

  • How

    ABB has developed a number of cyber security assessment tools. The PCP versions of these tools have been extended with additional guidance for each requirement about what evidence is needed. These tools are available in Templafy. The latest approved version of the appropriate tool shall be used.

    For minor releases, e.g. rollups, temporary corrections (TCs) and certified corrections (CCs), you may use the lightweight assessment checklist and refer to the assessment of the previous release if certain conditions are met.

    For TCs that do not introduce any significant change, the TC checklist will include the security questions to be answered for the release.

    An alternative to using the Assessment tools is to use the security work item in Azure DevOps (ADO) during the assessment. See Assessment using security work items in ADO below for more information.

  • Inputs to the assessment
    For the initial assessment, typical inputs are system requirements, drafts of artifacts, the assessment from the previous release (including exceptions from that release) and known security issues.
    For the final assessment, approved artifacts are needed as evidence of the completion and fulfillment of the requirements.
    Please note: The input documents should describe all that is needed for the security assessment. The Security assessment should just refer to these. It may provide extracts and condensates of them, but it should not describe anything which is not described in an input document. It should not be necessary to read a security assessment for a product to understand its security functionality/status. If the input documents do not contain the needed information to show that the security requirements are fulfilled, the input documents need to be updated before the assessment can be completed. An alternative could be to create a separate document that describes the security compliance in the way an architecture document would, and refer to this.

Assessment of updates to previous releases​

For releases such as rollups, TCs, CCs, or service packs you may refer to the assessment of the previous release if the following condition met;
It is a pure bug correction R&D project and the product interfaces are unchanged, i.e. no functional changes, no changes in protocols or stacks, no new components, no new or changed APIs, no support for new versions of the operating system, etc.

As a help to determine whether a release can refer to a previous assessment the PAPCP Lightweight Security Assessment Checklist should be used. In addition to answering the questions in the checklist with Yes or No, references to some previous and still applicable evidence as well as evidence of some activities that are mandatory for each release, must be provided. The assessor may ask for som additional information to be provided and assessed. If the assessor does not find the lightweight assessment sufficient for the release, he will ask for a full assessment.

For TCs, that only fixes defects and do not introduce any significant change, the security documentation of the base product version is judged to be valid. The TC checklist will include the security questions to be answered for the release.
If the release concerns a security defect, the necessary documentation and verification shall be handled by the impact analysis of the defect and no separate assessment document is needed.
Examples of significant changes are changing/adding new features and functionality, APIs, communication stacks, 3rd-party components or external interfaces, or changes that extend the impact/scope of the TC by affecting other components of the product, in particular if critical ones.

New versions of assessment tools​

When preparing for the final assessment or when refering to a previous assessment, check that no new versions have been published.
If there is a new version of a tool, the changes must be reviewed and if they include changes to the requirements, e.g. a new requirement added, that affect the overall assessment report then it must be handled. It is advisable to use the new version of the tool and copy the answers that are are still applicable from the previous assessment report into the new.

Assessment using the cyber security assessment tools​

The cyber security assessment tools are a set of Excel templates where the main sheet “Compliance Assessment” contains the requirements. Through filtering it is possible to choose the relevant scope. The cyber security engineer is responsible to gather the argument/evidence for each requirement.
The assessor, who is assigned by the head of cyber security, selects a rating and writes a comment for each requirement. When writing his comment, the assessor can add a predefined cell style to the comments cell to color code the current status; green, yellow or red. Green is accepted for release, but any comment should be used for improvement and considered during the next initial assessment. Yellow is used when something more is needed and red will block a release. The “Instructions” sheet of the assessment tool provides guidelines and explanations for the different columns.

Assessment using security work items in ADO​

If the ADO collection has a work item of the type "Security", it is possible to import the cyber security requirements from the first three tools mentioned in Compliance assessment tools into ADO.

The ABB Cyber Security Assessment Tool Importer will import the requirements as security work items under a feature or epic. See How-to Use the ABB Cyber Security Assessment Tool Importer for detailed information.

Once the work items are imported, they can be used for planning the security activities. Information from the assessment tools, such as assessment tool, requirement category, ID, and security level can be used for filtering of work items. The requirement and PCP evidence/guidance are imported as the description of the work item.

Evidence and arguments given by the project should be listed in the "Compliance Argument" field. The assessor makes his comment in the "Discussion" field and the head of cyber security for the business unit approves the cyber security assessment before the release by closing the work item.

Below is an explanation of the different states of the work item:

State​Explanation​Assessment status
NewThe security item has been created with description, tags, security rating and security level added from information in the excel sheet, but it has not been investigated.NOT FULLFILLED
ActiveThe requirement has not been fulfilled, but should be in the feature. The work item is planned and worked on.-
ResolvedA conclusion has been reached and documented in the “Compliance Argument” section.-
ClosedThe bug is resolved and verified, and all associated work has been completed.FULLFILLED
RemovedThe item is not applicable for the product.OUT OF SCOPE

How to handle gaps found in security assessment during the initial assessment​

A gap that concerns a new or changed security functionality shall be handled by an epic/feature work item. In addition, a complex security functionality shall be handled by implementation proposal. Incorrect or insufficient behavior of a security functionality shall be handled as a defect. In the security assessment, make a note about how the gap will be addressed, e.g. by referring to a work item ID.

How to handle gaps found in security assessment before release​

A gap that concerns a product requirement in the ABB Product Security Standard or ABB Cloud Offerings/Operations Standards shall be handled by an exception request. The product may only be released if the exception is granted.
A gap that concerns a process requirement in the ABB Security Development Life Cycle (SDLC) Standard shall be discussed with head of cyber security or a person appointed by the head of cyber security.
For a gap that concerns a security functionality planned to be included in the current release a decision shall be made by product management and the head of cyber security or a person appointed by the head of cyber security; either to implement the security functionality before the release or add a comment for the functionality to be a candidate for next release.

Assessment for 3rd-party suppliers​

All suppliers of commercial software shall comply with ABB Cyber Security Requirements for Suppliers and confirm their compliance in SAP Ariba. In case of critical software, the product owner reach out to the local purchase team to request that a detailed checklist should be updated by the supplier/reseller/redistributor. This assessment is performed via a questionnaire sent to the customer and reviewed by the cyber security engineer. More information can be found in the process Minimum Cyber Security Requirements for Product Procurement, which shall be followed for the procurement of any third-party software-related product that is part of ABB products or solutions.

Exceptions​

Generally, all requirements must be fulfilled before product release. But there may be product specific reasons why a requirement cannot be met. In that case, the release owner must request an exception.

The exception request should include at least:

  • References to any requirements that are not met.
  • The reasons for failing to meet the requirements.
  • Committed plans that address the gaps and assure future compliance.
  • Potential resulting risks to ABB.
  • Potential resulting risks to ABB customers including the plans to communicate those risks to affected customers.
  • The business justification for requesting the exception.

The exception request is typically written by the release owner with the assistance of the head of cyber security and the Cyber Security Exception Request Form Template should be used. Fore more information about exceptions see Exceptions to ABB Cyber Security Standards and Requesting an Exception to the Corporate Policy "CFIS-CP-02 Information & Cyber Security Policy.

Deferring High Severity DSAC findings​

If DSAC has found high-severity issues that cannot be corrected before release there are two options.

  • Reclassification The issue may be "reclassified". This is relevant if the product team has a strong argument why the severity set by DSAC is not relevant. If the head of cyber security agrees to go for reclassification, the product team can request a reclassification form from DSAC. In this the team describes why the severity of the finding is something else than what DSAC initially set. A reclassification can be accepted if the PAPCP head of cyber security, the PA head of cyber security and the DSAC manager all agree to this.

  • ABB Corporate Policy exception If the issue is correctly classified ("reclassification" cannot be used), but the team anyway has strong reasons to release the product without correcting the issue until later, the team may request an exception as described above, including the approval from the Group Cyber Security Council.

Default exceptions​

There are some default exceptions where the ABB cyber security standards do not need to be met. For example, if an ABB product supports PROFIBUS for communicating with a 3rd-party PROFIBUS device, the requirement on secure protocols (RE.15) is by default excepted since standard PROFIBUS does not exist in a secure variant.

For default exceptions, there is no need to request an exception, but the default exception shall be referred to from the security assessment.

For more information about default exceptions for the different standards, see:
9AKK108468A2710 Default exceptions for the Security Development Life Cycle Standard 9AKK108468A2706 Default exceptions for the Product Security Standard

Compliance assessment tools​

There are different tools for performing assessments:

  • for ABB Product Security Standard - PAPCP Security Development Life Cycle Assessment Tool is available in Templafy
  • for ABB Security Development Life Cycle (SDLC) Standard - PAPCP Security Development Life Cycle Assessment Tool is available in Templafy
  • for cloud offerings and cloud operations - PAPCP Cloud Security Assessment Tool is available in Templafy
  • for small projects (SDLC and PSA) - PAPCP Lightweight Security Assessment Checklist.xlsx is available in Templafy
  • a tool for importing the requirements to ADO as work items (for information see How-to Use the ABB Cyber Security Assessment Tool Importer)
Owner: Cyber Security Team