# PKI Approval Process
# Request Process for a Production Environment
TIP
For development purposes, developers may choose to use one of the pre provisioned environments with a fixed enrollment code.
To start the PKI approval process for a production environment, the requestor must send a support request to the Ability PKI Support team. Ideally, this pre-approval process should be initiated when the devices/edge are ordered for production at the factory.
# Details to be shared with the Ability PKI Support team
- Product name or Ability environment (if for the Ability Platform itself)
- A brief description of the use cases/purpose
- Does the product fulfill the MCSR for internet-facing products or if it has an approved exception
- Product manager (if not the requestor)
- Business line and/or product group owning the product
- Manufacturing quantity
- Expected manufacturing start and end dates
- Manufacturing location (factory external/internal)
- Name and email of the manufacturer contact person
- Any additional comments
This process is only to verify, approve and register the chosen point of contact from a specific business line or a product group. Once the user is approved by the business line Security Contact and the Ability Security Leads, the user is then added as an approved requester for a given business line. This is a one-time process per user per BU and not required everytime when the same user requests for Creation of the PKI Profile or while sending PKI enrollment codes.
WARNING
Along with the Approval request, optionally the business line user can request for the PKI profile creation by supplying the requested info. To understand the overall flow of enrollment code approval, refer this page.
# Checks and Approval
For production environments, the PKI Administration team does the following checks before the team creates the production PKI profile for a business line.
| ID | Check | Objective |
|---|---|---|
| 1 | Product Entitlement | Ensure that the product is entitled to enroll in the Ability PKI. Entitlement depends on adherence to the MCSR for Internet-Facing Products, or if an approved exception is in place. |
| 2 | Product Feature Support | Ensure that the product supports an enrollment and renewal protocol as used by Ability PKI. Ensure that the product supports the cryptographic protocols used by the Ability Platform. Ensure that the product uses a Device ID as defined by the Ability Platform. |
| 3 | Requestor is a legitimate representative for the requesting product organization | Ensure that only legitimate users file requests. |
| 4 | Organization details | Ensure that the organizational, product and certificate details are correct. |
| 5 | Correct decision makers | Ensure that the decision is made by an authorized person. |
Checks (1) through (4) are performed by the organization's primary cybersecurity person. For details, see the table below.
Check (5) is performed by the respective member of the GCSC drafted from the group of the Division Cyber Security Head, Head of Cyber Security Digital ABB, Group Head of Cyber Security and Chief Information Security Officer.
The decision makers depend on the requesting product use case. The four-eyes principle applies. If the primary and GCSC decision makers are the same person, then another appropriate member of the GCSC must be assigned.
| Case | Primary decision maker | GCSC decision maker |
|---|---|---|
| default | "closest" GCSC member | group head of cyber security |
| certificate for BL product | BL cyber security manager | division cybersecurity head |
| certificate for division product | division cybersecurity head | group head of cyber security |
| certificate for Digital ABB | head of cybersecurity, Digital ABB | group head of cyber security |
| certificate for GF-IS | head of special security projects | chief information security officer |
You can find the contacts of the BL cybersecurity managers and GCSC members here
# Certificate Renewal
Certificate renewal will be done automatically if the edge/device has implemented the supported enrollment and renewal protocol correctly. Note that in the event the certificate has expired, i.e. when the device is in stock for the lifetime of the certificate, the expired certificate will still be able to automatically renew. Only if the certificate is revoked will this not be possible, requiring manual action.
# Certificate Information
The certificate will always contain information regarding ABB and the owner organizational unit. The following information is included.
| Filed Name | Fixed/Optional/Mandatory | Value |
|---|---|---|
| Common Name (CN) | Mandatory | Device ID uniquely identifying the device in the Ability Platform. More information can be found on the information model pages |
| Organizational Unit (OU) | Optional | BL code (e.g. PG9964 for Ability) |
| Organization | Fixed | ABB Information Systems Ltd (no other values are permitted) |
| Country | Fixed | CH (added by default, even if not provided) |
| Locality | Fixed | Zurich (added by default ) |