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
Thoughts on the TRISC 2009 Conference
This was my third consecutive year attending the TRISC Conference and it gets better and better every year. This year, the location was outstanding, the presenters were top-notch, and the Keynotes were pretty good. This was my first time actually presenting at the TRISC Conference and I thought they did an excellent job from the presenter point-of-view as well. They kept the presentations on time, they had my notes all printed up and ready for attendees, and A/V equipment worked well. No complaints from me there.
My favorite Keynote speaker was far and away Johnny Long. His talk was on "No Tech Hacking" and he is as entertaining as he is talented. If you ever get a chance to see him speak, definitely do so. Also, be sure to check out his website at IHackCharities.org.
My least favorite Keynote speaker was Ken Watson. He spoke all monotone and the presentation on these centers around the country that the government is using to team up with industry to prevent attacks on critical infrastructure was pretty lame. I guess I just expected more and from talking with others it seems like I'm not alone.
My favorite presentation was Robert Hansen and Rob MacDougal's talk on "Assessing Your Web App Manually Without Hacking It". It was a simple concept that everyone from managers to developers to IT guys can follow to get an idea as to how many vulnerabilities their application might contain. RSnake!
My least favorite presentation was "The Importance of Log Management in Today's Insecure World" by Ricky Allen and Randy Holloway from ArcSite. Too vendory, not technical enough, and kinda a lame presentation in general. Maybe I'm just bitter because I heard that the other presentations that took place while I was in this session were really good.
This was the first year that TRISC had a Casino Night and it was awesome. I played Texas Hold 'Em most of the night and took Nathan Sportsman's money and a bunch of Rob MacDougal's as well. They had Roulette, Blackjack, and Craps tables there as well and the goal was to start with $10,000 in chips and for every $5,000 you had at the end of the night you got a raffle ticket. I ended up with over $40,000 and 9 raffle tickets and won three different items. Score.
Overall, TRISC 2009 was not the best conference that I've ever attended, but was certainly the best TRISC to date. I was very impressed and am looking forward to next year. FYI, all presentations from the conference are online and available for viewing here.
PCI Compliance – Convert Drudgery Into a Powerful Security Framework
For my last session of the day at TRISC 2009, I decided to attend Joseph Krull's presentation on PCI Compliance. Joe works as a consultant for Accenture and has performed 60+ PCI engagements for various companies. If your organization does any processing of credit card information, my notes from that session below should be useful:
- As many as 65% of merchants are still not PCI compliant
- Fines can be just the beginning; service charges and market share price dilution for non-compliant merchants have already had substantial repercussions in the US and may soon reach other regions·
- Many retailers still don’t have a clear view of compliance, and cannot effectively identify gaps
- The first steps to PCI compliance are a thorough internal assessment and gap analysis – many merchants skip these steps and launch multiple costly projects
- PCI provides a regulatory and compliance framework to help prevent credit card fraud for organizations that process card payments
- The framework is comprehensive and effective but adherence to the specific standards is often challenging – primarily due to the complexities involved in both program design and implementation
- Any merchant that accepts or processes credit cards must maintain compliance with the PCI DSS. Specific obligations vary based on transaction volumes.
- Focus right now is on the Level 4’s.
- TJX subject to 20 years of mandatory computer systems audits after massive breach
Challenges
- Providing adequate and clear program management for all of the entire spectrum of PCI remediation activities (60-70% give to “Compliance guy” and typically fail. Should go to senior security guy)
- Accurately scoping requirements throughout the organization, including remote sites and international operations
- Evaluating and then implementing a wide variety of complex technologies – including encryption
- Redesigning or replacing internal applications and payment systems to adequately protect cardholder data
- Developing, implementing and enforcing new or revised policies and procedures across the entire organization
- Differing opinions with auditors regarding PCI compliance requirements, especially related to the concept of “Compensating Controls”
- Verifying PCI compliance for 3rd party partners that process data on behalf of the merchant
Differences from PCI DSS 1.1 to 1.2
- Active monitoring plans for all 3rd party PCI Service Providers (Requirement 12.8)
- Visits to offsite data storage locations at least annually
- Mandatory phase out of weak encryption for wireless networks
- Additional requirements for the use of “Compensating Controls” for specific PCI security requirements
- Assessor testing procedures changed from “Observe the use of…” to “Verify the use of”
- Quality assurance program for PCI assessors
- Process restricts or eliminates assessors from performing PCI work due to poor quality assessments
- Assessors must now go beyond cursory observation of security controls and provide statistical samples
- Assessors now going much deeper to include verifying individual system settings, requesting and analyzing configuration files, studying data flows, …
The Cost of Compliance and Non-Compliance
- According to a comprehensive Forrester Research report on PCI compliance, companies spend between 2%-10% of their IT budget on PCI compliance
- Credit card companies are levying fines on non-compliant merchants
- Up to $25,000 per month for each month of non-compliance for L1’s ($5,000 for L4’s)
- $10,000-$100,000 per month for prohibited storage of magnetic stripe data
- Up to $500,000 per incident if a confirmed compromise occurs
- Continued non-compliance may result in revocation of CC processing privileges
- Banks and acquirers may increase processing fees for non-complinat merchants. In 2008, one retailer estimated an annual increase in operational costs of $18 million due to this increase in processing fees on VISA card transactions alone.
- Banks and acquirers can often pass on damages they incur to merchants
- Repeat or additional PCI assessments & internal audits
Corporate Compliance Framework
- Although PCI provides compliance requirements in most areas, it’s only a subset
- ISO 27002:2005 is what they used for PCI
- Good general requirements, but no explanation on how to do it
- PCI sets best practices
- For example, ISO 5.1.1 maps to PCI 12.1, 12.4, and 12.6.2
How to “Sell” PCI Compliance to Senior Management
- Gloom and Doom
- Fines and sanctions will sink us
- Probability of success 40-50%
- The PCI Umbrella
- We need these 15 projects and ten new security products to be PCI compliant
- Probability of success 40-50%
- Who has done the gap assessment
- The Long Term Approach
- If we achieve PCI compliance we will also be well on our way to other requirements
- PCI compliance is not a project or technology based solution – it is being able to demonstrate that an organization has the means in place to protect sensitive information
- Use as a building block to sell to senior management
Security Policy Architecture – How to fix your current disaster
One of the sessions that I attended during the day on the Tuesday of TRISC 2009 was by Doug Landoll from Lantego on "Security Policy Architecture". The presentation was a very good overview of how to put good security policies in place that are easily auditable should that need arise and that are as comprehensive as necessary. The actual presentation slides are available here and because he had some very good visual aids in his presentation, I'm going to just recommend that you check out the actual slides. My notes, however, are below just in case the slides ever get deleted for some reason:
Importance of Security Policies
- Govern expected behavior and process
- Expected and prohibited behavior
- Security process
- Establishes roles and responsibilities
- Management & oversight
- Execution
- Define protection measures
- Access controls
- Physical security measures
- Monitoring, audit, and oversight
- Response priorities
Hazards of Weak Security Policies
- Unclear expected behavior
- Personnel guess at what is allowable & expected
- Minor “infractions” – undefined & unnoticed
- Leads to eroding culture of trust
- Unclear roles and responsibilities
- No oversight – administrator actions go unchecked
- No management – activities according to whim
- Unclear protection measures
- “Heroes” define network security
- Extremely tech-centric security posture
Security Architecture Mistakes
- Mixed audience policies
- Ex: Encryption policy
- Use of encryption – users
- Selection of encryption algorithms – system owners
- Implementation of encryption – custodians
- Key escrow – system owners
- Oversight – auditors/management
- Ex: Security Updates
- Do not block network updates – users
- Patch every Tuesday – admins
- Ex: Encryption policy
- Who is the audience?
Common Policy Architecture Mistakes
- One topic = one policy
- Magic Policies
- Templates
- Handbooks
- Pros
- Solves the “blank piece of paper” problem
- Cons
- Old
- No consideration for your environment, culture, or organization
- Discourages analysis
- No SME (Subject Matter Expert) involvement
- Thwarts adoption
- Match policy to requirements
- PCI Policy project
- HIPAA Policy project
- TAC 202 Policy project
- Etc
- Problem
- Requirements by controls
- Policies organized by audience & topic
Clean Slate Approach
- Assess what you have
- Independent & complete review process
- Determine controls framework
- COBIT, ISO 27001
- Map in requirements
- PCI DSS, HIPAA, TAC 202
- Organize create policy statements
- For each control (rows) and requirement (column)
- Create policy architecture
- According to audience & topic
Policy Assessment Approach
- Step 1 (Essential Elements Checklist)
- Steps 2 (controls & framework) & 3 (map requirements)
- Steps 4 (policy statements) & 5 (policy architecture)
Conclusion
- Administrative Controls
- Management, oversight, process
- Address organizational and insider issues
- Lack of policy architecture
- Leads to weak administrative controls
- Unplanned technology implementation
- “implementation by appointment”
- Ensure your controls are complete
- Reaction is NOT a strategy (Don’t do it because a vendor called you or because an auditor said to do it)
Deep Packet Inspection and the Loss of Privacy and Security on the Internet
For my first session of the day on Tuesday of the TRISC 2009 conference I attended a presentation by Andrew MacFarlane from Data Foundry, Inc. on "Deep Packet Inspection and the Loss of Privacy and Security on the Internet". While the concept of DPI is nothing new to me and I remember first hearing about it around the FBI's Carnivore project, this particular use case was something that I hadn't heard about. Apparently pretty much every Tier 1 ISP has hopped onboard the DPI bandwagon and is now using the technology for everything from traffic prioritization to targeted advertising. To make matters worse, you automatically agree to this type of monitoring by accepting your ISP's terms of service. Data Foundry has been one of the few ISP's who have spoken out against this practice, but unless more people (especially end-users) lobby their congressmen to remove this waiver of privacy rights as part of our terms of service acceptance, the future of privacy and security on the internet is awfully bleak. My notes from the session are below:
How Secure is Your Bank Account?
Recently I was elected the new Treasurer of the Capitol of Texas Chapter of the Information Systems Security Association. No, that's not my way to seek your approval, but thanks for the kudos. The reason why I bring this up is that one of the first things I needed to do as the new Treasurer was change the bank account information over from the old 2008 board members to the new 2009 ones. I called in advance and scheduled a meeting with a banking representative and asked what I needed to bring with me. The answer was documentation showing the board change, a current account signer, and a new account signer (me). So far so good.
So me and two of the old board members show up at the bank to do the deed. We sit down in the guys office with the door wide open while he proceeds to ask me personal questions such as my social security number and mother's maiden name in front of those guys and anyone within earshot. I probably should have said something right there, but lowered my voice and gave the guy the requested information, but that was strike #1 for a bank whose name I will not mention.
I tell him that I've brought two of the current signers with me and motion toward the guys sitting next to me. They tell the bank representative their names and the representative acknowledges. He starts handing me paperwork to sign effectively removing the old names off of the account and putting the account solely in my name. At this point he's asked for my driver's license, my SSN, my mother's maiden name, but has yet to verify that the guys sitting next to me were who they said they were. No request for any form of identification from either of them. Strike #2.
I ask him to assist me with setting up the online account access and he makes a quick call to find out what needs to be done and hands me another form which I sign. At this point he tells us we're all set. One of the old board members asks "So at this point all of my information has been completely removed from the bank account?" and the bank representative says "yes". We thank him and leave only to discuss what just transpired outside amongst ourselves. What would have prevented us from walking into that bank with a fake document showing a board member change, having two of my buddies pretend that they were the old board members, and getting the account changed into my name and walking off with the money? They required no signature or identification from the old board members. In fact, I did pretty much all of the talking and I'm pretty sure they didn't even say their names (or that they were the old board members), I did. You guessed it, strike #3!
So what have we learned from this little exercise? First, no matter how secure your systems are, you need to make sure your process take security into account equally. Second, Capitol of Texas ISSA really needs to find a new bank. Do you have any idea how secure your bank account is?
Cryptography for Penetration Testers – OWASP AppSec NYC 2008
This presentation was on "Cryptography for Penetration Testers" and was by Chris Eng, the Senior Director of Security Research at VeraCode.
The Premise
How much do you really have to know about cryptography in order to detect and exploit crypto weaknesses in web apps.
Goals
- Learn basic techniques for identifying and analyzing cryptographic data
- Learn black-box heauristics for recorgnizing weak crypto implementation
- Apply techniques
The Crypto that Matters in 6 Short Slides
Types of Ciphers
- Block Ciphers: Operates on fixed-length groups of bits, called blocks. Block sizes vary depending on the algorithm. Several different modes of operation for encrypting messages longer than the basic block size. Example ciphers include DES, 3DES, Blowfish, AES
- Stream Ciphers: Operates on plaintext one bit at a time
Block Ciphers: Electronic Code Book (ECB) Mode
- Fixed-size blocks of plaintext are encrypted independently
- Each plaintext block is substituted with ciphertext block, like a codebook
- Weaknesses: Structure in plaintext is reflected in ciphertext. Ciphertext blocks can be modified without detection.
Bliock Ciphers: Cipher Block Chaining (CBC) Mode
- Each block of plaintext is XORed with the previous ciphertext block before being encrypted
- Change of message affects all following ciphertext blocks
- Initialization Vector (IV) is used to encrypt first block
Stream Ciphers
- Plaintext message is processed byte by byte (as a stream)
- Key scheduler algorithm generates a keystream using a key and an Initialization Vector (IV combined (XOR) with plaintext bit by bit
- Encrypt by XORing plaintext with the generated keystream
Common Crypto Mistakes
- Insecure cipher mode (usually ECB)
- Inappropriate key reuse
- Poor key selection
- Insufficient key length
- Insecure random number generation
- Proprietary or home-grown encryption algorithms (Don't do this ever!)
Analysis Techniques
Dealing with Gibberish Data
What do you do when you are pen testing a web application and you encounter data that is not easy to interpret?
- Cookies
- Hidden fields
- Query string parameters
- POST parameters
How random is it?
- Output of cryptographic algorithms should be evenly distributed, given a sufficiently large sample size.
- Tools such as ENT (http://www.fourmilab.ch/random) will calculate entropy per byte, chi-square distribution, arithmetic mean, serial correlation, etc
Observe Characteristics
Is the length a multiple of a common block size?
- Indicates that the application may be using a block cipher
Is the length the same as a known hash algorithm?
- For example, MD5 is usually represented as 32 hex characters
- May also indicate the presence of an HMAC
- Still may be worthwhile to hash various permutations of known data in case a simple unkeyed hash is being used
Stimulus, Response
Does the length of the token change based on the length of some value that you can supply?
For a block cipher, you can determine the block size by incrementing input one byte at a time and observing when the encrypted output length jumps by multiple bytes (ie, the block size)
How does the token change in response to user-supplied data?
- Figure out how changing different parts of the input affects the output
- Is more than one block affected by a single character change in the input?
Deeper Block Cipher Inspection
Are there any blocks of data that seem to repeat in the same token or over multiple tokens?
- Possibly ECB mode, this doesn't just happen by coincidence
EXAMPLE
Context: A public-facing web portal for a large ISP. Used an encrypted cookie to authenticate identity. A new cookie is issued on each request. Base64 decoded EE cookies. Divided by 8 and found 8 byte blocks. Noticed some repetition in the same position. The only variable blocks are the last two (possibly a "last accessed" timestamp or similar timeout mechanism). Register a new account with a username of 'c' x 32, the maximum length permitted, and observe the value of the EE cookie.
'c' x 32 is Perl notation for "cccccccccccccccccccccccccccccccc"
The token is longer, meaning the username is probably stored in the cookie. Still noticed repition in same position. Register another account with a username of 'c' x 16 and compare to the EE cookie generated in the previous step. Didn't see two identical blocks for 'c' x 16 and four identical blocks for 'c' x 32. Reason is padding. The username doesn't align perfectly with the block offset. Want to figure out what position in the cookie the usernaem is located. Additional user accounts were created with specific usernames in order to determine if there is any initial padding in the first block. Now you know where the username is in the ciphertext.
Able to successfully subvert the authentication mechanism without any knowledge of the algorithm or the key, based solely on observed patterns in the ciphertext. The root cause was the insecure cipher mode and the lack of a verification mechanism. ECB mode shoul dnot be used (use CBC instead).
EXAMPLE
Token values observed in URLs. Changed every time we logged on to the application. Never the same for any two sessions or any two users. Base64 decoded values for several different "stmt" tokens. Statement numbers were displayed in the browser. Looked for correlations between statement number and cipher-text. Conclusion: It looks like a stream cipher. Use XOR to calculate 10 bytes of the keystream based on the known plain-text (ie. the statement number). Now try the same things against one of the other collected tokens, such as the one called "Ctxt". Get ASCII text that allows you to infer what it would say. Expand it out more and more to get the keystream. Repeat over and over until you have enough of the key to figure out anything in the application.
Through this iterative process, we can obtain the entire keystream (or rather, a sufficient amount of the keystream to encrypt and decrypt all of the cipher-text we encounter). Can replace the statement number with another valid statement number and view the contents.
Able to subvert the encryption mechanism without any knowledge of the algorithm or the key based solely on observed patterns in the ciphertext. They were using RC4 with a unique key generated for each user session. Root cause of the vulnerability is the re-use of the keystream.
Practical Advanced Threat Modeling – OWASP AppSec NYC 2008
This presentation was by John Steven who is the Senior Director of Advanced Technology Consulting at Cigital, Inc.
What is a threat?
- An agent who attacks you?
- An attack?
- An attack's consequence?
- A risk?
What is a threat model?
- Depiction of the system's attack surface, threats who can attack the system, and assets threats may compromise.
- Some leverage risk management practices. Estimate probability of attack. Weigh impact of successful attack.
Elements of a threat model
- Structural view
- Threat actors
- Assets
- Attack vectors
- Privilege/"trust"
Threat
- Capability: Access to the system, able to reverse engineer binaries, able to sniff the network
- Skill Level: Experienced hacker, script kiddie, insiders
- Resources and Tools: Simple manual execution, distributed bot army, well-funded organization, access to private information
- Threats help encourage thorough throught about how intentions for misuse and determine "out of bounds" scenarios.
A Few Words on STRIDE
- A conceptual checklist backed by data flow diagrams
Attack Trees
- Aggregate attack possibilites
- Use OR, AND
- Allow for decoration (probability, cost, skills required, etc)
Threat Modeling as a Process
- Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.
Leading Up to Threat Modeling
- Identify threats
- Enumerate doomsday scenarios
- Document misuse/abuse
- Diagram structure, assets
- Annotate diagram with threats
- Enumerate attack vectors
- Iterate
Input: Goals, Doomsday Scenarios
Misuse/Abuse Cases (use case view and component view)
Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")
Anchor in Software Architecture
Consider where attacks occur:
- Top-down: enumerate business objects (sensitive data, privileged functionality)
- Bottom-Up: enumerate application
Output: Security Assessment & Test Design. Threat models drive assessments, Test design. Establish rules of engagement. Prioritize areas of interest. Manage a team in risk-based fashion. Establish a single tie between vulnerability and control.
Application Structure: No "One Size Fits All"
Application Structure: Topology - Coloration shows authorization by role. Arrows indicate resolution of principal/assertion propagation. Use structure to separate privilege.
Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).
Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".
Assets: Flow - Assets exist not only in rest, but also flow through the system. Use different types of flags to represent data flow of assets.
Use different colored arrows to represent each different attack vector.
Target Using Layered Attacks: Bootstrap later attacks with those that "deliver". Use one layer to exploit another (net, app). Combine attacks to reach desired target.
Take Homes
- Base threat model in software architecture
- When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
- Enumerate initial attack vectors. Use common low hanging fruit.
- Elaborate more attacks. Find opportunities for privilege escalation. Layer attacks to target or "hop" to assets. Fill in gaps by "inventing" attacks.
- Use threat modeling to drive security testing