Methodologies and Practices within ASAS

TL;DR

Methodologies and practices within ASAS (Applied Software Assurance Science) provide structured approaches to ensure software security throughout its lifecycle. They help you identify vulnerabilities, mitigate risks, and build secure applications proactively. By integrating security early and continuously, these methods reduce the cost and effort of fixing issues later.

1. The Mental Model

Think of ASAS methodologies as a security blueprint for your software project. You're not just building a house; you're building a fortress. These practices are the specific techniques and tools you use at each stage to make sure that fortress is impenetrable.

2. The Core Material

Methodologies and practices in ASAS guide you through systematically securing software. This isn't just about scanning for bugs at the end; it's about embedding security from the very first idea to deployment and beyond.

2.1 Key Methodologies

Photo by Markus Winkler on Pexels

Several key methodologies inform ASAS, often overlapping and complementing each other:

• Secure Software Development Lifecycle (SSDLC): This extends the traditional SDLC by integrating security activities into every phase (requirements, design, implementation, testing, deployment, maintenance). Instead of a separate security gate, it's a continuous process.
• DevSecOps: This methodology aims to "shift security left" (earlier in the development process) by automating security tasks and fostering collaboration between development, security, and operations teams. It's about making security an integral, seamless part of the DevOps pipeline.
• Agile Security: Adapting security practices to agile development environments, focusing on short iterations, continuous feedback, and integrating security tasks into sprints. It emphasizes flexibility and responsiveness to changing threats.

2.2 Core Practices

Photo by Elina Fairytale on Pexels

Within these methodologies, you'll encounter several core practices:

• Threat Modeling: Systematically identifying potential threats, vulnerabilities, and attacks against an application. This is typically done during the design phase but can be revisited.
• Security Requirements Gathering: Defining explicit security requirements alongside functional requirements. What needs to be protected, from whom, and to what extent?
• Secure Coding Guidelines: Following established best practices for writing code that is resistant to common vulnerabilities (e.g., input validation, secure error handling, proper authentication/authorization).
• Security Testing:
  • Static Application Security Testing (SAST): Analyzing source code or compiled code for security vulnerabilities without executing the program. Think of it as a spell checker for security issues.
  • Dynamic Application Security Testing (DAST): Testing the application from the outside, while it's running, to find vulnerabilities that an attacker could exploit. It simulates real-world attacks.
  • Interactive Application Security Testing (IAST): Combines elements of SAST and DAST, monitoring the application from within while it's running to identify vulnerabilities.
  • Penetration Testing (Pen Testing): Manual or automated simulation of real-world attacks by security experts to identify vulnerabilities and gauge the system's resilience.
• Vulnerability Management: The process of identifying, assessing, reporting, remediating, and mitigating vulnerabilities in systems and software.
• Security Training: Educating developers and team members on secure coding practices, common vulnerabilities, and the importance of security.

Here's a simplified view of how these practices integrate into an SSDLC:

graph LR
    A["Requirements (Define Security Needs)"] --> B["Design (Threat Modeling)"]
    B --> C["Development (Secure Coding, SAST)"]
    C --> D["Testing (DAST, IAST, Pen Testing)"]
    D --> E["Deployment (Secure Configuration)"]
    E --> F["Maintenance (Vulnerability Mgmt, Monitoring)"]
    F --> A;
    F -- "Feedback & Iteration" --> C;

2.3 Tools and Techniques

Photo by G N on Pexels

To implement these practices, you'll use various tools and techniques:

• Static Analyzers (SAST tools): SonarQube, Checkmarx, Fortify.
• Dynamic Scanners (DAST tools): OWASP ZAP, Burp Suite, Acunetix.
• Interactive Tools (IAST tools): Contrast Security, HCL AppScan.
• Threat Modeling Tools: Microsoft Threat Modeling Tool, OWASP Threat Dragon.
• Vulnerability Scanners: Nessus, OpenVAS.
• Security Information and Event Management (SIEM) systems: Splunk, ELK Stack (for monitoring).

3. Worked Example

Let's say you're developing an e-commerce website. Using an SSDLC approach with DevSecOps principles, here's how some practices might play out:

1. Requirements Phase: You define that user passwords must be hashed and salted, all sensitive data (credit card info) must be encrypted in transit and at rest, and user accounts must have multi-factor authentication (MFA).
2. Design Phase: You perform a threat model. You identify potential threats like SQL Injection on the login page, Cross-Site Scripting (XSS) on product review pages, and unauthorized access to customer databases. You decide on architectural mitigations like using parameterized queries for database interactions and implementing a strong Content Security Policy (CSP).
3. Development Phase: Developers write code following secure coding guidelines. Before committing, an automated SAST tool integrated into the CI/CD pipeline scans their code. It flags a potential XSS vulnerability where user input isn't properly sanitized before being displayed. The developer fixes it immediately.
4. Testing Phase: After deployment to a staging environment, an automated DAST scan runs, simulating attacks. It tries various inputs on the login page and attempts to bypass authentication. A penetration tester then manually reviews the application, trying to exploit business logic flaws or other subtle vulnerabilities the automated tools might have missed.
5. Deployment & Monitoring: The application is deployed with secure configurations. In production, a SIEM system monitors logs for suspicious activity, like multiple failed login attempts from a single IP address, triggering an alert.

4. Key Takeaways

• Integrating security early and continuously in the development lifecycle is crucial for cost-effective security.
• Threat modeling helps you proactively identify and mitigate potential security weaknesses before they become problems.
• A combination of SAST, DAST, IAST, and penetration testing offers comprehensive vulnerability detection.
• DevSecOps emphasizes automating security tasks and fostering collaboration across teams to embed security.
• Security awareness and training for developers are fundamental to writing secure code from the start.
• Vulnerability management is an ongoing process, even after deployment, to address new threats.

Common Mistakes to Avoid:
- Treating security as an afterthought: Don't bolt security on at the end; it's always more expensive and less effective.
- Over-reliance on automated tools: Tools are great, but they don't catch everything. Manual review and human expertise (like pen testing) are still vital.
- Ignoring security requirements: Don't just focus on functional features; explicit security requirements guide secure development.
- Skipping threat modeling: Without understanding your threats, you can't effectively defend against them.

5. Now Try It

Choose a simple application you're familiar with (e.g., a login form, a blog comment section). Spend 15 minutes thinking about it. Identify at least three potential security threats against it and one specific mitigation practice you'd implement for each threat. What success looks like: You'll have a clear understanding of specific threats and concrete security actions, demonstrating the core thinking behind ASAS methodologies.