We Are In This Together

I am starting to hear a troubling rationale regarding PCI compliance.  It typically is expressed as a reluctance to comply with the complete PCI standards because the organization does not store cardholder data.  You hear people questioning why they need to have anti-virus, log analysis, file monitoring and other security measures in place if they are not storing cardholder data.

Well, get a clue, your organization is just one of many in the systems that handle cardholder data.  Your organization is just one part of the overall cardholder data flow.  Cardholder data flows from the merchant to one or more gateways or processors to an acquirer and back.  Each one of these entities is dependent on the security posture of the other to ensure that cardholder data is protected.  If you are shortcutting security at your point in the process, you are creating a gap in everyone’s security.

If your organization is one of the lucky ones to have gotten cardholder data off of all of your systems, you still process and/or transmit cardholder data.  People sometimes forget that the PCI standards are about the processing, storage or transmission of cardholder data.  Just because you no longer store cardholder data, you still need to be concerned about securing the processing and transmission of cardholder data.

Securing the processing of cardholder data is typically the easier of the two to control.  All you have to do is control the access to the device and make sure that users cannot access the memory of the device.  However, with today’s development environments, security surrounding the processing of cardholder data is not as simple as it seems.  Most developers have no idea as to how their programs physically work when it comes to memory management.  As a result, we are seeing more and more instances of cardholder data being stored in the memory of all sorts of devices.  In the best cases, the cardholder data in memory is cleared once the transaction has been approved or declined.  However, in a lot of cases, the device memory contains every transaction that has been processed since the last run of end-of-day or similar process.  And powering off a device is no guarantee that memory is purged.  As a result, just because you only process cardholder data does not mean you are safe.

Then there is the more obvious security related to the transmission of cardholder data.  End-to-end encryption is in the news ever since Robert Carr of Heartland Payment Systems made it all the rage.  However, security of the transmission of cardholder data is also easier said than done.  One of the biggest obstacles can be the processors, gateways and acquirers themselves.  A lot of these organizations do not even support the secure transmission of cardholder data.  While this situation is getting better every day, it still surprises me how many of these organizations are still transmitting cardholder data in an insecure manner.  However, even with end-to-end encryption, there are still ways to compromise cardholder data.  Yes, it is more difficult, but it is not impossible.

All of this discussion of securing memory and communications is moot if the PCI standards are not completely followed.  If anyone is able to compromise the data flow at any point in the line, the flow is compromised.  And once compromised, the data is for the taking.  Therefore it is imperative that everyone in the data flow keep their guard up and ensure that their security measures are sufficient to protect the data flow.  That means following the PCI standards to ensure security.

The other part of this troubling situation is that when all cardholder data gets removed from the merchant systems, it will be the processors, gateways and acquirers that will become the targets.  Attackers will do whatever it takes to get into them for the data they hold.  If organizations that connect to these entities are not doing everything they need to secure their environments, they will be used as the way into the processors, gateways and acquirers.

That is why everyone needs to stay on top of their game even when cardholder data is no longer stored.

Advertisement

PCI Compliance and Franchising

There was post recently on the SPSP Forum regarding the lack of information on franchise operations and PCI compliance.  Since I have been searching for a topic to write on, I thought I would take up this topic.

The PCI DSS has only one reference to franchises and that is on page 7.  The reference on page 7 is only in regards to sampling.  During our first year of QSA training, we were told that PCI compliance in a franchise environment is controlled by the operational relationship between the franchiser (the organization that licenses the concept) and the franchisee (the organization that executes the retail concept).  Franchisees typically maintain their own merchant accounts and have their own contracts with an acquiring bank.  For PCI compliance purposes, most franchisees are independent from their franchiser and therefore, the franchisee is responsible for their PCI compliance and any document filing.

At their simplest, franchisees use “knuckle busters” and stand-alone terminals.  In these instances, the franchisee can fill out and file a self-assessment questionnaire (SAQ) B.  Other franchisees, such as those in the fast food industry have purchased un-customized integrated point of sale (POS) with a network at the restaurant.  These sorts of installations typically meet the requirements for SAQ C.

However, thanks to technology and integration, the PCI compliance of the franchiser and franchisee can blur.  The best example of technology creating a PCI compliance nightmare for a franchiser is Speedpass from Exxon/Mobil.  Speedpass is a great customer convenience and probably one of the more innovative uses of RFID technology.  The customer registers one or more credit cards at the Exxon/Mobil Web site and is mailed a Speedpass RFID fob.  At the service station, the customer merely waves the Speedpass RFID in proximity to the Speedpass logo on the gas pump and they are validated and pay without a credit card ever being used.  From a PCI compliance perspective, this sounds like a very secure approach and it is.  However, because of Speedpass, franchised operations have to send their Speedpass transactions through Exxon/Mobil’s central data center.  That data center is where the Speedpass RFID serial number is translated to a credit card number that the Speedpass customer entered into the Exxon/Mobil Web site.  That credit card number is then used with the franchisee’s merchant number to process the transaction.  As a result, Exxon/Mobil is on the hook for not only their own PCI compliance, but also all of their franchisees that accept Speedpass.  The lesson of Exxon/Mobil is that if the franchiser requires franchisees to process their transactions through the franchiser’s data center, then the franchiser is responsible for everyone’s PCI compliance.  The franchiser also is responsible for the monitoring and compliance of all franchisees.

Then you have the franchises that integrate sales and inventory management with corporate to ensure accurate ordering of material and to get daily sales figures.  No cardholder data is ever involved.  Most of these older solutions transfer their data at the end of day via FTP or some other batch data transfer method.  These sorts of solutions keep the franchisee and franchiser separated, so PCI compliance is straightforward.  In these instances, the franchisee just treats the franchiser as a service provider and files their own PCI compliance documentation.

However, in this age of total integration, newer solutions fully integrate the front of the business to the back of the business all to a central data center, regardless of the legal relationship between the parties.  The franchiser is typically not accessing individual sales transactions, they just want to know how many of each item has been sold and they want visibility into a store’s inventory data in real time.  This integration is also key to many franchise e-Commerce operations such as online ordering with in-store delivery, reservations and other customer friendly functions.  All of this integration means that the franchiser’s systems are then passing cardholder data (CHD) to the franchisee and possibly sending CHD the other way as well.

To add insult to injury, the franchiser, under the guise of making all of this technology easy to operate for the franchisee, provides help desk and IT operations management to the franchisee.  Where this all goes wrong is that now the franchiser’s IT personnel have access to the franchisee’s networks and computer systems and, possibly, CHD.  Regardless of whether or not CHD is involved, the franchiser has remote access to the franchisees’ systems, which means that the two parties must rely on each other for PCI compliance.

In the end, PCI compliance in a franchise environment all depends on the responsibilities of each party.  If they are truly separate, then there are no compliance conflicts between the parties.  However, when the franchiser begins providing PCI in-scope related services and/or technology solutions to their franchisees, then the franchisee relies on the franchiser for their PCI compliance and the franchiser is on the hook for that compliance.

UPDATE: Visa has introduced a new category of third party service providers called Corporate Franchise Servicers.  See this post regarding this program.

Compensating Controls

A lot of organizations are relying on numerous compensating controls to achieve their compliance with the PCI DSS.  For version 1.2 of the PCI DSS, compensating controls have two new requirements and these new requirements will have the potential to cause a lot of organizations to become non-compliant.  As a result, I expect to find the next year very painful for our new clients as we explain these new rules and they attempt to come up with the documentation to keep their compensating controls.

There are now six requirements to the Compensating Controls worksheet.  The original four:

• The PCI DSS requirement that cannot be met;
• The control objective(s) of the PCI DSS requirement;
• The business reason(s) why the PCI DSS requirement cannot be met; and
• The compensating control(s) that have been put into place to achieve the PCI DSS requirement.

In addition to the original four requirements, two more have been added.  Those requirements are:

• Validation that the compensating controls are functioning as defined; and
• How the organization maintains the compensating controls.

The easier of the two new requirements is how an organization maintains the compensating controls.  However, while it is the easier of the two from a discussion standpoint, the fact that an organization must be able to document its maintenance processes for controls could be problematic.  In most organizations, the change control process for the control environment is typically not documented.  As a result, most organizations will have to adopt their change control processes for other business issues and just apply it to changes to their control environment.

The other new requirement is the one that most organizations will struggle with, providing documentation that the controls they are using to compensate for their lack of meeting the PCI DSS requirement are functioning as designed.  While this sounds simple and straight forward, I can tell you from personal experience that a lot of the compensating controls that were documented under v1.1 of the PCI DSS cannot provide this sort of proof.  In addition, a lot of compensating control cannot undergo the scrutiny of testing required to determine that they are functioning as designed.

So, where is the problem?  An organization must prove that it walks the walk, not just talks the talk.  This is where the wheels typically come off the bus.  It is very easy to say that something is a control; it is another thing to be able to actually prove it.  Organizations will have to provide documentation in the form of completed checklists or other formal documents that proves that the control is not only being used but that if a control exception occurs, the exception is addressed.  In addition, the QSA will also have to observe these processes at work so that they can satisfy themselves that the control is functioning.

I am not saying that compensating controls are a bad thing.  There are instances where organizations have no other choice.  The most common issue in this category is the database that takes more than 9 to 15 months to re-encrypt in order to change encryption keys.

In my experience, though, there are even more organizations that are using compensating controls because it is an easy out.  One of the most common reasons is that they need to avoid a large expenditure.  There are also those organizations where meeting the requirement will take a cultural change that management cannot step up to make.  There are also those organizations that just despise being told what to do and are just digging in their heels.  And, finally, there are those organizations that just plain do not want to have to get off their rear and do something.  For organizations like this, the jury rigging and hurdles they go through to make a compensating control work is mind boggling and, more often than not, costs more in time and resources than just meeting the original requirement.

If your organization is relying on compensating controls to be compliant with the PCI DSS, then you will want to make sure that you absolutely have no other alternative than a compensating control.  You should do an analysis of what it costs to maintain and comply with the compensating control versus implementing the PCI DSS requirement as written.  I would say that in about 85%+ of the cases, you will find that meeting the original requirement can be achieved easier and cheaper than using the compensating control.

PCI Check Box Compliance – Volume 1

We just started an engagement with a new client a week ago.  While reviewing documentation, we came across this situation that I had to share because it points out how some QSAs out there just want to check a box and not use their heads.  It is this sort of mentality that gives all QSAs a black eye and it needs to stop.

In order to meet requirement 5 of the PCI DSS, one of the biggest QSACs required our new client to get anti-virus software for their IBM iSeries (aka AS/400) mainframe.  The rationale?  If there is an anti-virus solution published for an OS platform, there must be a virus or malware out there that it protects it from.  Whoa!

This client also has AIX running, IBM’s UNIX derivative.  Technically, ClamAV can be recompiled and installed on AIX, yet the QSA did not tell the client that they needed anti-virus on AIX.  So much for consistency.

Even without a decent technical background, a review of the Web sites offering anti-virus solutions for the iSeries would tell you that your logic was patently wrong.  All of the anti-virus solutions for the iSeries are very clear that the iSeries does not have any viruses or malware, but it can be a carrier if you have mountable file systems for Windows or UNIX defined on your iSeries.  In the case of this client, they do not have any mountable shares, so there is no risk.

However, if you do have an iSeries that has implemented Windows or NFS shares, there is a much simpler way to handle this situation.  Just use one of your existing systems that does have anti-virus installed to scan the mountable shares on the iSeries weekly.  We had recommended this sort of approach for years for NetWare environments which had notorious problems with anti-virus solutions that were installed under NetWare.  The NetWare shares were scanned by a Windows system that had administrator rights so it could scan everything in the mountable volumes.

I will not bore you with all of the technical details, but there are a number of reasons why an iSeries, or IBM zSeries, Unisys ClearPath and other ‘old’ technology systems for that matter, cannot be infected like a PC.  These mainframe systems are almost impossible to infect directly if they are running their ‘old’, proprietary operating systems such as zOS, MCP and the like.  The controls surrounding true ‘root’ access on these OSes are such that you really must be a ‘Geek God’ to have such rights.  Even systems programmers in these environments do not have those kinds of rights.  And then, even if you did have the ultimate rights, there are other controls in place that would only allow your code to function on a particular computer complex, so it would not necessarily be transferrable to another system.  So much for infecting others.

But there is a risk with these platforms.  Most of these systems also will run slightly modified versions of Linux and UNIX and those can definitely be infected.  In those cases, all bets are off and you need to treat this big iron just like their Intel brethren.

So, the lesson to be learned from this experience?  If you do not have expertise with a platform, find someone that does have that expertise.  After all, not everyone working on a PCI assessment must be a QSA.  The QSA just needs to always be on-site when the work is being performed.  So, use someone in your organization that has the platform expertise or find a sub-contractor that has the expertise, but do not try to wing it.  Winging it only makes all of us look bad.

Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

• The PANs can only be displayed one at a time.
• You have to be in administration mode to view the PANs.
• The PANs cannot be printed out.
• The PANs are stored in memory, not on a hard drive.
• The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.”

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.

Segregation Of Duties

This is a subject that has come up a number of times lately and I think it needs to be addressed as there is apparently a lot of confusion about segregation of duties.

Let us first define segregation of duties.  When duties are properly segregated, no one individual is able to complete a task without the assistance of one or more individuals.  Segregation of duties grew out of the finance and accounting areas where it is important to have as many individuals involved as possible to minimize the likelihood of fraud.  This is the first important lesson of segregation of duties, it does not eliminate the possibility of fraud, it only minimizes the possibility.  If a group of individuals decide to work together to commit fraud, segregation of duties will not stop such activity.  However, the group will have to work together which is where the deterrent factor comes in as it is more difficult to hide a fraud with a group of people involved.

What people have been complaining about most when I talk to them about segregation of duties is that they will have to increase head count.  In today’s tight economy, increasing headcount is typically not an option and even in good times, increasing headcount is not always desirable.   While there are situations where headcount does have to increase to get proper segregation of duties, I would say that in 90%+ of cases that I have been involved with this is just not true.  In fact, in a number of cases, headcount actually got reduced.

As I stated earlier in the definition, what segregation of duties involves is making sure that processes that involve people are structured such that no one individual can complete the task.  In the PCI compliance realm, there are a number of areas requiring segregation of duties.  The majority of which are related to change control.  The reason change control needs segregation of duties is to minimize human error.  The idea is that, if more people are involved, the less likely that human error will be introduced and therefore security will be maintained.

So, in a change control environment with proper segregation of duties you have the following simplified process.

• Person ‘A’ makes a change to something (program, device, etc.) based on the requirements specified in Change Request ‘1’.
• Person ‘A’ conducts unit testing of the change to make sure that the change is operating as expected.
• Person ‘B’ reviews the change and conducts integrated testing of the change to make sure that the change is operating as expected with the complete system.  Typically this testing is in an environment that replicates production.  If testing is not successful, ‘B’ documents the failure and sends the request back to ‘A’ for further work and testing.
• If testing is successful, Person ’B’ meets with Manager ‘C’ and provides ‘C’ with the results of testing.  If testing was successful, ‘C’ approves the change to go into production and an implementation schedule is agreed to for the implementation of the change.  If ‘C’ believes that the change is not what was documented in Change Request ‘1’, then ‘C’ will reject the proposed change and send the request back to ‘A’ for further work.
• If approved, Person ‘B’ moves the change from test to production.

As you can see in my simple example, there are only three people involved in the change process – two staff and a manager.  The staff could switch off the change initiator and change tester roles, but the manager is always going to be the approver.  In larger organizations, there may be more steps and more people involved in each step, but the idea is the same – minimize the potential of introducing human error into the process.  The idea being that, with more people involved in the review of the process and the results, the less likely that an error will occur.

Does human error still occur? You bet, all of the time.  Why?

• Because the people involved are human and errors occur.
• People do not have the experience to perform their role in the process.
• People get lax in their role in the process.
• The process is not followed to the letter.
• Testing plans and testing as a whole are skipped or short cut.

In today’s hurry up environment, people expedite processes by not following all of the steps in the belief that it does not affect the outcome.  While not as critical as flying a plane, the commercial aviation industry has proven over the last 70 years that procedures have a major impact on minimizing human error.

However, if people are left in roles for too long, job stagnation can become a serious problem.  However, job stagnation can be simply addressed by rotating people’s responsibilities.  Such an approach not only keeps people fresh, but has the added benefit of cross training them for other tasks.  A lot of organizations I work with rotate their quality assurance people back to roles as change initiators or as production operations personnel to keep them fresh.

Hopefully I have pointed out that it does not take a mass of people to maintain segregation of duties.  It just requires a creative approach to ensuring that you have the most people possible to ensure that no one person is carrying the entire load or all of the responsibility.

More On Compliance

Main Entry: com•pli•ance
Pronunciation: \kəm-‘plī-ən(t)s\
Function: noun
Date: circa 1630

1 a : the act or process of complying to a desire, demand, proposal, or regimen or to coercion

I just saw another whiner on the Web stating that compliance does not mean you are secure.  Based on the aforementioned definition from Webster’s, anyone taking the position that compliance has nothing to do with security should get out of the business.  So, where are these people going wrong?  In my opinion, they are confusing the assessment of compliance with the act of complying.

An assessment only makes sure that, at a given point of time, your security policies, standards and procedures are being adhered to by your personnel.  But compliance is more than just doing things right at a point in time or only when you are being assessed.  Security is a 24×7 occupation, so you can never let up.  Therefore, compliance is one of the most important aspects of your security posture.

Compliance starts with the appropriate security policies, standards and procedures.  If you are not following security best practices that are appropriate for your organization from a recognized source such as NIST, SANS or similar, then all of your compliance will not matter because your security policies, standards and procedures are flawed and/or incomplete.  So the first order of business is getting the appropriate security best practices put in place.

The next necessary step is training your personnel to ensure their compliance with your security policies, standards and procedures.  Security training and awareness of your organization means that they have an understanding of the security risks that are present in today’s computing environments and also understand the reasons for your security policies, standards and procedures.  It is the rationale of security policies, standards and procedures that most organizations miss and why training seems to provide limited results.  It is very hard to get people to comply with security policies, standards and procedures if you are not completely explaining them.  Without a full explanation, your personnel will likely ignore them as meaningless or pointless.  You can have all of the latest, greatest technological security solutions in the world, but if your personnel are not complying with your security best practices, all of that technology is worthless.

You also need to do monitoring of your personnel’s compliance with your policies, standards and procedures.  Unfortunately, anything less than 100% compliance means that you have gaps in your security.  Some of those gaps may be small and/or covered by other security elements.  But some of those gaps may be huge and put your entire organization at risk.  It is these huge gaps that need immediate attention and personnel retraining to ensure that they get closed quickly and do not occur again.  It is the act of closing the loop that makes security successful.  If you are not correcting mistakes or improving your security policies, standards and procedures, you will be doomed to failure.

And finally, security is not perfect.  Success in security is minimizing risk, not getting rid of it.  Risk will always exist because getting rid of it in most cases is too expensive and/or time consuming.  Compliance with your security policies, standards and procedures is one of the keys to that success.  If you are not enforcing compliance, then your success will be very limited.

So there is my two cents worth on compliance.  If you still believe that compliance is not security, think again.  And if you still think compliance is meaningless, then you better find a new occupation because security will eat you alive.  As a person in the security profession, it is all about compliance with security policies, standards and procedures.  And that, my friends, means that compliance equals security.