Welcome · Secure Delivery Framework

Need a fully-managed, measurable programme of security capability improvement?

Product Security Levels

Overview coming soon.

Policy Viewer

Resource Objectives (1)

To make security requirements simpler to establish and more applicable to Product Teams’ own Products this framework requires the definition of Product Security Levels – a clear categorisation of Products by technology, type of data handled, and criticality to the Organisation.

This allows Product Teams to quickly determine where their Product sits within the risk management approach of the Organisation and have clear requirements for its implementation and operation.

These Product Security Levels consider, and are applicable to, the whole Product Delivery Organisation and require technical knowledge to define, so it is the responsibility of the Technology Community Of Practice.

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts
Capabilities
Document: Product Security Levels
Risk Type: Usability
Event: Over or under-investment in security
Caused By: Product Teams not having clear, measurable and effective security requirements for their Product
Leading To: Misdirected investment, opportunity cost or products of insufficient security quality
D-TA-A-2-1 Design > Threat Assessment > Application Risk Profile: Do you use centralized and quantified application risk profiles to evaluate business risk?

Group Objectives (12)

This objective, and the other similar ‘include‘ objectives, simply state what has to be in your Product Security Levels for the Product Delivery Organisation. You may want to include more, but you cannot be missing any of these and still run a secure Product Delivery Organisation.

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Recommended Product Components
Capabilities: Secure Product Design
Document: Recommended Product Components
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams utilising many different technologies in their Products unnecessarily
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
D-SA-B-2-1 Design > Security Architecture > Technology Management: Do you have a list of recommended technologies for the organization?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Minimum Application Requirements For Security
Capabilities: Secure Product Implementation
Document: Minimum Application Requirements For Security
Risk Type: Usability
Event: Over or under-investment in security
Caused By: Product Teams not having clear, measurable and effective security requirements for their Product
Leading To: Misdirected investment, opportunity cost or products of insufficient security quality
D-SR-A-2-1 Design > Security Requirements > Software Requirements: Do you define, structure, and include prioritization in the artifacts of the security requirements gathering process?
G-PC-B-2-1 Governance > Policy & Compliance > Compliance Management: Do you have a standard set of security requirements and verification procedures addressing the organization's external compliance obligations?
V-AA-A-2-1 Verification > Architecture Assessment > Architecture Validation: Do you regularly review the security mechanisms of your architecture?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Data Processing Obligations
Capabilities: Risk Management
Document: Objectives For Data Processing Obligations
Risk Type: Viability
Event: An investigation into negligence
Caused By: Product Teams inconsistently handling Product Data in ways that may not meet internal and external compliance requirements
Leading To: A substantial fine and/or sanction from an external regulatory body
O-OM-A-2-1 Operations > Operational Management > Data Protection: Do you maintain a data catalog, including types, sensitivity levels, and processing and storage locations?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Dependency Management
Capabilities: Secure Product Implementation
Document: Objectives For Dependency Management
Risk Type: Viability
Event: The Impact of a Security Incident is increased
Caused By: Product Delivery Organisation unable to effectively respond and resolve security incidents
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
I-SB-B-2-1 Implementation > Secure Build > Software Dependencies: Do you handle 3rd party dependency risk by a formal process?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Exploratory Security Testing
Capabilities: Quality Control
Document: Objectives For Exploratory Security Testing
Risk Type: Feasibility
Event: A security vulnerability is identified by somebody outside of the Organisation
Caused By: Product Teams not identifying and remediating discoverable product insecurities as part of delivery
Leading To: Increased cost for remediation, impact on delivery or increased risk of a Security Incident
V-ST-B-2-1 Verification > Security Testing > Deep Understanding: Do you perform penetration testing for your applications at regular intervals?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Product Component Management
Capabilities: Secure Product Design
Document: Objectives For Product Component Management
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams operating Product Components with known vulnerabilities
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
O-EM-B-2-1 Operations > Environment Management > Patching and Updating: Do you follow an established process for updating components of your technology stacks?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Product Secrets Management
Capabilities: Secure Build And Deploy
Document: Objectives For Product Secrets Management
Risk Type: Viability
Event: The Impact of a Security Incident is increased
Caused By: Product Teams inconsistently managing Product Secrets
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
I-SD-B-2-1 Implementation > Secure Deployment > Secret Management: Do you inject production secrets into configuration files during deployment?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Security Defect Management
Capabilities: Quality Control
Document: Objectives For Security Defect Management
Risk Type: Feasibility
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams inconsistently managing Security Defects
Leading To: Increased cost for remediation, impact on delivery or increased risk of a Security Incident
I-DM-A-2-1 Implementation > Defect Management > Defect Tracking: Do you keep an overview of the state of security defects across the organization?
I-SB-A-2-1 Implementation > Secure Build > Build Process: Is the build process fully automated?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Security Component Testing
Capabilities: Quality Control
Document: Objectives For Security Component Testing
Risk Type: Feasibility
Event: A security vulnerability is identified by somebody outside of the Organisation
Caused By: Product Teams not identifying and remediating discoverable product insecurities as part of delivery
Leading To: Increased cost for remediation, impact on delivery or increased risk of a Security Incident
I-SD-A-2-1 Implementation > Secure Deployment > Deployment Process: Are deployment processes automated and employing security checks?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Recommended Shared Security Services
Capabilities: Secure Product Design
Document: Recommended Shared Security Services
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams not using Shared Security Services that are applicable to their Product
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
D-SA-A-3-1 Design > Security Architecture > Architecture Design: Do you base your design on available reference architectures?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Product Artifact Integrity
Capabilities: Secure Build And Deploy
Document: Objectives For Product Artifact Integrity
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams deploying unknown or incorrect versions of Product Artifacts
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
I-SD-A-3-1 Implementation > Secure Deployment > Deployment Process: Do you consistently validate the integrity of deployed artifacts?

Group or Individual: Technology Community Of Practice
Artefact: Product Security Levels
Concepts: Product Data Integrity
Capabilities: Secure Product Implementation
Document: Objectives For Product Data Integrity
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams deploying unknown or compromised of Product Data
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
O-OM-A-1-1 Operations > Operational Management > Data Protection: Do you protect and handle information according to protection requirements for data stored and processed on each application?

Accountability Objectives (5)

Policy objectives that use the verb ‘Ensure‘ assign accountability to a person. This is an accountability objective. While Product Leads are accountable for all the responsibilities of a Product Team, some accountabilities are called out specifically for clarity.

It’s not scalable or effective for a Product Delivery Organisation to have a central team or person chasing dozens or even hundreds of Product Teams to ensure their Products meet the security requirements of the Organisation.

A Product Team being unable to build and operate its Product in a way that meets the requirements of the Product’s Security Level, for reasons that are communicated to, and accepted by, the Product Delivery Organisation is handled by this framework and results in either:

The Product Security Levels being improved to meet the specific needs of more Products or,
Documented Risks being updated to capture and manage the deviation from Product Security Levels

Group or Individual: Product Lead
Artefact: Product Security Levels
Concepts: Data Processing Obligations, Dependency Management, Exploratory Security Testing, Minimum Application Requirements For Security, Product Artifact Integrity, Product Component Management, Product Data Integrity, Product Secrets Management, Recommended Product Components, Recommended Shared Security Services, Security Component Testing, Security Defect Management
Capabilities: Quality Control
Risk Management
Secure Build And Deploy
Secure Product Design
Secure Product Implementation
Document
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams not meeting the security objectives for their Product expected by the Product Delivery Organisation
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
D-TA-A-2-1 Design > Threat Assessment > Application Risk Profile: Do you use centralized and quantified application risk profiles to evaluate business risk?
G-PC-B-2-1 Governance > Policy & Compliance > Compliance Management: Do you have a standard set of security requirements and verification procedures addressing the organization's external compliance obligations?
G-SM-B-2-1 Governance > Strategy & Metrics > Measure and Improve: Did you define Key Perfomance Indicators (KPI) from available application security metrics?
I-DM-A-2-1 Implementation > Defect Management > Defect Tracking: Do you keep an overview of the state of security defects across the organization?
I-SB-A-2-1 Implementation > Secure Build > Build Process: Is the build process fully automated?
I-SB-B-2-1 Implementation > Secure Build > Software Dependencies: Do you handle 3rd party dependency risk by a formal process?
I-SD-A-2-1 Implementation > Secure Deployment > Deployment Process: Are deployment processes automated and employing security checks?
I-SD-A-3-1 Implementation > Secure Deployment > Deployment Process: Do you consistently validate the integrity of deployed artifacts?
I-SD-B-2-1 Implementation > Secure Deployment > Secret Management: Do you inject production secrets into configuration files during deployment?
I-SD-B-3-1 Implementation > Secure Deployment > Secret Management: Do you practice proper lifecycle management for application secrets?
O-EM-B-2-1 Operations > Environment Management > Patching and Updating: Do you follow an established process for updating components of your technology stacks?
O-OM-A-2-1 Operations > Operational Management > Data Protection: Do you maintain a data catalog, including types, sensitivity levels, and processing and storage locations?
V-RT-A-2-1 Verification > Requirements-driven Testing > Control Verification: Do you consistently write and execute test scripts to verify the functionality of security requirements?
V-ST-B-2-1 Verification > Security Testing > Deep Understanding: Do you perform penetration testing for your applications at regular intervals?

If Product Security Levels and the guidance for them is not clear and understandable for a Product Team then that is a problem the Technology Community Of Practice must address.

It does not mean that the requirements of a Product’s security level can be ignored by the Product Team. This prevents continuous security improvement by the Product Delivery Organisation.

Group or Individual: Product Lead
Artefact: Product Security Levels
Concepts: Data Processing Obligations, Dependency Management, Exploratory Security Testing, Minimum Application Requirements For Security, Product Artifact Integrity, Product Component Management, Product Data Integrity, Product Secrets Management, Recommended Product Components, Recommended Shared Security Services, Security Component Testing, Security Defect Management
Capabilities: Quality Control
Risk Management
Secure Build And Deploy
Secure Product Design
Secure Product Implementation
Document
Risk Type: Viability
Event: An investigation into negligence
Caused By: Product Teams being unable to understand the Minimum Application Requirements For Security for their Product
Leading To: A substantial fine and/or sanction from an external regulatory body
D-SR-A-2-1 Design > Security Requirements > Software Requirements: Do you define, structure, and include prioritization in the artifacts of the security requirements gathering process?

Products change constantly. New features are developed and the overall design of the Product will evolve over time. Manually testing for the continued presence of all the required Minimum Application Requirements For Security as the Product is developed is time-consuming and simply won’t be done frequently enough, if at all.

To consistently ensure that every release of the Product meets its Minimum Application Requirements For Security the Product Team must implement automated testing for the implementation of these requirements. The Product Lead is accountable for this automated testing being created and maintained.

Group or Individual: Product Lead
Artefact: Product Security Levels
Concepts: Minimum Application Requirements For Security
Capabilities: Secure Product Implementation
Document
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams not implementing the Minimum Application Requirements For Security in their Products
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
V-RT-A-3-1 Verification > Requirements-driven Testing > Control Verification: Do you automatically test applications for security regressions?

The requirements of Product Security Levels can be exceeded but they must never be left unmet by a release of a Product. If measurements from testing a Product release during the Product Build Process show that the new version of the Product will not meet the requirements of its Product Security Level then that release must never enter the Product Deployment Process.

The Product Lead is accountable for this happening.

Group or Individual: Product Lead
Artefact: Product Security Levels
Concepts: Data Processing Obligations, Dependency Management, Exploratory Security Testing, Minimum Application Requirements For Security, Product Artifact Integrity, Product Component Management, Product Data Integrity, Product Secrets Management, Recommended Product Components, Recommended Shared Security Services, Security Component Testing, Security Defect Management
Capabilities: Quality Control
Risk Management
Secure Build And Deploy
Secure Product Design
Secure Product Implementation
Document
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams not meeting the security objectives for their Product expected by the Product Delivery Organisation
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
I-SB-A-3-1 Implementation > Secure Build > Build Process: Do you enforce automated security checks in your build processes?
I-SB-B-3-1 Implementation > Secure Build > Software Dependencies: Do you prevent build of software if it's affected by vulnerabilities in dependencies?

The requirements of Product Security Levels can be exceeded but they must never be left unmet by a release of a Product. If measurements from testing a Product release during the Product Deployment Process show that the new version of the Product will not meet the requirements of its Product Security Level then that release must never reach customers.

The Product Lead is accountable for this happening.

Group or Individual: Product Lead
Artefact: Product Security Levels
Concepts: Data Processing Obligations, Dependency Management, Exploratory Security Testing, Minimum Application Requirements For Security, Product Artifact Integrity, Product Component Management, Product Data Integrity, Product Secrets Management, Recommended Product Components, Recommended Shared Security Services, Security Component Testing, Security Defect Management
Capabilities: Quality Control
Risk Management
Secure Build And Deploy
Secure Product Design
Secure Product Implementation
Document
Risk Type: Viability
Event: The Likelihood of a Security Incident is increased
Caused By: Product Teams not meeting the security objectives for their Product expected by the Product Delivery Organisation
Leading To: Loss of customers, financial fraud losses, increased TCO, substantial fines/sanctions from an external regulatory body
I-SD-A-3-1 Implementation > Secure Deployment > Deployment Process: Do you consistently validate the integrity of deployed artifacts?

Product Security Levels

Policy Viewer

Resource Objectives (1)

Technology Community Of Practice MUST maintain a set of Product Security Levels

Group Objectives (12)

Technology Community Of Practice MUST include Recommended Product Components as part of Product Security Levels

Technology Community Of Practice MUST include Minimum Application Requirements For Security as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Data Processing Obligations as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Dependency Management as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Exploratory Security Testing as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Product Component Management as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Product Secrets Management as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Security Defect Management as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Security Component Testing as part of Product Security Levels

Technology Community Of Practice MUST include Recommended Shared Security Services as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Product Artifact Integrity as part of Product Security Levels

Technology Community Of Practice MUST include Objectives For Product Data Integrity as part of Product Security Levels

Accountability Objectives (5)

Product Lead MUST ensure Product Security Levels are met

Product Lead MUST ensure Technology Community Of Practice is consulted when Product Security Levels are unclear

Product Lead MUST ensure Minimum Application Requirements For Security are automatically verified

Product Lead MUST ensure Product Build Process halts if Product Quality Metrics show that Product Security Levels can not be met

Product Lead MUST ensure Product Deployment Process halts if Product Quality Metrics show that Product Security Levels can not be met