Skip to main content

Cyber Security

To help our customers protect their critical systems and sensitive information from digital attacks security has to be built into our products.
Therefore, the Cyber Security process is an integrated part of most of the PCP R&D processes.
This page contains an overview of security-related activities within PCP R&D, and additional information can be found under respective process area in the QMS.

This page focuses on cyber security related to the development activities in R&D. There are interfaces to other organizational functions for security, e.g., system requirements (SR) from PPM and customer-reported security issues (L3 Support).

Audience and applicability​

This page is suitable for release owners and cyber security engineers who will plan and oversee the security related activities during the development phase, or anybody who wants an overview of cyber security activities during development.
It is applicable for all R&D projects that are developed according to PCP R&D Processes, including:

  • Full-scale system and product projects.
  • Rollups (bug corrections).
  • Minor updates, e.g. temporary corrections, certified corrections, and patches.

Overview​

Below image gives an overview of security-related activities in the different process areas.

CS-1

note

The section below contains a brief description the security-related activities of each process area. For further details, see the provided references.

Requirements​

The security-related requirements are handled in the same way as other requirements. To easily be found, mark or categorize them as security requirements.

Define security epics, features, and stories​

The security requirements for the system or product releases originate from PPM as system requirements which become system epics in Azure DevOps (ADO). Break down the system epics into epics, features and stories to make the streams and teams work on the security gaps.

ABB has security requirements that all products should fulfill, and other security requirements which are identified in different analysis activities (e.g., in threat modeling). These findings often impact the design and may require changes in implementation to mitigate the vulnerabilities and must be captured in ADO.

Adherence to the ABB Cyber Security Standards is a general requirement for ABB products.

Architecture​

Security architecture in product development aims to create a robust and resilient security posture for the product, mitigating risks and ensuring the protection of sensitive information and assets through-out its lifecycle.

Security architecture refers to the design and implementation of security measures within a software or hardware product to protect it from potential threats, vulnerabilities, and attacks. It involves the integration of various security controls, protocols, and mechanisms into the overall architecture of the product to ensure that it operates securely and protects sensitive data and resources.
Key aspects of security architecture in product development include threat modeling, access control, data security, network security, security compliance (like ISA/IEC62443), security updates, and patch management.

When designing the architecture best practices should be considered. See the guides Secure Design Best Practices and Architectural Security Best Practices for more information.
The security architecture should include the description of the security context to show what security features exist in the surrounding environment and helps to understand the defense in depth approach.

Security context​

The security context defines the environment in which the product is expected to reside, regarding e.g. network location/isolation, physical security needed. This helps to understand the defense in depth approach. In product development, the security context refers to the specific environmental requirements, constraints, and considerations related to ensuring the security of the product. It encompasses various factors that influence the design, implementation, and maintenance of security measures within the product. Understanding the security context is essential for effectively addressing security concerns and mitigating risks throughout the product lifecycle.

Attack surface analysis​

Attack surface analysis is a systematic process of identifying and assessing the various entry points or attack vectors that malicious actors could potentially exploit to compromise the security of the product. It involves examining the product's architecture, components, interfaces, and dependencies to understand where vulnerabilities may exist and how they could be exploited. It identifies the interfaces/surfaces of the product or system that can be attacked and the measures to prevent these attacks.

See the guide Attack Surface Analysis for more information and examples.

After the analysis is reviewed the identified parts shall be tested for security vulnerabilities.

Security criticality analysis​

Security criticality analysis inspects the components in a product needing extra attention when minimizing the risk of vulnerabilities. Extra regression testing may be relevant for the critical components.

See the guide Security Criticality Analysis for more information and examples.

Threat modeling​

Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations prioritized.
The purpose of threat modeling is to provide defenders with a systematic analysis of what controls, or defenses, need to be included given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker.

Threat models shall be reviewed not only when the design changes, but also periodically for released products (for certified products at least once a year) and updated if required in response to the emergence of new threats to the product.

The guide How-to Perform Threat Modeling describes how to integrate threat modeling in an agile development process. The document 3BSE070612 Threat Modeling Guideline contains general information about what a threat model is and what it should contain.

Software Development​

Secure design​

The design shall be based on commonly accepted security industry recommendations and guidelines (e.g., as recommended by NIST or defined in international standards). Select the most suitable communication protocols, cryptographic algorithms, and authentication methods to fulfill the security requirements.

Apply "hardening" for security, i.e., everything is closed/disabled by default and only opened/enabled if used.

When reviewing the design; check that the design covers the intended security part of the architecture, considers the best practices and implement or follow the applicable mitigations described in the threat model.
The guides Secure Design Best Practices and SW Development Security Best Practices have more information on the subject.

Secure coding​

Developers shall follow coding guides and best practices to make the code more secure. See Secure Coding Guideline. The adherence to the selected rules is done automatically with the help of a static code analysis tool or manually during code review. Any security rules not checked by the tools must be captured during code reviews using the code review checklists. The guide Code Review Guideline provides more information about code reviews.
Based on the rules in the selected ruleset a secure coding verification strategy needs to be decided upon, to describe how the rules are enforced.

Security analysis and low-level security testing​

Security Testing Guideline contains details about both different security analysis and types of testing.

Static code analysis​

Security focused static code analysis is also called static application security testing (SAST). Enable the security-related checks in the used static code analysis tool. The CWE top-25: Most Dangerous Software Weaknesses lists the most common and impactful issues experienced over the previous two calendar years. Pay extra attention to security-critical components identified in the security criticality analysis. The guide Static Code Analysis provides more information.

Software composition analysis​

The purpose of the software composition analysis is to create a complete inventory of all the software components included in a product. Use it to monitor vulnerabilities and other lifecycle issues in these components.

Analyze the source code with Black Duck to list the used open source software (OSS) and to get assistance monitoring these for vulnerabilities. It is mandatory to use the analysis tool when 3rd-party software components have been added or changed. In addition to that, an analysis should be done once a year to capture any changes in the landscape in which the product resides. The Open Source Competence Center (OCC) oversees ABB's central open source software approval process. Also see the 3rd party and OSS section below.

Perform a binary analysis on all internal and 3rd-party code (i.e. binary executable files, including embedded firmware, to be delivered by the ABB to be installed for a product.) This analysis operates on the binaries (e.g., .exe, or .dll), and can use reverse engineering to analyze what was built. For 3rd-party software binaries, binary analysis should be done prior to including them in source code to know the vulnerabilities. PAPCP recommend using Black Duck Binary Analysis which is described in the guide How-to Perform Binary Composition Analysis with BDBA

Low-level security testing​

Security testing is performed both by the development team and the test team. Some security tests are best performed by developers who know the code, however some types of tests are required to be executed by a person different than the one who wrote the code.

Digital code signing​

Digitally sign the executables and scripts before the release. It makes it possible to validate authenticity (software author) and integrity (code not altered or corrupted since it was signed). The guide Code Signing contains general information and a section about the ABB CodeSigning Service.

Draft of end-user documentation​

The user documentation must include relevant cyber security information for the product and describe the defense in depth strategy. The guide Cyber Security in User Documentation lists the requirements from the ABB Cyber Security Standards as to what needs to be included.

Hardware Development​

The ABB Cyber Security Standards was initially created for software development, but some of the requirements also apply for hardware development. Firmware can be considered software, and the product and process requirements related to software development are applicable also for firmware. Which requirements are applicable for the different product types can initially best be seen by looking in the Security Assessment tools.
For more information, see the sections ABB Cyber Security Standards and Cyber Security Assessment below.

Test​

The document Security Testing Guideline contains details about planning and performing security related testing.

Product and system tests​

Some security tests are required to be executed by an independent department, i.e. security requirements testing, threat mitigation testing, and penetration testing.

Pre-DSAC​

Tests are performed to find security vulnerabilities before the DSAC testing, focusing on finding vulnerabilities with tools like Nmap, Nessus, and Achilles. The tools are available in a virtual machine provided by the DSAC team and performed by the development teams.

DSAC​

The Device Security Assurance Center (DSAC) is an independent organization within ABB that performs security robustness testing for external interfaces of ABB products. Correct all high-severity issues reported by DSAC before the release. Any exceptions must be approved. Prepare for the test well in advance.

The Security Testing Guideline has details about DSAC testing and what to think about. More information about DSAC as well as access to documents can be found on Inside or the DSAC portal.

Regression testing​

Security must be a part of the regression testing performed on a release. It ensures that the main operation, safety measures, and security functions are intact. The pre-DSAC tests are also part of regression testing.

Attack surface review and reduction​

The attack surface identified during the design phase is reviewed in the running product and preferably verified with tools.

The attack surface for a Windows computer can be analyzed with the Microsoft Attack Surface Analyzer. A network attack surface can be analyzed with port scanning. For other types of applications, other tools may be used.

Based on the result of the review, the attack surface should be reduced as much as possible.

Release​

It is the responsibility of the release owner to plan and follow up on the security activities for a release. How-to Initiate a Project includes cyber security activities during the first stages of a project.

Release notes​

The release notes shall include information about corrected cyber security issues. The release notes shall also explain the security risk if the customer does not upgrade.

According to the 'SUM-2' requirement of IEC 62443, the following information should be provided to the user when releasing security updates.

  • The product version number(s) to which the security patch applies.
  • Instructions on how to apply approved patches manually and via an automated process.
  • Description of any impacts that applying the patch to the product, including reboot.
  • Instructions on how to verify that an approved patch has been applied.
  • Risks of not applying the patch and mediations that can be used for patches that are not approved or deployed by the asset owner.

End-user documentation​

The user documentation shall provide the necessary information for the customer to ensure that the site is as secure as possible. It must include the additional actions the end user needs to take to build a system or industrial plant with a defense in depth approach. The guide Cyber Security in User Documentation with the requirements from the ABB Cyber Security Standards can be used as a checklist during the planning and review of user documentation.

L4 and Maintenance​

Vulnerability handling​

A cyber security weakness in a released system or product is handled as a vulnerability. The vulnerability shall be submitted as a ‘cyber security’ tagged defect and the severity of the defect, calculated by using common vulnerability scoring system (CVSS), shall be documented in the defect.

Examples of vulnerability sources:

  • External party (e.g., by a customer, researcher, or government organization) claiming they have found a vulnerability in an ABB solution
  • A vulnerability that potentially impacts the installed base is found internally in ABB
  • Malware targeting ABB solutions

The vulnerabilities mentioned above shall be handled according to the Software Vulnerability Handling Procedures described in How-To Handle Software Vulnerabilities in addition to the ordinary defect handling process. The process includes response, investigation, and field communication by use of Security Advisories for security vulnerabilities.

Field communication​

Vulnerabilities impacting customers must be communicated using security advisories, which includes workarounds, patches, and other security-related information.
If the vulnerability is in a 3rd-party product, or in the environment where the ABB product operates or has a dependency on, a cyber security notification may be created.
The document 3BUL980146 Writing and Publishing Field Communication contains more information about these two artifacts.

Configuration Management​

Secure development environment​

The development environment used by engineers to develop products and solutions must be secure. The security risks in the development environment must be understood, and controls applied where appropriate to verify legitimate use.

A secure development environment should:

  • Protect from stealing information (e.g., encryption and access keys, passwords, code, documents, or intellectual property).
  • Prevent embedding malicious code in components, products, or systems, see Anti-malware Multi-scanning Tool.
  • Prevent using compromised development devices as a proxy for attacking the development environment.

Tools can be managed by IS/IT (GBS) with a delegated responsibility to application owners to manage access rights. The application owner is responsible to keep the list of users and access rights updated for his organization, see 9AKB2020-001714, IS Application Management. The development environment (servers, network, tools, etc.) is mainly managed by ABB's IS/IT department. They are responsible to ensure the development environment is secure. Several policies provided by IS/IT must be followed to ensure a secure development environment.

All assets managed by the local business unit (Distinct IT assets), i.e. hardware (physical or virtual) and software used on such devices, also need to fulfill the security policies regarding Asset Management, Vulnerability Management, Backup & Recovery, Anti-malware management, User Access Management, Network Connectivity, Hardening , Software Licensing & Maintenance, and Logging & Monitoring as described in PAIS-BR-01, Distinct IT Asset Management.
A standard, 3BPA000154 Distinct Compute - Reference Design, for distinct IT environments covering Engineering, LABs, Projects, R&D and Software Build has been developed as a help for local teams to build and document the distinct IT environment and gather evidence that the environment is properly secured.

More information about the IS/IT security policies can be found in the following places:

Bug management​

Security-related defects found and corrected in the development are handled as any other defect, but defects in releases must be handled as vulnerabilities. It must be possible to monitor the status of security defects separately from other defects.
The standard bug template has fields related to security that will determine if the bug is a security bug and provide a classification of the bug. The security-related defects are classified using CVSS. Security Effect Values and Definitions are described in Bug Classification. The section Security bugs below provides advice and references related to how to handle security bugs based on when and where they are found.

3rd-Party and OSS​

Types​

3rd-party software includes commercial software, OSS component, and OSS code snippet. These are diveded into three types:

  • Type – ‘A’ - Any 3rd-party software that is included in the build or installation package (e.g.: 3rd-party Libraries, embedded OS, etc)
  • Type – ‘B’ - Any 3rd-party software that the Product depends on or that is typically used in its deployment without being an integrated part of the ABB Product (e.g.: MS Windows, MS Office, Acrobat Reader, etc)
  • Internal Use – Development and test tools are used only internally. This includes 3rd-party software used during the development and testing of the products (Eg: Compilers, Linkers, Unit test FW, etc)

ABB´s SDLC standard no longer uses these type names, but within PAPCP we still do.

Qualification of 3rd-party software​

If new 3rd-party software is needed in a product, the release owner or cyber security engineer must make a request for introducing a new 3rd-party software according to the document 2PAA121395: 3rd Party Software Qualification Process Description
Ensure that the export control codes are properly documented, e.g., based on the potential use of cryptography.

Commercial suppliers of 3rd-party software need to fulfill ABB Cyber Security Requirements for Suppliers
The document 9AKK106930A4408 Minimum Cyber Security Requirements for Product Procurement describes the obligations for an R&D team that decides to use 3rd party SW from a commercial supplier.
Also see the info pages about Minimum Cyber Security Requirements for Product Procurement and ABB Cyber Security Requirements for Suppliers .

Security update handling​

Monitoring the security updates and lifecycle is a continuous activity before and after the release, for both active and classic versions.
Work together with the supplier to ensure there aren't any vulnerabilities in the 3rd-party software.

Each product must have a strategy defined for the handling of 3rd-party software. In case of vulnerabilities or components reaching end-of-life, 3rd-party software must be updated, and patches sent to the customers. The following two guides describe How-to Handle End-of-Life Software and How-to Handle Vulnerabilities in 3rd-Party Software. Also see the document 2PAA121397 3rd Party Software Lifecycle Handling Process Description..
The tool Dependency Track shall be used for all released products for vulnerability monitoring of 3rd party SW components. Information about how to use the tool can be found on this page .

Additional SDLC practices​

The above sections describes SDLC practices that are integrated in the different PCP R&D process areas. This section describe SDLC practices that are not integrated in any specific process area.

Security training​

ABB has several interactive cyber security training courses available through https://mylearning.abb.com/ .

Training for the different roles shall follow the Cyber Security Course Path, which includes both mandatory and optional courses.

The product team can get the training concerning pre-DSAC and the tools from the ABB DSAC core team.

Each R&D project shall plan for the cyber security training needed (in addition to the mandatory process training) and document it in a suitable project plan document. Line management is responsible for planning cyber security training for the different R&D roles, for new employees, and consultants and are also responsible for keeping training logs of performed security training.

Continuous improvement of the SDLC​

Continuous improvements to the development processes are done based on lessons learned, collected at the end of a release, program increment (PI) retrospectives or periodic reviews.
During the root cause analysis of specific bugs, improvements of the processes are also considered. Root cause analysis for a security bug, is done when needed according to How-To Handle Software Vulnerabilities and as a part of the PI retrospective.

During a periodic review the focus should be to check whether some patterns can be identified in the defects reviewed for that period. Key words/concepts that may suggest that a deeper analysis is needed are "many bugs" or "re-assessment of previous issues". If many bugs with a certain pattern are found a root cause analysis could provide the information needed to improve the process. Changes to the security landscape may also require changes to the security processes.

Improvements to the process may be needed if:

  • Many (more than usual) security bugs are found.
  • Specific patterns can be seen (see below).
  • Recurring (already addressed) security issues are encountered.
  • Bugs are found late in the development process, (could they have been found earlier?)
  • Bugs are reported by a customer, (were these known bugs that were deferred?).
  • Security issues with multiple possible causes or factors which impacted several areas or processes other than security are experienced.
  • A security bug that required more effort than normal or a deeper investigation to be fixed is found, (did it delay our commitments?).
  • The cyber security landscape (external and/or internal) has changed (e.g. new technologies such as tools, programming language, new security context for our offerings, emerging cyber security threats, or new marketing or regulatory requirements).
  • A new type of product is developed, or a new type of technology is used.

Patterns could be:

  • Many security bugs related to flooding.
  • Many security bugs in product X or version Y.
  • Many security bugs discovered in STT.

Security bugs​

Bugs related to security can be found during development or in a released product. The bug can reside in code developed by ABB or in 3rd-party software and it can be reported from within the organization or from outside.
How to handle a security bug differs slightly depending on when and where it is found. The sections below provide more advice and references for these aspects of how to handle security bugs.
The section Bug management under "Configuration management" above describes how to handle security aspects of all bugs.

Vulnerabilities​

A software vulnerability is a weakness that enables a way of realizing a threat. For more information about different types of software vulnerabilities and the associated threats see Software Vulnerabilities and Threats. Below are the links to a workshop and a PowerPoint about vulnerabilities for those who want more information.
Vulnerability Management Workshop-20230323_090449-Meeting Recording.mp4
Vulnerability handling in PAPCP.pptx

The workshop covers

  • Different aspects of vulnerabilities such as characteristics, how to rate the vulnerability and how to record it as a bug in ADO.
  • Discussions about how to find vulnerabilities, and tools that can be used.
  • An introduction to the Product security incident response team (PSIRT) and their activities.
  • Information about field communications; when and how to write them.
  • Information about the vulnerability handling process and process descriptions.

DSAC bugs​

Bugs reported by DSAC are noted in a test report and should be transferred to a product bug in ADO and the severity adjusted. All issues reported as "high-severity" by DSAC should be corrected before the release whereas medium severity issues need to be fixed in the immediate next release. For more information about bugs found by DSAC see Security Testing Guideline.

Bugs in released products​

If a bug affects a released product it shall be handled according to How-To Handle Software Vulnerabilities.

Bugs in 3rd-party components​

3rd-party components should be monitored for bugs either via Black Duck or manually. A vulnerability in a 3rd-party component shall be tracked as a bug. An out of date 3rd-party component shall also be tracked as a bug. For more information about how to handle these bugs see How-to Handle Vulnerabilities in 3rd-Party Software and How-to Handle End-of-Life Software.

ABB Cyber Security Standards​

All ABB products that include software and all suppliers of commercial software to ABB, must fulfill the mandatory security requirements described in the ABB Cyber Security Standards.


From the main page for the ABB Cyber Security Standards, you can find more information about the standards as well as links to e-learning about them.

Cyber security assessment​

Applicability​

Cyber security assessments are required for all projects. 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). The latest version of the cyber security assessment tool templates, in Templafy shall be used. Hardware products vary a lot, some contain firmware and others have no firmware or communication capabilities at all, which means that only a selection of the requirements are applicable depending on the product.
If the ADO collection has a work item of the type "Security", the security requirements from the assessment tools can be imported to ADO for planning purposes and for the assessment to be performed on the work items.
For minor releases, e.g. rollups, TCs and CCs, you may use a light weight 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 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.

Below is a list of the tools that are available as templates in Templafy:

  • PAPCP Security Development Life Cycle Assessment Tool - for ABB Security Development Life Cycle Standard
  • PAPCP Product Security Assessment Tool - for ABB Product Security Standard
  • PAPCP Cloud Security Assessment Tool - for Cloud Offerings and Cloud Operations
  • PAPCP Light Weight Security Assessment Checklist

When using the security assesssment tools you ensure the compliance with the IEC 62443-4 standards. For more details about Cyber Security Assessments, see the guides Cyber Security Assessment and How-to Use the CSR Importer Tool.

Purpose​

The purpose of the security assessment is to analyze the product design from a security perspective and to find security weaknesses at an early stage. It will help identify any new security requirements needed for the release and will ensure that the product fulfills the defined security requirements including the ABB Cyber Security Standards.

For small changes, TCs, CCs, and service pack releases where no requirement or design changes are done) the security documentation of the base product version is judged to be valid. If the release concerns a security defect, the necessary documentation, and verification shall be handled by the impact analysis of the defect.

A first pass of the security assessment is performed before M2/G2 to identify any new security requirements needed for the release or any open security related issues to be handled, such as medium severity issues reported by DSAC in the previous release that were deferred. After this pass the assessment form may indicate gaps, i.e. it may contain rows with requirements that have been marked as applicable, but that are not yet fulfilled.

It is recommended to update the assessment when new information is available in input documents and to synchronize with the business unit head of cyber security that the activities to close the identified gaps are progressing as expected.

Before the product release (M5/G5) one more assessment pass shall be done to check that the project has closed the previously identified gaps.

Responsibilities​

The security assessment is typically filled out by the cyber security engineer, with the involvement and contribution of other members of the development team, particularly the architect, developer, and product owner. The assessment is reviewed and approved by the business unit head of cyber security, or a person appointed by him.

Exceptions​

The ABB Cyber Security Standards must be fulfilled, but there may be product specific reasons why a requirement cannot be met. In this case, the R&D project needs to request an exception. An exception must also be requested if DSAC has found high severity issues that cannot be corrected before release.

The exception request is typically written by the release owner with the assistance of the head of cyber security using the Cyber Security Exception Request Template. The request is granted or denied by the ABB Group Cyber Security Council (GCSC). Note that a well-prepared exception request takes about two weeks to review and decide upon.

There are also default exceptions for which there is no need to request an exception. Such default exception shall be referred to from the security assessment. For example, if an ABB product supports PROFIBUS for communicating with a 3rd-party PROFIBUS device, the requirement on secure protocols is excepted by default since standard PROFIBUS does not exist in a secure variant. Below is a list of documents describing the exceptions for the different standards:

Assessment of suppliers​

All suppliers of commercial software shall comply with the requirements described in the document 9AKK106930A4400 ABB Cyber Security Requirements for Supplier.
Potential suppliers confirm their compliance in SAP Ariba. When the supplier is created in Decision Focus (DFN), cyber security-related checkpoints are part of the supplier registration.

In the case of critical software, the product owner can request that a detailed checklist for the Cyber Security Requirements should be filled out by the supplier, reseller, or redistributor. This assessment is performed via a questionnaire sent to the customer and reviewed by the cyber security engineer.

The following document describe the qualification process 2PAA12395 3rd Party Software Qualification Process Description and this guide How to Create Supplier in DFN

Malware scanning​

The release media must be scanned to detect malware using MetaDefender or another solution using at least three different anti-malware tools. Any findings must be handled as described in the guide How-to Handle Suspected Malware in ABB Software.
If the scanning did not detect any malware, the report containing information about the scanned items and the result shall be archived and used as evidence.
See the Multiscan Meta Defender User Guide for more information about the tool.

Storing and archiving cyber security artifacts​

Some artifacts are directly related to cyber security, e.g. cyber security assessment reports, threat model, criticality analysis, and attack surface analysis. The cyber security assessment is specific for a certain project, while the other are product-related. The documents must be safely stored and archived in the OnePCP DMS in a location together with other project and product documents.

Artifacts​

Artifact​Description​RACIReceiver​Comments
Security Assessment ReportAn assessment of the product from a security perspective to initially identify activities to plan for, and later to serve as evidence for the fulfillment of the security requirements.(R): Cyber Security Engineer
(A): Head of Cyber Security
(C): Head of Cyber Security
(I): 3rd party SW engineer, Architect, Development Team, Product Owner, Release Owner, Stream Owner		Release-
Light Weight Security Assessment ChecklistA checklist for minor projects to evaluate if the assessment of the previous release is still valid and can be referred to. It also checks some mandatory activities.(R): Cyber Security Engineer
(A): Head of Cyber Security
(C): Head of Cyber Security
(I): 3rd party SW engineer, Architect, Development Team, Product Owner, Release Owner, Stream Owner		Release-
EpicEpics for security could include certification requirements, security level or other specific security requirements.See Requirements process-Responsibility of Requirements
Product/Stream ArchitectureThe architecture should include the cyber security perspective.See Architecture process-Responsibility of Architecture
Security ContextThe security expected to be provided by the environment for a product or component.See Architecture process-Responsibility of Architecture
Threat ModelA model to identify potential threats, document vulnerabilities, and suggest mitigations.See Architecture process-Responsibility of Architecture
Criticality AnalysisCriticality rating of the components in a product according to their need of extra attention when minimizing the risk for vulnerabilities.See Architecture process-Responsibility of Architecture
Attack Surface AnalysisThe set of entry points that hackers can potentially use to attack the product.See Architecture process-Responsibility of Architecture
Quality PlanThe cyber security chapter of the quality plan lists specific information related to cyber security for the release.See Quality & KPIs process-Responsibility of Quality & KPIs

References​

PCP R&D Security​

ABB Instructions and Guidelines​

ABB Security Information Sites​

Secure Coding Sites​

Other​

Owner: Cyber Security Team