Securing the Core JEE Patterns
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
Avoid:
- XSLT and Xpath vulnerabilities
- XML Denial of Service
- Disclosure of information in SOAP faults
- Publishing WSDL files
- Unhandled commands
- Unauthorized commands
Project Goals
- 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.
Uses
- 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
Next Steps?
- 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
Our Dream
- New web application framework idea + Design-time security analysis = Secure-by-default web application framework
Virtualization Security Best Practices from a Customer’s and Vendor’s Perspective
The next session during the ISSA half-day seminar on Virtualization and Cloud Computing Security was on security best practices from a customer and vendor perspective. It featured Brian Engle, CIO of Temple Inland, and Rob Randell, CISSP and Senior Security Specialist at VMware, Inc. My notes from the presentation are below:
Temple Inland Implementation - Stage 1
Overcome Hurdles
- Management skeptical of Windows virtualization
Don't Fear the Virtual World
- First year:
- Built out development only environment
- Trained staff
- Developed support processes
- Showed hard dollar savings
Temple Inland - Stage 2
- Build QA environment
- Improve processes
- Develop rapid provisioning
- Demonstrate advanced functions
- Vmotion
- P2V Conversions
Temple Inland - Stage 3
First production environment
Temple-Inland Implementation
- Prior to VMWare. Typical remote facility
- Physical domain controller
- Physical application/file server
- Physical tape drive
- New architecture
- Single VMWare server
- No tape drive
- Desktops
- Virtualize desktops through VMWare
- No application issues like Citrix Metaframe
- Quick deployment and repair
How Virtualization Affects Datacenter Security
- Abstraction and Consolidation
- +Capital and Operational Cost Savings
- -New infrastructure layer to be secured
- -Greater impact of attack or misconfiguration
- Collapse of Switches and servers into one device
- +Flexibility
- +Cost-savings
- -Lack of virtual network visibility
- -No separation-by-default of administration
Temple-Inland split the teams so that there was a virtual network administration team within the server administration team.
How Virtualization Affects Datacenter Security
- Faster deployment of servers
- + IT responsiveness
- -Lack of adequate planning
- -Incomplete knowledge of current state of infrastructure
- VM Mobility
- +Improved Service Levels
- -Identity divorced from physical location
- VM Encapsulation
- +Ease of business continuity
- +Consistency of deployment
- +Hardware Independence
- -Outdated offline systems
Build anti-virus, client firewalls, etc into the offline images so that servers are up-to-date right when they are installed.
If something happens to a system, you can't just pull the plug anymore. You have to have policies and processes in place.
With virtualization you can have a true "gold image" instead of having different images for all of the different types of hardware.
Security Advantages of Virtualization
- Allows automation of many manual error prone processes
- Cleaner and easier disaster recovery/business continuity
- Better forensics capabilities
- Faster recovery after an attack
- Patching is safer and more effective
- Better control over desktop resources
- More cost effective security devices
- App virtualization allows de-privileging of end users
- Better lifecycle controls
- Future: Security through VM Introspection
Gartner: "Like their physical counterparts, most security vulnerabilities will be introduced through misconfiguration"
What Not to Worry About
- Hypervisor Attacks
- ALL theoretical, highly complex attacks
- Widely recognized by security community as being only of academic interest
- Irrelevant Architectures
- Apply only to hosted architecture (ie. Workstation) not bare-metal (ie. ESX)
- Hosted architecture generally suitable only when you can trust the guest VM
- Contrived Scenarios
- Involved exploits where best practices around hardening, lockdown, desgin, for virtualization etc not followed or
- Poor general IT infrastructure security is assumed
Are there any Hypervisor Attack Vectors?
There are currently no known hypervisor attack vectors to date that have lead to "VM Escape"
- Architecture Vulnerability
- Designed specifically with isolation in mind
- Software Vulnerability - Possible like with any code written by humans
- Mitigating Circumstances:
- Small Code Footprint of Hypervisor (~21MB) is easier to audit
- If a software vulnerability is found, exploit difficulty will be very high
- Purpose build for virtualization only
- Non-interactive environment
- Less code for hackers to leverage
- Ultimately depends on VMWare security response and patching
- Mitigating Circumstances:
Concern: Virtualizing the DMZ/Mixing Trust Zones
Three Primary Configurations
- Physical separation of trust zones
- Virtual separation of trust zones with physical security devices
- Fully collapsing all servers and security devices into a VI3 infrastructure
Also applies to PCI requirement
Physical Separation of Trust Zones
Advantages
- Simpler, less complex configuration
- Less change to physical environment
- Little change to separation of duties
- Less change in staff knowledge requirements
- Smaller chance of misconfiguration
Disadvantages
- Lower consolidation and utilization of resources
- Higher cost
Virtual Separation of Trust Zones with Physical Security Devices
Advantages
- Better utilization of resources
- Take full advantage of virtualization benefits
- Lower cost
Disadvantages (can be mitigated)
- More complexity
- Greater chance of misconfiguration
Getting more toward "the cloud" where web zone, app zone, and DB zone are all virtualized on the same system, but still using physical firewalls.
Fully Collapsed Trust Zones Including Security Devices
Advantages
- Full utilization of resources, replacing physical security devices with virtual
- Lowest-cost option
- Management of entire DMZ and network from a single management workstation
Disadvantages
- Greatest complexity, which in turn creates highest chance of misconfiguration
- Requirement for explicit configuration to define separation of duties to help mitigate risk of misconfiguration; also requires regualar audits of configurations
- Potential loss of certain functionality, such as VMotion (being mitigated by vendors and VMsafe)
How do we secure our Virtual Infrastructure?
Use the principles of Information Security
- Hardening and lockdown
- Defense in depth
- Authorization, authentication, and accounting
- Separation of duties and least privileges
- Administrative controls
Protect your management interfaces (VCenter)! They are the keys to the kingdom.
Fundamental Design Principles
- Isolate all management networks
- Disable all unneeded services
- Tightly regualte all administrative access
Summary
- Define requirements and ensure vendor/product can deliver
- Consider culture, capability, maturity, architecture and security needs
- Implement under controlled conditions using a defined methodology
- Use the opportunity to improve control deficiencies in existing physical server areas if possible
- Implement processes for review and validation of controls to prevent the introduction of weaknesses
- Round corners where your control environment allows
- Sustain sound practices that maintain required controls
- Leverage the technology to achieve efficiency and improve scale
Best Practices Guide: Web Application Firewalls – OWASP AppSec NYC 2008
This presentation was by Alexander Meisel and is from a paper that was put together by the Germany OWASP chapter. He began by introducing the problem being online businesses having HTTP as their "weak spot". Then talked about the definition of the term "Web Application Firewall". It's not a network firewall and not only hardware. The targeted audience of the paper is technical decision makers, people responsible for operations and security, and application owners. Next he talked about some of the characteristics of web applicatons with regard to security. Prioritize web applications in regard to their importance (access to personal customer data, access to confidential company information, certifications). Some technical aspects include test and quality assurance, documentaiton, and vendor contracts.
Where do WAFs fit into the web application security field? WAFs are part of a solution. Create a table with wanted functionality (CSRF, session fixation, *-Injection). Do a rating/evaluation with "+" meaning it can be very well implemented using a WAF, "-" meaning it can not be implemented, "!" meaning depends on the WAF/application/requirement, and "=" meaning it can partly be implemented with a WAF.
Looks at the benefits and risks of WAFs. Good baseline security. Compliance. Just-in-time patching of problems. Additional benefits (depending on functionality) could be central reporting and error logging, SSL termination, URL encryption, etc.
Some risks involved in using WAFs are false positives, increased complexity, having yet another proxy, and potential side effects if the WAF terminates the application.
Protection against the OWASP Top 10. App vs WAF vs Policy. Three types of applications: web application in design phase, already productive app which can easily be changed, and productive app which cannot be modified or only with difficulty. Table of OWASP Top 10 in regards to work required with the 3 types of applications to fix the problem in the application itself, using a WAF, and using a policy.
Criteria for deciding whether or not to use WAFs. Company wide criteria includes the importance of the application for the success of the company, number of web applications, complexity, operational costs, and performance and scalability. Criteria with regard to the web application includes changeability of the application, documentation, maintenance contracts, and time required fixing bugs in third-party products. Consideration of financial aspects includes avoidance of financial damage via successful attacks and teh costs of using a WAF (license, update, project costs for eval and WAF introduction, volume of work required/personnel costs).
He started going pretty fast here since he was already running over on time. The gist was a bunch of best practices for introduction and operation of web application firewalls. He talked about technical requirements, job requirements, and an iterative procedure for implementation.
This presentation was mostly just an overview of what is in the paper and he didn't get into too much specifics. Go check out the paper at https://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls to get the details!