Benchmarking Application Security Expertise!

In protecting websites, we know there is a very serious need for expertise.  What is the best way to communicate that?  Certifications are one of the only routes to establishing a benchmark for expertise in this fast paced technology driven industry.  Application security experts are in high demand- this is even called out in some of my favorite guidance language:

“individual(s) must have the proper skills and experience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings. Similarly individuals using automated tools must have the skills and knowledge to properly configure the tool and test environment, use the tool, and evaluate the results.”

Prior to now, there was only one route to really demonstrate your expertise, the CSSLP.  I am proudly submitting my latest certification for those hard earned CPEs- this cert is very relevant to today’s security landscape- I am now a certified Application Security Specialist!

Certified Application Security Specialist

I would encourage you consider pursuing this designation with the Institute for Certified Application Security Specialists.  This type of designation will give your team that edge when engaging the ‘proper skills and experience’ debate with your auditor (or in your next interview!)

Flying with Dad

So I love flying.  I grew up hearing about it in absolutely every bedtime story as a child.  This last year, I was challenged by a certain ‘colleague’ of mine to learn to fly.  (We will probably post more about that at a later date as the race to final written exams and check rides heats up!)

Anyway, it has been a life long dream of mine to fly with my dad, and actually FLY the damn plane.  Since I haven’t finished my license, I can’t sit in that left seat (the pilot’s seat)- but that day is coming.  Here is my dad taunting me:Next time I come to Texas, I’m taking this plane up for a joy ride!

Untangling ‘out of scope’ Vulnerabilities & Compliance Threats

Let’s say that we have a website that consists of many different subdomains, like this:

• http://www.example.com
• http://blogs.example.com
• http://shopping.example.com
• https://payment.example.com

All of the pages that take credit card information as input are hosted under the payment.example.com subdomain. Would XSS vulnerabilities on pages within the first 3 subdomains be issues that would/should cause the company to fail a PCI compliance audit?

Four good questions ome out of this single scenario:

1. Will a website vulnerability prevent a company from achieving PCI compliance?
   Remember the difference between validation and compliance.  PCI validation is what happens during the audit.  Picture the moment where you hand your insurance to a police officer during a routine traffic stop.  That is validation, the point in time where you are verifying the proof of insurance.  
    
   Compliance is maintaining that secured state all of the time, not just during PCI validation.  (just having your ‘proof of insurance’ card for a cancelled policy means you might sneak past validation, but you certainly are not compliant, right?)
    
   Another example would be applying your Windows service packs.  If Microsoft releases a patch the night before the auditor shows up, there is no way that patch gets applied in time to be ‘validated’.  That patch must go through testing, limited deployment, and then enterprise wide deployment.  That doesn’t mean you aren’t compliant, but you better be getting that patch deployed!          

   Continually identifying website vulnerabilities is only part of the battle.  

   A well run PCI Audit will probably be focused on ensuring the website security program is performing up to expectations established in the PCI standard.  It hopefully won’t come down to ‘we found a vulnerability, so you fail.’ (get a good PCI Qualified Security Auditor, ask for references or referrals)

2. Will a non-credit card related website be considered ‘in scope’ for PCI compliance?
   If www.example.com, shopping.example.com, or blogs.example.com has the ability to weaken the security of your  payment.example.com application- they are absolutely in scope.          

   Relationships to explore and test against will include Same Origin Policy and crossdomain.xml for starters.

    

3. Can a vulnerability in a non-payment website affect the security of the payment website?
   Absolutely. XSS + CSRF == Yes.  
4. Can a vulnerability in the non-payment website affect the compliant state of the payment website?
   Yes.  FWIW, attackers look for and explore edge cases.  If you have a poorly secured blogs.x or shopping.x that allows the ‘bad guys’ options for attack, why would they waste a bunch of time on a highly tested and secured payments website?          

   Obvious sites like https://payment.example.com are often well tested, the other ‘ignored’ sites can create or expand the attack surface against more valued sites.  Organizations often have massive volumes of unknown vulnerabilities in sites they don’t see value in testing.
   

Website security is challenging.  Building and maintaining a well balanced website security program is the key to making compliance a no-brainer.

1. Keep an inventory of all of your websites.
2. Know who ‘owns’ those sites, who is responsible for them.
3. Place a value on those websites.  A priority of sorts. Some will have a regulatory impact (like PCI), others are valued due to revenue.
4. Test the websites.  All of ’em.  Test the more valuable sites more carefully, but don’t ignore the little ones.  You cannot afford it.
5. Distribute the findings, communicate the risk, make business decisions on what to do.
6. Track and measure the success of the program.
7. Repeat!

This post is slightly modified from an email thread on the WebAppSec mailing list.  Thank-You to Joe Hargrove for the posing this question.