OWASP ASVS: Architecture, Design, and Threat Modeling

Introduction to OWASP ASVS and Verification Levels

Secure Software Development Lifecycle and Threat Modeling

Key Architectural Controls: Authentication, Access Control, and Data Protection

Applying ASVS in Practice: Checklists, Agile Security, and Procurement

Authentication, Session Management, and Access Control

Modern Authentication Standards and Password Security

Session Management: Security Requirements and Common Pitfalls

Access Control Design and Operation-Level Security

Integrating Authentication and Access Control in Agile Development

This course will teach you in great details with examples, Cyber Security best practices according to NIST and OWASP Guide

1. Secure Software Development Lifecycle (SDLC)

• Definition: A structured process that incorporates security activities (requirements, design, implementation, testing, deployment, maintenance) throughout software development.
• ASVS Requirement: Verify the use of a secure SDLC that addresses security in all stages of development. (V1.1.1)
• Best Practices:
• Establish security policies and coding guidelines.
• Provide secure coding checklists to developers and testers.
• Conduct regular security training and awareness.

2. Threat Modeling

• Definition: Systematic analysis to identify, prioritize, and address potential threats to an application.
• ASVS Requirement: Verify the use of threat modeling for every design change or sprint planning to identify threats, plan countermeasures, facilitate risk responses, and guide security testing. (V1.1.2)
• Process Steps:

1. Identify Assets: What needs protection (e.g., data, services)?
2. Diagram Architecture: Map components, data flows, and trust boundaries.
3. Identify Threats: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
4. Plan Countermeasures: Define controls to mitigate identified threats.
5. Guide Testing: Use threat model outputs to inform security test cases.

3. Integrating Security in Agile and Sprint Planning

• ASVS Requirement: Verify that all user stories and features contain functional security constraints. (V1.1.3)
• Practical Tips:
• Add security acceptance criteria to user stories (e.g., “As a user, I should only access my own profile”).
• Review design changes for new or altered threats.
• Raise security tasks in the backlog for missing controls.

Applying ASVS Level 2 Controls

• Documentation: Maintain records of trust boundaries, components, and data flows. (V1.1.4)
• Architecture Review: Analyze high-level architecture and connected services for security risks. (V1.1.5)
• Centralized Controls: Implement vetted, reusable security controls to avoid duplication and gaps. (V1.1.6)
• Secure Coding Checklist: Make security requirements and guidelines available to all developers and testers. (V1.1.7)

Example Workflow

1. Sprint Planning: Include threat modelling for new features.
2. Design Review: Document architecture and trust boundaries.
3. Development: Use secure coding checklists and centralised controls.
4. Testing: Create security test cases based on threat model findings.
5. Deployment: Ensure security controls are effective and documented.

Summary

For Cybersecurity professionals, integrating a secure SDLC and threat modeling into development is essential for meeting OWASP ASVS Level 2 requirements. This approach ensures threats are identified early, security controls are built-in, and applications are resilient against skilled attackers. Use the ASVS as a blueprint to guide your organization’s secure development practices.