Web Admin Blog Real Web Admins. Real World Experience.

26Apr/111

Demanding Secure Developers

Much like many other companies these days, National Instruments hires many of our developers straight out of school. Many times when engaging with these new hire developers, I will ask them what kind of security they learned at their university. In almost all cases I've found that the answer hasn't changed since I graduated back in 2002. Occassionally I'll get a developer who mentions one particular professor or class where they discussed secure coding practices, but most of the time the answer is "I didn't learn security in school". This absolutely kills me. It's like asking an architect to design a building without them knowing anything about support structures and load distribution. The end result may look awesome on the outside, but the slightest breeze will knock it over. With computers being embedded into literally every aspect of our society, do you really want code that crumbles the moment a user does something other than what was explicitly intended?

This leads me to the conclusion that security should be considered a fundamental part of code development and not an afterthought. We should be teaching security to students at a University level so that when they graduate, corporations don't spend valuable time re-training them on proper development techniques. I've heard rumors of large companies like Oracle actually being able to impact college curriculum by telling universities they simply won't hire developers without security training. Unfortunately, most companies aren't in a position to make demands like that, but it certainly wouldn't hurt to develop relationships with faculty at your local university and tell them what you'd like to see out of their students. I did some poking around on the internet and it seems like some professors are already starting to get the memo. For example, I found a great paper written by three professors at the USAF Academy Dept. of Computer Science called Incorporating Security Issues Throughout The Computer Science Curriculum where they say:

While the general public is becoming more aware of security issues, what are our universities doing to produce graduates ready to address our security needs?  Computer science as a discipline has matured to the point that students are regularly in tructed in software engineering principles--they learn the importance of life cycle issues in the development and maintenance of software.  Where are they receiving similar instruction on security concerns in the software life cycle?  The authors propose that security should be taught throughout every computer science curriculum--that security should always be a concern and should be considered in the development of all software just as structured programming and documentation are.

Gentlemen, I couldn't agree more.  Security needs to be a foundational piece of every Computer Science program in the country.  Not one class.  Not one professor.  Secure programming techniques need to be a consideration in every CS class in every university.  Universities teach students how to write functions, create object-oriented code, and do proper documentation, but when graduates don't know the basic tenets of input validation, then we have a real problem.  If you agree with me, then I challenge you to write to the Dean of your local CS program and ask them what they are doing to ensure graduates are familiar with secure coding practices.  I'd be very interested in hearing back from you as to what their response was.

17Dec/103

Physical Security FAIL :-(

Notice anything wrong with this picture?

Iron mountain lock is unlocked.

I was walking by one of the Iron Mountain Secure Shredding bins at work one day several months ago and noticed that the lock wasn't actually locked. Being the security conscious individual that I am, I tried to latch the lock again, but the lock was so rusted that it wouldn't close as hard as I tried. I can't just leave it there like that so I call the number on the bin's label and there is an automated message that tells me that they're not taking local calls anymore and gave me a different number to try. I call that number and they ask me for my company ID number which I had no idea what it was. She informed me that without that ID number I couldn't submit a support request. I informed the lady that this bin contained sensitive personal and financial information and that the issue couldn't wait for some random company ID to be found. Fortunately, she gave in and created the support ticket for me saying that I should hear back from someone within four hours.

One week later, on Friday, Iron Mountain finally calls me back and says that they will come to replace the lock the following Monday before 5 PM. When the lock hadn't been replaced yet on Monday evening, I called Iron Mountain back up. Looking at their records, they showed that a new lock had been delivered, but they had no idea where and the signature was illegible. I work on a three-building campus with 14 floors between them and almost 3,000 people. If they can't tell me where the lock is, then there's no way for me to track it down. They said that they would investigate and call me back.

After not hearing back from them again for a couple of days, I called them back. The woman I spoke with had no real update on the investigation. She said that she would send another message "downstairs" and escalate to her supervisor. At this point it had been almost three weeks with sensitive documents sitting in a bin with a malfunctioning lock. The next day they called me back and said they were never able to track down who the new lock was left with so they would bring us a new one at no charge. Finally, after a total of 24 days with a unlocked Secure Shredding bin, Iron Mountain was able to replace the lock. Iron Mountain......FAIL.

2Jul/107

Auditors Just Don’t Understand Security

Part of my new role as the Information Security Program Owner at NI is taking care of our regulatory compliance concerns which means I spend quite a bit of time dealing with auditors. Now auditors are nice people and I want to preface what I'll say next by saying that I think auditors do perform a great service to companies. I'm sure that most of them are hard-workers and understand compliance requirements probably better than I do, but they just don't understand security.

As a case in point, we're in the middle of our annual audit by one of those "Big Four" audit firms which I won't name here to protect the innocent. I sent an email checking in with our auditors to make sure that they had everything they needed before we went into our four-day holiday weekend. They said that they had received everything they needed except for documentation on "privileged users from the current OS and Database environments" as well as "evidence of current password settings from the application servers, OS, and Database". We go through a round of translation from Auditorese to Techie and figure out that they want exports of some specific user, profile, role, and privilege tables from the database and copies of /etc/passwd, /etc/shadow, and /etc group from the servers.

So we obtain the requested documentation and I shoot them back an email message to find out their proposed method for transferring the files. Secure FTP? No. PGP encryption? Nope. Their response back was astonishing:

How large do you think they'll be? Email should be fine.

Seriously? These are the guys that we're paying to verify that we're properly protecting our systems and they're suggesting that sending our usernames and password hashes via cleartext email is an appropriate method of file transfer. I respond back:

I'm not really concerned about the size of the files, but rather, the data that they contain. Sending files containing the users, groups, and password hashes for our financial systems via cleartext is probably not a good plan considering the point of this process is protecting that data.

And they respond with:

Whatever you'd like Josh. As long as you have the files as of today, we're good.

So now I'm convinced that auditors (or at least these auditors) view security as nothing more than a checklist. The people telling me what I need to do in order to protect my systems really have no clue about the fundamentals of security. If it's not on their checklist, then it must not be of importance. In this particular situation it may be easier or more convenient to send the documents via email, but any security professional worth their salt would tell you that's not secure nor appropriate for that data. Either our auditors hold themselves to a very different standard than the rest of us security professionals or they just don't understand security unless it's on a checklist.

13Nov/090

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
13Nov/090

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
13Nov/090

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)
  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.

13Nov/090

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

  1. Metrics quantify the otherwise unquantifiable
  2. Metrics can show trends and trends matter more than measurements do
  3. Metrics can show if we are doing a good job or bad job
  4. Metrics can show if you have no idea where you are
  5. Metrics establish where "You are here" really is
  6. Metrics build bridges to managers
  7. Metrics allow cross sectional comparisons
  8. Metrics set targets
  9. Metrics benchmark yourself against the opposition
  10. 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
13Nov/090

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
12Nov/090

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
12Nov/090

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)