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 addresses 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 function 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 wer 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.

Non-Compliant ROCs

There really is such a thing, but you rarely ever see or hear of one.  But unlike the Loch Ness Monster or Big Foot, they can and do exist.

There is no reason that an organization cannot file a Report On Compliance (ROC) that is not compliant.  The topic came up again because we have a client that is addressing some issues related to complying with v1.2 of the PCI DSS.  Their remediation efforts will not be done for another five or six months, but their PCI ROC needs to be filed in one month and they do not think they can put in place compensating controls to address the remaining issues.  As a result, there will be a couple of items on their PCI ROC that are in the dreaded ‘Not In Place’ column.

The first thing everyone needs to be aware is that there is nothing in the PCI DSS that says an organization must file a compliant PCI ROC.  It is just that filing a compliant PCI ROC makes for much less work for the acquiring bank and the merchant or service provider involved.  But there are those out there that believe that a merchant or service provider must file a complaint ROC and that is just false.

So, what happens if an organization files a non-compliant PCI ROC?

If an organization needs to file a non-compliant PCI ROC, then they need to be prepared for the additional scrutiny required by their acquiring bank and/or the card brands.  When a merchant or service provider files a non-compliant PCI ROC, the organization that receives the PCI ROC must initiate an effort to track the requirements that are Not In Place.  They need to periodically follow up on the Not In Place requirements and report the status of any Not In Place requirements to the card brands.  The term ‘periodically’ is left to the acquiring bank to determine.  But how often they follow up can be as little as quarterly and as often as weekly.  The most common timeframe seems to be monthly meetings, but your experience will likely vary.  This process is required to continue until all Not In Place requirements are deemed in place.

So, how does the acquiring bank determine that your organization’s Not In Place items are now In Place?  Well that is where things are not so well defined.  What is defined is that the merchant or service provider informs the acquiring bank or card brands during the follow up meeting/call that the Not In Place requirements are now In Place.  What is not well defined is what happens after being informed that requirements are no In Place.  Since there are no procedures documented in the PCI DSS, by the PCI SSC in an FAQ or by the card brands, what happens next varies from acquiring bank to acquiring bank.

In most cases, the acquiring bank requests the merchant or service provider to get their QSA to update the ROC by reflect the changes in the Not In Place requirements.  My Firm’s problem with this approach is that in updating the PCI ROC, we are only looking at those requirements that have been updated from Not In Place to In Place.  We are not re-conducting all of the testing in the PCI ROC.  As a result, we only update those requirements that have changed and we place a disclaimer in the PCI ROC that states what items were updated and when those updates occurred.  We do not update the date of the report as the entire report was not updated.

Our preferred approach is to issue a letter with an attachment that contains the individual requirements that are now In Place.  The letter documents the scope of the re-review and the approach taken to test the updated requirements.  This approach allows for the updating of the PCI ROC, but only those items that changed and does not alter the original PCI ROC that was issued.  In this way, anyone reviewing the original report and the update has a clear understanding of what changed and why.

PCI Check Box Compliance – Volume 2

I want to shed some light on a troubling practice that I think people should be aware.  The practice of which I am referring is QSAs that apparently spend little time on-site conducting their Report On Compliance (ROC) fieldwork.  We are hearing a little too often from new clients that the amount of on-site fieldwork we are scheduling is significantly more than the time spent on-site by their last QSA.  As a result, I wanted to take this opportunity to discuss why a certain amount of on-site work is required if a QSA is to successfully perform their duties.  I am hopeful with the advent of the PCI SSC’s QA program that this practice will come to an end, but you never know.

About a year ago, the PCI SSC, as part of their QA program, issued a scorecard for evaluating a PCI Report On Compliance (ROC).  The scorecard calls out five verifications that may be required by each individual PCI DSS requirement.  Not every requirement requires all five areas be covered but a number of requirements do.  Those areas are:

• Verified by review of documentation;
• Verified by interview;
• Verified by observation of system setting or configuration file;
• Verified by process, action or state; and
• Verified by network traffic monitoring.

Verified by review of documentation is just what you think.  The QSA is required to obtain and review all relevant documentation related to PCI DSS compliance.  Documentation is best reviewed before conducting any interviews and observations.  The allows the QSA to minimize ramp up time on the organization’s cardholder processing environment and gives the QSA a better understanding of the environment to minimize clarifications and questions.  Just as an FYI, based on my analysis, there are, at a minimum, 256 discrete documents required to complete a ROC.

As with documentation, verified by interview is also straight forward.  A QSA  is required to interview all relevant personnel that have knowledge required to complete the ROC.  According to the scorecard, there are 129 interview topics that are required to be discussed.  Interestingly, some PCI DSS requirements that you would think do not have an interview component actually do.  This is an area that caught a lot of QSAs when they went through their QA reviews.  Interviews can typically be conducted via conference calls and LiveMeetings, so there is no requirement to be on-site for these.

Verified by observation of system, setting or configuration file is defined as the assessor observed the device, component or server configuration file parameters, system setting parameters or any other parameters to prove that these parameters were set to produce the outcome specified  To accomplish this, the assessor may use local system administrators, database administrators and application support personnel as needed.  Based on the scorecard, there are 124 observations that are required.

Verified by process, action or state is one that trips a lot of us up.  What the PCI SSC is requiring here is that the QSA observe a process, an action or the state of a device so that they can have proof that what the documentation and the interviews state is in fact what is actually executed by the personnel involved.  There are 301 observations in this category required by the PCI SSC to be performed for a ROC.

Verified by network traffic monitoring is another tough one.  It is tough mostly because a lot of organizations do not have a way to monitor network traffic that is acceptable.  Yes, they are monitoring their network traffic, but they are not inspecting it with a tool like WireShark which is what is needed here.  What the PCI SSC requires is that the QSA observe the network traffic to make sure it is encrypted and that inappropriate cardholder data is not present.  There are 9 observations of network traffic required.  These can be done remotely in most cases.

The QSA must truly observe all of these items.  Given the number of items that must be observed, it just seems unrealistic to get all of it done in one or two days.  It is possible to do some of these observations using conference tools such as WebEx or LiveMeeting.  But when asked, our new clients tell us that no such meetings occurred for making these observations.  So we are stumped as to how the previous QSA got the observations completed in such a short period of time.

Regardless of what the PCI SSC requires, there is a huge amount you can learn about an organization by spending time on site.  An auditor can tell a well run operation just be looking around and talking to people.  Looking around and talking to people takes time.  In a lot of cases, these sorts of observations of an organization’s operations can point you in the direction of potential compliance issues that just require a bit of digging.  You cannot get that kind of time if you are doing back to back to back on meetings to complete your observations.  As a result, we have some concerns about whether or not these QSAs are identifying potential compliance issues that may exist.

In the end, these QSAs may be saving you money at the expense of your security.

Threat Landscape Is Changing – Advanced Persistent Threat

If you are not familiar with Advanced Persistent Threat or APT, you better get yourself up to speed as soon as possible.  This is a threat that will likely catch you flat footed if you are not addressing it.  As a member of InfraGard I was made aware of APT a year or so ago, but it was a great report recently produced by MANDIANT Corporation that really brought this threat into perspective.  I cannot stress how urgently you should go to their Web site and request a copy of their latest M-TRENDS report.  It is covers this topic in much more detail and is very enlightening.

APT is not your usual attack.  As the name implies, it is a very skilled long-term siege on your network and computer systems.  The attack is taken slowly and carefully so as not to trigger any alerts at the target.  These are teams of very skilled professionals, not hactivists, script kiddies or even organized crime groups.  As far as anyone can figure out, these professionals are state sponsored based on the scale and logistics of their operations.  Their “job”, so to speak, is to compromise networks and systems for the purpose of gaining access to information.  What makes APT particularly insidious is that they set things up so that they can keep coming back.  What makes APT even more effective is that regardless of the countermeasures put in place to thwart attacks; these people have the resources and knowledge to work around those countermeasures.  In effect, APT brings my adage to life, “If someone wants to get you bad enough, they will do whatever it takes to make that happen regardless of what you do to prevent it.”

While I know that you are likely saying to yourself that your organization would not be on the APT radar, think again.  If you have a presence on the Internet whether that is ecommerce, a static Web site or even an email server, you are a potential target of APT.  And while you may not have information they want, you may have a business partner that they wish to compromise and they will use your network to get a way in to your business partner.  This all goes back to a post I made a while back regarding the fact that we are all interconnected these days, one network to another and so on.  So while APT may not be able to directly get into a target, they may be able to compromise a network attached to the target and get in that way.  As a result, we all need to take precautions to ensure we have each other’s backs.

The M-TRENDS report goes into great detail on the methods used, so I will not bore you here with those details.  But, some of the take aways I got from the report are as follows.

• These are very sophisticated attacks and require a level of sophistication in information security that most organizations do not practice.  As a result, if you intend to stay out of APT’s clutches, you are going to have to raise the bar on your information security program significantly.  Raising the bar does not necessarily mean spending more money on the latest and greatest security technologies.  On the contrary.  APT wants targets that think security technology is the only way to secure an organization.  It is organizations that rely heavily on technology and ignore or belittle security training that they prey upon.  This means that you need to focus your efforts on things like training and being more diligent on log reviews and alert follow up.  The requirements in PCI DSS requirement 10 go a long way in assisting you with finding anomalous network traffic and the like.
• APT relies on heavy reconnaissance of networks and the gathering of information to be used in their social engineering attacks.  There initial forays into your network will likely be as innocuous as port and vulnerability scans as well as spidering all of your public Web pages and LinkedIn, Facebook, MySpace, Twitter, etc.   While you can do very little about the port and vulnerability scanning, you can do quite a bit about spidering.  Now is the time to reconsider the information you post publicly on your Web sites.  It is also time to start managing the information that is ending up out on social networking sites.  A just published study in the UK indicated that information regarding a number of top secret projects for the military could be found on various social engineering Web sites.  If that is the case for really hush-hush projects, imagine the sorts of information that could be garnered about your own organization.  Remember, it is this sort of information gathering that have caused most of the break-ins to celebrities’ and politicians’ email and social sites.  In addition, all of this ‘personal’ information is just a quick Advanced Google search away.
• With social engineering as one of the big keys to APT, it is time to get serious about training of your personnel.  APT use a number of targeted social engineering techniques such as ‘spear phishing’ to gain ways into an organization.  If you still think social engineering training is useless, here is the biggest reason I can give you to get serious about training.  It does not have to be boring, but it does need to convey a sense of urgency and the extreme risk presented.  Just having people read the M-TRENDS report and then discussing it would likely go a long way to motivating people to think before they do something they will regret later.
• The malware used by APT is very sophisticated and is constructed in such a way as to thwart most current anti-virus and anti-malware solutions.  In addition, APT malware is regularly updated to continue to blind these solutions.  As a result, relying on these solutions is not feasible.  You will need other measures in place to ensure your security such as critical file monitoring, file signature hashing and similar measures.  I am not suggesting that you take these measures on all you systems, but you probably should consider it on systems that contain critical data or have access to critical data.  There are a number of PCI DSS requirements that can help you with this, but the biggest is requirement 10 again followed by requirement 11.5.
• You will likely need to make your network segmentation even more granular.  As I stated in the last bullet, you do not want to have to put these countermeasures on every system you have.  Unfortunately, unless you further tweak your network segmentation to keep sensitive systems and non-sensitive systems apart, you are not going to keep APT at bay.  Granularity does not mean more VLANs or segments; it more likely means more or tighter ACLs to control access to information.
• To hide their activities, APT uses encrypted data streams between their malware and their command and control systems.  As a result, traditional network traffic monitoring will not help unless you are monitoring for “unknown” encrypted traffic.  Again monitoring can detect this, but you need to be monitoring for encrypted data traffic that is not “normal.”  This can also be controlled by controlling outbound traffic to unknown destinations.
• Finally, a lot of these attacks are from known locations such as China.  If your organization is not conducting business outside of the United States, why is your firewall configured to accept traffic from anywhere on the Internet?  For that matter, why does your firewall allow outbound connections to foreign countries?  All of this is configurable if you take the time to enable it in your firewalls, but most organizations never go to that length.  Now you have a big reason why to start restricting traffic in and out of your network like you should have been doing all along.

The PCI DSS has a number of controls in it that, if properly implemented and monitored, would go a long way in making APT’s activities more difficult.  However, that is the rub.  Unfortunately, most organizations do not execute the PCI DSS consistently and therefore they can end up being owned by APT.  And just complying with the PCI DSS is not necessarily going far enough, so you need to go beyond it to ensure your network’s security.

Always remember security is not and never will be perfect.  Your goal then is to make the life of APT as miserable as possible so when they come calling, they will likely go somewhere else to get what they want.  However, if you are their ultimate target, then you need to be sharp as they will do whatever it takes to get in.

The New PCI DSS Version Is Discussed

If you want to know about what’s coming in the next version of the PCI DSS, see this article.

The bottom line is that the new standard will be out in October 2010 and nothing much is changing, just clarifications.  However, this interview with Bob Russo does point out a few interesting tidbits.

The first is that end-to-end encryption sounds great, but needs to be further studied, defined and refined.  In addition, at the end points, the cardholder data must be decrypted, which means your key management procedures need to be bulletproof.  I had put up a series of posts last year right after Heartland discussed using end-to-end encryption.

The second thing I found interesting is his discussion of Chip and PIN.  Yes, Congress found this technology to their liking, but it has its own issues, some of which I discussed in a post a while back.  It’s not a be all to end all, but it does offer some additional features.  However, Mr. Russo neglected the fact that Chip and PIN cards do have magnetic stripes on them to be compatible with the rest of the world.

Finally, there will be more white papers, FAQs and the like written.

In general, not a lot to talk about.  However that can all change between now and then if we see some changes in tactics by the attackers.

Throwing Down The Gauntlet

I am having a bad day and just got done with a call with an acquiring bank and their PCI compliance coordinator.

What got me in a really foul mood was their demanding of my client that they take certain actions to better ensure the security of the acquiring bank’s transactions.  I do not know what it was, but their request just hit me wrong and I went on a rant.  However, after I was done, I started to think about it and said to myself, “Why not?”

My rant to this poor person revolved around why the card brands and acquiring banks do not expend their efforts to fix the credit card fraud problem instead of addressing the symptoms?  For the last ten years, the card brands have developed their various security programs that were merged together to form the various PCI compliance standards.  While these standards address the shortcomings of the existing processing environment, my impression is that the card brands are doing little, if nothing, to actually address the real problems.

How about we force the card brands to develop a truly secure credit card and related secure transaction processing?  Given the technology available today, one would think that with the right people involved, a secure credit card could be readily developed and at the same time, a secure transaction processing environment could be designed that does not allow the storage of cardholder data except at those points where it is required.  And at those points where cardholder data needs to be stored, these points are heavily secured, monitored and fortified against attack and the breaching of data.  Those projects alone would probably go so far as to reduce card fraud and breaches by 90% to 95%.

Yes, I know that such changes would not come quickly, but you might be surprised.  If a new, secure process and card was introduced and it provided the benefits that I think it likely would, a lot of merchants might actually have a reason to get on board and spend the money to fix the real problem.

So, how about it card brands and acquiring banks?  Are you up to the challenge?

Call Center FAQ Significantly Changes

On January 22, 2010 the PCI SSC issued an update to their clarification regarding their FAQ on call centers storing CVV/CVC/CID in their call recordings.  The bottom line is that call centers are no longer allowed to store such cardholder information in recordings that are maintained digitally, regardless of whether they are encrypted.

The new FAQ (#5362) states that:

“It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”

I am assuming that this change in policy is the result of the PCI SSC determining that, regardless of what we have been told in the latest reports from Verizon Business Services and other sources, there have been breaches of cardholder data that were the result of compromising digital audio recordings.

A big thank you to Emma Jenkins at VeriTape for pointing out this change.

The Great PCI Debate

If you have a chance, download a copy of this podcast.  There are two parts plus a transcript and it is well worth the effort.  I would like to thank Bill Brenner and Martin McKeay for having the foresight to get together a panel of people to discuss this topic.  I would also like to thank the panel for providing probably the best discussion yet of the pros and cons of PCI.

• Jack Daniel, a member of the National Information Security Group (NAISG)
• Ben Rothke, senior security consultant for BT Global Services
• Dr. Anton Chuvakin
• Ward Spangenberg, a Seattle-based security consultant
• Michael Dahn, a PCI QA manager and director for the InfraGard National Members Alliance (INMA)

Based on my interpretation of the podcast, here are the take aways that I got from listening to this great discussion.  Interestingly enough, some of them may sound very familiar.

• Security is not perfect.  There will always be a risk no matter what you do.
• There will always be organizations that just do not get it and never will.
• If controls are not consistently implemented, maintained and monitored, then your security measures will not matter.
• The PCI DSS is common sense not rocket science.
• The PCI standards are not perfect, but they are better than nothing.
• The PCI standards are a bare minimum and you must go beyond them to better ensure security.  However, if you can consistently execute the bare minimum, you are ahead of the curve.
• Most Level 2, 3 and 4 merchants are clueless about security let alone the PCI standards and will likely remain targets.

For reference, I have put in links to those relevant postings that I made on similar topics over the last year.

Two Good Security Articles You Should Not Miss

I ran across these today and thought I would pass them along.

The first article discusses the lessons that can be learned from the Google attack, also known as ‘Aurora’, on Web sites.  What is interesting is that if your organization was complying with the PCI DSS, the attack would have been almost immediately been identified.  At that point, the attack could have been mitigated.  And remember, mitigation can include unplugging your network from the Internet.  Granted, that is a drastic action to take, but this was a drastic attack and would have warranted such an approach.  Most organization’s incident response plans never discuss disconnecting their organization from the Internet.  However, disconnecting your organization from the Internet might be a valid action to take in certain circumstances such as with ‘Aurora’.

The second article discusses the issue of using proprietary encryption algorithms.  It amazes me the number of people that need to reinvent the wheel all in the name of putting their personalization and creativity on a given project.  Encryption is not a place to reinvent the wheel.  So all of you “experts” out there that think you can do better than AES, get over it.  You cannot do better.

If you are not keeping up on security, you really need to keep up.  To ease the pain, get a free RSS Feed reader such as FeedDemon and subscribe to a number security RSS feeds so that you can keep informed on security and threats.

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.