Page Comparison

Governance

Strategy & Metrics

All

All

All

Not scope of this standard, task for IT security function.

Governance

Policy & Compliance

Stream A
Policy & Standards

1

Determine a security baseline representing organization’s policies and standards.

But you can use TSS-WEB as a basis to describe your organization-specific baseline.

Governance

Policy & Compliance

Stream A
Policy & Standards

2

Develop security requirements applicable to all applications.

TSS-WEB covers this for Web-based applications.

Governance

Policy & Compliance

Stream A
Policy & Standards

3

Measure and report on the status of individual application’s adherence to policies and standards.

Not scope of this standard, task for IT security function.

Governance

Policy & Compliance

Stream B
Compliance Management

1

Identify 3rd-party compliance drivers and requirements and map to existing policies and standards.

This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it.

Governance

Policy & Compliance

Stream B
Compliance Management

2

Publish compliance-specific application requirements and test guidance

This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it.

Governance

Education Policy & GuidanceCompliance

Stream A
Training and Awareness

1

Provide security awareness training for all personnel involved in software developmentB
Compliance Management

3

Measure and report on individual application’s compliance with 3rd party requirements.

See “General Requirements” at5. Security within Development Process

This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it.

Governance

Education & Guidance

Stream A
Training and Awareness

2

Offer technology and role-specific guidance, including security nuances of each language and platform1

Provide security awareness training for all personnel involved in software development

See “General Requirements” at5. Security within Development Process

Governance

Education & Guidance

Stream A
Training and Awareness

1

Identify a “Security Champion” within each development team.2

Offer technology and role-specific guidance, including security nuances of each language and platform

See “General Requirements” at5. Security within Development Process

Governance

Education & Guidance

Stream A
Training and Awareness

2

Develop a secure software center of excellence promoting thought leadership among developers and architects3

Standardized in-house guidance around the organization’s secure software development standards.

A basic assessment of the application risk is performed to understand likelihood and impact of an attack

Although establishing such a community is a task for a IT security function, participation at it is described as role duties for a “security champion” at 1.4 Roles

Design

Threat Assessment

Stream A
Application Risk Profile

1

This cannot be covered by TSS-WEB, since we don’t know your specific compliance drivers. But you can use TSS-WEB and integrate yours into it.

Governance

Education & Guidance

Stream A
Training and Awareness

1

Identify a “Security Champion” within each development team.

See “Assessment of all requirements and changes” “General Requirements” at5. Security within Development Process

Design

Threat Assessment Governance

Education & Guidance

Stream A
Application Risk Profile

2

Understand the risk for all applications in the organization by centralizing the risk profile inventory for stakeholdersTraining and Awareness

2

Develop a secure software center of excellence promoting thought leadership among developers and architects.

Perform best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists

Not covered since not scope of a standard but local risk management procedures in development are defined at 5. Security within Development Process

Design

Threat Assessment

Stream B
Threat Modeling

1

Although establishing such a community is a task for a IT security function, participation at it is described as role duties for a “security champion” at 1.4 Roles

Governance

Education & Guidance

Stream A
Training and Awareness

3

Build a secure software community including all organization people involved in software security.

Although establishing such a community is a task for a IT security function, participation at it is described as role duties for a “security champion” at 1.4 Roles

Design

Threat Assessment

Stream B
Threat Modeling

2

Standardize threat modeling training, processes, and tools to scale across the organizationA
Application Risk Profile

1

A basic assessment of the application risk is performed to understand likelihood and impact of an attack.

Security Requirements

Not in scope of TSS-WEB, should be described separately and linked into your own standard.

Design

See “Assessment of all requirements and changes” at 5. Security within Development Process

Design

Threat Assessment

Stream A
Software Requirements

1

High-level application security objectives are mapped to functional requirementsApplication Risk Profile

2

Understand the risk for all applications in the organization by centralizing the risk profile inventory for stakeholders.

Not covered since not scope of a standard but local risk management procedures in development are defined at 5. Security within Development Process

DesignSecurity Requirements

Threat Assessment

Stream A
Software Requirements

2

Structured security requirements are available and utilized by developer teamsApplication Risk Profile

3

Periodically review application risk profiles at regular intervals to ensure accuracy and reflect current state.

This is defined as a team responsible in 5. Security within Development Process

DesignSecurity Requirements

Threat Assessment

Stream B
Compliance ManagementThreat Modeling

1Evaluate

the supplier based on organizational security requirementsPerform best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists.

See 7. Supplier Requirements “Assessment of all requirements and changes” at5. Security within Development Process

DesignSecurity Requirements

Threat Assessment

Stream B
Compliance ManagementThreat Modeling

2Build security into supplier agreements in order to ensure compliance with organizational requirements

Standardize threat modeling training, processes, and tools to scale across the organization.

Not in scope of TSS-WEB, should be described separately and linked into your own standard.

DesignSecurity Architecture

Threat Assessment

Stream AB
Architecture DesignThreat Modeling

1

Teams are trained on the use of basic security principles during design3

Continuously optimization and automation of your threat modeling methodology.

Not in scope of TSS-WEB, should be described separately and linked into your own standard.

Design

Security ArchitectureRequirements

Stream A
Architecture DesignSoftware Requirements

2

Establish common design patterns and security solutions for adoption1

High-level application security objectives are mapped to functional requirements.

See https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/327729/8.1+General+Principles “General Requirements” at 5. Security within Development Process

Design

Security ArchitectureRequirements

Stream B
Organization and Culture

1

Elicit technologies, frameworks and integrations within the overall solution to identify riskA
Software Requirements

2

Structured security requirements are available and utilized by developer teams.

See8. Implementation Requirements

Design

Security ArchitectureRequirements

Stream B
Organization and Culture

2

Standardize technologies and frameworks to be used throughout the different applications

A
Software Requirements

3

Build a requirements framework for product teams to utilize.

Create a formal definition of the build process so that it becomes consistent and repeatable

Not scope of this standard. This is a duty of architectural board.

Implementation

Secure Build

Stream A
Build Process

1

See8. Implementation Requirements

Design

Security Requirements

Stream B
Compliance Management

1

Evaluate the supplier based on organizational security requirements.

See “Secure Build” at 5. Security within Development Process

Implementation

Secure Build

Stream A
Build Process

2

Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline7. Outsourced Development

Design

Security Requirements

Stream B
Compliance Management

2

Build security into supplier agreements in order to ensure compliance with organizational requirements.

See “Secure Build” at 5. Security within Development Process

Implementation

Secure Build

Stream A
Build Process

3

Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails7. Outsourced Development

Design

Security Requirements

Stream B
Compliance Management

3

Ensure proper security coverage for external suppliers by providing clear objectives.

See “Secure Build” at 5. Security within Development Process

Implementation

Secure Build

Stream B
Software Dependencies

1

Create records with Bill of Materials of your applications and opportunistically analyze these7. Outsourced Development

Design

Security Architecture

Stream A
Architecture Design

1

Teams are trained on the use of basic security principles during design

See “General Requirements” at 5. Security within Development Process

Design

Security Architecture

Stream A
Architecture Design

2

Establish common design patterns and security solutions for adoption.

See “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878327729/48.1+Protection+of+Source+and+Program+Code

Implementation

Secure Build

Stream B
Software Dependencies

2

Evaluate used dependencies and ensure timely reaction to situations posing risk to your applicationsGeneral+Principles

Design

Security Architecture

Stream A
Architecture Design

3

Reference architectures are utilized and continuously evaluated for adoption and appropriateness.

See “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code

Implementation

Secure Deployment

Stream A
Deployment Process

1

Formalize the deployment process and secure the used tooling and processesNot scope of this standard. This is a responsibility of architectural board.

Design

Security Architecture

Stream B
Technology Management

1

Elicit technologies, frameworks and integrations within the overall solution to identify risk.

Automate the deployment process over all stages and introduce sensible security verification tests.

Yes, see “secure build & deployment” at 5. Security within Development Process

Implementation

Secure Deployment

Stream A
Deployment Process

2

Not scope of this standard. This is a responsibility of architectural board.

Design

Security Architecture

Stream B
Technology Management

2

Standardize technologies and frameworks to be used throughout the different applications

Secure Deployment

See 6. Security Tests, “Utilize automated security testing tools”

Implementation

Not scope of this standard. This is a responsibility of architectural board.

Design

Security Architecture

Stream B
Secret Technology Management

1

Introduce basic protection measures to limit access to your production secrets3

Impose the use of standard technologies on all software development.

See “Protection of Secrets” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code 4. Secure Development Environment. Also a responsibility of architectural board.

Implementation

Secure DeploymentBuild

Stream BA
Secret Management

2

Inject secrets dynamically during deployment process from hardened storages and audit all human access to themBuild Process

1

Create a formal definition of the build process so that it becomes consistent and repeatable.

See “Secure Build” at 5. Security within Development Process

Implementation

Secure Build

Stream A
Build Process

2

Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline.

See “Secure Build” at 5. Security within Development Process

Implementation

Secure Build

Stream A
Build Process

3

Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails.

See “Secure Build” at 5. Security within Development Process

Implementation

Secure Build

Stream B
Software Dependencies

1

Create records with Bill of Materials of your applications and opportunistically analyze these.

See “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code

Implementation

Secure Build

Stream B
Software Dependencies

2

Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications.

See “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code

Implementation

Secure Build

Stream B
Software Dependencies

3

Analyze used dependencies for security issues in a comparable way to your own code.

See “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code, and reference to metrics in 6. Security Tests

Implementation

Secure Deployment

Stream A
Deployment Process

1

Formalize the deployment process and secure the used tooling and processes.

Yes, see “secure build & deployment” at 5. Security within Development Process

Implementation

Secure Deployment

Stream A
Deployment Process

2

Automate the deployment process over all stages and introduce sensible security verification tests.

See 6. Security Tests, “Utilize automated security testing tools”

Implementation

Secure Deployment

Stream A
Deployment Process

3

Automatically verify integrity of all deployed software, indenendently on whether it's internally or externally developed.

Yes, see “secure build & deployment” at 5. Security within Development Process

Implementation

Secure Deployment

Stream B
Secret Management

1

Introduce basic protection measures to limit access to your production secrets.

See TBD

Implementation

Secure Deployment

Stream B
Secret Management

2

Inject secrets dynamically during deployment process from hardened storages and audit all human access to them.

See TBD

Implementation

Secure Deployment

Stream B
Secret Management

3

Improve the lifecycle of application secrets by regularly generating them and by ensuring proper use.

See TBD

Implementation

Defect Management

Stream A
Defect Tracking

1

Introduce a structured tracking of security defects and make knowledgeable decisions based on this information.

See “Defect tracking” at 6. Security Tests

Implementation

Defect Management

Stream A
Defect Tracking

2

Rate all security defects over the whole organization consistently and define SLAs for particular severity classes.

Not scope of this standard, task for IT security function.

Implementation

Defect Management

Stream A
Defect Tracking

3

Enforce the predefined SLAs and integrate your defect management system with other relevant tooling.

Not scope of this standard, task for IT security function.

Implementation

Defect Management

Stream B
Metrics and Feedback

1

Regularly go over previously recorded security defects and derive quick wins from basic metrics.

See “Defect tracking” at 6. Security Tests

Implementation

Defect Management

Stream B
Metrics and Feedback

2

Collect standardized defect management metrics and use these also for prioritization of centrally driven initiatives.

Not scope of this standard, task for IT security function.

Implementation

Defect Management

Stream B
Metrics and Feedback

3

Continuously improve your security defect management metrics and correlate it with other sources.

Not scope of this standard, task for IT security function.

Verification

Architecture Assessment

Stream A
Architecture Validation

1

Identify application and infrastructure architecture components and review for basic security provisioning

See, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Architecture Assessment

Stream A
Architecture Validation

2

Validate the architecture security mechanisms

See, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Architecture Assessment

Stream A
Architecture Validation

3

Review the architecture effectiveness and feedback results to improve the security architecture.

Not scope of this standard, could be task for IT security function or architecture board.

Verification

Architecture Assessment

Stream B
Architecture Mitigation

1

Ad-hoc review of the architecture for unmitigated security threats.

See “Protection of Secrets” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code

Implementation

Defect Management

Stream A
Defect Tracking

1

Introduce a structured tracking of security defects and make knowledgeable decisions based on this information, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Architecture Assessment

Stream B
Architecture Mitigation

2

Analyze the architecture for known threats.

Rate all security defects over the whole organization consistently and define SLAs for particular severity classes

See “Defect tracking” at 6. Security Tests

Implementation

Defect Management

Stream A
Defect Tracking

2

See, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Architecture Assessment

Stream B
Architecture Mitigation

3

Feed the architecture review results back into the enterprise architecture, organization design principles & patterns, security solutions and reference architectures.

Not scope of this standard, could be task for IT security function or architecture board.

Implementation

Defect Management

Stream B
Metrics and Feedback

1

Regularly go over previously recorded security defects and derive quick wins from basic metrics.

Verification

Requirements-driven Testing

1

Test for software security controls

See “Functional security tests” at 6. Security Tests

Verification

Requirements-driven Testing

2

Derive test cases from known security requirements

See “Defect tracking” at 6“Complete and correct implementation” at 5. Security Testswithin Development Process

Implementation

Defect ManagementVerification

Requirements-driven Testing

2

3

Perform regression testing (with security unit tests)

VerificationArchitecture Assessment

Requirements-driven Testing

Stream A
Architecture ValidationB
Misuse/Abuse Testing

1Identify

application and infrastructure architecture components and review for basic security provisioningPerform security fuzzing testing

Validate the architecture security mechanisms

See, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Architecture Assessment

Stream A
Architecture Validation

2

See “Developer tests” at 6. Security Tests

Verification

Requirements-driven Testing

Stream B
Misuse/Abuse Testing

2

Create and test abuse cases and business logic flaw test

See , “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Architecture Assessment“Developer tests” at 6. Security Tests

Verification

Requirements-driven Testing

Stream B
Architecture Mitigation

1

Ad-hoc review of the architecture for unmitigated security threats.Misuse/Abuse Testing

3

Denial of service and security stress testing

VerificationArchitecture Assessment

Security Testing

Stream BA
Architecture MitigationScalable Baseline

2

Analyze the architecture for known threats.1

Utilize automated security testing tools

See , “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” in 5. Security within Development Process

Verification

Requirements-driven “Utilize automated security testing tools” at6. Security Tests

Verification

Security Testing

Stream A

Scalable Baseline

1

Test for software security controls2

Employ application-specific security testing automation

See “Functional security tests” at 6. Security Tests

Verification

Requirements-driven Security Testing

Stream A

Scalable Baseline

2

Derive test cases from known security requirements3

Integrate automated security testing into the build and deploy process

See “Complete and correct implementation” “Secure Build & Deployment” at 5. Security within Development Process

Verification

Requirements-driven Security Testing

Stream B
Misuse/Abuse TestingDeep Understanding

1

Perform manual security fuzzing testing of high-risk components

See “Developer “Functional security tests” at 6. Security Tests

Verification

Requirements-driven Security Testing

Stream B
Misuse/Abuse TestingDeep Understanding

2Create and test abuse cases and business logic flaw test

Conduct manual penetration testing

See “Developer “Manual security tests” at 6. Security Tests

Verification

Security Testing

Stream AB
Scalable BaselineDeep Understanding

13

Utilize automated Integrate security testing toolsinto development process

See “Utilize automated “Manual security testing tools” tests” at 6. Security Tests

VerificationOperations

Security TestingIncident Management

Stream A
Scalable BaselineIncident Detection

2

Employ application-specific security testing automation1

Use available log data to perform best-effort detection of possible security incidents.

See “Functional security tests” at 6. Security Tests

Verification

Security Testing

Stream B
Deep Understanding

1

Perform manual security testing of high-risk componentsrequirements on “Possible security incidents monitoring” at 3. Operational Requirements and 8.10 Error Handling & Logging

Operations

Incident Management

Stream A
Incident Detection

2

Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation.

See “Functional security tests” at 6. Security Tests

Verification

Security Testing

Stream B
Deep Understanding

2

Conduct manual penetration testing

See “Manual security tests” at 6. Security Testsrequirements on “Incident management” at 3. Operational Requirements

Operations

Incident Management

Stream A
Incident Detection

3

Use a proactively managed process for detection of incidents.

Operations

Incident Management

Stream AB
Incident DetectionResponse

1Use available log data to perform best-effort detection of possible security incidents

Identify roles and responsibilities for incident response.

See requirements on “Possible security incidents monitoring” “Incident management” at 3. Operational Requirements and 8.10 Error Handling & Logging

Operations

Incident Management

Stream AB
Incident DetectionResponse

2Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation

Establish a formal incident response process and ensure staff are properly trained in performing their roles.

See requirements on “Incident management” “System hardening” at 3. Operational Requirements

Operations

Incident Management

Stream B
Incident Response

1

Identify roles and responsibilities for 3

Employ a dedicated, well-trained incident response team.

Not scope of this standard, task for IT security function.

Operations

Incident Environment Management

Stream BA
Incident ResponseConfiguration Hardening

2

Establish a formal incident response process and ensure staff are properly trained in performing their roles1

Perform best-effort hardening of configurations, based on readily available information.

See requirements on “System hardening” at 3. Operational Requirements

Operations

Environment Management

Stream A
Configuration Hardening

12

Perform best-effort consistent hardening of configurations, based on readily available informationfollowing established baselines and guidance.

See requirements on “System hardening” at 3. Operational Requirements

Operations

Environment Management

Stream A
Configuration Hardening

2

Perform consistent hardening of configurations, following established baselines and guidance3

Actively monitor configurations for non-conformance to baselines, and handle detected occurrences as security defects.

See requirements on “System hardening” “Security monitoring” at 3. Operational Requirements

Operations

Environment Management

Stream B
Patching and Updating

1

Perform best-effort patching of system and application components.

See requirements on “System updating / patching” at 3. Operational Requirements and “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code

Operations

Environment Management

Stream B
Patching and Updating

2

Perform regular patching of system and application components, across the full stack. Ensure timely delivery of patches to customers.

See requirements on“System updating / patching” at 3. Operational Requirements and “Security of 3rd party dependencies” at https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Source+and+Program+Code/4.+Protection+of+Source+and+Program+Code

Operations

Environment Management

Stream B
Patching and Updating

3

Actively monitor update status and manage missing patches as security defects. Proactively obtain vulnerability and update information for components.

Operations

Operational Management

Stream A
Data Protection

1

Implement basic data protection practices

See 8.11 Data Security & Cryptography, 8.10 Error Handling & Logging and 3. Operational Requirements

Operations

Operational Management

Stream A
Data Protection

2

Develop data catalog and establish data protection policy.

See “Security Documentation” at 5. Security within Development ProcessProcess

Operations

Operational Management

Stream A
Data Protection

3

Automate detection of policy non-compliance, and audit compliance periodically. Regularly review and update to data catalog and data protection policy.

Operations

Operational Management

Stream B
System Decomissioning / Legacy Management

1

Decomission unused applications and services as identified. Manage customer upgrades/migrations individually.

See requirement on “Decomission” at 3. Operational Requirements

Operations

Operational Management

Stream B
System Decomissioning / Legacy Management

2

Develop repeatable decommissioning processes for unused systems/services, and for migration from legacy dependencies. Manage legacy migration roadmaps for customers.

Not scope of this standard, task for IT security function.

Operations

Operational Management

Stream B
System Decomissioning / Legacy Management

3

Proactively manage migration roadmaps, for both unsupported end-of-life dependencies, and legacy versions of delivered software.

Not scope of this standard, task for IT security function.