Wireless scanning - PCI DSS requirement 11.1

Requirement 11.1 of the PCI DSS requires scanning for rogue wireless access points. The risk identified here is that some miscreant will connect a rogue wireless access point to your environment, then sit in their car outside and sniff information with the goal of intercepting passwords and other sensitive information so he/she can steal cardholder data.  This is an understandable view, don’t get me wrong, but it’s a limited view.   The control is there to mitigate the risk of any miscreant doing it, as an internal or external risk, as it is far easier for a member of staff to gain access to the office environment and plug a rogue device in than an external third party.

The requirement is as follows:

“11.1 Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis.

Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify any unauthorized devices.”

The methods above are slightly expanded from the methods enumerated in PCI DSS v1.2 and provide a bit more flexibility to merchants and service providers. In July 2009, the PCI SSC released an Information Supplement on PCI DSS Wireless Guidance prepared by the Wireless Special Interest Group. As that is a document just over 30 pages, I'll try to keep this short and sweet. If you're interested that document is available here: https://www.pcisecuritystandards.org/pdfs/PCI_DSS_Wireless_Guidelines.pdf

I'm going to go through the testing procedures for this requirement one by one for completion. However, only 11.1.b requires any real activity!

11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.

This is simply about incorporating the Wireless Scanning requirements in an appropriate policy (such as a Security Testing Policy).  A quarterly process that identifies the controls to be implemented should be documented, and the required evidence and control forms referenced.  The adequacy of the process is assessed in 11.1.b.

“11.1.b Verify that the methodology is adequate to detect and identify any unauthorized wireless access points, including at least the following:

 WLAN cards inserted into system components

 Portable wireless devices connected to system components (for example, by USB, etc.)

 Wireless devices attached to a network port or network device”

If you use wireless devices, these should all be documented as part of the asset inventory.  A simple process to validate the status of devices on the inventory against the active devices provides a good basis for control.  Also look to the wireless systems implemented to provide you with additional functionality to manage PCI DSS requirements. 

Network ports should be activated for required use only and a check of LAN and switch ports should be performed to verify only required devices are connected. E.g. if you have 10 servers and a firewall, you should probably have 11 cables going into your switch. While I know this is horribly difficult to monitor in many server rooms that are a cabling nightmare, tidy cabling can be a separate goal in itself and will not to be further discussed here!

Network Access Control can provide a simple solution to the issue, although with a heftier price tag.  Any investment should be decided based on the requirements of the business rather than solely on compliance requirements. Technology alone does not solve the problem; it must be configured and maintained.

Regular system users should not be permitted to install Plug'N'Play devices to their systems. Role Based Access Control is already required within the PCI DSS requirements and this is something that is fairly easy to lock down in most environments (usually via group policy).  Only devices that require and have authorised wireless access should have wireless configuration system services available.

On top of the normal physical security controls associated with a data centre or networking cabinet, racks should be locked and an eyes-on review should verify whether additional hardware has been introduced.

In terms of using tools an option which only requires configuration and some training is the use of the nmap scanner with the -O switch to identify wireless access points. The traditional use of WiFi analysers such as NetStumbler or Kismet will also assist you in establishing the wireless baseline of surrounding areas.  Once the baseline is established, monitoring can be based on any identified changes.

The requirement does not specify all of the above need to be implemented. This is here to provide a flavour of the measures available to demonstrate compliance.  The controls that are implemented must be effective; simply walking around once a quarter with a wireless scanner without direction does not provide adequate control. It is important to note the requirement calls for a methodology.

11.1.c Verify that the documented process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities.

If the environment is split over many sites or locations, the processes must be sufficient to cover the locations included within the scope of compliance, not just the sampled locations.  If a third party hosting company is used as a Service Provider someone must be responsible for the controls at this location.

11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to personnel.

If you are using a Wireless IPS (WIPS), configure the settings to email or otherwise alert the appropriate security personnel if rogue access points are introduced to the environment.

11.1.e Verify the organization’s incident response plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected.

The whole process is broken if the people that you rely on to implement the controls do not know what to do in the case of exceptions.  It is important for these controls to filter into the incident response framework.  Incident response should include a provision for the processes to be followed for alerts about possible use of rogue devices, and invocation procedures if the presence of a rogue device is confirmed.

UK Government release 10 Steps to Cyber Security advice sheet

The UK government via CESG, the Information Security Arm of GCHQ, have recently released a document entitled “10 Steps to Cyber Security”. The full document is available at http://www.bis.gov.uk/assets/biscore/business-sectors/docs/0-9/12-1121-10-steps-to-cyber-security-advice-sheets.pdf

The 10 areas of focus within the document are given two pages each for further review and are as follows:

• Home and Mobile Working
• User Education and Awareness
• Incident Management
• Information Risk Management Regime
• Managing User Privileges
• Removable Media Controls
• Monitoring
• Secure Configuration
• Malware Protection
• Network Security

Overall, it is very important that the government are being proactive in highlighting the online threat landscape for businesses and references to control frameworks such as ISO 27000 are welcome. On the other hand, the fact that 3rd party service providers and [often exploited] online interfaces are not referenced appears to be a massive oversight. Unfortunately, many of the control frameworks are not easily found online. For example, the controls referenced are familiar from the PCI DSS, ISO 27000, the Code of Connection, Public Sector Network and IL3 requirements. Not all of these standards are freely distributed.

Sources of training and other informational material for the above would also be of enormous value to those perusing the document as otherwise, it appears to come to a ‘dead end’. Use of SANS, NIST and CIS for secure systems baselines and the ‘Think Privacy’ campaign for user awareness are examples of excellent resources. Achieving other controls through the implementation of sound and considered policies for users, passwords and audit logs can also use the SANS, NIST and CIS documents as well as Microsoft and other online resources.

Deep INTEL Day two

Another good day at DeepINTEL, combination of talks on APTs, security intelligence gathering, social media and evasion techniques.

So if I had to pick my two favourites (other than yours finux!) from day 2 it would be

Massive Storage - Richard Perlotto (of Shadow Server fame)

Richard's talk had tech-awesomeness stamped right through it.  The Shadow Server Foundation does some really cool analysis and intelligence gathering.  Have a look at their site to get a good idea, I'll never do it justice here. http://www.shadowserver.org/wiki/.  Richard went into the details on how they handle the sheer volume of data that they have to work with.  We're talking petabyte storage requirements without EVAs or SANs, relational databases are out,  Hadoop HDFS and Casandra are in, and some custom software to do even more index and data management.  Without doubt my favourite slide was the server density pic, where they show the servers are mounted vertically rather than horizontally as this allows more to be squeezed into a rack.  The shelves were straining and lights were flashing.  Couldn't look at it without wanting one!

Facebook and you - Jonathon Deutsch

Here's Johnny!  Nicely delivered presentation showing how intelligence gathering can be done by the various government agencies by crawling through Facebook profiles and the default settings for friend lists.  The concept of Facebook-hardening was interesting although quite counter to what facebook is all about.  Some good examples of where certain nation states had crafted fake profiles to try to get intel on military personnel.


The day has been stacked with discussion on mass malware, advanced persistent threats, and how to respond to them.  Add in some antivirus evasion and DNS tunnelling examples and the audience were well engaged.

Hope I get to speak at a Deepsec event again, the guys run a good con.  Everything ran really smoothly, scheduling was kept on top of and the venue was top notch.  Highly recommended.

Deep INTEL - Day one

The guys from DeepSec have done a great job with the DeepINTEL conference.  Well organised, great location and a good speaker line up.  They kindly let me talk about the importance of breach disclosure, so I gave an updated version of the Athcon talk incorporating some of the feedback and post con chatter.

Quick summary of my favourite presentations from day one.

Wargames in the fifth domain - Karin Kosina

Karin gave a really great presentation on the concept and notions of "cyberwar" or what it isn't really.  When the slides go out I highly recommend a read through them as it was well delivered and referenced.  Covering the various international treaties and conventions on what actually constitutes war and the acts of violence that constitute force.

I think the biggest take away point for me from Karin's talk was that most of the rhetoric on cyber war actually describes electronic espionage (I'm going to stop saying cyber now!). Very few instances of damage have occurred that would constitute violence in order for the act to be considered war.

Hopefully I'll manage to get her to co-author the piece I'm writing on collateral damage from electronic espionage


Sexy Defence - Maximising the home field advantage - Iftach Ian Amit

Some really interesting content from Ian on establishing a culture of counter intelligence and investigating what the legal extent of certain counter ops are, as well as the benefits of sensible risk based pen-testing.  Good demo on poisoning malware to give it a signature that is easily detectable, that helps verify that your source of intelligence on threats is accurate, and also enables it to be blocked with a custom IDS signature.  I think that the Bsides Dallas crew might have pinched Ian's subject as the theme for their CFP is just called "sexy defence"!

Picking two favourites from the day two line up could be tricky as there does appear to be some good subjects on the roster.

Some thoughts on PTPE

In recent years there has been much discussion about the use of Point-To-Point Encryption (PTPE or P2PE) as a method for minimising the scope of compliance requirements for merchants. Effectively this works as follows: 

- Merchant has a Point of Interaction such as a PIN Entry Device which encrypts cardholder data using keys to which the merchant has no access.

- Encrypted cardholder data is transmitted from the merchant environment to the service provider’s environment

- Encrypted cardholder data is decrypted by the service provider using a HSM and sent for authorisation

Authorisation message is sent back to the merchant

In the above process, the merchant has no access to cardholder data or any of the keys that do any of the encryption, at any time.   This is a hugely important part of the process, as a number of discussions were had about using other types of encryption for securing the data.  In a PTPE environment the card data confidentiality is maintained using encryption and responsibility for the key management techniques is transferred to a third party.   According to the current release from the PCI Council, only a hardware to hardware implementation of the above solution can achieve scope reduction. This means that all encryption takes place within a PTS validated terminal which is approved for SRED (Secure Read and Exchange of Data) and Open Protocols (if using IP communications) modules and all decryption takes place within a Host Security Module (HSM) in the service provider’s environment.

I’ll go further into the P2PE requirements overview in a moment but it’s worth pointing something out here.

A service provider can provide a solution to a merchant whereby cardholder data is encrypted in the terminal and decrypted in the service provider’s environment. The merchant and service provider can be PCI DSS compliant and the service does not have to be validated and certified as a PTPE solution. The benefit of a validated PTPE solution is that a merchant can effectively write off their face to face channel’s PCI scope and much of the risk while relying on the service provider’s validated solution. If a merchant uses a PTPE solution which is not listed with the SSC, that merchant will need to complete an applicable SAQ depending on the environment or a RoC depending on transaction volumes.

The PTPE requirements are split across 6 domains. In a nutshell, these are as follows:

Domain 1: a POI which is PTS (PIN Transaction Security) 2.0 or PTS 3.0 validated with the SRED module validated and enabled and Open Protocols listed and enabled if the terminal uses IP must be used as part of a P2PE solution.

Domain 2: any application on the PTS PED (PIN Entry Device) must be validated by a PA-QSA (PTPE). Such validation must be performed for applications which do and which do not handle cardholder data.

Domain 3: the POI (Point Of Interaction) device must be secured at all times. This includes inventories, physical security and transport controls.

Domain 4: this domain covers segmentation between encryption and decryption environments and is not currently in scope as the standard is hardware/hardware only. This will be elaborated upon for hybrid environments when such may be approved.

Domain 5: the decryption environment must be PCI DSS compliant and must use secured and approved decryption devices. Physical security and inventories are again prominent here.

Domain 6: management of encryption keys is detailed here and is far more complete than you may be familiar with from requirement 3 of the PCI DSS.

Domain 6 also contains 2 annexes:

Annex A: Cryptographic Key Operations for Symmetric-Key Distribution using Asymmetric Techniques

Annex B: Cryptographic Key Operations for Key-Injection Facilities

The PCI SSC has clearly put a lot of work into this standard and there is pretty much no room for interpretation. The exams are a test of knowledge much more so than the standard QSA exams. While there are currently no validated PTPE solutions as yet, this will be an interesting areas to watch develop.

My considerations are:

Service providers able to provide this service in Europe may become an oligopoly (at least in Europe). I’ve heard rumours of terminal providers restricting the ability to install custom applications.

However, this could also become a very disruptive technology in the market, allowing smaller terminal manufacturers to team up with smaller payment processors and enter the face to face payment market.

There is an opt-out clause available to merchants whereby they can disable the encryption mechanism in the PTPE solution. This is effectively a ‘KILL’ switch and requires the merchant to accept responsibility to use alternative controls and/or processing method. I imagine the problem threshold to affect this should be pretty high and controlled! There’s not much detail as to how this would work in practice.