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

The 10000' View For Most Organizations

• Legal and Regulatory Compliance: Because we have to
• Incident Prevention, Risk Mitigation and Cost of Entry: Because this is what everyone else does
• Competitive Advantage: Really?

Regs are Not App Sec Friently...

• Regulations, contracts, and RFPs are usually based on the notion of "reasonable effort" - state regulations, HIPAA, FTC, SEC, Red Flags Rule
• When regulations do get technical, they focus on old school security fetishes like firewalls, SSL, encryption, biometric passes and server rooms

A Few Examples

• PCI Prioritized Approach
• Massachusetts 201 CMR 17.00
• The encryption exemption in state data breach notification laws
• HIPAA Notification Form
• Recent SEC Action
• Most of the contracts/RFPs/Vendor security whitepapers I have seen...

A Real World Example of Where Your PII Lives...

• Small company with a few dozen employees sells widgets over the Internet
• Pay an outsourced team to develop a Joomla/Drupal/whatever site to build a widget-lovers community where users can connect.  All sorts of PII involved in the app
• They deploy their site on a shared hosting/VPS model and basically only interact with the App from a web admin interface
• They know a bit about the technical details of their app but not much.  Actually, no actual web developers were really involved in the building or deployment of the app

Here is What Company A Did...

• Asked their developer team in India to develop code securely.  Referenced OWASP Top 10 or similar list.
• Told their dev team that services and DB users needed to run with minimum privilege.  Dev team balked.  Company A agreed to pay a bit extra.
• ...
• ...

Here's What Company B Did...

• Installed anti-virus on all employee machines
• Bought a firewall for the corporate network
• Maybe even got two-factor tokens for network access
• Made sure everything is going over SSL everywhere,.
• Put a biometric reader in the data center
• Encrypt all laptops

Company B is more likely to be in compliance with state laws and other regulations.

Company B is also more likely to suffer a data breach.

So the only thing left to finance your application security program is the "reasonable spend" argument...

As a community we need to get some consensus on what constitutes a reasonable spend...

About the OWASP Security Spending Benchmarks Project

• First survey focused on general web application spending.
• Second survey focused on cloud computing.
• Responses currently being gathered for third survey
• Approximately 50 companies profiled in each case
• We do not collect IP addresses
• Most of the partners are security vendors
• Relatively small respondent base
• Meant to stimulate a discussion on security spending benchmarks

Percentage of Development Headcount Spent on Security

• 41% had less than 2%
• 20% had 5-10%
• 18% didn't know
• 10% had 2-5%

Percentage IT Budget on Web Application Security

• 33% don't know
• 24% had 5-10%
• 12% had 1-5%
• 12% had 10-20%

Organizational Responsibility for Security Reviews

• 67% in IT Security

47% of companies surveyed provide developers with security training via internal resources.

• Organizations that have suffered a public data breach spend more on security in the development process than those that have not.
• Web application security spending is expected to either stay flat or increase in nearly two thirds of companies
• Half of respondents consider security experience important when hiring developers

Cloud Summary

• SaaaS is in much greater use than IaaS or PaaS.
• Security spending does not change significantly as a result of cloud computing.
• Organizations are not doing their homework when it comes to cloud security.
• The risk of an undetected data breach is the greatest concern with using cloud computing, closely followed by the risk of a public data breach.
• Compliance and standards requirements related to cloud computing are not well understood.

Future of Project

• Currently collecting responses for the third survey
• Partners assist in promoting survey, analyzing results, and providing strategic input
• Current status of project can always be found on OWASP website
• New partners are always welcome

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)

1. 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)
2. 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)
3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
5. 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)
6. 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.
7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
8. 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.
9. 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.
10. 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.

• Showcase great OWASP projects
• Provide the best, freely distributable application security tools/documents
• Ensure that the tools provided are easy to use as possible
• Continue to document how to use the tools and how the modules were created
• Align the tools with the OWASP Testing Guide v3 to provide maximum coverage
• Awesome training environment

330,081 total downloads as of 10/5/2009

~5,094 GB of bandwidth since launch (7/2008)

Most downloads in 1 month = 81,607 (3/2009)

Available Tools: 26 "Significant"

• Web Scarab
• Web Goat
• CAL9000
• JBroFuzz
• WSFuzzer
• Wapiti
• Burp Suite
• Paro
• Spike Proxy
• Rat Proxy
• w3af
• Grendel Scan
• Nikto
• nmap
• Zenmap
• sqlmap
• SQL Brute
• Metasploit
• ....

OWASP Documents

• Testing Guide v2 & v3
• CLASP
• Top 10 for 2007
• Top 10 for Java Enterprise Edition
• AppSec FAQ
• Books (CLASP, Top 10 2007, Top 10 + Testing + Legal, WebGoat and Web Scarab, Guide 2.0, Code Review)
• WASC Threat Classification
• OSTTMM

Where are we going?

• Project Tindy (Live CD installed to a virtual hard drive, persistence, VMware, VirtualBox, and Paralles)
• Project Aqua Dog (OWASP Live CD on a USB drive, VM install + VM engine + USB drive = mobile app sec platform, currently testing, Qemu is the current VM engine)
• Much easier URL - AppSecLive.org
• Community site around OWASP Live CD
• Online Tool DB (331+ tools)
• New release will be based on Ubuntu instead of SLAX
• Create .deb packages for every tool
• Create a repository for packages
• Add dependency info to packages
• Brings the 26,000+ existing packages to the Live CD
• More fun cool stuff like Wubi (install Ubuntu onto an existing windows desktop to be able to dual-boot without repartitioning windows)

Design Goals

• Easy for users to keep updated
• Easy for project lead to keep updated
• Easy to produce releases (every 6 months)
  • Crank out new .debs when new tool releases
  • Continually updating repository
• Focused on just application security - not general pen testing
  • Both dynamic and static tools
  • Developer tools also

OWASP Education Project

• Natural ties between these projects
  • Already being used for training classes
  • Need to coordinate efforts to make sure critical pieces aren't missing form the OWASP Live CD
  • Training environment could be customized for a particular class thanks to the individual modules
    • Student gets to take the environment home
  • As more modules come online, even more potential for cross pollination
  • Builder tools/docs only expand its reach
  • Kiosk mode?

Crazy Pie in the Sky Idea

• .deb package + auto update + categories = CD profiles
• Allows someone to customize the OWASP Live CD to their needs
• Example Profiles:
  • Whitebox testing
  • Blackbox testing
  • Static analysis
  • Targe specific (Java, .Net)

What have you done for me lately?

• For Testers/QA testers
  • Wide array of tools, preconfigured and ready to go
  • Nice "jump kit" to keep in your laptop bag
  • Great platform to test or learn the tools
• For App Sec Professionals
  • Both dynamic and static tool coverage
  • Ability to customize the job your on
• For Trainers
  • Ready to go environment for students
  • Ability to customize for the class

Get Involved

• Join the mailing list
• Post on hte AppSecLive.org forums
• Download an ISO or VM
  • Complain or praise, suggest improvements
  • Submit a bug to the Google Code site
• Create a deb package of a tool
  • How I create the debs will be documented, command by command and I'll answer questions gladly
• Suggest missing tools, docs, or links
• Do a screencast of one of the tools being used on the OWASP Live CD

Learn More

• Google "OWASP Live CD"
• Download & Community Site (http://AppSecLive.org)

Everything is stored in /opt/owasp

WAF Fallacies (at least in regards to OWASP ESAPI WAF)

• WAFs add attack surface
• WAFs can create culture problems
• WAFs can't fix business logic vulnerabilities
• WAFs are way too expensive
• WAFs complicate networks

Why fix in ESAPI WAF vs Fix in code?

• Changing in ESAPI WAF is just a text file
• Shorter gap between time discovered and WAF fix vs code fix

Advantages of WAF

• Performance - Only your rules are checked, plus state is already managed by the app server
• Capability - being closer to the app lets us do more
• Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time

Principle: Make common tasks easy, uncommon tasks possible

General virtual patching functionality is easy to understand

Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy

Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)

Can add "outbound" security as well

• Add anti-clickjacking header
• Set uniform content-type
• Add HttpOnly flag
• Add secure flag
• Detect outbound information
• Replace outbound information

Takes advantage of early failing to make rules as optimized as possible

Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):

• Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
• Unchecked Redirect
• Add HttpOnly
• Add anti-clickjacking header
• Privilege escalation

3 Different WAF Modes

• Log
• Block
• Redirect

Latency with all of the rules turned on is about 5%.  With selected rules is closer to 0%.  Basically an order of n magnitude where n is the number of rules enabled.  Comes out to milliseconds.

By the end of the presentation should be able to....

• Evaluate an organizations existing software security practices
• Build a balanced software security assurance program in well-defined iterations
• Demonstrate concrete improvements to a security assessment program
• Define and measure security-related activities throughout the organization

Lessons Learned

• Microsoft SDL
  • Heavyweight, good for large ISVs
• Touchpoints
  • High-level, not enough details to execute against
• CLASP
  • Large collection of activities, but no priority ordering
• ALL: Good for experts to use as a guide, but hard for non-security folkds to use off the shelf

Drivers for a Maturity Model

• An organization's behavior changes slowly over time
  • Changes must be iterative while working toward long-term goals
• There is no single recipe that works for all organizations
  • A solution must enable risk-based choices tailored to the organization
• Guidance related to security activities must be prescriptive
  • A solution must provide enough details for non-security-people
• Overall, must be simple, well-defined, and measurable

Therefore, a viable model must...

• Define building blocks for an assurance program
  • Delineate all functions within an organization that could be improved over time
• Define how building blocks should be combined
  • Make creating change in iterations a no-brainer

SAMM Business Functions (4 in total)

• Start with the core activities tied to any organization performing software development
• Named generically, but should resonate with any developer or manager
• Governance, Construction, Verification, Deployment

SAMM Security Practices (12 in total)

• From each of the Business Functions, 3 Security Practices are defined
• The Security Practices cover all areas relevant to software security assurance
• Each one is a 'silo' for improvement
• Governance: Strategy & Metrics, Education & Guidance, Policy & Compliance
• Construction: Threat Assessment, Security Requirements, Secure Architecture
• Verification: Design Review, Code Review, Security Testing
• Deployment: Vulnerability Management, Environment Hardening, Operational Enablement

What is "software"?

• Lots of different aspects of what software is
• Could be a tarball of source code, UML and specifications, or a server running the code

Under each Security Practice

• Three successive Objectives under each Practice define how it can be improved over time
• Level 1, Level 2, and Level 3
• "Going from crawling to walking to running"
• 72 different actives all about the size of a bread box

Per Level, SAMM defines...

• Objectives
• Activites
• Results
• Success Metrics (2-4 metrics for each objective)
• Costs (training, content, license, or buildout)
• Personnel (overhead on different roles because operating at this level)

Conducting Assessments

• SAMM includes assessment worksheets for each Security Practice

Assessment Process

• Supports both lightweight and detailed assessments
• Organizations may fall in between levels (+)

Creating Scorecards

• Gap Analysis
  • Capturing scores from detailed assessments versus expected performance levels
• Demonstrating Improvement
  • Capturing scores from before and after an iteration of assurance program buld-out
• Ongoing Measurement
  • Capturing scores over consistent tiem frames for an assurance program that is already in place

Roadmap Templates

• To make the "building blocks" usable, SAMM defines Roadmaps templates for typical kinds of organizations
  • Independent SW Vendors
  • Online Service Providers
  • Financial Services Organizations
  • Government Organizations
• Organization types chose because
  • They represent common use-cases
  • Each organization has variations in typical software-induced risk
  • Optimal creation of an assurance program is different for each

Expert Contributions

• Build based on collected experiences with 100's of organizations
  • Including security experts, developers, architects, development managers, IT managers

Industry Support

• Several case studies already
• Several more case studies underway

The OpenSAMM Project

• http://www.opensamm.org
• Dedicated to defining, improving, and testing the SAMM framework
• Always vendor-neutral, but lots of industry participation
• Targeting new releases every ~18 months
• Change management process

Future Plans

• Mappings to existing standards and regulations
• Additional roadmaps where need is identified
• Additional case studies

Jeff Williams

• Cross Site Scripting is an epidemic
• We need to view insecure software as a disgrace
• Everything OWASP is free and void of commercialism
• "When information comes with an agenda, people discount it"

Tom Brenan

Global Membership Committe 2010 Focus

• Global expansion
• 7x increase (2008)
• Vote your board members

Global Industry Committee 2010 Focus

• Building industry special interest groups
• Continuing to impact regulation (NIST, government, organizations, EU)

Dave Wichers

Global Conferences Committee 2010 Focus

• Support four global AppSec Conferences per year
• Support OWASP regional and local events worldwide

Sebastian Deleersnyder

Global Education Committee 2010 Focus

• Academic outreach
• OWASP bootcamp
• Roll out college OWASP education kits

Global Chapter Committee 2010 Focus

• Identify and reactive inactive chapters
• Actively support chapters with mentors and speakers
• College OWASP education kits

Dinis Cruz

Global Projects Committee 2010 Focus

• Apply assessment criteria version 2 to all projects
• Unified dashboard for OWASP projects
• Launch and manage 2010 season of code

This past Tuesday I presented to a crowd of about 35 people at the Austin OWASP Meeting.  The title of my presentation was "Using Proxies to Secure Applications and More".  Since so many people came up to me afterward telling me what a great presentation it was and how they learned something they can take back to the office, I decided (with a little insistance from Ernest) that it was worth putting up on SlideShare and posting to the Web Admin Blog.

The presentation starts off with a brief description of what a proxy is.  Then, I talked about the different types of proxies.  Then, the bulk of the presentation was just me giving examples and demonstrating the various proxies.  I included anonymizing proxies, reverse proxies, and intercepting proxies.  While my slides can't substitue for the actual demo, I did try to include in them what tool I used for the demo.  If you have any specific questions, please let me know.  All that said, here's the presentation.

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.

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

Lotus Notes/Domino History

Lotus Notes is client and Domino is the server.  Supports multiple protocols with one interface (HTTP, LDAP, SMTP/POP/IMAP, file sharing).  Strong on workflow application and collaborative application.  Used by .gov, .edu, .com.  Google search shows 66 million notes databases facing the internet.  People use it because it's easy to develop and deploy a simple application, granular access control, good logging method, and it integrates well with e-mails.

Notes Databases

Notes databse is building block of Domino application (.nsf or .ntf).  Notes Database is a container for data (document, message, web page), design elements (form, page, view, folder, navigator, agent, frameset, outline).

Two components in Domino server architecture.  There is an HTTP Server and a Domino Engine (URL Parser, Command Handler, and Database).

Web Access Syntax

• http://host/data/base/NotesObject?Action&Arguments
• Database = Notes Database
• NotesObject  = the web accessible design element
• Action = the action on NotesObject
• Arguments = the qualifiers for the action (optional)

Notes Database Access Control List (ACL)

• Define users and groups access privileges on the database
• Seven access levels (manager, designer, editor, author, reader, depositor, and no access)
• Eight access options for each level (create/delete documents, create/delete folders/views, create/delete agents, create/delete public documents)
• Anonymous and -Default-
• Maximum internet and password access: only works for name-password authentication but not for certificate authentication.  A web user cannot get the access greater than the "Maximum" access even if the access explicitly given is higher
• Further restriction can be done by conjunction with reader field, author field, and access list of documents for granular read and write access control

Notes Web Authentication

• Anonymous user - who does not have Person documents in DOmino Directory (names.nsf)
• Authentication occurs if anonymous access is disabled on server configuration document and Notes objects
• Name-password authentication: user/pass are authenticated to Person document and internet password in Domino directory (names.nsf).  Basic authentication and session-based authentication.  Internet password lockout function (Notes 8 only)
• SSL client certificate authentication

Common Security Mistakes in Development

1. Unauthorized Access: Anonymous access.  Anonymous privilege is assigned to Default access level if there is no anonymous group explicitly set.  Default access level is Designer and Maximum Internet and Password Access is Editor of most built-in templates.  Forceful browsing.  Solutions are to setup anonymous group and assign it "no access".  Review the ACLs of all databases and confidential documents.
2. Using Default Objects (Databases):  Default databases are statrep.nsf, schema.nsf, reports.nsf, names.nsf, log.nsf, events.nsf, doladmin.nsf, dbdirman.nsf certsrv.nsf, certlog.nsf, admin4.nsf, ...  Anonymous users should not be allowed to access these databases.
3. Default Objects (view): $DefautlView?OpenView, $DefaultNav?OpenNav, $DefaultForm?OpenForm, help?OpenHelp, $about?OpenAbout, $searchform?searchdomain, $searchform?searchsite, $searchform?searchview, $Icon?OpenIcon, $first, $file.  Solutions are to use the URL redirection and mapping on server document, customize the default pages, and apply the appropriate access control.
4. SQL Injection: Places to process User Input (@Commands, WebQueryOpen, WebQuerySave, WebQueryClose, @URLQueryString, OpenAgent, RunAgent).  Solutions is input validation in fields by formula or lotus scripts
5. Cross Site Scripting: Most cross site scripting vulnerabilities are persistent.  Solutions are to use input validaton or to HTMLencode.
6. Session Management: By default uses basic authentication.  Username and password are sent in clear-text in teh packet of every request.  Solution is to configure the server document to use session-based authentication.  Do not append sensitive data to Querystring.
7. Information Leakage: Hard coding username and password.  Solutions are to remove the sensitive information from the source code and log and customize the error message.
8. Operating System Interaction: LotusScript has system commands such as Shell, OSLoadProgram, OSLoadLibrary, FileCopy, Open, Kill, Get, Input, Close.  Solution is to hardcode the path and validate the filename input.

Testing security is challenging but it can be done:

• Lotus Notes Designer (Design Synopsis)
• Grep
• A good text editor
• Paros

References

• Secure Domino Application
• Lotus Security Handbook