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.
How nice blog You have written!. I will share it with others.
ReplyDeleteFeelcurisity to visitgood business security system
It feels so nice to find somebody with some original thought on this subject. Really helpful to you for starting this security solutions ct.
ReplyDeleteHi,
ReplyDeleteThanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.
Attestation Of Compliance