Transcript Security of Electronic Voting

Software Security Initiative
James Walden
Northern Kentucky University
Topics
1. Security Operations
2. Web Application Firewalls
3. Build Security In Maturity Model
CSC 666: Secure Software Engineering
Software Security Practices
4. Security Testing
5. Abuse Cases
6. Security
Operations
1. Code Reviews
2. Risk Analysis
3. Penetration
Testing
Abuse
Cases
Requirements
Risk
Analysis
Design
Code Reviews +
Static Analysis
Coding
Security
Testing
Testing
CSC 666: Secure Software Engineering
Penetration
Testing
Security
Operations
Maintenance
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
1.
2.
3.
4.
5.
6.
7.
8.
9.
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