Removing The Drama Of A PCI DSS Assessment

I had to prepare a presentation for a client a while back giving them some tips on how to prepare and get through a PCI assessment as easy as possible.  I thought it might be good to share those thoughts.

Trust But Verify

This famous quote from US President Ronald Reagan is the mantra of a PCI assessment.

The PCI DSS is based on the “trust” that organizations are complying with the PCI DSS.  However self-assessment processes and QSAs are used to “verify” that the organization is, in fact, complying with the PCI DSS.  As a result, the organization being assessed not only has to produce documentation to that effect, but the QSA must also observe that the PCI DSS requirements are being followed.

The net is that, just because you say something is fact, your QSA must substantiate your statements so that they, too, will treat them as fact.  If you remember nothing else but this simple truth, you will understand why a QSA must do what they do.

Scope

If PCI assessments go wrong for any reason, this is probably the primary reason.  It fascinates me that people often profess ignorance of the PCI DSS, yet somehow become experts on the subject when it comes to scoping.

Remember point number one, trust but verify.  Under that premise, the PCI SSC makes a QSA’s primary responsibility to confirm the scope of the PCI assessment as they verify the facts.  As a result, in order to confirm that scope, the QSA must look at everything and then, through investigation and evaluation, determine that the areas you deem out of scope are, in fact, truly out of scope.

Let your QSA ask their questions and conduct their observations without arguing with them about scope.  They are only doing this because they are required to confirm the facts and your fighting with them about scope is only going to making them wonder what you are trying to hide.  The bottom line is that arguing with your QSA about scope only makes your assessment all the more painful and time consuming.

If you truly want to avoid arguing over scoping, get a copy of the Open Source PCI Scoping Toolkit.  Go through your environment and determine the categories of all of your systems and networks.  This is a good annual exercise because you need to prove your scope every year.

Applicability

According to the PCI SSC, there are five PCI DSS requirements that can never, ever be marked as ‘Not Applicable’: 1.2.3, 3.2.1, 3.2.2, 3.2.3 and 11.1.  I have discussed these all before but they deserve another quick discussion here.

Clients will argue ad nauseam that wireless is not implemented or is out of scope and therefore refuse to discuss wireless.  For requirement 1.2.3, a QSA is required to document the procedures they followed to rule wireless in or out of scope.  That of course means the QSA must investigate any wireless networks and evaluate if the controls are rigorous enough to keep wireless out of scope.  For requirement 11.1, the QSA must investigate and evaluate if the organization’s controls surrounding the detection of rogue wireless are appropriate regardless of whether or not the organization has implemented wireless networking.

3.2.1, 3.2.2 and 3.2.3 are all related to the securing of cardholder data when it is stored.  Even if an organization is not storing cardholder data on their systems, a QSA must document the procedures they used to confirm that cardholder data is not stored on the organization’s systems.  This usually involves a review of flat files and database schemas and the running of utilities and queries against those systems and databases looking for cardholder data.

The bottom line is do not argue about something being ‘Not Applicable’ and then hinder the QSA’s investigation to prove it is ‘Not Applicable’.  Do not get me wrong, you need to keep your QSA on point, but remember that QSAs are required to evaluate the situation and then document the process used to determine that a particular requirement is ‘Not Applicable’.  All you do by complicating that investigation is add more time to your assessment and, potentially, cause a requirement to be marked as ‘Not In Place’ instead of ‘Not Applicable’.

Yes, I Did Kind Of Ask That Earlier

Like security, the PCI DSS also works from a ‘defense in depth’ approach.  A lot of the questions QSAs ask are very similar just asked from a different perspective.  The people that develop assessment and audit programs will tell you that this is the most effective way to uncover the level of compliance with a given program.  The reason is that organizations who have not integrated a compliance program into their day-to-day operations will typically provide inconsistent or confusing answers to the similar questions.  Not that this is a perfect technique mind you, but it does work the majority of the time.

Please be patient with your QSA.  They did not write these procedures, but they are required to execute them.

Answer The Question

Most people suck when being questioned, particularly in a legal proceeding, including yours truly.  Lawyers always instruct anyone that will be called to testify in a legal proceeding to take their time, focus on the question being asked and only answer the question being asked.  Never, ever, ever provide any information outside of the question, i.e., do not elaborate.  The trouble is that lawyers know that silence is a vacuum and it is human nature to fill that vacuum with extraneous information.  Hence why they typically have long pauses between questions.

QSAs and auditors tend to operate under the same principle as a lawyer.  People get into trouble when they start talking about things that are outside of the question, out of scope or not relevant to the assessment.  Such responses will at first confuse the QSA for a moment as they try to reconcile your remarks.  But then, the QSA may question whether they truly understand the environment and, possibly, the scope of the assessment.  It is then that they may start quizzing you and your staff as they go back and reconfirm their understanding of the environment.  All of this takes time, time away from the assessment process as you cover old ground while the QSA re-verifies the facts.

The lesson to be learned here is that there is nothing wrong with saying, “I do not know.”  Or “I will have to look into that question and get back to you.”  The worst thing you can do is try and “tap dance” around the question or never really answer the question.  If you do not have the answer, then find out who does have the answer and point the QSA to that person.

Prepare

And finally, the best thing you can do to avoid all of these issues is to walk through the PCI assessment process and requirements with those of your staff that will be interviewed/observed and make sure they understand the questions to be asked and how they should be answered.

If you really want to know what the QSA will ask, why they will ask and the evidence they will require, get a copy of the PCI DSS ROC Reporting Instructions from the PCI SSC Document Library.  The Reporting Instructions document is the “Bible” for QSAs as it documents how they will be assessed in a PCI SSC Quality Assurance review.  Reviewing and understanding this document will go a long way to minimizing the “What do you need that for?” questions that all QSAs encounter.

For each requirement’s tests, the Reporting Instructions will tell you:

• What observations, if any, need to be performed and documented.
• What documents, if any, need to be collected and reviewed and what information needs to be identified in those documents.
• What people, if any, need to be interviewed and about what topic(s).
• What processes, actions taken or states of equipment, if any, need to be observed and documented.
• Whether or not sampling can be used.

Using the Reporting Instructions, you can also gather a lot of the observations ahead of time.  Your QSA will still have to conduct some observations such as that default passwords are not used, that timeouts occur, that change management operates and the like.  But by gathering screen shots and documenting what you used as testing conditions will go a long way to making your assessment go much more smoothly and quickly.

Hopefully this discussion will help you get through your next PCI assessment without all of the associated drama that can come from such an exercise.

Advertisement

Requirements That Are Never ‘Not Applicable’

Believe it or not, there are two PCI DSS requirements that can never be marked ‘Not Applicable’.  According to the PCI SSC, requirements 1.2.3 and 11.1 can never be noted as ‘Not Applicable’.

Requirement 1.2.3 states:

“Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.“

Even if an organization does not have wireless, the PCI SSC has stated that this requirement may never be marked as ‘Not Applicable’.  The QSA is required to document the network and describe any wireless the organization has implemented, regardless of whether or not the wireless has any contact with the cardholder data environment.

While this may seem a little over the top, think about why it is included in the PCI DSS.  One of the largest breaches that ever occurred was the result of a poorly engineered and operated wireless network.  As a result, to prevent future breaches due to wireless networking, the PCI DSS requires that the QSA ensure that any wireless, in or out of scope, is evaluated to determine if it is securely implemented.

When an organization does have wireless networking implemented, the PCI DSS requires that wireless networking to be segregated from the cardholder data environment (CDE) whether the wireless is used to carry cardholder data (CHD) or not.  Again, this is in response to the large breach.  Wireless is broadcast over public airwaves and an organization cannot be assured that someone is not eavesdropping on that broadcast.  However, it is this broadcasting over public airwaves that trip up most organizations.  People neglect or forget this fact and do not put in place the appropriate security and controls over wireless networks.  As a result, the PCI DSS is trying to ensure that should wireless be compromised, the entire network is not also compromised by default.  That then requires that controls such as ACLs and/or firewall rules are put in place to restrict traffic flow between any wireless networks and any other networks.

And even if an organization does not have wireless networking, under this requirement the QSA is required to document what procedures they used to determine that there was no wireless implemented.

As a result, a QSA is not allowed to place a ‘Not Applicable’ for this requirement.

As with requirement 1.2.3, requirement 11.1 was also put in place in response to that large breach as well as a number of other, unrelated breaches.  This requirement is also in response to the low cost of wireless networking equipment and the ease with which it can be implemented in a stealthy manner thus providing an attacker with a way into an organization’s network.  For reference, requirement 11.1 states:

“Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”

Whether an organization has wireless networking or not, the PCI DSS requires that the organization periodically assess its wireless networking posture to ensure that either wireless is still not present or that if wireless is used, that only the organization’s wireless is present on their network.

For an organization with only one or a few locations, this requirement is not that onerous.  However, for a Wal*Mart or Target with thousands of locations, scanning each of those locations on a quarterly basis is daunting.  As a result, you get wireless intrusion solutions such as those from Motorola and AirTight to automatically detect unapproved wireless devices.  While these solutions meet the requirements of 11.1, they can be expensive and difficult to implement, monitor and manage.  There is the alternative of implementing other controls on the network which can also be used to meet this requirement that I have discussed in another blog entry.  However, this compensating control has its drawbacks as well.

As with requirement 1.2.3, no organization can mark requirement 11.1 as ‘Not Applicable’ just because they do not have wireless networking implemented.

At the end of the day, the bottom line here is that all organizations are required to ensure that wireless networking is either not present on their network or, if present, it is only their wireless devices and that those wireless devices are appropriately implemented and secured.

Extremely Mobile Payment Processing

In a previous post I discussed mobile computing and PCI compliance.  In the last couple of weeks I have been questioned about using mobile devices such as smartphones and Wi-Fi enabled PDAs as payment terminals and I thought this particular incarnation of mobile computing deserved an in-depth look.

Pay attention to that Apple iPhone advertisement.  If you notice in one of their advertisements they show a person processing a credit card payment on their iPhone.  As Apple likes to say, “There’s an app for that.”  However, it is not just Apple that has a payment application for a mobile device; there are also payment processing applications for Windows Mobile environments.  There are also proprietary solutions from VeriFone and the like.  Some of these applications are PABP and/or PA-DSS certified.  Devices from VeriFone and the like are PCI PTS certified, but the iPhone and other cellular phones as well as PDAs are not PCI PTS certified devices.

So when the pizza delivery person shows up at your door and wants to swipe your credit card through their mobile device, how do you know that it is safe?  You likely will not know.

The security surrounding the telecommunications used by these devices is the easiest thing to discuss.  All of the devices I have been able to examine use telecommunications methods that are encrypted either by SSL v3 or TLS.  The cellular network and Wi-Fi are just used as the conduit and are not relied upon to provide any security.

Do not assume that VeriFone and the like are meeting all of the PCI standards.  While their mobile payment terminals are PCI PTS certified, the application software in those devices is not PA-DSS certified.  I pointed to the flaws in these devices in a previous post.

But there are bigger problems lurking with the iPhone.  Ask any computer forensic examiner about the iPhone and they will talk at length about the fact that the iPhone has a number of “features” that make security and privacy things of the past.  From a PCI compliance perspective, some of the more problematic issues are as follows.

• Deleted information does not physically get deleted.  In some cases, deleted data can remain on an iPhone for up to six months or even more depending on use.
• The iPhone has a built-in keyboard logger, so anything typed into it is recorded.
• While it is not certain that card swipes would be retained on the iPhone, given all of the other information it retains, it is highly likely that such information would also be retained.

As a result, using the iPhone as a payment processing platform is probably not a good idea until it is certified.

So what, if anything, are the PCI SSC and/or the card brands doing about this situation?  As much as they can, given that these solutions are popping up faster than they can identify them.  The problem is that the developers of these applications are usually unaware that they are required to comply with various PCI standards.  And since the developer is responsible for certifying their solution unless they get ‘ratted out’, the solution will not get certified.  So it is up to the application developer and the merchants to ensure that an application is properly certified.  If that is not worrisome enough, the cost involved in certifying such an application would likely raise the cost of that solution to a point where it would not be economical to the merchant or salesperson.

Wireless Scanning Compensating Control

I got a comment regarding my post titled “Wireless Security – Random Thoughts On How To Fix” asking what sorts of compensating controls would address requirement 11.1.  Since I have been looking for a topic, I thought I would address this as well as provide people with an example of how you develop a compensating control.

In order to construct a proper compensating control, you must first answer a couple of basic questions.

• Define the objective for the original requirement; and
• Identification of how the compensating control addresses the aforementioned objective.

In order to be able to define the objective for the original requirement, you need to understand the requirement.  Requirement 11.1 states, “Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”  On the face of it the purpose of requirement 11.1 is to ensure that all wireless access points are accounted for at each location using a wireless scanner or WIDS/WIPS, so that any potential rogue access points are identified and therefore can be removed from the network.  But is that the “real” objective of the requirement?  Before you go running off for alternative ways of identifying rogue access points, let us ruminate a bit further about the objective of requirement 11.1.  What is the “real” objective of requirement 11.1?  The real objective is to make sure that rogue access points do not end up on your network and if they do, you can identify and remove them as soon as possible.

Remember the criteria for compensating controls.  Compensating controls must:

• Meet the intent and rigor of the original PCI DSS requirement;
• Provide a similar level of defense as the original PCI DSS requirement;
• Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review;
• Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review; and/or
• Be “above and beyond” other PCI DSS requirements.

With all of this in mind, what are controls you can put in place to keep rogue wireless access points from being placed on your network in the first place?  The following should not be considered a complete list of controls you can put in place, but it does provide enough controls to create a compensating control for requirement 11.1.

• Disable all unused switch ports.  If unused switch ports are disabled, the installation of a rogue access point cannot be accomplished by plugging it into an open port on the switch.  This approach is usually not appreciated by network administrators as it requires the re-enabling of a port whenever a device needs to be added at a location.  It can also be disliked by remote facility personnel as it means there can be additional delays in getting another network device on the network.  While this control is referenced in requirement 9.1.2, it is not germane to requirement 11.1, so we can use this control for our compensating control for requirement 11.1.
• Enable MAC address filtering on the switch ports.  This control will restrict what device can be plugged into an active switch port.  Essentially tying a single device to a single switch port.  As with the first bullet, MAC address filtering creates a network management issue when you want devices added or changed.  So you will be adding to the effort required to change any devices out in the field.  Since MAC address filtering is not required by the PCI DSS, this control will go above and beyond.
• Monitoring of switch ports and generating alerts whenever a device is unplugged or plugged into a switch port.  Most switches will generate log entries when a device is either unplugged or plugged into a switch port.  Those events should be investigated immediately.  Such events can be the first sign of someone trying to plug in any sort of rogue device from a wireless access point to their own laptop.  Monitoring of this nature is required as part of requirement 10.  However, how you use monitoring to meet requirement 11.1 is not considered part of that requirement, so you can use the information you gather and monitor in requirement 10 to meet your requirement for 11.1.
• Monitoring the network for any devices that do not respond to SNMP inquiries using your organization’s SNMP private community string.  Again, if a device does not respond to SNMP inquiries using your organization’s SNMP private community string it is either mis-configured or does not belong.  So if you cannot communicate with the device, it needs to be investigated and either fixed or removed.  Monitoring of this sort is not even called out in requirement 10, so I would say that this sort of monitoring would go above and beyond.
• Disable dynamic host configuration protocol (DHCP).  DHCP is a wonderful service, but it is also a dangerous service.  It is dangerous because it allows any device, whether it belongs on your network or not, to obtain an IP address immediately when it connects to the network.  If any device can obtain an IP address when connected, then it has full connectivity to your network.  By not implementing DHCP, you remove that risk by requiring all devices to be preconfigured for their segment of the network.  Yes, your networking people will likely not appreciate this, but it provides a good security feature.  DHCP is called out as part of requirement 9.1.2, but again, it is not germane to 11.1, so we can use it here for our compensating control.

Because these controls can have a significant impact on your network and computing environment, we need to discuss a few more items.

First, you only need to disable DHCP at your retail locations, not your corporate office.  Typically, an organization has a lot more control over their computing environment at their corporate office, than at their retail locations.  As a result, enabling DCHP at the corporate office is not as risky, but you should still avoid enabling unused switch ports and unused jacks throughout any of your facilities.

If you are going to utilize wireless in any of your organization’s locations, make sure to properly isolate the wireless network from the rest of your network.  Even though you have implemented all of the compensating controls above to secure your network from rouge access points, you still need to ensure a secure wireless networking environment.  If you need wireless for operational purposes, make sure to secure it properly so that it cannot easily be compromised.  Such measures typically include not broadcasting the SSID and using WPA2 Enterprise security.

If you wish to provide wireless access to guests at your corporate office, make sure that their traffic is separated from any other wireless traffic and that they are only granted access to the Internet and no other internal resources.  A lot of organizations today require even guests to authenticate to their wireless as an extra security measure to keep people from using the available bandwidth at will as well as providing a mechanism to have guests acknowledge their responsibilities when using the wireless network.

Once you have the aforementioned information documented, you still have a few more things to cover in your compensating control.  You still need to implement your own feedback loop on these controls to ensure that they are functioning as designed.  Unlike Ron Popiel’s  miracle TV  oven, you cannot just ”set it and forget it” with these controls.  You need to have a plan in place to periodically follow up on all of these controls to ensure that they are functioning as designed.  Typically, that means tracking statistics collected from the monitoring controls.  It also means periodically observing these controls in action to ensure that monitoring is taking place and that ports really are disabled.  This sort of follow up is easily implemented as part of your financial field audit work.

In addition to your own follow up.  Your QSA also has to document what they did to confirm that these controls were in place and functioning as designed.  Their work is going to be similar to your own internal follow up work, but will likely be less extensive than your internal work as long as no exceptions are found.

You should now have a compensating control for requirement 11.1.  But better than that, you should now have a much better understanding of how a compensating control is developed and documented.

Mobile Computing And PCI

Mobile computing is all the rage in Europe and is becoming quite a thing here in the US.  As a result, we are seeing more and more inquiries regarding PCI compliance and mobile computing.

First, let us make sure we all understand what we are talking about.   Mobile computing is defined as, “Using a computing device while in transit. Mobile computing implies wireless transmission, but wireless transmission does not necessarily imply mobile computing.”

Laptops, netbooks, smartphones and even cell phones are all capable of some form of mobile computing.  You can order laptops and netbooks with cellular modems built into them.  Smartphones run Windows Mobile, iPhone OS, Symbian and Palm webOS that make them essentially very portable computing devices.  And all of these devices have access to the Internet through a browser running a Java virtual machine and other common Web-based computing environments, making them capable of executing a lot of Web-enabled applications.

On the application side, a lot of organizations have mobile computing-enabled their Web sites.  Just pay attention to all of the “m.domain.com” URLs that are advertised on TV and the Internet.  TV stations, airlines and financial institutions are all jumping on the mobile computing bandwagon.  From a PCI compliance perspective, airlines are probably on the leading edge of the credit card transaction generation wave followed by financial institutions.  Over a mobile device, you can pay for a first class upgrade; purchase a premium seat near the front of the plane or in an exit row and pay for your checked luggage.  In the financial institution arena, you can pay bills and check your credit card balance.

Security experts are enthusiastic about mobile computing as they currently believe it is actually safer than doing similar activities on a PC.  But, they couch their enthusiasm with the caveat that this is only for the moment.  Most security experts believe that once mobile computing starts catching on in a big way that the hackers will follow and that will bring mobile computing into the same league as the traditional PC.

One of the biggest problems with mobile computing is the fact that most people do not have firewall, anti-virus or other security software on their mobile device.  This is particularly true for smartphones and cellular phones.  As a result, they are easy targets to compromise or infect.  In addition, the security on their mobile devices is limited if they have even implemented it at all.  A number of European financial institutions have addressed this issue by requiring their mobile banking customers to have such software on their mobile device.  In some cases, the financial institution is providing the software via their mobile Web site which is leading hackers to spoof the financial institution’s Web site to direct the user to load compromised anti-virus or firewall software.

And security gets very tricky in some mobile computing environments.  The trickiest of all is Windows Mobile.  It seems that Windows Mobile has a different version for practically every different smartphone it executes on.  And it is not just from Motorola to Samsung to LG that it is different.  It can be different between a given manufacturer’s models such as the Samsung Saga and Omnia.  As a result, software that runs on the Omnia may not run on the Saga and vice versa.  All of this incompatibility makes development of a standard security solution difficult and time consuming for Windows Mobile.  This is why the iPhone has taken such a lead in applications.  It has one and only one operating environment, making application development very easy and compatibility a given.

On the application side, the issue is with ensuring that a secure communication link is made between the mobile device and the application.  For a browser-based application, this is not a big deal.  Like their PC brethren, mobile devices support TLS.  You also need to keep in mind that most mobile browser-based application can be susceptible to the same attack vectors that PC browser-based applications are susceptible.  So, you need to send your mobile applications through the same code review and security assessment processes as your other browser-based applications.

Another issue with mobile computing is making sure that if the end user looses their mobile device, there is nothing truly lost.  Therefore, if you are saving user credentials or other sensitive information, you must make sure that that information is properly secured and cannot be readily obtained by anyone other than the proper end user.  Given my earlier comment about mobile device security, this can be a bit challenging.  Particularly from the standpoint that most mobile computing users do not want to log on to their mobile device.  And if they do have to log on, they want it as simple and convenient as possible.

SMS-based applications are where things can get interesting.  Just look at the impact SMS donations have had for Haitian earthquake relief.   In three days, the American Red Cross raised over $6M in donations using SMS.  Granted, this example of donations does not directly involve credit cards, but it could.  Numerous SMS-based applications have been and are being developed.  However, SMS is not as simple and secure as one might think.  Depending on how an SMS-based application is implemented, there may be the cellular carrier and other third parties that are in the middle of the communication stream and may therefore be part of the transaction’s PCI compliance requirements.  The only way to know is to get into the application itself and understand how it is architected.

Now do not get the wrong idea.  Mobile computing is not entirely a bad thing.  It is just an unexplored area of computing that needs more work and research before we get crazy with it.  While that will not likely happen, hopefully this article will explain where the risks exist and compensating controls can be put in place to protect the information that ends up being stored or transmitted on these mobile devices.

Wireless Security Update

I had an opportunity this week to be involved in some testing of Motorola’s AirDefense wireless security solution at a client where we were conducting their annual PCI Security Assessment.  I wrote in a post a while back about wireless IDS/IPS and discussed my findings from that testing a couple of years ago.  With everything in technology, as time passes, things change.  Fortunately, things change for the better, but there are still potential pitfalls.  This should not be viewed as an endorsement of the AirDefense solution.  It just happens to be the solution that we were able to test.

Again, as I have stated previously, I am not going to delve into the details of how to accomplish making a network device ‘stealthy’ because I do not want to give anyone ideas or a leg up.  However, it should be noted that doing this is not difficult.

Two years ago, we configured some wireless access points to be very stealthy and located them around a facility and then had AirDefense attempt to locate and identify them.  While AirDefense was able to identify half of the rogue access points and that they were potentially rogue access points, it was not able to confirm that these devices were in fact within the confines of the facility.  The bottom line, half of the devices were not identified, so you had a 50-50 chance of finding a potentially rouge access point.  Not very good odds in the security business.

It is now two years later and I am going to conduct a very similar test.  First, this test was not quite as similar as I would like as we used cable/DSL routers with integrated wireless b/g access points.  The reason the testing will not be similar to the last time is that the test devices being used this time have built-in firewalls that protect the wireless versus the access points that we tested with the last time which had no built-in security features beyond WEP.  One of these devices we kept stock, using only the vendor supplied security capabilities.  On the other device we loaded up DD-WRT and made significant changes to make the access point and device itself as stealthy as possible.  In addition, we only have two devices to use versus a variety of devices two years ago.  However, using vendor firmware and DD-WRT should give us a good set of tests.

In our first test, we plugged the routers in (electrical as well as network WAN port on the router) and let them run in native, non-stealthy mode so that we could see how AirDefense would respond for our baseline.  As expected, AirDefense performed flawlessly and found and identified these devices without a problem and about two minutes later delivered the security alerts to the client’s security and networking personnel.  Unfortunately, our client is in the process of implementing more AirDefense sensors because they just moved into their new expansion space and we were located there.  As a result, AirDefense could not specifically locate the wireless.  However, with a few more sensors, they could have narrowed the search area and somewhat triangulated on the location of the rogue devices.

For our second test, we configured both devices to be as stealthy as possible.  Because of the limitations of the vendor configuration software, we were not able to configure that unit as stealthy as the one running DD-WRT.  The client reset the AirDefense database and we plugged everything in again.  The router running the vendor software was identified very quickly just as in the original test.  The DD-WRT device took some human intervention to determine that it was likely a rogue device.  However, the good news is that this time the DD-WRT device was found by AirDefense unlike two years ago when most of these devices were not found.

During our debrief regarding the testing with the client’s security personnel, we identified some frustrations with AirDefense.  The biggest is that, with the prevalence of wireless, the sensors are flooded with signals out in their retail locations.  While AirDefense claims that with an appropriate number of sensors it should be able to sift through the chaff of signals, my client’s experience is that it does not.  They have spent a significant amount of time attempting to tune the system so that spurious signals have a minimal impact, but they have found that all it takes is adjacent retailers or even homeowners to add wireless and AirDefense goes on alert, regardless of the number of sensors.  This client has installed AirDefense at only 20% of their locations, but they tell us that the number of daily alerts can be mindboggling and a lot of work to clear.  While the client’s staff has slugged through these alerts day after day, management is obviously very concerned about maintaining this level of diligence going forward as the rollout completes.

Another problem that they run into is with the coffee shops that are located within their retail locations.  However, it is not with the separate access points that these locations operate as they have been tuned out.  No, it is the coffee shop’s customers’ notebooks and netbooks that are the problem.  Most of these devices’ wireless are mis-configured and are acting as access points as well as wireless clients.  This creates the bulk of their alerts within their retail facilities and masks a lot of the real alerts.

The other point that the client’s security personnel wanted passed along to others is that an AirDefense type of solution is not a guarantee that you will identify every rogue access point.  Most of this problem is related to the human element.  All it takes is a lapse in diligence and you can end up with problems.  This was brought home the week before we arrived when the client’s resident wireless security guru was on vacation.  While on vacation, a couple of alerts were written off by their back up because of this person’s inexperience.  Turned out that these alerts were real problems and required action when they were uncovered when the guru got back.  There will be more remedial education for all other security personnel on the AirDefense system.  However, the bigger change will be making sure that the guru is not the only one making the call on what gets investigated.  With that responsibility spread out to more people, it is hoped that coverage will be more consistent when the team is not together.

In the end, I am glad to report that wireless IDS/IPS is advancing.  However, it is not a silver bullet nor do I expect it to ever be a silver bullet.  It still requires humans to make the call on what to investigate and what to ignore.  That requires skill and experience with the tool in a particular environment.  And that skill and experience takes time to develop.  So, just because you have implemented wireless IDS/IPS, does not mean that you are immediately protected.  Your security personnel will still have to ramp up on the tool in your environment.

Wireless Security – Random Thoughts On How To Fix

This has possibly been the hardest post yet to write.  Mainly because I am at a loss for answers.  There just does not seem to be a lot of solutions out there to address real wireless attacks.  So, I have done my best to come up with some thoughts on how to conduct a wireless assessment that will provide some reasonable level of assurance that your network is not compromised.  Note, I said ‘reasonable’ as I do not think there is a way to get absolute assurance that your network cannot be compromised when wireless is involved.

• Document the business reasons for implementing a wireless network.  Just because you can, does not always mean you should.  In a significant number of situations, you will find that the only reason for implementing wireless is just for the convenience it offers.  Does your organization really need wireless ‘guns’ that update inventory in real time or can you use guns that record inventory and then upload it in batch when the ‘gun’ is placed in a cradle?  In most situations, the cradle works just as well as the wireless solution.  That is not to say that there are not situations that warrant a wireless solution.  I have a number of clients that use wireless terminals and handhelds in innovative ways to improve customer service.  However, until there is a real business purpose with a real return on investment, do what you can to push back and not implement wireless. But be advised, since some vendors are now only producing wireless solutions, finding a hard wired alternative may not be possible.
• Architect your wireless network to be secure from the start.  There are ways to do this that are not as onerous as you might think.  Primarily, it needs to be isolated away from the rest of your network.  The reason is that no matter the security you implement, wireless uses the public airwaves to transmit, the key word being ‘public’.  As a public network, attackers can eavesdrop on your wireless whenever they want and they can and will make attempts to crack your security all they want and there is nothing you can do to stop it.  Once your wireless network is isolated, treat it as the public network it is and implement firewalls, IDS/IPS and any other security measures on your wireless network segment.  Make sure that you create a consistent configuration so that you minimize the potential for introducing a mistake   One of the best methods is to use those centralized, managed wireless solutions versus individual wireless access points.
• The PCI SSC needs to change requirement 11.1 to address the realities of the real world.  First, I question the usefulness of wireless scanning in the first place and I would highly recommend that it be dropped.  But assuming it is here to stay, for all but the very smallest of merchants, scanning with a wireless analyzer quarterly is a pipe dream.  I would recommend that quarterly testing is only a requirement when it is possible.  For all other merchants that wish to perform wireless testing with an analyzer I would recommend that requirement 11.1 suggest a sampling approach to ensure that all facilities are tested when significant network changes are implemented at the facility or at least once every three to four years.  Let us face facts here, there is no way Best Buy, Wal*Mart or Target are going to test their hundreds or thousands of stores on a quarterly basis.  It is just physically impossible.  They do not even conduct individual store financial audits that often, so who thought they would get wireless scans done that often?  Next, the PCI SSC has to provide in requirement 11.1 some additional alternative solutions besides an IDS/IPS on the wireless network segment.  Based on my experience, almost all of my clients that are using wireless are creating a compensating control to satisfy requirement 11.1.  It seems to me that if the majority of organizations with wireless are using a compensating control to meet the requirement, then the PCI SSC needs to create a requirement that does not require the majority of organizations to use a compensating control to satisfy the requirement.
• If your organization has decided to use wireless scanning with an analyzer, admit that wireless scanning requires a technical expertise that your organization likely does not have.  This is a perfect project for a qualified network security consultant to perform.  The costs for such projects are easy to control as they are driven by the location and number of facilities you need scanned.  If your facilities are widely scattered, you may want to go with a consulting firm that better covers your locations so that you can minimize travel costs.  You can also control costs by using a consistent configuration for your wireless.  That way you can use a sample of facilities versus scanning every facility.  However, since building construction usually varies from location to location, that may require making sure that all your facilities are scanned within a one or two year period.
• Don’t be buffaloed by a consultant’s certifications.  Customers are usually baffled by all the letters following a consultant’s name (even I have a boatload of letters after my name).  While certifications are good, it’s a consultant’s practical experience with security and wireless that counts.  Nine times out of ten, the consultant that meets with you will not be the one that does the work.  So, make sure that you and someone from your technical staff review the biographies of the consultants’ that will actually work on your project and that you personally talk to them either face-to-face or by phone.  Ask them about the wireless assessment engagements they have done.  Have them describe the process and make sure that it matches the process the sales person described.  Ask them about the typical findings that result from such projects and make sure that they can explain their findings to both technical and non-technical personnel.  And of course, make sure that you are not buying the process that I’ve discussed earlier.
• Don’t buy supposedly sophisticated looking tools.  Regardless of whether you are doing it yourself or getting a consultant to assist, don’t buy based on tools.  A lot of people do good work with NetStumbler/Kismet, and the right wireless card.  Some of these tools are just expensive solutions using the same techniques as the person with shareware tools.  So when evaluating wireless security solutions, ask the vendor tough questions about how their solution discovers rogue access points and get them to address my earlier points on why wireless scanning is flawed.  In most situations, you will find that these vendors are offering a solution no better than the one you can get for free.  When talking to consultants, be wary of the consultant that talks about their tools and does not talk much about their process.  Consultants that talk ad-nauseam about their tools typically do not have the experience to deliver the results that you desire.  They are typically going to be no better than anyone else with a scanner.
• Get a good understanding of the consultant’s process.  Ask the consultant to describe their wireless security assessment process.  Experienced consultants will have a number of service offerings in this area from basic scanning (essentially what I describe earlier but with a much more robust analysis of the results) to a full out wireless assessment that can resemble something out of a good spy movie.  Obviously, the more sophisticated it gets, the higher the cost.  However, for some clientele such as DoD contractors and the like, a very detailed and sophisticated analysis of all things wireless is what they require in order to satisfy contractual requirements.  For most merchants, what they need is something towards the lower end of the cost scale that will provide them with a reasonable assurance that their network is secure.  For most processors, their wireless assessment will likely be a bit more robust than a merchant’s because of the added risk they have due to the data they retain.

I have taken up a lot of bandwidth on this topic, possibly too much.  However, I think you start to see that wireless is not as simple a technology to secure as some of the security standards portray.    Wireless is not a technology that you just “add on” when you need it.  In the end, the most critical aspect to wireless is that it requires significant forethought before being added to a network.

The Shortcomings Of Wireless Scanning

I’m probably going to really stir the pot with this and my coming posts, but I think this is an important subject to discuss.  I don’t have all the answers on this topic, but I know that the current approaches I see out there are just not providing the level of security that I think is needed.  So, to paraphrase Bette Davis from ‘All About Eve’, “Fasten your seat belts. It’s going to be a bumpy post.”

PCI DSS requirement 11.1 states:

“Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”

The requirement gives you two options, you use some sort of wireless analyzer or you implement a wireless IDS/IPS solution.  Of course, there is also the third option of meeting this requirement with a compensating control.  In this post, I will discuss the shortcomings of the wireless analyzer approach.

A lot of my clients taking the wireless analyzer approach are typically having someone (usually an internal auditor or IT support person) go out to as many of their facilities as possible and use a notebook computer, a wireless network card or the notebook’s built-in wireless adapter and a shareware tool like NetStumbler or Kismet.  This person then walks the interior of the facility and the exterior perimeter of the facility using the tool to record what wireless is discovered, saving the results to a file.  A pretty straight forward process – quick, easy, done.

While this process meets the PCI compliance requirements, it certainly does not ensure security or that there are not unauthorized wireless devices on the network.  This is because in most instances the results are not analyzed to ensure that only authorized wireless was discovered.  However, even if an organization were to analyze the results produced from NetStumbler or Kismet, they would be hard pressed to draw any conclusions from those results since you really have to analyze them in real-time, not after the fact.

Besides the fact that results are not analyzed, I seriously doubt most of my clients have the technical expertise to even conduct an informed analysis of a wireless scanner like NetStumber or Kismet.  And, to add insult to injury, the test for 11.1.a states, “Verify that a wireless analyzer is used at least quarterly …”  No where does the PCI DSS state that you must analyze the results of the analyzer, you just need to use a wireless analyzer quarterly.  The end result is that most people, even those in the information security profession, and the organization’s management believe that this is sufficient to ensure the security of their networks.  In my opinion, this is a VERY false sense of security.

So, what do I see as the shortcomings of just scanning with a notebook, NetStumbler/Kismet, etc.?

• The majority of wireless scanning is done using an omni-directional antenna.  Most wireless cards use built-in antennas and those antennas are omni-directional meaning that they can receive their signals from any direction.  Also, many of the external antennas are also omni-directional.  The problem is that an omni-directional antenna does not provide the best method of locating potential rouge access points since it is difficult to determine the location of access points based on the direction of their signal.  It takes a significant amount of walking around and detailed monitoring of signal strength to get a fix on a given access point.  It’s not that it cannot be done, it’s potentially a lot of work which makes it difficult for all but the most experienced operators of wireless scanners.  As a result, it can take a significant amount of time to locate all of the wireless access points in a facility and prove that they are all valid.
• This wireless scanning approach assumes the attacker wants to be found or is unaware of wireless security techniques.  One of the things that fascinates me about wireless scanning is that it assumes that someone wants the access point to be found.  A smart attacker would configure their rogue access point so that it is electronically ‘hidden’ on your network (I’m being purposely vague here to avoid giving away the entire store, but be assured this can be accomplished).  Not that such an AP configured this way cannot be found, but the effort required to find it will be extremely difficult using the basic scanning techniques I’m talking about.  As a result, with the right attacker, you will be compromised until you take your approach to a higher level.
• If you identify a rogue access point, then what?  Obviously, you want to remove it from your network as soon as possible.  However, most retailers I work with would be hard pressed to get this done as quickly as they like because of a lack of qualified personnel in the field that can locate the rogue unit and then remove it.  As I stated earlier, it will be difficult to find a properly configured rogue access point, so the likelihood that you will even identify such a device is low.
• Then there is the whole problem of if you were hit once, what will stop the attacker from coming back?  With the price of access points on eBay and the like going for as little as $5 including shipping, it’s highly likely that if you find an attacker’s access point, they can absorb the loss and quickly replace it.

I’ve taken enough of everyone’s time on explaining where I think the wireless analyzer approach falls short.  Coming are my thoughts on the wireless IDS/IPS approach.