Archive for the 'Requirement 9 – Restrict physical access to cardholder data' Category



06
Mar
11

PCI And Virtualization

I just received an invitation for a Webinar on Virtualization and PCI compliance.  My friend, John Kindervag is one of the panelists and, no, this is not an unpaid advertisement for anyone to attend even though I have provided the link to register.  For an hour they will be discussing this topic because now the PCI DSS v2.0 references virtualization.  Let us be very clear, while the PCI DSS prior to v2.0 never explicitly discussed virtualization, QSAs were instructed on how to approach virtualization security.  And as you will see, virtualization security is no different than any other operating system security.

In my very humble opinion, virtualization is a one minute security issue, if that long.  Let us cut to the chase, as small an attack vector virtualization can be, it is still a potential attack vector, so you need to secure it.  Is that clear enough?  The real issue is how to secure a virtualized environment.

There are two different forms of virtualization.  There are stand-alone hypervisors (what NIST refers to as “bare metal”) like VMware vSphere, VMware ESXi, Microsoft Hyper-V and Citrix XenServer.  Bare metal hypervisors are what we typically run into the most in our PCI compliance engagements, but not necessarily a guarantee.  There are also VMware Server, VMware Desktop and Microsoft VirtualPC (what NIST refers to as “hosted”) that require a host OS to run on as an application no different than Microsoft Word.  Obviously, the attack vectors are wildly different for each type of virtualization.

For whatever reason, it seems that a lot of IT professionals do not recognize that a hypervisor is an operating system.  Yes it is a very specialized operating system, but it is an operating system just like Linux or Windows.  Most hypervisors are based on Linux or UNIX and have a few security hardening similarities.  But given a hypervisor’s specialization, they have significantly different security hardening requirements from their Linux or UNIX counterparts.  As such, hypervisor vendors typically provide a security hardening standard for each of their hypervisor operating systems.  All you need to do is go to the hypervisor vendor’s Web site and download the security hardening guide for your version of hypervisor.  Which brings up a good point, if your hypervisor vendor does not provide a security hardening guide, then you need to find a different hypervisor.

For bare metal implementations, the only thing you have to secure is the hypervisor itself.  However, with hosted virtualization, you need to secure the host operating system as well as the hypervisor.  In addition to the hypervisor, you will need to follow the host operating system vendor’s security hardening guide to ensure that the host OS is also secure.

But hardening your virtualized operating system is not the end of the job.  You need to properly implement your virtualized environment securely as well and that is more than just hardening the hypervisor.  The most obvious security item that needs to be done is that any guest operating systems implemented need to also be securely hardened.  It still surprises me the number of IT professionals that somehow seem to think that because they are implementing Windows or Linux as a virtual machine that there is something different about security and you can totally skip or skimp on hardening.  Security hardening procedures need to be completely followed regardless of whether the guest OS is stand-alone or in a virtual machine.

The next area that seems to get the short shrift is infrastructure security.  This is particularly true of the management of the hypervisor environment.  Most implementations I have seen do a good job of securely connecting the virtual machines, but the hypervisor infrastructure environment leaves a lot to be desired from a security perspective.  The first mistake I see is that the hypervisor management environment is not segregated from other networks.  In the first scenario I commonly see, the production network and the hypervisor management network are on the same segment.  If an attacker compromises any virtual machine, they gain access to the hypervisor management environment and can therefore gain access to the virtual cardholder data environment.  In the other scenario, the corporate network and hypervisor network are one and the same and therefore everyone that is on the corporate network can also gain access to the hypervisor management network.  The way to fix both of these situations is to put the hypervisor management network on its own network segment.  I also recommend to organizations that they dedicate a NIC to only that segment.  However, if an organization already has an operations management network segment separate from other networks, I have no problem having the hypervisor management network in that segment as well.

The other scenario I frequently see is virtual machines from the cardholder data environment (CDE) intermingled with virtual machines that are not part of the CDE.  The problem here is that in the event of a compromise of a non-CDE virtual machine, CDE virtual machines may be accessible because of the configuration of the virtualization environment.  The best way to use virtualization for PCI compliance is to isolate your CDE virtual machines in a physically separate virtual environment from your non-CDE virtual machines.

For the truly paranoid, you can also fiddle with parameters such as physical/logical NIC assignments as well as SAN configurations.  While these sorts of configuration changes can provide additional security to the equation, I have my doubts as to the significance of these changes from a security perspective.  In my years of dealing with virtualization, these sorts of configuration changes have been more for performance reasons and enhanced security was just a nice byproduct.

Finally, there is the maintenance aspect of virtualization.  I think everyone gets the fact that virtualized or not, the guest operating systems need to be maintained and patched just like their stand-alone brethren.  However, when you ask organizations how often they patch their hypervisor; some will say to you very honestly, “You have to patch it?”  Earlier on I stated that a hypervisor is also an operating system and, as such, it needs to be patched just like any other operating system.  Granted a hypervisor does not usually get patched every month like Windows, but there are patches issued every so often by hypervisor vendors.

Best of luck to John and the round table that are presenting this month on virtualization and PCI compliance.  Hopefully this post will help explain what they will be discussing as well as lead to more insightful questions on the topic.

Advertisement
21
May
10

Passing The Buck

When you are providing services to customers and those services are in-scope for compliance with any of the PCI standards, do not be shocked when your customer’s QSA asks you to prove that you are complying with the relevant PCI standards.  What sort of services are we talking about?  While not a completely inclusive list, here are some of the most common services I run across that are in-scope for PCI compliance.

  • Network management.  This includes management and/or monitoring of firewalls, routers, switches, etc.,
  • Server management.  This includes configuring of servers, patching of servers, add/change/delete of user accounts, monitoring of servers, management of server log files, etc., or
  • Network security management.  This includes management and/or analysis of infrastructure and/or server logs, monitoring of security devices such as firewalls and IDS/IPS, incident response, etc.

The most common point of confusion I run across is with those third parties that are providing network management services.  If the service provider is only providing a telecommunications circuit, then the service provider is not in-scope of PCI compliance.  This fact has been confirmed time and again by the PCI SSC.  However, once you start to be responsible for managing routers, switches or other networking infrastructure, those services are in-scope for PCI compliance.

What I think these service providers forget is that it is not just the storage of cardholder data that is the concern of the PCI standards.  It is the processing and transmission of cardholder data that is also covered.  Now, if cardholder data transmissions are encrypted and the third party does not have the ability to decrypt those transmissions, then the third party is not in-scope.  However, where service providers get in trouble is that the data stream is encrypted at the router that they manage or they manage other devices that come into contact with unencrypted data.  They think that because they are off the hook in one instance, they are off the hook for all which is not the case.

If your company is managing customers’ networks, then explain just how your customers can respond to the following sample of network management compliance tests from the PCI DSS.

  • 1.1.1 – Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.
  • 1.1.4 – Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.
  • 1.2 – Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment …
  • 1.2.2 – Verify that router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.

The bottom line is that your customers cannot respond to these requests if your organization is performing them, just ask your customers.  They expect as part of your service agreement to respond to these requests.  Given the ingenuity of entrepreneurs, almost anything can be outsourced for a price, hence why each service that is outsourced needs to be addressed individually to determine whether or not the service is in-scope for PCI compliance.

For those service providers that are reading this and are still unconvinced, I would ask you this question.  If your organization is not responsible, then who is?  Your customer contracted with you to perform the service; therefore they no longer have the knowledge to respond to anything regarding these requests.  If they cannot respond, then who does respond?  And I would point out that if a QSA cannot obtain satisfactory responses to these requirements, then the QSA is obligated to mark them as ‘Not In Place’ which means your customer is not in compliance and must  remediate the problem.

I would remind everyone that security is an all or nothing operation.  Either everyone and everything is secure in the business process chain or they are not secure.  All it takes is just one weak link and the party is over.  We live in a very interconnected world and therefore the security of any one entity can make or break the security of all others.

And if you are still unconvinced, I would have you ask your attorney what happens if a breach occurs at one of your customer’s and is the result of your organization’s failure to comply with one or more of the PCI DSS requirement that caused the breach?  My guess is that your attorney will tell you that you are legally on the hook and that likely all fines, penalties and any other sanctions will be against your organization, not your customer.

And finally, if you are still saying this is all BS, then you better get out of this business because this is what is coming down the line.  QSAs are just the messengers, so do not complain to or about us.  It is the PCI SSC and the card brands that set the rules.  And the PCI SSC is cracking down on QSAs and making sure that we all consistently interpret the PCI DSS and other standards.  So the fact that “no one has asked us about this before” is rapidly coming to an end as every QSA will begin asking for your compliance.

As they like to say, “If it’s too hot in the kitchen, then maybe it’s time to get out.”

13
May
10

Annoying Requirements – 9.7.1

There are some requirements that just seem silly and appear to have no real purpose other than to be lightening rods for PCI DSS naysayers as why the PCI DSS is an inconsequential standard.  One of those requirements is 9.7.1 which states, “Classify the media so it can be identified as confidential.”

I think we all understand what the PCI SSC is getting at here.  They want to make sure that all removable media, in particular magnetic tape, is labeled as “classified” so that if any removable media goes missing, people that find any such media know that it is to be treated as confidential and not be released in the public domain.  This is predicated on the idea that people are basically honest and would obey such a labeling and would not investigate further.  However, the people that are the threat could really care less that the media is labeled confidential, that is why they want to get a hold of it.

Then there are the security experts that argue that by labeling something as ‘confidential’ all you are doing is further identifying the media as something that needs to be further examined by a person to see why it is confidential.  After years of conducting social engineering testing, I tend to agree with these experts.  Human nature just begs some people to find out why something is labeled ‘confidential’.  This is why leaving thumb drives or CD-ROMs in parking lots labeled ‘Customer List’ and sending out spam with links to the latest naughty celebrity interview, pictures or video still are very effective social engineering ploys.

The PCI DSS was created with numerous requirements that cover one another such that if one requirement is not performing completely, the other requirements will fill the gap.  In this case, there are a number of other requirements that cover 9.7.1 such as:

  • 3.1 – Keep cardholder data storage to a minimum.
  • 3.2.1 – Do not store the full contents of any track from the magnetic stripe
  • 3.2.2 – Do not store the card-verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.
  • 3.2.3 – Do not store the personal identification number (PIN) or the encrypted PIN block.
  • 3.4 – Render the PAN, at a minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs).
  • 9.5 – Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility and review the location’s security at least annually.
  • 9.6 – Physically secure all paper and electronic media that contain cardholder data.
  • 9.7.2 – Send the media by secured courier or other delivery method that can be accurately tracked.
  • 9.9 – Maintain strict control over the storage and accessibility of media that contains cardholder data.
  • 9.9.1 – Properly maintain inventory logs of all media and conduct media inventories at least annually.

Even if these other requirements are not met, just what does the PCI SSC and the card brands think a label is going to do?  It does nothing to improve security and ends up as “make do” work for some clerk to label all tapes, CD-ROMs, thumb drives, etc.  The epitome of those Dilbert cartoons from the 1990s that lambasted the ISO 9000 compliance craze.

To comply with this requirement, all I ask my clients to do is to declare all information, at a minimum, as confidential or whatever their second lowest data classification is called.  That way all employees know that, at a minimum, all information they come in contact with is confidential.  As such, they are not to share this information with anyone else unless there is a valid need to know that information for someone to complete their job.  But I do not require them to label removable media as ‘confidential’.

The message to the PCI SSC, get rid of this requirement.  It does nothing to improve anyone’s security.

17
Apr
10

Managed Networks And PCI Compliance

Here is a subject that keeps coming up, particularly with organizations that manage networks for merchants.  If I manage an organization’s network, is my organization in-scope for PCI compliance?  The answer is yes, the services you are providing are placing your organization and its relevant services in-scope.

The first response from the network management company is usually, “How can that be, all other telecom companies are out of scope, why not us?”  Quickly followed by, “No other QSA has ever asked us to go through this.”  Remember, the QSA is just the messenger.  Everything stated in this post is from the PCI DSS, the DSS Glossary and other PCI SSC and card brand publications.  This is what the PCI SSC is asking all QSAs to do as part of their PCI assessment work.  If you do not agree, talk to the PCI SSC as they are the only ones that can change the standards.

To answer, “How can that be, all other telecom companies are out of scope, why not us?”

It is very simple. Your organization is not providing just a circuit.  The PCI SSC has been very clear on this.  If all you are providing is a circuit and no other services, then you are out of scope.  The moment your service to a merchant or service provider goes beyond just providing a basic method of transport, you cross into PCI compliance territory.  Basically, the PCI SSC’s interpretation is that if the merchant or service provider has outsourced all or part of a role to your organization, it stands to reason that your organization has assumed that responsibility and, by default, also assumed the relevant PCI compliance responsibility.

But, what if the data is encrypted before it gets to our equipment?  As long as your organization does not have the ability to decrypt the data stream, then your services are out of scope.  However, if the cryptographic process involves your equipment or you manage cryptographic keys, then you are in-scope and must comply with the PCI DSS.

What are your compliance obligations?  Based on my analysis, your organization is involved or responsible for at least the following PCI DSS requirements; 1, 2, 4, 6, 7, 8, 9, 10 and 12.  Here is my high-level take on what you need to be prepared to document, discuss and/or prove you are doing.

  • Provide policies, standards and procedures for device management.
  • Provide policies, standards and procedures for physical and logical security.
  • Provide a copy of your incident response plan.
  • Provide access control definitions for groups and roles that manage the devices.
  • Provide job descriptions for the personnel that manage the devices.
  • Document all protocols/services that are used for managing the devices including a business reason for each of the protocols/services.
  • Provide configurations of a sample of physical devices.  Sampling is allowed as long as the service provider can prove that it has implemented a standard process for managing the devices in question.
  • Provide documentation that supports that device configurations are properly backed up and secured.
  • Provide documentation that supports that device configurations that are running and those that are stored are one in the same.
  • Verification that all relevant policies, standards and procedures are followed in configuring new devices.
  • Verification that documented protocols/services are the only ones configured on the managed devices.
  • Verification that security is properly implemented on all managed devices.
  • Verification that appropriate access control systems are implemented on the managed devices.
  • Verification that remote access is secure.
  • Verification that all user accounts are appropriate managed and controlled.
  • Verification that all logging is implemented and logs are reviewed at least daily.
  • Verification that log information is properly secured.
  • Verification that the time management is properly implemented on each device.
  • Verification that some form of critical file monitoring is being performed.
  • Verification that there is a formal change management process in place including testing.
  • Verification that any cryptographic keys are properly managed and secured.
  • Verification that all devices have been appropriately patched and that there is a patch management process in place.
  • Verification that appropriate physical security controls are in place.
  • Verification that logs are maintained for any backups stored off-site.
  • Verification that alerts are responded to as documented in the incident response plan.

Now for the second comment, “No other QSA has ever asked us to go through this.”  If no other QSA has asked you to go through this, shame on them.  This is why the PCI SSC implemented its Quality Assurance program so that all QSAs start doing the same level of work.  This is also why there is such a variance in QSA costs.  We are finding that the QSAs that are the cheapest are the ones that are not being appropriately rigorous with their assessment of an organization against the PCI DSS.  As the PCI SSC takes more QSAs through the QA process and puts them through remediation, things will change and assessment costs will become more consistent.

01
Feb
10

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.

Update: According to Jerry Dixon, director of analysis at Team Cymru, APT is no different than any other attack.




Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

February 2023
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728