Untangling ‘out of scope’ Vulnerabilities & Compliance Threats

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

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


2 Responses to “Untangling ‘out of scope’ Vulnerabilities & Compliance Threats”

  1. Rafal Los Says:

    Great post – this needs to get much more exposure. You’re outing some of the questions people have in the back of their minds but are afraid ask… either because they don’t know who to ask, or because the answers are always different…

    Again, great post, well done.

  2. modsdoday Says:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: