...
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 |
Not scope of this standard, task for IT security function. | |||||||
Governance | Stream A | 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 | Stream A | 2 | Develop security requirements applicable to all applications. |
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. |
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. |
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 |
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. |
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 |
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 |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
See “General Requirements” at 5. Security within Software Development Process | |||||||
Design | Stream A | 2 | Structured security requirements are available and utilized by developer teams. |
| |||||||
Design | Stream A | 3 | Build a requirements framework for product teams to utilize. |
| |||||||
Design | Stream B | 1 | Evaluate the supplier based on organizational security requirements. |
| |||||||
Design | Stream B | 2 | Build security into supplier agreements in order to ensure compliance with organizational requirements. |
| |||||||
Design | Stream B | 3 | Ensure proper security coverage for external suppliers by providing clear objectives. |
| |||||||
Design | Stream A | 1 | Teams are trained on the use of basic security principles during design |
See “General Requirements” at 5. Security within Software Development Process | |||||||
Design | Stream A | 2 | Establish common design patterns and security solutions for adoption. |
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. |
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. |
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 |
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. |
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. |
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. |
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. |
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. |
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. |
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. |
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, 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. |
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, 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. |
| |||||||
Implementation | Stream B | 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 | Stream B | 3 | Improve the lifecycle of application secrets by regularly generating them and by ensuring proper use. |
| |||||||
Implementation | Stream A | 1 | Introduce a structured tracking of security defects and make knowledgeable decisions based on this information. |
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. |
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. |
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. |
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. |
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. |
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 |
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 |
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. |
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. |
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. |
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. |
Not scope of this standard, could be task for IT security function or architecture board. | |||||||
Verification | Stream A | 1 | Test for software security controls |
See “Custom security tests & developer tests” at 6. Security Tests | |||||||
Verification | Stream A | 2 | Derive test cases from known security requirements |
See “Complete and correct implementation” at 5. Security within Software Development Process | |||||||
Verification | Stream A | 3 | Perform regression testing (with security unit tests) |
| |||||||
Verification | Stream B | 1 | Perform security fuzzing testing |
See “Custom security tests & developer tests” at 6. Security Tests | |||||||
Verification | Stream B | 2 | Create and test abuse cases and business logic flaw test |
See “Custom security tests & developer tests” at 6. Security Tests | |||||||
Verification | Stream B | 3 | Denial of service and security stress testing |
See “Custom security tests & developer tests” at 6. Security Tests | |||||||
Verification | Stream A | 1 | Utilize automated security testing tools |
See “Utilize automated security testing tools” at6. Security Tests | |||||||
Verification | Stream A | 2 | Employ application-specific security testing automation |
See “Custom security tests & developer tests” at 6. Security Tests | |||||||
Verification | Stream A | 3 | Integrate automated security testing into the build and deploy process |
See “Secure build & deployment” at 5. Security within Software Development Process | |||||||
Verification | Stream B | 1 | Perform manual security testing of high-risk components |
See “Custom security tests & developer tests” at 6. Security Tests | |||||||
Verification | Stream B | 2 | Conduct manual penetration testing |
See “Custom security tests & developer tests:” at 6. Security Tests | |||||||
Verification | Stream B | 3 | Integrate security testing into development process |
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. |
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. |
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. |
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. |
See requirements on “System hardening” at 3. Operational Requirements | |||||||
Operations | Stream B | 3 | Employ a dedicated, well-trained incident response team. |
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. |
See requirements on “System hardening” at 3. Operational Requirements | |||||||
Operations | Stream A | 2 | Perform consistent hardening of configurations, following established baselines and guidance. |
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. |
See requirements on “Security monitoring” at 3. Operational Requirements | |||||||
Operations | Stream B | 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 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. |
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 |
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. |
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. |
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. |
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. |
Not scope of this standard, task for IT security function. |