The OWASP Security Spending Benchmarks Project
This presentation was by Boaz Belboard, the Executive Director of Information Security for Wireless Generation and the Project Leader for the OWASP Security Spending Benchmarks Project. My notes are below:
It does cost more to produce a secure product than an insecure product.
Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.
Why do we spend on security? How much should we be spending?
- Security imposes extra costs on organizations
- The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
- No comparable data for development or web apps
- Regualtions and contracts usually require "reasonable measures". What does that mean?
OWASP Security Spending Benchmarks Project
- 20 partner organizations, many contributors
- Open process and participation
- Raw data available to community
Reasons For Investing in Security
- Contractual and Regulatory Compliance
- Incident Prevention, Risk Mitigation
- Cost of Entry
- Competitive Advantage
Technical and Procedural Principles
- Managed and Documented Systems
- Business-need access
- Minimization of sensitive data use
- Security in Design and Development
- Auditing and Monitoring
- Defense in Depth
Specific Activities and Projects
- Security Policy and Training
- DLP-Type Systems
- Internal Configurations Management
- Credential Management
- Security in Development
- Locking down internal permissions
- Secure Data Exchange
- Network Security
- Application Security Programs
Building an In-House Application Security Assessment Team
This presentation was by Keith Turpin from The Boeing Company. About three years ago, all of Boeing's assessments were coming from outsourced service providers. They realized that they were unable to have control over the people and process and had difficulties integrating the controls into the SDLC and decided to bring these functions in house. The goal of this presentation is to show some of the issues they ran into and how they addressed those problems. My notes from the presentation are below:
Contraced Services Considerations
- Some Advantages:
- Highly skilled
- Established tools, processes, and standards
- Unbiased
- Available as needed
- Some Disadvantages:
- Expensive, especially for an extended engagement
- Less control and flexibility
- Not familiar with company processes and culture
- Rotating staff
Planning
- Considerations for establishing an internal team:
- Time to staff and train the team
- Overlap of external and internal teams
- Development of processes and standards
- Acquiring necessary tools
Service Model
- Define the services your team will provide. This will be greatly influenced by:
- The team's size and skills
- The number of applications you have to support
- The tools available
- The level of executive support
- The funding model
- Who pays for your services
- The team's role
- Development support, pre-deployment testing or post deployment auditing and pen testing
OWASP Top 10 – 2010
This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member. My notes are below:
What's Changed?
- It's about Risks, not just vulnerabilities
- New title is: "The Top 10 Most Critical Web Application Security Risks"
- OWASP Top 10 Risk Rating Methodology
- Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
- 2 Risks Added, 2 Dropped
- Added: A6 - Security Misconfiguration
- Was A10 in 2004 Top 10: Insecure Configuration Management
- Added: A8 - Unvalidated Redirects and Forwards
- Relatively common and VERY dangerous flaw that is not well know
- Removed: A3 - Malicious File Execution
- Primarily a PHP flaw that is dropping in prevalence
- Removed: A6 - Information Leakage and Improper Error Handling
- A very prevalent flaw, that does not introduce much risk (normally)
- Added: A6 - Security Misconfiguration
- A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
- A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser. For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe. (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
- A3 - Broken Authentication and Session Management: Means credentials have to go with every request. Should use SSL for everything requiring authentication.
- A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
- A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application. Vulnerability is caused by browsers automatically including user authentication data with each request. (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
- A6 - Security Misconfiguration: All through the network and platform. Don't forget the development environment. Think of all the places your source code goes. All credentials should change in production.
- A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
- A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL. If they aren't validated, attacker can send victim to a site of their choice.
- A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely. Failure to identify all sensitive data. Failure to identify all the places that this sensitive data gets stored. Failure to properly protect this data in every location.
- A10 - Insufficient Transport Layer Protection
OWASP Top 10 Risk Rating Methodology
- Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
- Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))
This is generic across the internet, not specific to any organization.
Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).
What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.
Application Security Metrics from the Organization on Down to the Vulnerabilities
This presentation was by Chris Wysopal, the CTO of Veracode. My notes are below:
"To measure is to know." - James Clerk Maxwell
"Measurement motivates." - John Kenneth Galbraith
Metrics do Matter
- Metrics quantify the otherwise unquantifiable
- Metrics can show trends and trends matter more than measurements do
- Metrics can show if we are doing a good job or bad job
- Metrics can show if you have no idea where you are
- Metrics establish where "You are here" really is
- Metrics build bridges to managers
- Metrics allow cross sectional comparisons
- Metrics set targets
- Metrics benchmark yourself against the opposition
- Metrics create curiosity
Metrics Don't Matter (Mike Rothman)
- It is too easy to count things for no purpose other than to count them
- You cannot measure security so stop
- This following is all that matters and you can't map security metrics to them:
- Maintenance of availability
- Preservation of wealth
- Limitation on corporate liability
- Compliance
- Shepherding the corporate brand
- Cost of measurement not worth the benefit
Bad metrics are worse than no metrics
Security Metrics Can Drive Executive Decision Making
- How secure am I?
- Am I better off than this time last year?
- Am I spending the right about of money?
- How do I compare to my peers?
- What risk transfer options to I have?
Goals of Application Security Metrics
- Provide quantifiable information to support enterprise risk management and risk-based decision making
- Articulate progress towards goals and objectives
- Provides a repeatable, quantifiable way to assess, compare, and track improvements in assurance
- Focus activities on risk mitigation in order of priority and exploitability
- Facilitate adoption and improvement of secure software design and development processes
- Provide and objective means of comparing and benchmarking projects, divisions, organizations, and vendor products
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
Development Issues within AJAX Applications: How to Divert Threats
This presentation was by Lars Ewe, CTO of Cenzic on AJAX applications and trying to explore the different implications of running AJAX in your environment. My notes are below:
Agenda
- What is AJAX?
- AJAX and Web App Security
- AJAX and Test Automation
- Vulnerability Examples: XSS, CSRF, & JavaScript Hijacking
- AJAX Best Security Practices
- Demo
- Q&A
What is AJAX?
- Asynchronous JavaScript And XML
- AJAX allows for a new generation of more dynamic, more interactive, faster Web 2.0 applications
- AJAX leverages existing technologies, such as DHTML, CSS< DOM, JSON, and the (a)synchronous XMLHTTPRequest (XHR)
- Not just a set of technologies, but a new Web application development approach and methodology
- XHR allows for (a)synchronous server requests without the need for a full page reload
- XHR "downstream" payload can be
- XML, JSON, HTML/JavaScript snippets, plain text, serialized data, basically pretty much anything...
- Responses often get further processed using JavaScript and result in dynamic web page content changes through DOM modifications
AJAX Code Example
xhr = new XMLHttprequest();
xhr.open("GET", AJAX_call?foo-bar, true);
xhr.onreadystatechange = processResponse;
xhr.send(null);
function processResponse() {
if (xhr.readyState == 4) {
if (request.status == 200) {
response = xhr.responseText;
...
}
}
}
XHR and the Same Origin Policy
- Same origin policy is a key browser security mechanism
- To prevent any cross-domain data leakage, etc
- With JavaScript it doesn't allow JavaScript from origin A to access content/data from origin B
- Origin refers to the domain name, port, and protocol
- In the case of XHR, the same origin policy does not allow for any cross-domain XHR requests
- Developers often don't like this at all!
Common Cross Domain Workarounds
Cross-domain access is often still implemented by various means, such as:
- Open / Application (server-based) proxies
- Flash & Java Applets (depending on crossdomain.xml)
- Ex: FlashXMLHttpRequest by Julien Couvreur
- RESTful web service with JavaScript callback and JSON response
- EX: JSONscriptRequest by Jason Levitt
AJAX Frameworks
- AJAX frameworks are often categorized as either "Client" or "Proxy/Server" framework
- "Proxy/Server" frameworks sometimes result in unintended method/functionality exposure
- Beware of any kind of "Debugging mode" (Ex: Direct Web Remoting (DWR) debug=true)
- Remember: Attackers can easily "fingerprint" AJAX frameworks
- Beware of JavaScript Hijacking
- Don't use HTTP GET for "upstream"
- Prefix "downstream" JavaScript with "while(1);"
AJAX and Web App Security
- AJAX potentially increases the attack surface
- More "hidden" calls mean more potential security holes
- AJAX developers sometimes pay less attention to security, due to it's "hidden" nature
- Basically the old mistake of security by obscurity
- AJAX developers sometimes tend to rely on client side validation
- An approach that is just as flawed with or without AJAX
- Mash-up calls/functionality are often less secure by design
- 3rd party APIs (Ex: feeds, blogs, search APIs, etc) are often designed with ease of use, not security in mind
- Mash-ups often lack clear security boundaries (who validates, who filters, who encodes/decodes, etc)
- Mash-ups often result in untrusted cross-domain access workarounds
- AJAX sometimes promotes dynamic code (JavaScript) execution of untrusted response data
AJAX / Web 2.0 and Test Automation
- Spidering is more complex than just processing ANCHOR HREF's; various events need to be simulated (Ex: mouseover, keydown, keyup, onclick, onfocus, onblur, etc)
- Timer events and dynamic DOM changes need to be observed
- Use of non-standard data formats for both requests and responses make injection and detection hard to automate
- Page changes after XHR requests can sometimes be delayed
- In short, you need to have browser like behavior (JavaScript engine, DOM & event management, etc)
Cross-Site Scripting (XSS)
- AJAX is changing the game a little bit since the script tag may already be there, just need to look for JSON or JavaScript snippets to inject yourself into
Cross-Site Request Forgery (CSRF)
- Want to send a token for AJAX requests as well
JavaScript Hijacking
- Attacker code (override Array constructor)
- Render the JavaScript on the wire useless to anyone who doesn't have access to the code itself
- The attacker cannot sanitize the JavaScript since they do not have access to the code
AJAX Best Security Practices
Pretty much all the usual Web app security best practices apply:
- Analyze and know your security boundaries and attack surfaces
- Beware of reliance on client-side security measures
- Assume the worst case scenario for all 3rd party interations
- 3rd parties can inherently not be trusted!
- Be extremely careful when circumventing same origin policy
- Avoid/limit the use of dynamic code/eval()
- Beware of JavaScript Hijacking
- Implement anti-CSRF defenses
Enterprise Application Security – GE’s Approach to Solving Root Cause
The first presentation of the day that I went to was by GE's Darren Challey and was about GE's application security program and how he took a holistic approach to securing the enterprise. My notes on this presentation are below:
Why is AppSec so hard?
- AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
- Changing landscape
- Increase skill and talen t pool of technically proficient individuals willing to break the law
- Growing volume of financially valuable data online
- Development of criminal markets (black markets) to facilitate conversion to money
- "Attackers now have effective skills, something to steal, and a place to sell it"
- Application Security is a complete one-sided game
- Need to become an enabler (not a barrier)
- Must inject application security earlier through Guidance, Education, and Tools
- Must understand the development and deployment process and integrate rather than mandate
- NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
- Solving the problem of the enterprise (Culture Change)
- Success factors
- Form a mission and strategy
- Develop policy (but not corporate "mandate")
- Gain executive buy-in (cost / benefit / risk)
- Understand the magnitude of problem (metrics)
- Asset inventory and vulnerability management
- Develop standards (what should I do and when?)
- Establish a formal program (strong leadership)
- Focus on education and training materials
- Develop in-house expertise, services and "COE"
- Continuous improvement, measurement, KPI
- Communicate!
- Drive a culture change (shared need, WIIFM)
- Communicate expectations with vendors
- Implement incentives (and penalties)
- Digitize after the process is solid (tools)
- AppSec program mission & structure
- AppSec program strategy
- Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve
Guidance
- "GE Application Security Working Group" (Talking to the businesses is critical! Meet every 2 weeks.)
- Secure Coding Guidelines
- Vulnerability Remediation Guide
- Secure Deployment
- Quick Reference Card
- Contractual Language
- Desk Calendars
- Metrics: AppSec calendars helped increase visitors to key Guidance materials (track hits to website docs when certain activities take place)
Education
- CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
- CBT2: GE Best Practices for Secure Coding (90 min)
- CBT3: Attack Profiles & Countermeasures (120 min for security people)
- Developer Awareness Assessment:
- 100's of internally-developed questions
- Randomized questions, timed completion
- Vendors track their own resutls
- Allows tailoring of training/awareness programs
Tools
- - COE AppSec assessment services
- Vendor framework & Metrics
- Compliance handbook
- Common objects repository
- GE Enterprise Application Security
- Scanning and Monitoring tools
- Automation is the way to go (but the tools are not quite there yet)
Metrics
- Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
- Is it making a difference (map avg of critical/high vulnerabilities per assessment)
Forming a Center of Excellence
- Combines the best available people, processes and tools
- Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
- COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
- Application Assessment Types (black/grey box vs white box)
- Application assessment process (map of the workflow with "swim lanes" of who does each step)
- Measure number of vulnerabilities and severities
- Measure customer satisfaction (overall, ease of engagement, responsiveness)
Everything You Need To Know About Cloud Security in 30 Minutes or Less
The last presentation of the day was by Rich Mogull on "Everything you need to know about cloud security in 30 minutes or less". It all started with all of the presentations and diagrams having pictures of clouds so some guy decides to sell that. Makes security practitioners sad.
Why the cloud is a problem for security
- Poor understanding of cloud taxonomies and definitions
- A generic term, frequently misused to refer to anything on the Internet
- Lack of visibility into cloud deployments
- Organic consumption
Couldn't have talked about this stuff 6 months ago because nobody knew about it and it wasn't discussed.
Security Implications
- Variable control
- Variable visibility
- Variable simplicity/complexity
- Variable resources
Control, visibility, and resources goes down as simplicity and management goes up
Is the cloud more or less secure than we are now? It depends. Something are more secure and some things are less secure because of all of the variability.
Saas
- Most constrained
- Most security managed by your provider
- Least flexible
PaaS
- Less constrained
- Security varies tremendously based on provider and application-shared responsibility
- Security responsibility
IaaS
- Most flexible
- Most security managed by your developers
Specific Issues
- Spillage and data security
- Reliability/availability
- Capability to apply traditional security controls in a dynamic environment
- Lack of visibility into cloud usage
- Changing development patterns/cycles
How do you use your static and dynamic analysis testing tools in the cloud?
Where do you roll your cloud when it fails?
Your Top 2 Cloud Security Defenses
- SLA
- Contracts
Understand Your SLAs
- Are there security-specific SLAs?
- Can you audit against those SLAs?
- Are there contractual penalties for non-compliance?
- Do your SLAs meet your risk tolerance requirements?
Suggested SLAs
- Availability
- Security audits - including third party
- Data security/encryption
- Personal security
- Security controls (depend based on service)
- User account management
- Infrastructure changes
Understand Your Cloud
- What security controls are in your cloud?
- How can you manage and integrate with the controls?
- What security documentation is available?
- What contingency plans are available?
Cloud Security Controls to Look For
- Data encryption/security (key management)
- Perimeter defenses
- Auditing/logging
- Authentication
- Segregation
- Compliance
Cloud Security Macro Layers
- Network
- Service
- User
- Transaction
- Data
Don't Trust
- SAS70 Audits
- Documentation without verification
- Non-contractual SLAs
What to Do
- Educate yourself
- Engage with developers
- Develop cloud security requirements
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
About the Cloud Security Alliance
The next presentation at the ISSA half-day seminar was on the "Cloud Security Alliance" and Security Guidance for Critical Areas of Focus in Cloud Computing by Jeff Reich. Here are my notes from this presentation:
Agenda
- About the Cloud Security Alliance
- Getting Involved
- Guidance 1.0
- Call to Action
About the Cloud Security Alliance
- Not-for-profit organization
- Inclusive membership, supporting broad spectrum of subject matter expertise: cloud experts, security, legal, compliance, virtualization, etc
- We believe in Cloud Computing, we want to make it better
Getting Involved
- Individual membership (free)
- Subject matter experts for research
- Interested in learning about the topic
- Administrative & organizational help
- Corporate Sponsorship
- Help fund outreach, events
- Affiliated Organizations (free)
- Joint projects in the community interest
- Contact information on website
Download version 1.0 of the Security Guidance at http://www.cloudsecurityalliance.org/guidance
Overview of Guidance
- 15 domains
- #1 is Architecture & Framework
- Covers Governing in the Cloud (2-7) and Operating in the Cloud (8-15) as well
Assumptions & Objectives
- Trying to bridge gap between cloud adopters and security practitioners
- Broad "security program" view of the problem
Architecture Framework
- Not "One Cloud": Nuanced definition critical to understanding risks & mitigation
- 5 principal characteristics (abstration, sharing, SOA, elasticity, consumption/allocation)
- 3 delivery models
- Infrastructure as a Service
- Platform as a Service
- Software as a Service
- 4 deployment models: Public, Private, Managed, Hybrid
Governance & ERM
- A portion of cloud cost savings must be invested into provider security
- Third party transparency of cloud provider
- Financial viability of cloud provider
- Alignment of key performance indicators
- PII best suited in private/hybrid cloud outside of significant due diligence of public cloud provider
- Increased frequency of 3rd party risk assessments
Important thing to consider is the financial viability of your provider. You never want to have your data held hostage in a court battle.
Legal
- Contracts must have flexible structure for dynamic cloud relationships
- Plan for both an expected and unexpected termination of the relationship and an orderly return of your assets
- Find conflicts between the laws the cloud provider must comply with and those governing the cloud customer
Compliance & Audit
- Classify data and systems to understand compliance requirements
- Understand data locations, copies
Information Lifecycle Management
- Understand the logical segregation of information and protective controls imnplemented in storage, transfers, backups
Summary
- Cloud Computing is real and transformational
- Cloud Computing can and will be secured
- Broad governance approach needed
- Tactical fixes needed
- Combination of updating existing best practices and creating completely new best practices
- Common sense is not optional
Call to Action
- Join us, help make our work better
- www.cloudsecurityalliance.org
- info@cloudsecurityalliance.org
- Twitter: @cloudsa, #csaguide