TSS-WEB 2.0 generally covers a large number of OWASP SAMM 2.0 security practices, especially from maturity level 1 & 2. We’ve added additional requirements to TSS-WEB where this was possible. However, the scope of TSS-WEB is another as OWASP SAMM.
Whereas TSS-WEB describes a security dev standard for particular development units, OWASP SAMM focuses on the entire organization. Therefore, organization-wide tasks that have to be done by the IT security government function and that are therefore mostly within business function Governance are not covered in TSS-WEB. Also, whereas TSS-WEB describes a robust enterprise standard, OWASP SAMM provides three level of maturity for all objectives.
TSS-WEB can be helpful for implementing a large number of requirements (= those that affect the dev organization) of OWASP SAMM.
Detailed Coverage
Business Function | Security Practice | Stream | Mat. | Requirement | TSS-WEB Coverage |
|---|---|---|---|---|---|
Governance | All | All | All | NO Not scope of this standard, task for IT security function. | |
Governance | Stream A | 1 | Determine a security baseline representing organization’s policies and standards. | NO But you can use TSS-WEB as a basis to describe your organization-specific baseline. | |
Governance | Stream A | 2 | Develop security requirements applicable to all applications. | YES TSS-WEB covers this for Web-based applications. | |
Governance | Stream A | 3 | Measure and report on the status of individual application’s adherence to policies and standards. | NO Not scope of this standard, task for IT security function. | |
Governance | Stream B | 1 | Identify 3rd-party compliance drivers and requirements and map to existing policies and standards. | NO 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 | Stream B | 2 | Publish compliance-specific application requirements and test guidance | NO 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 | Stream B | 3 | Measure and report on individual application’s compliance with 3rd party requirements. | NO 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 | Stream A | 1 | Provide security awareness training for all personnel involved in software development | YES See “General Requirements” at5. Security within Software Development Process | |
Governance | Stream A | 2 | Offer technology and role-specific guidance, including security nuances of each language and platform | YES See “General Requirements” at5. Security within Software Development Process | |
Governance | Stream A | 3 | Standardized in-house guidance around the organization’s secure software development standards. | NO 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 | Stream A | 1 | Identify a “Security Champion” within each development team. | YES See “General Requirements” at5. Security within Software Development Process | |
Governance | Stream A | 2 | Develop a secure software center of excellence promoting thought leadership among developers and architects. | PARTIALLY 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 | Stream A | 3 | Build a secure software community including all organization people involved in software security. | PARTIALLY 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 | Stream A | 1 | A basic assessment of the application risk is performed to understand likelihood and impact of an attack. | YES See “Security within change management & agile development” at 5. Security within Software Development Process | |
Design | Stream A | 2 | Understand the risk for all applications in the organization by centralizing the risk profile inventory for stakeholders. | NO 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 | Stream A | 3 | Periodically review application risk profiles at regular intervals to ensure accuracy and reflect current state. | NO This is defined as a team responsible in 5. Security within Software Development Process | |
Design | Stream B | 1 | Perform best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists. | YES See “Security within change management & agile development” at5. Security within Software Development Process | |
Design | Stream B | 2 | Standardize threat modeling training, processes, and tools to scale across the organization. | NO Not in scope of TSS-WEB, should be described separately and linked into your own standard. | |
Design | Stream B | 3 | Continuously optimization and automation of your threat modeling methodology. | NO Not in scope of TSS-WEB, should be described separately and linked into your own standard. | |
Design | Stream A | 1 | High-level application security objectives are mapped to functional requirements. | YES See “General Requirements” at 5. Security within Software Development Process | |
Design | Stream A | 2 | Structured security requirements are available and utilized by developer teams. | YES | |
Design | Stream A | 3 | Build a requirements framework for product teams to utilize. | YES | |
Design | Stream B | 1 | Evaluate the supplier based on organizational security requirements. | YES | |
Design | Stream B | 2 | Build security into supplier agreements in order to ensure compliance with organizational requirements. | YES | |
Design | Stream B | 3 | Ensure proper security coverage for external suppliers by providing clear objectives. | YES | |
Design | Stream A | 1 | Teams are trained on the use of basic security principles during design | YES See “General Requirements” at 5. Security within Software Development Process | |
Design | Stream A | 2 | Establish common design patterns and security solutions for adoption. | YES Seehttps://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/327729/8.1+General+Principles | |
Design | Stream A | 3 | Reference architectures are utilized and continuously evaluated for adoption and appropriateness. | NO Not scope of this standard. This is a responsibility of architectural board. | |
Design | Stream B | 1 | Elicit technologies, frameworks and integrations within the overall solution to identify risk. | NO Not scope of this standard. This is a responsibility of architectural board. | |
Design | Stream B | 2 | Standardize technologies and frameworks to be used throughout the different applications | NO Not scope of this standard. This is a responsibility of architectural board. | |
Design | Stream B | 3 | Impose the use of standard technologies on all software development. | YES See 4. Secure Development Environment. Also a responsibility of an architectural board. | |
Implementation | Stream A | 1 | Create a formal definition of the build process so that it becomes consistent and repeatable. | YES See “Secure build & deployment” at 5. Security within Software Development Process | |
Implementation | Stream A | 2 | Automate your build pipeline and secure the used tooling. Add security checks in the build pipeline. | YES See “Secure build & deployment” at 5. Security within Software Development Process | |
Implementation | Stream A | 3 | Define mandatory security checks in the build process and ensure that building non-compliant artifacts fails. | YES See “Secure build & deployment” at 5. Security within Software Development Process | |
Implementation | Stream B | 1 | Create records with Bill of Materials of your applications and opportunistically analyze these. | YES See “Security of 3rd party dependencies” at 5. Security within Software Development Process | |
Implementation | Stream B | 2 | Evaluate used dependencies and ensure timely reaction to situations posing risk to your applications. | YES See “Security of 3rd party dependencies” at 5. Security within Software Development Process | |
Implementation | Stream B | 3 | Analyze used dependencies for security issues in a comparable way to your own code. | YES See “Security of 3rd party dependencies” at 5. Security within Software Development Process , and reference to metrics in 6. Security Tests | |
Implementation | Stream A | 1 | Formalize the deployment process and secure the used tooling and processes. | YES Yes, see “Secure build & deployment” at 5. Security within Software Development Process | |
Implementation | Stream A | 2 | Automate the deployment process over all stages and introduce sensible security verification tests. | YES See 6. Security Tests, “Utilize automated security testing tools” | |
Implementation | Stream A | 3 | Automatically verify integrity of all deployed software, indenendently on whether it's internally or externally developed. | YES Yes, see “Secure build & deployment” at 5. Security within Software Development Process | |
Implementation | Stream B | 1 | Introduce basic protection measures to limit access to your production secrets. | YES | |
Implementation | Stream B | 2 | Inject secrets dynamically during deployment process from hardened storages and audit all human access to them. | YES Yes, see “Secure build & deployment” at 5. Security within Software Development Process | |
Implementation | Stream B | 3 | Improve the lifecycle of application secrets by regularly generating them and by ensuring proper use. | YES | |
Implementation | Stream A | 1 | Introduce a structured tracking of security defects and make knowledgeable decisions based on this information. | YES See “Defect tracking” at 6. Security Tests | |
Implementation | Stream A | 2 | Rate all security defects over the whole organization consistently and define SLAs for particular severity classes. | NO Not scope of this standard, task for IT security function. | |
Implementation | Stream A | 3 | Enforce the predefined SLAs and integrate your defect management system with other relevant tooling. | NO Not scope of this standard, task for IT security function. | |
Implementation | Stream B | 1 | Regularly go over previously recorded security defects and derive quick wins from basic metrics. | YES See “Defect tracking” at 6. Security Tests | |
Implementation | Stream B | 2 | Collect standardized defect management metrics and use these also for prioritization of centrally driven initiatives. | NO Not scope of this standard, task for IT security function. | |
Implementation | Stream B | 3 | Continuously improve your security defect management metrics and correlate it with other sources. | NO Not scope of this standard, task for IT security function. | |
Verification | Stream A | 1 | Identify application and infrastructure architecture components and review for basic security provisioning | YES See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software Development Process | |
Verification | Stream A | 2 | Validate the architecture security mechanisms | YES See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software Development Process | |
Verification | Stream A | 3 | Review the architecture effectiveness and feedback results to improve the security architecture. | NO Not scope of this standard, could be task for IT security function or architecture board. | |
Verification | Stream B | 1 | Ad-hoc review of the architecture for unmitigated security threats. | YES See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software Development Process | |
Verification | Stream B | 2 | Analyze the architecture for known threats. | YES See, “Security within change management & agile development” and “Architectural approval” and “Security documentation” in 5. Security within Software Development Process | |
Verification | Stream B | 3 | Feed the architecture review results back into the enterprise architecture, organization design principles & patterns, security solutions and reference architectures. | NO Not scope of this standard, could be task for IT security function or architecture board. | |
Verification | Stream A | 1 | Test for software security controls | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Verification | Stream A | 2 | Derive test cases from known security requirements | YES See “Complete and correct implementation” at 5. Security within Software Development Process | |
Verification | Stream A | 3 | Perform regression testing (with security unit tests) | NO | |
Verification | Stream B | 1 | Perform security fuzzing testing | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Verification | Stream B | 2 | Create and test abuse cases and business logic flaw test | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Verification | Stream B | 3 | Denial of service and security stress testing | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Verification | Stream A | 1 | Utilize automated security testing tools | YES See “Utilize automated security testing tools” at6. Security Tests | |
Verification | Stream A | 2 | Employ application-specific security testing automation | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Verification | Stream A | 3 | Integrate automated security testing into the build and deploy process | YES See “Secure build & deployment” at 5. Security within Software Development Process | |
Verification | Stream B | 1 | Perform manual security testing of high-risk components | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Verification | Stream B | 2 | Conduct manual penetration testing | YES See “Custom security tests & developer tests:” at 6. Security Tests | |
Verification | Stream B | 3 | Integrate security testing into development process | YES See “Custom security tests & developer tests” at 6. Security Tests | |
Operations | Stream A | 1 | Use available log data to perform best-effort detection of possible security incidents. | YES See requirements on “Possible security incidents monitoring” at 3. Operational Requirements and 8.10 Error Handling & Logging | |
Operations | Stream A | 2 | Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation. | YES See requirements on “Incident management” at 3. Operational Requirements | |
Operations | Stream A | 3 | Use a proactively managed process for detection of incidents. | ||
Operations | Stream B | 1 | Identify roles and responsibilities for incident response. | YES See requirements on “Incident management” at 3. Operational Requirements | |
Operations | Stream B | 2 | Establish a formal incident response process and ensure staff are properly trained in performing their roles. | YES See requirements on “System hardening” at 3. Operational Requirements | |
Operations | Stream B | 3 | Employ a dedicated, well-trained incident response team. | NO Not scope of this standard, task for IT security function. | |
Operations | Stream A | 1 | Perform best-effort hardening of configurations, based on readily available information. | YES See requirements on “System hardening” at 3. Operational Requirements | |
Operations | Stream A | 2 | Perform consistent hardening of configurations, following established baselines and guidance. | YES See requirements on “System hardening” at 3. Operational Requirements | |
Operations | Stream A | 3 | Actively monitor configurations for non-conformance to baselines, and handle detected occurrences as security defects. | YES See requirements on “Security monitoring” at 3. Operational Requirements | |
Operations | Stream B | 1 | Perform best-effort patching of system and application components. | YES See requirements on “System updating / patching” at 3. Operational Requirements and “Security of 3rd party dependencies” at 5. Security within Software Development Process | |
Operations | Stream B | 2 | Perform regular patching of system and application components, across the full stack. Ensure timely delivery of patches to customers. | YES See requirements on“System updating / patching” at 3. Operational Requirements and “Security of 3rd party dependencies” at 5. Security within Software Development Process | |
Operations | Stream B | 3 | Actively monitor update status and manage missing patches as security defects. Proactively obtain vulnerability and update information for components. | ||
Operations | Stream A | 1 | Implement basic data protection practices | YES See 8.11 Data Security & Cryptography, 8.10 Error Handling & Logging and 3. Operational Requirements | |
Operations | Stream A | 2 | Develop data catalog and establish data protection policy. | YES See “Security Documentation” at 5. Security within Software Development Process | |
Operations | Stream A | 3 | Automate detection of policy non-compliance, and audit compliance periodically. Regularly review and update to data catalog and data protection policy. | ||
Operations | 1 | Decomission unused applications and services as identified. Manage customer upgrades/migrations individually. | YES See requirement on “Decomission” at 3. Operational Requirements | ||
Operations | 2 | Develop repeatable decommissioning processes for unused systems/services, and for migration from legacy dependencies. Manage legacy migration roadmaps for customers. | NO Not scope of this standard, task for IT security function. | ||
Operations | 3 | Proactively manage migration roadmaps, for both unsupported end-of-life dependencies, and legacy versions of delivered software. | NO Not scope of this standard, task for IT security function. |