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

Policy & Compliance

Stream B
Compliance Management

3

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

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

Provide security awareness training for all personnel involved in software development

See “General Requirements” at5. Security within Software Development Process

Governance

Education & Guidance

Stream A
Training and Awareness

2

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

See “General Requirements” at5. Security within Software Development Process

Governance

Education & Guidance

Stream A
Training and Awareness

3

Standardized in-house guidance around the organization’s secure software development 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

Education & Guidance

Stream A
Training and Awareness

1

Identify a “Security Champion” within each development team.

See “General Requirements” at5. Security within Software Development Process

Governance

Education & Guidance

Stream A
Training and Awareness

2

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

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 A
Application Risk Profile

1

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

See “Assessment of all requirements and changes” “Security within change management & agile development” at 5. Security within Software Development Process

Design

Threat Assessment

Stream A
Application 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 Software Development Process

Design

Threat Assessment

Stream A
Application 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 Software Development Process

Design

Threat Assessment

Stream B
Threat Modeling

1

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

See “Assessment of all requirements and changes” “Security within change management & agile development” at5. Security within Software Development Process

Design

Threat Assessment

Stream B
Threat Modeling

2

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.

Design

Threat Assessment

Stream B
Threat Modeling

3

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 Requirements

Stream A
Software Requirements

1

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

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

Design

Security Requirements

Stream A
Software Requirements

2

Structured security requirements are available and utilized by developer teams.

See8. Implementation Requirements

Design

Security Requirements

Stream A
Software Requirements

3

Build a requirements framework for product teams to utilize.

See8. Implementation Requirements

Design

Security Requirements

Stream B
Compliance Management

1

Evaluate the supplier based on organizational security requirements.

See7. Outsourced Development

Design

Security Requirements

Stream B
Compliance Management

2

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

See7. Outsourced Development

Design

Security Requirements

Stream B
Compliance Management

3

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

See7. 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 Software Development Process

Design

Security Architecture

Stream A
Architecture Design

2

Establish common design patterns and security solutions for adoption.

Seehttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/327729/8.1+General+Principles

Design

Security Architecture

Stream A
Architecture Design

3

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

Not 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.

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

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

Design

Security Architecture

Stream B
Technology Management

3

Impose the use of standard technologies on all software development.

See 4. Secure Development Environment. Also a responsibility of an architectural board.

Implementation

Secure Build

Stream A
Build Process

1

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

See “Secure Build” build & deployment” at 5. Security within Software 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” build & deployment” at 5. Security within Software 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” build & deployment” at 5. Security within Software 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 5. Security within Software Development Process

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 5. Security within Software Development Process

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 5. Security within Software Development Process , 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 “Secure build & deployment” at 5. Security within Software 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 “Secure build & deployment” at 5. Security within Software Development Process

Implementation

Secure Deployment

Stream B
Secret Management

1

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

See TBD 8.15 Protection of Secrets

Implementation

Secure Deployment

Stream B
Secret Management

2

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

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

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 8.15 Protection of Secrets

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” “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software 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” , “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software 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, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software Development Process

Verification

Architecture Assessment

Stream B
Architecture Mitigation

2

Analyze the architecture for known threats.

See, “Assessment of all requirements and change” ans “Architectural Approval” and “Security Documentation” “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software 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.

Verification

Requirements-driven Testing

1

Test for software security controls

See “Functional “Custom security tests & developer tests” at 6. Security Tests

Verification

Requirements-driven Testing

2

Derive test cases from known security requirements

See “Complete and correct implementation” at 5. Security within Software Development Process

Verification

Requirements-driven Testing

3

Perform regression testing (with security unit tests)

Verification

Requirements-driven Testing

Stream B
Misuse/Abuse Testing

1

Perform security fuzzing testing

See “Developer “Custom security tests & 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 “Developer “Custom security tests & developer tests” at 6. Security Tests

Verification

Requirements-driven Testing

Stream B
Misuse/Abuse Testing

3

Denial of service and security stress testing

See “Developer “Custom security tests & developer tests” at 6. Security Tests

Verification

Security Testing

Stream A
Scalable Baseline

1

Utilize automated security testing tools

See “Utilize automated security testing tools” at6. Security Tests

Verification

Security Testing

Stream A
Scalable Baseline

2

Employ application-specific security testing automation

See “Functional “Custom security tests & developer tests” at 6. Security Tests

Verification

Security Testing

Stream A
Scalable Baseline

3

Integrate automated security testing into the build and deploy process

See “Secure Build build & Deployment” deployment” at 5. Security within Software Development Process

Verification

Security Testing

Stream B
Deep Understanding

1

Perform manual security testing of high-risk components

See “Functional “Custom security tests & developer tests” at 6. Security Tests

Verification

Security Testing

Stream B
Deep Understanding

2

Conduct manual penetration testing

See “Manual security tests” “Custom security tests & developer tests:” at 6. Security Tests

Verification

Security Testing

Stream B
Deep Understanding

3

Integrate security testing into development process

See “Manual “Custom security tests & developer tests” at 6. Security Tests

Operations

Incident Management

Stream A
Incident Detection

1

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

See requirements 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 requirements 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 B
Incident Response

1

Identify roles and responsibilities for incident response.

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

Operations

Incident Management

Stream B
Incident Response

2

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

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

Operations

Incident Management

Stream B
Incident Response

3

Employ a dedicated, well-trained incident response team.

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

Operations

Environment Management

Stream A
Configuration Hardening

1

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

2

Perform consistent hardening of configurations, following established baselines and guidance.

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

Operations

Environment Management

Stream A
Configuration Hardening

3

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

See requirements on “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 3. Operational Requirements and “Security of 3rd party dependencies” at 5. Security within Software Development Process

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 5. Security within Software Development Process

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 Software Development Process

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.