Software Security Initiative James Walden Northern Kentucky University
Topics • Security Operations • Web Application Firewalls • Build Security In Maturity Model CSC 666: Secure Software Engineering
Software Security Practices • Code Reviews • Risk Analysis • Penetration Testing • Security Testing • Abuse Cases • Security Operations AbuseCases Risk Analysis Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Requirements Design Coding Testing Maintenance CSC 666: Secure Software Engineering
Security Operations User security notes • Software should be secure by default. • Enabling certain features/configs may have risks. • User needs to be informed of security risks. Incident response • What happens when a vulnerability is reported? • How do you communicate with users? • How do you send updates to users? CSC 666: Secure Software Engineering
Code Deployment Manage deployment process • Change management process. • Scrub debug/test code from software. • Use automated tools for deployment. Maintain three sets of servers • Development • Staging • Production CSC 666: Secure Software Engineering
Web Application Firewalls Analyze + filter HTTP traffic • Intrusion Detection • Intrusion Prevent Open Source WAFs • AQTronix WebKnight • Breach ModSecurity Commercial WAFs • Armorlogic Profense • Breach WebDefend • Citrix Application Firewall • Fortify Defender CSC 666: Secure Software Engineering
Modes of Operation • Bridge: transparent bridging firewall. • Router: install at single point of entry. • Reverse Proxy: traffic redirected to flow through WAF by DNS or routing. • Embedded: server plugin; no need to configure network but only works with some web servers. CSC 666: Secure Software Engineering
Modes of Operation Bridge or Router Embedded Reverse Proxy CSC 666: Secure Software Engineering
SSL • Terminates SSL: Reconfigure network to move SSL operations to WAF itself. WAF to server communication can be plaintext or SSL encrypted. • Passively decrypts SSL: WAF decrypts SSL traffic using copy of server’s SSL private key. Data travels untouched to web server. • Occurs after SSL: Embedded WAFs can be posititioned to analyze traffic after server decrypts SSL data. CSC 666: Secure Software Engineering
Traffic Blocking • Connection Intermediation: Traffic intercepted by WAF. Attacks blocked by not forwarding packets to destination. • Connection Reset: Traffic inspected by WAF, which blocks attacks by resetting TCP connections. • 3rd Party Blocking: Traffic inspected by WAF, which notifies other devices to block. CSC 666: Secure Software Engineering
Traffic Blocking WAFs can block • IP addresses • TCP connections • HTTP requests • Application sessions • Application users • Too many new requests/sessions WAFs can rewrite parts of HTTP request • Request headers • Response headers • Cookies • URLs • HTTP message bodies CSC 666: Secure Software Engineering
Canonicalization WAFs convert data to standard form • URL-decoding • Paths (., .., \) • Mixed case • Whitespace condensation • HTML entity decoding • Escaped cahracter decoding • Unicode standardization CSC 666: Secure Software Engineering
Signatures and Rules Signatures • Text strings • Regular expressions Rules • Signatures + • Operators (length, field) • Logical expressions • Control flow • Session management CSC 666: Secure Software Engineering
BSI Maturity Model Guide for building and improving a SSI. Based on survey of top software security programs: • Adobe • Depository Trust and Clearing Corporation • EMC • Google • Microsoft • QUALCOMM • Wells Fargo Software Security Initiative Statistics • 2-10 years old (average 4) • 12-100 people (average 41) • Approximate 100:1 developer:security person ratio. CSC 666: Secure Software Engineering
Using the Maturity Model Executive leadership • Accountability and empowerment. • Difficultieis: Grassroots and network security. Identify organization security goals. • Identify which practices fit best with organizational culture. Use all 12 practices. • Better to put some level 1 activities in each practice in place than go to level 3 in one. • Not necessary to do all practices in level 1 before moving to level 2. CSC 666: Secure Software Engineering
Software Security Framework Governance: Practices that help manage and measure a software security program. Intelligence: Practices producing collection sof corporate knowledge used in swsec. SSDL Touchpoints: Practices associated with analysis and assurance of particular software development artifacts & processes. Deployment: Practices interfacing with network security and software configuration abd maintenance organizations. CSC 666: Secure Software Engineering
Software Security Framework CSC 666: Secure Software Engineering
Practices and Business Goals CSC 666: Secure Software Engineering
Strategy and Metrics CSC 666: Secure Software Engineering
Compliance and Policy CSC 666: Secure Software Engineering
Training CSC 666: Secure Software Engineering
Attack Models CSC 666: Secure Software Engineering
Security Features and Design CSC 666: Secure Software Engineering
Standards and Requirements CSC 666: Secure Software Engineering
Architecture Analysis CSC 666: Secure Software Engineering
Code Review CSC 666: Secure Software Engineering
Security Testing CSC 666: Secure Software Engineering
Penetration Testing CSC 666: Secure Software Engineering
Software Environment CSC 666: Secure Software Engineering
Configuration Management CSC 666: Secure Software Engineering
Ten Core Activities Everyone Does CSC 666: Secure Software Engineering
References • Brian Chess, Gary McGraw, Sammy Migues, Building Security In—Maturity Model, http://www.bsi-mm.com/ • CLASP, OWASP CLASP Project, http://www.owasp.org/index.php/Category:OWASP_CLASP_Project, 2008. • Noopur Davis et. al., Processes for Producing Secure Software. IEEE Security & Privacy, May 2004. • Karen Goertzel, Theodore Winograd, et al. for Department of Homeland Security and Department of Defense Data and Analysis Center for Software. Enhancing the Development Life Cycle to Produce Secure Software: A Reference Guidebook on Software Assurance, October 2008. • Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006. • Gary McGraw, Software Security, Addison-Wesley, 2006. • Ivan Ristic, Apache Security, O’Reilly, 2005. • Ofer Shezaf, ModSecurity “The Core Rule Set”: Generation detection of application layer attacksModSecurity "The Core Rule Set": Generic detection of application layer attacks, 6th OWASP AppSec Conference, 2007. • Web Application Security Consortium, “WAFEC, or how to choose WAF technology,” http://www.webappsec.org/projects/wafec/, 2006. CSC 666: Secure Software Engineering
