Keynote - Tony UcedaVelez - Fixing Threat Models with OWASP Efforts

### Overview In this keynote address at an OWASP conference in Orlando, Tony UcedaVelez discusses the persistent dysfunctions in threat modeling and application security, arguing that security organizations rely too heavily on automated scanning tools and compliance checklists without understanding threat intelligence or actual business impact. Drawing from consulting experiences with federal agencies, medical IoT startups, and commercial insurers, he urges practitioners to move away from post-implementation bug hunting and adopt risk-centric threat modeling early in the software development lifecycle (SDLC) by weaponizing existing OWASP tools and frameworks.

### Key Topics - **Communication Breakdown & The Risk Formula**: Security professionals often struggle to articulate business value. The traditional formula $\text{Risk} = \text{Threat} \times \text{Vulnerability} \times \text{Impact}$ is often misused because organizations focus almost exclusively on finding bugs (vulnerabilities) through SAST, DAST, IAST, and RASP tools while ignoring realistic threats and the financial impact on operations. - **The PASTA Framework**: As co-author of the Process for Attack Simulation and Threat Analysis (PASTA), UcedaVelez highlights its seven stages, emphasizing Stage 1 (Business Impact) and Stage 4 (Threat Intelligence). Unlike generic checklists, PASTA models risk by incorporating real adversary motivations, incident precedents, and operational consequences. - **Evidentiary Threat Modeling vs. Generic Lists**: The OWASP Top 10 or standard lists should not be treated as a complete threat model. Effective models require decomposing application architectures, inspecting protocols (such as CoAP and DTLS in IoT), evaluating trust boundaries, and building attack trees or attack patterns (referencing CAPEC) grounded in actual threat data. - **Aligning Security with Business Value**: Translating technical security findings into monetary impact—such as financial losses per hour of downtime, regulatory penalties, or compromised records—transforms security requirements into functional priorities that developers and executives can support.

### Technical Details - **Application Decomposition & Protocols**: Practitioners must understand underlying protocols and RFC specifications rather than treating applications as black boxes. For example, when assessing lightweight IoT protocols like CoAP that run over UDP rather than TCP/TLS, security engineers must evaluate mitigations like DTLS. - **Mapping OWASP Projects to Threat Modeling Stages**: - *Stage 1 (Business Impact)*: OWASP CISO Project metrics help derive financial impact and justify security investments. - *Preemptive Hardening*: OWASP Cheat Sheets and the Application Security Verification Standard (ASVS) provide baseline mitigation before deep modeling. - *Stages 4 & 5 (Threat & Vulnerability Identification)*: Combining threat intelligence with tools like OWASP ZAP and the OWASP Testing Guide to evaluate specific weakness points. - *Stage 6 (Attack Modeling)*: Using frameworks such as the OWASP Web Testing Framework (WTF), PTES (Penetration Testing Execution Standard), and the ModSecurity Core Rule Set (alongside WAF benchmarking) to simulate probabilistic, criminal-style attack paths rather than running automated scanner scripts blindly. - *Maturity & Governance*: Utilizing OpenSAMM (and referencing BSIMM) to iteratively mature software security programs.

### Takeaways - **Shift Left with Empathy**: Stop acting as "collectors" delivering tickets after deployment; engage developers early during architectural design to avoid costly remediation cycles. - **Speak the Business Language**: Communicate security risk in terms of revenue, operational uptime, and regulatory consequences rather than raw vulnerability names. - **Operationalize Community Resources**: Utilize OWASP's extensive ecosystem (ASVS, ZAP, CISO Project, Juice Shop, OpenSAMM) to implement an evidence-based, threat-informed security program.