This presentation was by Rohit Sethi, the Project Leader for the Secure Pattern Analysis Project at OWASP and he works at Security Compass, a security analysis and training company. My notes from the session are below:
- Before anyone starts building complex systems, they need to design.
- We create threat models on completed designs.
- What about during design?
- Book: "Core J2EE Patterns Best Practices and Design Strategies"
- If you use J2EE development, chances are you're using patterns documented here
- Core J2EE patterns are used extensively
- Patterns are used in JSF, Velocity, Struts, Tapestry, Spring, and Proprietary Frameworks
Example: Project: Analyze Patterns
Use to Implement:
- Synchronization Tokens as Anti-CSRF Mechanism
- Page-level authorizations
- XSLT and Xpath vulnerabilities
- XML Denial of Service
- Disclosure of information in SOAP faults
- Publishing WSDL files
- Unhandled commands
- Unauthorized commands
- Analyze patterns for security pitfalls to avoid
- Determine how patterns can implement security controls
- Provide advice portable to most frameworks
A security pattern is not the same as a security analysis of a pattern.
- Designing new web application frameworks (make the next generation of frameworks secure by default)
- Designing new apps that use the patterns
- Source code review of existing apps
- Runtime assessment of existing apps
- Integrate with threat modeling of new or existing apps
You can help:
- Tell developers
- Improve the analysis
- Add code review and examples to the existing pattern book
- Look at other pattern books to see if there are other patterns that we should analyze
- New web application framework idea + Design-time security analysis = Secure-by-default web application framework
It's my second year at the OWASP AppSec Conference and this year it is in Washington, DC. The New York City Conference last year proved to be probably the best conference I've ever been to. Based on the agenda and the facilities, this year is looking very promising. Today's keynote is by Joe Jarzombeck, the Director for Software Assurance at the National Cyber Security Division for the Office of the Assistant Secretary of Cybersecurity and Communication. Man, is that a mouthful. My notes on the presentation are below:
DHS NCSD Software Assurance Program
- A public/private collaboration that promotes security and software resilence throughout the SDLC
- Reduce exploitable software weaknesses
- Address means to improve capabilities that routinely develop, acquire, and deploy resilent software products
- IT/Software Security risk landscape is a convergence between "defense in depth" and "defense in breadth"
- Applications now cut through the security perimeter
- Rather than attempt to break or defeat network or system security, hackers opt to target application software to circumvent security controls
- 75% of hacks are at the application level
- Most exploitable software vulnerabilities are attributed to non-secure coding practices
- Enable software supply chain transparency
- Acquisition managers and users factored risks posed by software supply chain as part of the trade-space in risk mitigation efforts
- DHS Software Assurance program scoped to address:
- Standalone Common Body of Knowledge (CBK) drawing upon contributing companies/industries
Build Security In: https://buildsecurityin.us-cert.gov
- Focus on making software security a normal part of software engineering
- Process agnostic lifestyle
- There was an interesting slide on touchpoints and artifacts that I took a picture of with my phone and I will try to post here.
Resources to Check Out
"Software Security Engineering: A Guide for Project Managers"
"Enhancing the Development Lifecycle to Produce Secure Software"
Fundamental Practices for Secure Software Development
The Software Assurance Pocket Guide Series
Software Assurance in Acquisition: Mitigating Risks to the Enterprise
- Check out Appendix D - Software Due Diligence Questionnaires
"Making the Business Case for Software Assurance"
"Measuring ... Assurance"
Common Weakness Enumeration (CWE)
- If you have this weakness, then it's not a matter of if, but when you'll be breached.
Since Michael Howard moved from Redmond to Austin, I've had the privilege to see him present several times now. This is the guy who literally wrote the book on writing secure code and the secure development lifecycle. He is a fantastic speaker and I'd highly recommend checking him out if you every get the opportunity. Yesterday, I heard that he was speaking on securing your code at the San Antonio OWASP meeting so I decided it was worth making the drive down to see his presentation. So, I give to you Michael Howard's Top 10 Strategies to Secure Your Code straight out of one of his Microsoft TechNet presentations.
Michael began by giving us the definition of a secure system. He said "A secure system does what it's supposed to do and no more." It's such a simple concept, but in practice such a hard thing to achieve. Here are his suggestions on how to accomplish that: