Security is a journey, not a means to an end

I do not know who said this, but they are right.  Threats are always changing; therefore, the tactics necessary to protect your organization’s assets are also always changing.  As a result, security is never a project that is completed; it is one of those never-ending projects.

As I stated in an earlier post about complaints that the PCI DSS always seems to be changing, the PCI DSS changes in response to the threat landscape changing.  And just when you think you have things under control, out comes a new threat that puts a hole in your ‘perfect’ security.  And so the process starts over as you come up with a plan to close the latest hole.

When threats originally started out, they were focused at the network level.  Denial of service attacks were all the rage.  Attacks used the available network services against themselves.  Any network was a potential target.  Remember that last statement.

When those services were disabled, the attacks moved up to the operating system.  However, unlike network attacks, operating system attacks were specific to an operating system.  This is why Windows captured the market on attacks.  When you own 90%+ of the market, you become the biggest target.  However, as Linux and other systems get wider adoption, it is just not good enough to write a Windows attack.

But now the situation is getting worse.  Why?  Because we have created an ideal attack environment in our desire to have every computer operate like all others.  We have created a situation that allows threats to automatically be cross platform enabled.  How?  We are migrating our applications to SQL-based databases and browser-based applications.  Thus creating the perfect attack environment because attackers can develop threats against a single environment.  This is why attacks have moved away from the network and operating system and have moved to the application with cross-site scripting and SQL injections.  And the future for attacks will continue to leverage this common environment because, in our infinite wisdom, we continue to migrate all of our applications (external AND internal) to this environment.  Remember my statement about any network being a target.  What goes around comes around and now every application is a potential target.

What was the PCI DSS response?  Requirement 6.6 was added in v1.1 to institute code reviews or the use of application firewalls.  Requirement 11.3 was changed in v1.2 to include conducting penetration testing on all external AND internal applications.

And given the voracity of insider attacks, it is likely that even more changes are coming.  After the Hannaford, RBS WorldPay and Heartland breaches, there is a call for end-to-end encryption.  While this may stymie insider attacks for a while, I am certain the attackers will find a new vector and we will start the process all over.

So, if you do not like constant change, you had better get out of the security business – NOW!  And do not let the door hit you in the posterior on your way out.

Advertisement

More On The House Hearing On PCI

Okay, I just had to get more of my two cents into what is turning into a debacle. Linda McGlasson posted the latest swipe at the PCI DSS in her blog titled ‘The Agency Insider’. The blog entry is titled ‘Is PCI the Humpty Dumpty of Information Security?”

The first quote that I want to discuss is one from an ‘unnamed security expert’. According to Ms. McGlasson, “PCI, according to an unnamed security expert at a financial institution, is “clearly not good enough to defend against the sophisticated attacks we are experiencing.” The use of clear text card data on any network is just asking for trouble, my source says, but under current PCI requirements it is allowed provided the network is private, i.e., not connected to the Internet.” First, I have a problem with any ‘expert’ that goes unnamed. If you do not or cannot have your name associated with a quote, then you just should not be quoted.

The next issue I have is the use of the word ‘sophisticated’ regarding these attacks. Based on the facts publicly available regarding the Hannaford, Heartland and RBS WorldPay breaches, I do not think the word ‘sophisticated’ is justified. In the case of Hannaford, it appears that someone created a ‘doctored’ server image that contained the malware and then substituted that image for the good image. That took a lot of sophistication – NOT! In the case of Heartland, somehow a Trojan was inserted in their network. Given the ease with which Trojans are inserted into networks every day, I am not sure I would necessarily call that sophisticated either. The RBS WorldPay attack appears to be the same as the Heartland attack, but I have not seen enough specifics about it to say it too was a Trojan infiltration. In the end however, I am guessing that none of these attacks were particularly sophisticated.

Ms. McGlasson’s so-called ‘expert’ apparently does not have a clue about what is going on out in the ‘real’ world. Why? Because even if encryption had been implemented between the devices ala Kerberos, VPN, etc., these attacks would have succeeded as the attackers would still have had access to the data that they sought – encrypted network or otherwise. So, I am really suspect of her unnamed ‘’expert’.

Finally, on this topic, we need to split a PCI DSS hair here, so to speak. What we have been talking about at least for the Hannaford breach is pre-authorization data. Guess what? The protection of cardholder data pre-authorization is not covered by the PCI DSS. Why? Because there are so many variations on how pre-authorization is performed. Airlines and hotels can hang onto cardholder data for days, weeks or months until a flight is flown or a hotel stay is completed. When you purchase gasoline, the dealer can have your card for pre-authorization from the time you swipe your card until you complete filling your tank. In the end, the card brands and the PCI SSC have told merchants to treat cardholder data that they have pre-authorization just the same as they do post-authorization only even more securely as pre-authorization data typically includes even more sensitive data than post-authorization. Formal security standards for pre-authorization data from the PCI SSC have been in the works for the past two and half years and are expected to be released sometime this year.

The next quote that drove me over the edge was related to Chip and PIN. Ms. McGlasson states, “After looking at what other countries are doing with “chip and PIN” technology to cut fraud, such as all of Spain’s merchants agreeing to use chip and PIN, even Clarke came to the conclusion that the US is behind on technology.” When are people going to do some real research and find out that Chip and PIN has its own issues (see my post on Chip and PIN)?

Chip and PIN was developed to fight face-to-face transaction fraud, not the crimes that the PCI DSS is trying to address. The PCI DSS is addressing fraud that occurs after a transaction has been processed and data has been stored in a database or file on a computer system. Chip and PIN shares the same type of back end processing infrastructure as all other credit cards, so Chip and PIN is not an answer to the Heartland and RBS WorldPay sorts of breaches. Moreover, what is doubly worse is that, while Chip and PIN could secure online transactions much better than they are today, the card brands have not published standards for implementing online security with Chip and PIN. So, online transactions are not any better protected with Chip and PIN than with any other credit card.

To address the pre-authorization issue, the only encryption solution that will ever reduce the risk to transactions is to encrypt the transaction from the card itself to the processor. This is likely where Ms. McGlasson thinks Chip and PIN comes into the picture, but she did not articulate that very well in her post. What needs to be done is to ensure that from the terminal to the processor, the data stream is fully encrypted. This will create some potential issues with some integrated POS solutions, but I am sure the vendors of those solutions can work that out. This will also likely result in some standard APIs for credit card processing which will be a good thing. Standards usually get a good vetting and are typically quite good at addressing the known issues once they are published.

I really wish these pundits and so called ‘experts’ would know what they are talking about so that we could move on to securing the data. Nevertheless, it looks like people like me will have to continue debunking the statements that they keep tossing out there.

The ‘MPLS Is A Private Network’ Debate

This discussion item came up during recertification training last week.  It caused a lot of debate from the QSAs in the room with no final decision on who held the correct point of view.

The PCI SSC, participating organizations and the card brands have stated that MPLS (aka, Multiprotocol Label Switching) is a private network, meaning that cardholder data transmitted over an MPLS network does not have to be encrypted.  What was debated was the correctness of that decision.  Where I come down on this issue is that MPLS on its face is not necessarily as private as one might think.

Unlike previous telecommunication solutions such as frame relay and ATM, MPLS is Internet Protocol (IP) aware.  By definition, “When packets enter a MPLS-based network, Label Edge Routers (LERs) give them a label (identifier). These labels not only contain information based on the routing table entry (i.e., destination, bandwidth, delay, and other metrics), but also refer to the IP header field (source IP address), Layer 4 socket number information, and differentiated service. Once this classification is complete and mapped, different packets are assigned to corresponding Labeled Switch Paths (LSPs), where Label Switch Routers (LSRs) place outgoing labels on the packets.”  The key here is that MPLS uses IP header information in order to properly route traffic.  In essence, MPLS is no different from layer 3 IP switching/routing using VLANs on obviously a much larger scale.

Since MPLS is protocol aware, it allows carriers such as AT&T, Verizon, BT and the like to automatically reroute packets to avoid network congestion, outages and other issues that may affect network performance.  Not only can the carriers reroute packets on their own networks, but they can also reroute packets onto other carrier’s MPLS networks if necessary.  And best of all, this occurs automatically based on how your MPLS network is defined.

Carriers will point to IEEE 802.1q for securing MPLS networks.  802.1q is the definition for the tagging of VLAN traffic to separate traffic on the same VLAN.  While in theory the standard does keep the traffic separated even on the same VLAN, it also can be intercepted with the right tools.  So, security is in the eye of the beholder.

Contracts for MPLS service typically include clauses that indicate that the MPLS network will be private, meaning that one customer cannot get to another customer’s network and visa versa.  But here is a potential glitch.  If a carrier reroutes your MPLS traffic to another carrier’s MPLS network for any reason, there is likely no guarantee that your traffic will remain private.

So now that I have described what MPLS is and how it operates, what impact does or can it have on an organization’s PCI compliance? Well, it depends.

The primary point is that an organization’s network traffic is in the clear on an MPLS network, meaning that the carrier and anyone else that has access to the organization’s network can read packets on the MPLS network.  Based on the architecture of MPLS, there are potential risks that the carrier could misconfigure the MPLS network and cause packets to cross to a path.  While this sort of mistake is typically noticeable and rare, it has been known to happened, so it is not totally out of the realm of possibility.  In addition, IP spoofing and similar attacks can be used to penetrate the 802.1q protocol, so it is not an absolute assurance that your traffic will stay secure over the carrier’s network.

Carriers operate multiple customer MPLS networks using large layer 3 switches and many VLANs.  Traffic from multiple customers may be aggregated on a single VLAN or over their own individual VLAN.  Regardless, VLAN access controls need to be understood and properly managed and maintained just like on your own network.  Under MPLS, your carrier is just putting you into one or more VLANs to move your data from location to location.  Under network segmentation rules, there needs to be proper controls in place to ensure that VLANs and access to them a truly separated.  Remember, it is not just your data streams; it is many customers data streams being managed and separated.  Under MPLS, I would argue that the carrier’s controls in this area should also be assessed for PCI compliance as well as the customer’s because the carrier’s network is just and extension of the customer’s.

Since the carrier is just an extension of the customer’s network, the carrier needs to be made aware of PCI or other sensitive network traffic so that they can take appropriate measures to ensure the security of the data stream.  This may include having the carrier commit to ensuring the security of the data stream by segregating it from other customers’ traffic and not rerouting it to another carrier’s network.  If the carrier is aware of PCI data traffic, the carrier is also responsible for complying with PCI DSS requirements to ensure that traffic maintains its privacy and security.

In response to the risks presented by MPLS, a lot of organizations just encrypt their network traffic.  However, encryption defeats the point of MPLS because once the data stream is encrypted, MPLS can no longer have access to the IP headers.  There is currently an IEEE working group that is developing a new encryption standard that will make IP packet headers readable while encrypting the packet’s payload, thus allowing MPLS to still route packets without having access to the data contained in those packets.  When this new encryption standard will be released is anyone’s guess, but there is impetuous to get it agreed to quickly so that MPLS can be better secured.

The bottom line is that MPLS may or may not be private.  It all depends on how the carrier implements it.  As a customer, I would recommend that you discuss your network security and privacy requirements in detail with your carrier so that they can accommodate your requirements and understand their potential obligations.  Do not just accept their assurances that MPLS is private.  In the end, if the carrier cannot ensure the security and privacy of your data, then MPLS is likely not your networking solution.

UPDATE:

The PCI SSC issued an FAQ (#1045) in May 2014 on this topic.  To quote the Council:

Is MPLS considered a private or public network when transmitting cardholder data?

Whether an MPLS network can be considered a private network is dependent upon the specific provider and configuration of that network. The implementation would need to be evaluated to determine whether the MPLS network provides exposure to the Internet or other untrusted networks, before concluding whether the MPLS network can be considered private. If the MPLS network contains publically-accessible IP addresses or otherwise provides exposure to the Internet (for example, if an edge router has an Internet port), then it may need to be considered an “untrusted” or a public network.

If the MPLS network is determined to be private, transmissions of cardholder data over that network would not need to be encrypted per PCI DSS Requirement 4.1.  However, if there are points of exposure to the Internet or it is a shared connection, the MPLS network could be considered as untrusted or public, and Requirement 4.1 would apply.

MPLS networks that have been verified as being private are still in scope for PCI DSS, and, as with all private networks that are in scope, the MPLS network and associated devices would need to meet the applicable PCI DSS requirements.

 

I Couldn’t Have Said It Better Myself

I despise reinventing the wheel.

See the article at CSO Online entitled, ‘PCI Shrugged: Debunking Criticisms Of PCI DSS‘.

PCI Standards Are Overly Complex

At the March 31, 2009 hearing held by the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology, Mr. Michael Jones, CIO of Michaels Stores, Inc. stated, “The PCI Data Security Standards are an extraordinarily complex set of requirements. They are very expensive to implement, confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement.”  Let’s examine his statement and see if or where Mr. Jones is going off track.

First, let’s take his remarks regarding the fact that the PCI DSS is “confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement.”  After attending my latest recertification training, I could understand his remark.  There were a few QSAs in attendance that did not appear to fully understand what the PCI DSS is about and the concept of risk management.  However, these QSAs were in the vast minority of the rest of the attendees.  That said, there are a number of areas in the PCI DSS that are up for interpretation between the QSA and the acquiring bank.  So, while a QSA may interpret a given area as being compliant, the acquiring bank may not take the same view.  Given all of this, I’ll give the confusion and subjectivity points to Mr. Jones.  However, on the enforcement side of his comment, I think Mr. Jones is all wrong.  From my involvement in a variety of card brand enforcement actions, the card brands are neither confused or subjective when it comes to enforcement, far from it.  So, it’s a split decision so far.

Now let’s tackle the big issue, that the PCI DSS is “extraordinarily complex.”  Apparently, Mr. Jones has not seen the NSA security standards, ISO 27000 or the NIST FISMA standards.  If he thinks the PCI DSS is complex, he’s in for an extremely rude awakening if he ever sees these other security standards.  The PCI DSS is nothing more than a consolidated collection of information security ‘best practices’ for the protection of cardholder data (CHD).  They could be used as a framework for protecting any personally identifiable information (PII) and I typically recommend the PCI DSS standard to clients that are looking for a PII security framework.  It’s obvious that Mr. Jones does not have much of a background in information security or he would recognize that the PCI DSS is nothing extremely new or complex.  Based on my experience with organizations taking similar positions, I’m betting that Mr. Jones and his staff are not in a position to be able to address network and data security.

Finally, Mr. Jones stated that the PCI DSS is “very expensive to implement.”  I am guessing that this statement is the result of Mr. Jones running his operation on a shoestring budget with very little in the way of modern hardware and software.  While this sort of management style makes lots of friends with the other C-Level executives, it does nothing to help the organization adapt to the changing retail environment.  But regardless of whether we are talking retail or any other type of organization, what gets lost because of this shoestring approach is that there is a baseline cost of doing business that must be met just to be in business.  For Michael’s Stores, this would likely include applications such as an inventory management and distribution system, point of sale system, merchandising system, Internet-based store, etc. and all of the necessary hardware, utility software and networks to support it all.  All of these components have a cost associated to them, both an initial cost and on-going costs for support, security, privacy, maintenance, training and replacement.  I cannot tell you how many organizations, of all industries and sizes I have worked with over the years, do not compute total on-going costs so that they can plan and budget properly.  As a result, management of these organizations go through ‘shock and awe’ every time they need to invest in anything because things are never planned, they are always a surprise.  I’m again betting that Mr. Jones operates in this manner and as a result got caught without any way to provide an option to get PCI DSS compliant because of short sidedness on his part.

In the end, I think Mr. Jones used his appearance at the House hearing as a way to justify his own short sidedness.  It is these sorts of people that blame everyone but themselves for their problems when it is their limited and irrational views that are the real problem.  As I have said before, the PCI DSS is not perfect, but it is a lot better than Mr. Jones’ approach, which is apparently to do as little as possible and whine about it.

QSA Consistency

I attended my recertification training this past week in Chicago.  Kudos to Jeff Foresman, the PCI SSC’s new internal trainer.  Jeff is a great person with a great background as a former QSA and network security person.  I could not think of anyone better to conduct the QSA training.

One of the implicit goals of QSA recertification training is to ensure that all QSAs are consistent in their interpretation of the PCI DSS.  However, there are still a number of areas within the PCI DSS that are left up to the QSA for interpretation and their acceptance of risk.  It is these areas where QSAs are going to vary on whether or not a given situation is compliant with the PCI DSS.  It is with these areas that merchants and service providers ‘shop’ for a QSA that will interpret the PCI DSS the way the merchant of service provider wants them interpreted.  Which is a problem the PCI SSC recognizes, but can only address through continued QSA training.

One such area is anti-virus.  Requirement 5.1 states, “Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).”  The QSA is left to interpret what is meant by “all systems commonly affected.”  Almost all QSAs agree that all Windows systems require some sort of anti-virus (apparently there are still some ‘Windows-bigots’ out there that think Windows, properly hardened, is just fine).  However, not all QSAs are in agreement with other operating systems.  For example, using a QSA that is a ‘Linux-bigot’ could result in an organization being judged PCI compliant without having anti-virus on their Linux systems.  Even though in our recertification training we were explicitly told that Linux systems must have an anti-virus solution, which put some QSAs in the room in a tizzy.  The instructor’s response was that it was the QSA’s reputation that was on the line if they signed off on compliance and did not require Linux anti-virus.

Network segmentation is another area that is up for interpretation.  I have stated in my Network Segmentation post that, “I know good network segmentation when I see it.”  However, from class this week, it is apparent that not everyone agrees on what constitutes ‘good’ network segmentation.  Therefore, this will continue to be an area that will constantly have consistency issues from one QSA to another.

Finally, we had a discussion in class regarding compensating controls.  This is always a big area of discussion with clients and also a big area of inconsistency for QSAs.  Since I work for an organization that does a lot of internal audit and Sarbanes Oxley work, our definition of compensating controls is a bit more structured and risk adverse than the PCI SSC’s view.  We are able to work with clients to come up with acceptable, in our view, compensating controls.  However, some of the examples provided in class this past week indicated that not everyone has the same view of compensating controls as we do.  This will also be an area where there will be significant variance from one QSA to another.

The bottom line is that, unfortunately, merchants and service providers understand these inconsistencies and use them to get around PCI compliance issues by hiring QSAs that are like-minded and are willing to bend the rules.  Therefore, until QSAs become consistent, breaches will likely occur because one QSA was willing to take on the risk of judging something compliant when it should not have been judged that way.

The ‘I Have To Keep The Data’ Myth

I started this blog to dispel myths and a big one came up at last week’s House hearings.

Michael Jones, CIO of Michael’s Stores, stated, “As a retail CIO, there is nothing better than to not store a single credit card number anywhere in our network of systems.  But that data has to be kept in case of disputed transactions.”  What?  But this is a myth that you hear a lot from merchants.

I hear it the most in large organizations from their fraud prevention departments.  And while I understand their need, I think the PCI DSS provides them with more than enough capability in the first 6, last 4 truncation rule on primary account numbers (PAN).  Even using the approved truncated PAN can do just as much for fraud detection and prevention than having the full PAN.  If they still complain, then I recommend using a salted hashing algorithm on the PAN.  Under this approach, the PAN is no longer considered cardholder data, but the same PAN will hash to the same value making full text searches still functional.

You also hear this myth from accounting and credit management personnel.  These people are driven by the need to have the data available just in case.  Remember, for most merchants, disputes are not a big percentage of their transactions, typically less than 1% of all transactions.  But, for a Level 1 merchant doing 7 million transactions a year with a 0.5% dispute rate, they have to handle 35,000 disputed transactions per year.  So the volume can be a problem.  To address this, the accounting types pushed for and got the credit card data stored on a system to research these disputes.  It was for convenience.  However, in today’s networked world, access to this sort of transaction data can be provided by the merchant’s acquirer.  After all, it went through their systems as well.  All a retailer needs to be able to provide is a transaction number, transaction date and time of other unique transaction identifier and the first six and/or last four digits of the PAN so that they can link up the transaction with the acquirer’s data.  In many instances, acquirers can provide merchants with online access to their transaction databases for transaction lookup just for this purpose.  Granted, only a select few people at a merchant will have such access, but it can be obtained.  For smaller merchants, acquirers will provide transaction details back by facsimile for research purposes.

So, get off this ‘I have to keep it’ bandwagon.  There is no reason that a merchant has to retain cardholder data.  In today’s world, there are many ways to get the job done without putting the data at risk.

PCI Compliance Is Not Enough

In my opinion, Representative Yvette Clarke (D-NY) last week proved President Abraham Lincoln’s statement, “Better to keep one’s mouth shut and keep people guessing, than to open it and remove all doubt.”

Representative Clarke stated, “I do want to dispel the myth once and for all that PCI compliance is enough to keep a company secure.  It is not, and the credit card companies acknowledge that.”  I do not know where Representative Clarke’s aides have been, but I have not seen anything from any of the card brands that would indicate that they have acknowledged that PCI compliance is not enough.  To the contrary, based on the quotes from the card brands that I have seen the card brands and in particular, Visa USA believes that PCI compliance is the ‘Holy Grail’ of security.

Do not get me wrong.  Are there ways that the PCI standards can be improved?  No doubt about it.  However, the sort of standard that Representative Clarke is suggesting in her statements would not be workable, let alone implementable.  Moreover, if Michael Jones, the CIO of Michael’s Stores, thinks that the current PCI standards are overly complex, the standards that Representative Clarke is suggesting would probably take him completely over the edge.

Representative Clarke went on further to point to Chip and PIN as a salvation for security.  Again, Representative Clarke must not have the ‘best and brightest’ on her staff or they would have seen from a Google search that there are significant security issues related to Chip and PIN.  So while Chip and PIN could be a better solution, it is not the perfect solution Representative Clarke seeks.

PCI compliance is enough IF (and that is a big ‘IF’) a company is consistently diligent in applying the PCI standards day in and day out.  It is not the standard that is the problem; it is the consistent application of the standard every day that is the problem.  Why?  Because humans are involved and humans are fallible.

Representative Clarke misses the fact that there is a human element involved in all security and it is that human element that typically is the biggest problem.  Whether it is the programmer writing the firewall or application software, the person that erroneously configures a security device or a human being that misses or mistakenly responds to a security alert, it is those sorts of human errors that result in breaches.  Therefore, unless Representative Clarke intends to outlaw human beings from the practice of information security, she better own up to the problem and admit that breaches will occur regardless of her outrage.  What proper security will do is reduce the number and frequency of breaches, but it will never eliminate them.

What Representative Clarke also misses is that there is no such thing as perfect security.  If there were, banks would not be robbed as often as they are robbed.  Even with all of the sophisticated security in a bank, they are still robbed and fairly often, I might add.  The only reason bank robbers eventually are caught is that they get sloppy – they are human after all!

At the end of the day, even if a company invests in all of the security appliances, policies, standards, procedures and techniques, there is still a risk (small as it may be) that they could be breached.  In addition, no matter how diligent an organization is, they all get sloppy at certain tasks over time creating even more risk.  It is that risk that the dedicated attackers use to breach systems.  Because a dedicated attacker will do whatever it takes to create a breach no matter what barriers are put in their way.