Welcome · Secure Delivery Framework

Product Security Insights

TL;DR

Product Security Insights are a collection of knowledge about how your organisation delivers secure Products and the measures that show secure products are being delivered.

Expand the policy objectives on the right for more information on who maintains Product Security Insights and what they must contain.

Context

The Secure Delivery Framework specifies who is accountable and responsible for security at all levels. To be accountable or responsible for something, you must meet four requirements:

Understand what you’re accountable or responsible for
Have information that shows what you’re accountable or responsible for is being satisfactorily done
Have time in your working day to do what you’re responsible for or ensure what you’re accountable for is being done
If you’re accountable for ensuring something is being done, you must have decision-making oversight of the group responsible for doing it

The Technology Community Of Practice is required to maintain Product Security Insights. This collection of knowledge includes what has to be done by Product Teams and the Product Delivery Organisation to deliver secure products and the measures that show secure products are being delivered. This is how the framework ensures that requirements 1 and 2 are met.

The Details

To provide Product Security Insights for the entire organisation, you can use a combination of a wiki-style knowledge base and a dashboarding tool. This tool must enable you to collect and collate metrics from multiple sources into a unified, aggregated view at the required levels.

Alternatively, the Secure Delivery Platform provides the necessary Product Security Insights functionality as part of its comprehensive platform for securing your Product Delivery Organisation.

This framework requires that Product Security Insights include measurements of Agreed Ways of Working (how we build secure Products) and measurements of Product Security Levels (what our Products need to be secure).For more details on what they contain, see their respective pages in the Policy Viewer.

Each Product Team’s way of working and their Product’s security level requirements have measurable outputs that must be included in Product Security Insights. Doing so ensures that every responsible group and accountable decision-maker can fulfill their roles effectively.

Policy Viewer

Resource Objectives (1)

The Technology Community Of Practice’s role in this framework is to improve understanding and the decision-making information available across the Product Delivery Organisation. To do this it must maintain a Product Security Insights that is the source of both documented information and current measures of Product and Product Team security for the whole Product Delivery Organisation.

This policy does not specify what the Product Security Insights consists of, just what it must contain. It could be an in-house developed platform, a combination of a wiki-style documentation store and dashboarding tool, or even all held within a team chat platform.

Group or Individual: Technology Community Of Practice
Artefact: Product Security Insights
Concepts
Capabilities
Document: Product Security Insights
Risk Type: Viability
Event: An investigation into negligence
Caused By: Product Delivery Organisation being unaware of or not understanding how to manage security
Leading To: A substantial fine and/or sanction from an external regulatory body
G-EG-B-2-1 Governance > Education & Guidance > Organization and Culture: Does the organization have a Secure Software Center of Excellence (SSCE)?

Group Objectives (2)

Product Teams need clearly displayed indicators that show they’re correctly following Agreed Ways Of Working and the Product Delivery Organisation needs to see where Product Teams might be having difficulty with following Agreed Ways Of Working.

The Technology Community Of Practice has a scope of responsibility broad enough to provide these indicators. This is an essential service in the Secure Delivery Framework to keep the Alignment Gap (the difference between how you think people are working and how they’re actually working) to a minimum and hence the risk to the Organisation to a minimum.

Group or Individual: Technology Community Of Practice
Artefact: Product Security Insights
Concepts: Agile Threat Modelling, Business Impact Assessment, Continuous Security Improvement, Incident Detection, Incident Response, Product Data Classification, Product Decommissioning, Product Delivery Metrics, Product Quality Metrics, Product Secrets Management, Product Support Model, Secure Product Design, Security Component Testing, Security Defect Management, Third-Party Product Components, Third-Party Software Development Services, Third-Party Software-as-a-Service, Threat Intelligence
Capabilities: Incident Management
Operational Visibility
Quality Control
Risk Management
Secure Build And Deploy
Secure Product Design
Secure Product Management
Document: Measurements Of Agreed Ways Of Working
Risk Type: Value
Event: Product Delivery is slowed down or halted
Caused By: Product Delivery Organisation imposing unachievable, inefficient or unsustainable Agreed Ways Of Working on Product Teams
Leading To: Loss of customers, increased TCO, increased employee churn
D-SA-A-3-1 Design > Security Architecture > Architecture Design: Do you base your design on available reference architectures?
D-SA-B-2-1 Design > Security Architecture > Technology Management: Do you have a list of recommended technologies for the organization?
D-TA-B-2-1 Design > Threat Assessment > Threat Modeling: Do you use a standard methodology, aligned on your application risk levels?
G-PC-A-3-1 Governance > Policy & Compliance > Policy & Standards: Do you regularly report on policy and standard compliance, and use that information to guide compliance improvement efforts?
O-IM-A-2-1 Operations > Incident Management > Incident Detection: Do you follow a documented process for incident detection?
O-IM-B-2-1 Operations > Incident Management > Incident Response: Do you use a repeatable process for incident handling?
O-OM-B-2-1 Operations > Operational Management > System Decomissioning / Legacy Management: Do you follow an established process for removing all associated resources, as part of decommissioning of unused systems, applications, application dependencies, or services?
V-AA-B-2-1 Verification > Architecture Assessment > Architecture Mitigation: Do you regularly evaluate the threats to your architecture?
V-RT-B-3-1 Verification > Requirements-driven Testing > Misuse/Abuse Testing: Do you perform denial of service and security stress testing?
V-ST-A-3-1 Verification > Security Testing > Scalable Baseline: Do you integrate automated security testing into the build and deploy process?

Product Teams need clearly displayed indicators that show their Product is meeting the requirements of its Product Security Level and the Product Delivery Organisation needs to see where Product Teams might be having difficulty with meeting those requirements.

The Technology Community Of Practice has a scope of responsibility broad enough to provide these indicators. Making security quality for Products visible allows for more informed decision-making across the whole Product Delivery Organisation.

Group or Individual: Technology Community Of Practice
Artefact: Product Security Insights
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: Measurements Of 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?
G-EG-B-3-1 Governance > Education & Guidance > Organization and Culture: Is there a centralized portal where developers and application security professionals from different teams and business units are able to communicate and share information?
G-PC-B-3-1 Governance > Policy & Compliance > Compliance Management: Do you regularly report on adherence to external compliance obligations and use that information to guide efforts to close compliance gaps?
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-DM-B-2-1 Implementation > Defect Management > Metrics and Feedback: Do you improve your security assurance program upon standardized metrics?
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?
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?
O-OM-A-3-1 Operations > Operational Management > Data Protection: Do you regularly review and update the data catalog and your data protection policies and procedures?
V-AA-A-3-1 Verification > Architecture Assessment > Architecture Validation: Do you regularly review the effectiveness of the security controls?
V-ST-B-2-1 Verification > Security Testing > Deep Understanding: Do you perform penetration testing for your applications at regular intervals?

Prod​uct Security Insights