Vulnerability Scanning for PCI DSS Compliance

Maintaining compliance with PCI DSS requirements for vulnerability scanning can present a number of challenges for companies.  This blog post is aimed at tackling the challenges of vulnerability scanning and present ideas for managing the process, as well as evidencing it to your QSA.

The best starting point is to define the process for vulnerability scanning.  PCI DSS requires the following:

• Scans are performed at least quarterly
• Scans must be performed by a qualified resource for internal scans (not required to be an ASV) and by an Approved Scanning Vendor (ASV) for external scans
• External vulnerability scans must satisfy the ASV program requirements
• Scans must be performed after significant change in the environment
• Scans must achieve a passing score (as defined in ASV requirements for external scans, and by having no vulnerabilities ranked as ‘high’ for internal scans)

These guidelines provide the control requirements for the vulnerability scanning process within an organisation. Establishing a process to satisfy those requirements can be difficult, because of size, complexity or architectures that have been implemented.

When it comes to vulnerability scanning, it is much like any other job you would rather ignore; the longer you leave it the more time, effort and interruption it causes when you want or need to be doing something else.  Scanning more regularly, such as monthly, is often touted by QSAs as being a good way to manage the process (and it is) but it will not deliver the added benefits unless configurations and security patching are managed correctly. 

In order to perform a scan, you need to have identified what systems are in scope for your internal and external scans and to have created the appropriate profiles in the scanning configuration. Implementing network segmentation can reduce the number of systems which need to be scanned.  For the ASV scan, your ASV provider, under the PCI SSC ASV Program Guidelines requires the following:

• Information about any scoping discrepancies must be indicated on the Attestation of Scan Compliance cover sheet under heading "Number of components found by ASV but not scanned because scan customer confirmed components were out of scope ". This information should NOT be factored into the compliance status:
• Include any IP address or domain that was previously provided to the ASV that has been removed at the request of the customer
• For each domain provided, look up the IP address of the domain to determine if it was already provided by the customer
• For each domain provided, perform a DNS forward lookup of common host-names – like ―www,‖ ―mail,‖ etc. – that were not provided by the customer
• Identify any IPs found during MX record DNS lookup
• Identify any IPs outside of scope reached via web redirects from in scope web-servers (includes all forms of redirect including: JavaScript, Meta redirect and HTTP codes 30x)
• Match domains found during crawling to user supplied domains to find undocumented domains belonging to the customer

I mention this because I can only name a few ASVs that I have worked with through my clients who have demonstrated the processes identified above.  Just to note the requirements of the vulnerability scanning processes require the organisation or scan customer to acknowledge its responsibility to manage scope, and obligation to properly inform the ASV provider about your environment, including any local or external load balancers that may impact the scanning process.

For internal vulnerability scanning the chosen solution should be managed by someone who is able to demonstrate sufficient knowledge to perform the process.  In order to achieve this, the scope of scanning should be approved within the governance framework of the organisation, and implemented within the chosen solution.  The reports should always be passed back to the team responsible for the process.

There are a number of tools available, from managed and hosted solutions to customer implementations and free open source tools.  I have been to clients with 100+ servers in scope for PCI DSS assessment and have observed they are using scanning tools which do not facilitate ease of issues review or remediation management. If you want to scan large environments, investing in a tool which provides the business useable reports is a must as, in the early days of this process, remediation will likely be rather time consuming.  All of the findings within the reports should be considered for action, even if they are informational issues.  

When assets are identified for scanning they should be assigned an owner; this is the person who investigates the remediation plan for the identified issue and documents the relevant change control documentation to ensure the fixes are implemented.  This is where functionality of the tools selected to assist the business in maintaining compliance has to be considered. I am always amazed at how limited the functionality is of some solutions, such as only providing a PDF report, or CSV format download. It just makes the job harder!  A solution that can mirror the internal governance structure of an organisation can save time, meetings and other resources by just adding some work flow. 

Managing the identified issues from a scan is important, especially when a failure is noted.  Failures, as mentioned above, are in the instance of external scans anything with a CVSS baseline score over 4.0 and for internal scans any issues identified as ‘high’.  The ASV program guide suggests organisations attempt to address issues based on the CVSS scoring.  Any issues that have a failure implication need to have the following:

• Root cause analysis (newly identified issue, security misconfiguration etc
• Action plan for remediation
• Communication and assessment of compensating controls (for external scans this is completed with   the ASV)
• Change Management documentation

It is not just the changing security landscape that needs to be managed for vulnerabilities.  Changes made to the environment, such as addition of new servers, or new applications should always result in security testing being completed.  Prior to any other security testing, a full vulnerability scan on internal and external changes should be completed.  This should be the case even if you are going to complete penetration testing, as this will ensure that the tester’s time is spent on harder tasks rather than on the ‘low hanging fruit’.

Where an organisation has established and embedded change management procedures and governance structures such as a Change Advisory Board, these should be closely aligned and involved in the vulnerability scanning process. The ability to manage changes in the environment securely and in line with company processes will provide key documented evidence to the QSA that robust processes are in operation.

Part two of this post will cover the following item in more detail than they have been touched on in this post:

• How do you know you’re doing it right?
• Scan profiles
• False positives
• Compensating controls

Documentation in a Business Environment

Documentation is just as important as correctly securing a technology, without it the details can stay inside peoples heads, which can lead to it being forgotten or easily leaving an organisation.  Let’s look at how to do it, so it is both useful and meets our compliance or regulatory requirements.

Before looking any further it is important to understand the different types of documentation, so you can understand what a standard such as PCI DSS is actually requires from you:

Policy: Policy is management’s way to direct staff to do something, or to set expectations for something such as a certain level of control.    An information security policy is the starting point of an organisations commitment to managing security risks. 

Procedure: A procedure is defined as a detailed description of the steps necessary to perform specific operation.  To take this further a procedure is how you as a business are going to implement the desired level of control.  This can be seen as the business response to the management objective set in a policy.  A procedure can also be the operation of a specific control.  In some cases a specific procedure to detail the correct way a set of actions should be performed.

Standard: A standard is a set of rules or specifications that, when implemented together define a software or hardware asset.  The make it compliant blog has already completed a guide on defining configuration standards; this forms a really good basis for a standards document (but I may be biasedJ).  A key point to note with standards is there should be a defined exception handling and authorisation process; because we all know that it is not always possible to implement every detail all the time. 

Guidelines:  These are suggested actions or recommendations related to an area of a policy that may supplement a procedure.  Unlike a standard, implementation of guidelines may be at the reader’s discretion.  For example a policy statement may state that employees are required to wear identification at all times, a guideline may outline that the acceptable wearing is either on a neck tie or a pass holder; often directing the user where to request or find supplies of these.

Form: A policy may state a requirement for records to be maintained of control implementation, the best way to record this is through the completion of a form.  A procedure would define the level of detail required to be completed within a form and the required management authorisations to be captured.  Forms can be paper based or electronic, but they are useless if they are not maintained.

Presenting an auditor or assessor with a good set of structured documentation is an excellent way to start presenting your business as meeting the spirit and intent of many compliance and certification requirements.  If your documentation is a mess, one’s first impression is that your environment is going to reflect this. 

Some believe that having a 100 page policy document is not a good move, and some will argue if it is the one source of information people always know where to look.  I think that this is never going to be resolved, especially here.  The truth is it doesn’t really matter as long as the target audience can navigate it and understand it, and the key to this is referencing. 

A policy document should identify supporting procedure documentation when required; a procedure should identify the applicable standards, and so on.  If you have a 100 page policy document you should reference procedures as you go.  If you have independent documentation, then these can be referenced at the end. 

Assigning an owner to a document is a requirement to show that controls are owned, this creates accountability within the business.  Controls are only ever implemented when people are informed and aware of their responsibilities..  This is why hierarchy is important in documentation, and assignment of responsibilities starts at the executive level, tone at the top is important to ensure that staff at all levels understand the business requirements, especially for security.  A simple responsibilities matrix across the documentation of a business can be an excellent tool to help capture and define accountability and responsibility.

Make it clear who the target audience for the document is, make sure it is available to them, they know where to find it and can reference it easily.  Making documentation that is applicable to the staff and can be maintained by them is important.  Documentation for compliance is not a one off exercise; it must be demonstrably maintained during the year. 

Documentation should also identify the expected frequency of the control’s operation and associated reporting criteria.  The reporting criteria should include metrics that allow the effectiveness of the control(s) to be measured.  Having good management information about compliance before assessments ensures that there are no surprises.  If there has been notification about control failure or a noted issue, management can prepare a response. 

Management of exceptions is especially important when dealing with a control based assessment such as PCI DSS, if a control is not in place non-compliance must be noted.  The PCI DSS allows for compensating controls to be noted to assist in areas of non-compliance; however these are not just documentation. The compensating controls should produce evidence to show that you have been managing the risk, and will continue to do so once the assessment has finished.

Documentation should also identify where management information on controls are reported.  Not all information is required at Executive level. To ensure effective sponsorship and engagement in information security only relevant information should be provided.  Control failure tolerances should be defined this too can impact on reporting lines.  Some people only need to know about failure.  The most important part is that someone knows and is taking the necessary action.  This is the control owners’ responsibility to delegate, either to individual functions or the governance structures of a business, such as a security committee or risk committee. 

Valuing data - should we have a minimum value?

How much is your data worth, do you know and how do you work it out?
One of the points I tried to make during my breach disclosure presentation at AthCon'12 was the need for some regulated standard for the value of personal data.  I wanted to state the importance of setting a value for data so that the value can be used to help estimate how much protection it needs.


For example - if you are the proud owner of 1961 E-type Jag a quick shufti on autotrader will tell you that these are valued at around £129,000, and a '72 model around £100k less at £27,000.
Ok, where am I going with this little de-tour into classic cars?  Within a few clicks of a mouse I've got a rough idea of what my asset is valued at.  If I wanted to, I could fill out the forms on one of the many comparison sites and get a quote for car insurance, a few clicks later and I know how much a third party is going to charge me to accept the risk of damage/theft/fire etc...


If only information security was that simple, but it isn't.  The threats we have to manage change daily, risk mitigation is complex and often a seemingly unachievable, endless battle.  The risk focused CISO could easily be forgiven for finding themselves in a spin.  Buzzwords are a plenty, opinions can vary, and technology is only half the battle! 
To make things worse it is hard to value data.  As is often said, you wouldn't spend a £100 to protect an asset valued at £1.  But how do we know how much data is worth?  The problem with data is its worth different things to different people.  We can't just use a "market" valuation in the same way we can with the great e-type.  Your customer data may be hugely valuable to you in some instances and of no value to you in others.  However it is always of value to the customer in terms of their privacy.  That is the regulators responsibility to uphold.  Even if the customer doesn't care, the regulator is responsible to make sure that there are some principles that are adhered to.  We know personal data is worth less than sensitive data in respect to the Data Protection Act and there is a maximum fine of £500,000 from the ICO.  Sometimes it feels like that is about as much as we have to work with.  No comparison sites, no defined minimum value.  Confused?(.com)


One of the reasons I think the PCI DSS got traction in its early days was that the data was given a value, $25 per card if memory serves me correctly, based on the cost of re-issuing a card.  Couple this with the cost of any fraud committed and then perhaps a fine for none compliance and value can be quantified.  If you store 100,000 card numbers, that data (then) would be worth at least $2.5m+.  From here the business case for a security standard is born.  


Personal data on the other hand seems to be something of a quandary.  If we review the monetary penalty notices by the ICO you will start to see what I mean.
Recently there was a fine issued to Brighton and Sussex University Hospitals for £325,000 for not controlling the destruction of highly sensitive data properly.  Circa 70,000 records with highly sensitive medical data were lost.  So this equates to £4.60 per record.  Which seems very low for information related to an individuals sexual health and preference.


A £90,000 fine was issued to Central London Community Healthcare NHS Trust for the loss/inappropriate transmission of 59 faxes containing information relating to medical diagnosis and palliative care info (£1525 per fax).


Looking at the less sensitive data is even less helpful.  When a gambling industry worker sold over 65,000 records from an online bingo company for in the region of £25,000 (according to the ICO) he received a conditional discharge and was ordered to pay £1,700 as well as £830.80 costs.


The case of the bingo-bandit highlights a significant problem.  The organisation who had the data stolen couldn't/didn't determine the perpetrator and the punishment levied against the buyer wasn't really proportionate to the value the data had to him.


If the ICO were able to set a minimum value for a personal record and a minimum value for a sensitive record they could then set expectations of what reasonable controls are for that data.  This could then be based on the data's minimum value.  In the event of a loss of that data, the ICO could say X records multiplied by value A is my starting point.  Then apply a distress factor, and perhaps a responsibility factor (how well controlled, etc etc) - this would then give people and indicator.  These factors in the multiplier could be used to dictate behaviours.  E.g. organisations that come forward openly, and demonstrate transparency should be rewarded (in my opinion) as this allows the situation to be dealt swiftly and with in the interests of the data subject at the centre.

Are you ready for the Olympics?

The Olympics is coming, are you ready ?


Now, I'm not talking about your 100m personal best or whether you are a medal contender.  Unfortunately I'm talking about heightened risk of cyber security incidents.  During the Beijing Olympics there were 12 million cyber security incidents.  We should use that as the bench mark for our risk management for the London 2012 games.


The London Olympics has the potential to be an incredible event attracting people from all over the world to the UK.  With this unfortunately comes a heightened level of risk.  The UK.gov is already planning to fly combat planes in London airspace and is clearly concerned about the risk of a terrorist attack, as well as cyber attack.  UK.gov is working on the assumption that the threat level will be severe but with a focus on the games taking place come what may.


With a potentially reduced work force it will even more important to ensure that information security controls don't slip. Olympic phishing attacks are likely to be prevalent, no doubt offering access to events or tickets - these could be laced with malware or end up compromising sensitive information from your staff or customers.


Sensible steps to take -


Ensure that you have cover for staff responsible for authorising changes to IT infrastructure and be prepared to limit the number of IT changes during the games period.


Compliance controls - if you have recurring compliance controls that are likely to fall within the games period ensure someone is specifically tasked with staying on top of them and has a deputy.  External and internal vulnerability scans, patching and AV should all be kept up to date particularly if you are subject to PCI DSS.  Resist the temptation to open up your outbound internet access so that staff can access streaming sites from their PCs.  This can make matters worse if you get hit by some rogue malware.  A couple of TVs in the office may be a better solution - see below.

Plan for multiple types of incident, and ensure you have contingency for the assets that may be affected (Staff, internet, telecoms, IT etc)  Ensure that all staff know how to respond and are empowered to do so - consider adding social media engagement to your incident response plan, this can be a good way to get the message out on mass quickly from and too multiple types of devices.  Neira Jones of Barclaycard has a good blog post on that subject here.  


For those taking card payments who are serving the tourist community attending the games, there is probably going to be increased risk of payment fraud.  Cards from various parts of the world that may normally be declined are likely to be in use by tourists and fraudsters.  Make sure your staff are kept up to date and take additional steps if necessary to verify the card holder identity.  Have a quick chat with your acquiring bank to see if there is any advice they can offer and to understand what your responsibilities are.


Engage employees and customers!  Whilst this might seem slightly off topic for an infosec post I'd suggest finding a way to get your staff engaged in the Olympic celebrations whilst at work.  It is highly likely that a number of people will have taken annual leave and unauthorised absence may be higher than usual.  A couple of live TV feeds and positive acceptance that the games is going on might be enough to stop the odd straggler from an unauthorised absence when there is a big event.  Travel in London is likely to be slower and busier than normal, expect more remote working requests or delays in people getting to the office.


As a real example, I was in Portugal during the 2010 World cup working at a client site when Portugal beat North Korea 7-0.  Anyone who wanted to watch the game was given a free pass to do so by the operations manager, who had arranged a TV to be set up in the board room and a stack of pizza for everyone.  She had a full office every day I was there.  Contractors were invited as were clients and everyone enjoyed the atmosphere.


For those of you looking to be a little more pro-active, now is the time to be reviewing information security policies and procedures, updating risk assessments and incident response plans and ensuring you have up to date contacts with suppliers, third parties and any contractors.  They should be thinking about this too. 




Still 64 days to go ......


Andy