Pci

Quick Thoughts on the Point of Sale Security Fail Lawsuit

By Rich

Let the games begin.

It seems that Radiant Systems, a point of sale terminal company, and Computer World, the company that sold and maintained the Radiant system, are in a bit of a pickle. Seven restaurants are suing them for producing insecure systems that led to security breaches, which led to fines for the breached companies, chargebacks, card replacement costs, and investigative costs. These are real costs, people, none of that silly "lost business and reputation" garbage.

The credit card companies forced him to hire a forensic team to investigate the breach, which cost him $19,000. Visa then fined his business $5,000 after the forensic investigators found that the Radiant Aloha system was non-compliant. MasterCard levied a $100,000 fine against his restaurant, but opted to waive the fine, due to the circumstances.

Then the chargebacks started arriving. Bond says the thieves racked up $30,000 on 19 card accounts. He had to pay $20,000 and managed to get the remainder dropped. In total, the breach has cost him about $50,000, and he says his fellow plaintiffs have borne similar costs.

The breaches seemed to result from two failures -- one by Radiant (who makes the system), and one by Computer World (who installed and maintained it).

1. The Radiant system stored magnetic track data unencrypted, a violation of PCI standards.
2. Computer World enabled remote access for the system (the control server on premise) using a default username and password.

While I've railed against PCI at times, this is an example of how the system can work. By defining a baseline that can be used in civil cases, it really does force the PoS vendors to improve security. This is peripheral to the intent and function of PCI, but beneficial nonetheless. This case also highlights how these issues can affect smaller businesses. If you read the source article, you can feel the anger of the merchants at the system and costs thrust on them by the card companies. Keep in mind, they are already pissed since they have to pay 2-5% on every transaction so you can get your airline miles, fake diamond bracelets, and cheap gift cards.

The quote from the vendor is priceless, and if the accusations in the lawsuit are even close to accurate, totally baseless:

"What we can say is that Radiant takes data security very seriously and that our products are among the most secure in the industry," Paul Langenbahn, president of Radiant's hospitality division, told the Atlanta Journal-Constitution. "We believe the allegations against Radiant are without merit, and we intend to vigorously defend ourselves."

Maybe they can go join a certain ex-governor from Illinois on the next season of The Celebrity Apprentice, since they are reading from the same playbook.

There are a few lessons in this situation:

• The lines have moved, and PCI now affects civil liability and government regulation.
• PCI compliance, and Internet-based cardholder security, now affect even small merchants, even those without an Internet presence.
• We have a growing body of direct loss measurements (time to revise my Data Breach Costs model).
• We are seeing product liability in action... by the courts, not legislation.
• As with many other breaches, following the most basic security principles could have prevented these.

I think this last quote sums up the merchant side perfectly:

"Radiant just basically hung us out to dry," he says. "It's quite obvious to me that they're at fault. . . . When you buy a system for $20,000, you feel like you're getting a state-of-the-art sytem. Then three to four months after I bought the sytem I'm hacked into."

–Rich

Tokenization Will Become the Dominant Payment Transaction Architecture

By Rich

I realize I might be dating myself a bit, but to this day I still miss the short-lived video arcade culture of the 1980's. Aside from the excitement of playing on "big hardware" that far exceeded my Atari 2600 or C64 back home (still less powerful than the watch on my wrist today), I enjoyed the culture of lining up my quarters or piling around someone hitting some ridiculous level of Tempest.

One thing I didn't really like was the whole "token" thing. Rather than playing with quarters, some arcades (pioneered by the likes of that other Big Mouse) issued tokens that would only work on their machines. On the upside you would occasionally get 5 tokens for a dollar, but overall it was frustrating as a kid. Years later I realized that tokens were a parental security control -- worthless for anything other than playing games in that exact location, they keep the little ones from buying gobs of candy 2 heartbeats after a pile of quarters hits their hands.

With the increasing focus on payment transaction security due to the quantum-entangled forces of breaches and PCI, we are seeing a revitalization of tokenization as a security control. I believe it will become the dominant credit card transaction processing architecture until we finally dump our current plain-text, PAN-based system.

I first encountered the idea a few years ago while talking with a top-tier retailer about database encryption. Rather than trying to encrypt all credit card data in all their databases, they were exploring the possibility of concentrating the numbers in one master database, and then replacing the card numbers with "tokens" in all the other systems. The master database would be highly hardened and encrypted, and keep track of which token matched which credit card. Other systems would send the tokens to the master system for processing, which would then interface with the external transaction processing systems.

By swapping out all the card numbers, they could focus most of their security efforts on one controlled system that's easier to control. Sure, someone might be able to hack the application logic of some server and kick off an illicit payment, but they'd have to crack the hardened master server to get card numbers for any widespread fraud.

We've written about it a little bit in other posts, and I have often recommended it directly to users, but I probably screwed up by not pushing the concept on a wider basis. Tokenization solves far more problems than trying to encrypt in place, and while complex it is still generally easier to implement than alternatives. Well-designed tokens fit the structure of credit card numbers, which may require fewer application changes in distributed systems. The assessment scope for PCI is reduced, since card numbers are only in one location, which can reduce associated costs. From a security standpoint, it allows you to focus more effort on one hardened location. Tokenization also reduces data spillage, since there are far fewer locations which use card numbers, and fewer business units that need them for legitimate functions, such as processing refunds (one of the main reasons to store card numbers in retail environments).

Today alone we were briefed on two different commercial tokenization offerings -- one from RSA and First Data Corp, the other from Voltage. The RSA/FDC product is a partnership where RSA provides the encryption/tokenization tech FDC uses in their processing service, while Voltage offers tokenization as an option to their Format Preserving Encryption technology. (Voltage is also partnering with Heartland Payment Systems on the processing side, but that deal uses their encryption offering rather than tokenization).

There are some extremely interesting things you can do with tokenization. For example, with the RSA/FDC offering, the card number is encrypted on collection at the point of sale terminal with the public key of the tokenization service, then sent to the tokenization server which returns a token that still "resembles" a card number (it passes the LUHN check and might even include the same last 4 digits -- the rest is random). The real card number is stored in a highly secured database up at the processor (FDC). The token is the stored value on the merchant site, and since it's paired with the real number on the processor side, can still be used for refunds and such. This particular implementation always requires the original card for new purchases, but only the token for anything else.

Thus the real card number is never stored in the clear (or even encrypted) on the merchant side. There's really nothing to steal, which eliminates any possibility of a card number breach (according to the Data Breach Triangle). The processor (FDC) is still at risk, so they will need to use a different set of technologies to lock down and encrypt the plain text numbers. The numbers still look like real card numbers, reducing any retrofitting requirements for existing applications and databases, but they're useless for most forms of fraud. This implementation won't work for recurring payments and such, which they'll handle differently.

Over the past year or so I've become a firm believer that tokenization is the future of transaction processing -- at least until the card companies get their stuff together and design a stronger system. Encryption is only a stop-gap in most organizations, and once you hit the point where you have to start making application changes anyway, go with tokenization.

Even payment processors should be able to expand use of tokenization, relying on encryption to cover the (few) tokenization databases which still need the PAN.

Messing with your transaction systems, especially legacy databases and applications, is never easy. But once you have to crack them open, it's hard to find a downside to tokenization.

–Rich

New Details, and Lessons, on Heartland Breach

By Rich

Thanks to an anonymous reader, we may have some additional information on how the Heartland breach occurred. Keep in mind that this isn't fully validated information, but it does correlate with other information we've received, including public statements by Heartland officials.

On Monday we correlated the Heatland breach with a joint FBI/USSS bulletin that contained some in-depth details on the probable attack methodology. In public statements (and private rumors) it's come out that Heartland was likely breached via a regular corporate system, and that hole was then leveraged to cross over to the better-protected transaction network.

According to our source, this is exactly what happened. SQL injection was used to compromise a system outside the transaction processing network segment. They used that toehold to start compromising vulnerable systems, including workstations. One of these internal workstations was connected by VPN to the transaction processing datacenter, which allowed them access to the sensitive information. These details were provided in a private meeting held by Heartland in Florida to discuss the breach with other members of the payment industry.

As with the SQL injection itself, we've seen these kinds of VPN problems before. The first NAC products I ever saw were for remote access -- to help reduce the number of worms/viruses coming in from remote systems.

I'm not going to claim there's an easy fix (okay, there is, patch your friggin' systems), but here are the lessons we can learn from this breach:

1. The PCI assessment likely focused on the transaction systems, network, and datacenter. With so many potential remote access paths, we can't rely on external hardening alone to prevent breaches. For the record, I also consider this one of the top SCADA problems.
2. Patch and vulnerability management is key -- for the bad guys to exploit the VPN connected system, something had to be vulnerable (note -- the exception being social engineering a system 'owner' into installing the malware manually).
3. We can't slack on vulnerability management -- time after time this turns out to be the way the bad guys take control once they've busted through the front door with SQL injection. You need an ongoing, continuous patch and vulnerability management program. This is in every freaking security checklist out there, and is more important than firewalls, application security, or pretty much anything else.
4. The bad guys will take the time to map out your network. Once they start owning systems, unless your transaction processing is absolutely isolated, odds are they'll find a way to cross network lines.
5. Don't assume non-sensitive systems aren't targets. Especially if they are externally accessible.

Okay -- when you get down to it, all five of those points are practically the same thing.

Here's what I'd recommend:

1. Vulnerability scan everything. I mean everything, your entire public and private IP space.
2. Focus on security patch management -- seriously, do we need any more evidence that this is the single most important IT security function?
3. Minimize sensitive data use and use heavy egress filtering on the transaction network, including some form of DLP. Egress filter any remote access, since that basically blows holes through any perimeter you might think you have.
4. Someone will SQL inject any public facing system, and some of the internal ones. You'd better be testing and securing any low-value, public facing system since the bad guys will use that to get inside and go after the high value ones. Vulnerability assessments are more than merely checking patch levels.

–Rich

An Open Letter to Robert Carr, CEO of Heartland Payment Systems

By Rich

Mr. Carr,

I read your interview with Bill Brenner in CSO magazine today, and I sympathize with your situation. I completely agree that the current system of standards and audits contained in the Payment Card Industry Data Security Standard is flawed and unreliable as a breach-prevention mechanism. The truth is that our current transaction systems were never designed for our current threat environment, and I applaud your push to advance the processing system and transaction security. PCI is merely an attempt to extend the life of the current system, and while it is improving the state of security within the industry, no best practices standard can ever fully repair such a profoundly defective transaction mechanism as credit card numbers and magnetic stripe data.

That said, your attempts to place the blame of your security breach on your QSAs, your external auditors, are disingenuous at best.

As the CEO of a large public company you clearly understand the role of audits, assessments, and auditors. You are also fundamentally familiar with the concepts of enterprise risk management and your fiduciary responsibility as an officer of your company. Your attempts to shift responsibility to your QSA are the accounting equivalent of blaming your external auditor for failing to prevent the hijacking of an armored car.

As a public company, I have to assume your organization uses two third-party financial auditors, and internal audit and security teams. The role of your external auditor is to ensure your compliance with financial regulations and the accuracy of your public reports. This is the equivalent of a QSA, whose job isn't to evaluate all your security defenses and controls, but to confirm that you comply with the requirements of PCI. Like your external financial auditor, this is managed through self reporting, spot checks, and a review of key areas. Just as your financial auditor doesn't examine every financial transaction or the accuracy of each and every financial system, your PCI assessor is not responsible for evaluating every single specific security control.

You likely also use a public accounting firm to assist you in the preparation of your books and evaluation of your internal accounting practices. Where your external auditor of record's responsibility is to confirm you comply with reporting and accounting requirements and regulations, this additional audit team is to help you prepare, as well as provide other accounting advice that your auditor of record is restricted from. You then use your internal teams to manage day to day risks and financial accountability.

PCI is no different, although QSAs lack the same conflict of interest restrictions on the services they can provide, which is a major flaw of PCI. The role of your QSA is to assure your compliance with the standard, not secure your organization from attack. Their role isn't even to assess your security defenses overall, but to make sure you meet the minimum standards of PCI. As an experienced corporate executive, I know you are familiar with these differences and the role of assessors and auditors.

In your interview, you state:

The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem. The QSAs in our shop didn't even know this was a common attack vector being used against other companies. We learned that 300 other companies had been attacked by the same malware. I thought, 'You've got to be kidding me.' That people would know the exact attack vector and not tell major players in the industry is unthinkable to me. I still can't reconcile that."

There are a few problems with this statement. PCI compliance means you are compliant at a point in time, not secure for an indefinite future. Any experienced security professional understands this difference, and it was the job of your security team to communicate this to you, and for you to understand the difference. I can audit a bank one day, and someone can accidently leave the vault unlocked the next. Also, standards like PCI merely represent a baseline of controls, and as the senior risk manager for Heartland it is your responsibility to understand when these baselines are not sufficient for your specific situation.

It is unfortunate that your assessors were not up to date on the latest electronic attacks, which have been fairly well covered in the press. It is even more unfortunate that your internal security team was also unaware of these potential issues, or failed to communicate them to you (or you chose to ignore their advice). But that does not abrogate your responsibility, since it is not the job of a compliance assessor to keep you informed on the latest attack techniques and defenses, but merely to ensure your point in time compliance with the standard.

In fairness to QSAs, their job is very difficult, but up until this point, we certainly didn't understand the limitations of PCI and the entire assessment process. PCI compliance doesn't mean secure. We and others were declared PCI compliant shortly before the intrusions.

I agree completely that this is a problem with PCI. But what concerns me more is that the CEO of a public company would rely completely on an annual external assessment to define the whole security posture of his organization. Especially since there has long been ample public evidence that compliance is not the equivalent of security. Again, if your security team failed to make you aware of this distinction, I'm sorry.

I don't mean this to be completely critical. I applaud your efforts to increase awareness of the problems of PCI, to fight the PCI Council and the card companies when they make false public claims regarding PCI, and to advance the state of transaction security. It's extremely important that we, as an industry, communicate more and share information to improve our security, especially breach details. Your efforts to build an end to end encryption mechanism, and your use of Data Loss Prevention and other technologies, are an important contribution to the industry.

Unless your QSAs were also responsible for your operational security, the only ones responsible for your breach are the criminals, and Heartland itself. I cannot possibly believe that you trusted your PCI audit to determine if you were secure from attack; considering all we know, and all the information available on PCI, that would be borderline negligence. Even if your QSAs were completely negligent and falsified your compliance, that would not make them responsible for your breach.

Rather than blaming your QSAs, I hope you take this opportunity to encourage other executives to treat their PCI assessment as merely another compliance initiative -- one that does not, in any way, ensure their security. As an industry professional I see all too many organizations do the minimum for PCI compliance, and ignore the other security risks their organizations face, even when properly informed by their internal security professionals. This is the single greatest problem with PCI, and one you have an opportunity to help change.

If I misread your statements or the article was inaccurate, I apologize for my criticism. If any of my prior criticisms of your organization were unfounded, I take full responsibility and also apologize for those.

But, based on your prior public statements and this interview, you appear to be shifting the blame to the card companies, your QSA, and the PCI Council. From what's been released, your organization was breached using known attack techniques that were preventable using well-understood security controls.

As the senior corporate officer for Heartland, that responsibility was yours.

Rich Mogull,

Securosis

–Rich

The State of Web Application and Data Security—Mid 2009

By Rich

One of the more difficult aspects of the analyst gig is sorting through all the information you get, and isolating out any inherent biases. The kinds of inquiries we get from clients can all too easily skew our perceptions of the industry, since people tend to come to us for specific reasons, and those reasons don't necessarily represent the mean of the industry. Aside from all the vendor updates (and customer references), our end user conversations usually involve helping someone with a specific problem -- ranging from vendor selection, to basic technology education, to strategy development/problem solving. People call us when they need help, not when things are running well, so it's all too easy to assume a particular technology is being used more widely than it really is, or a problem is bigger or smaller than it really is, because everyone calling us is asking about it. Countering this takes a lot of outreach to find out what people are really doing even when they aren't calling us.

Over the past few weeks I've had a series of opportunities to work with end users outside the context of normal inbound inquiries, and it's been fairly enlightening. These included direct client calls, executive roundtables such as one I participated in recently with IANS (with a mix from Fortune 50 to mid-size enterprises), and some outreach on our part. They reinforced some of what we've been thinking, while breaking other assumptions. I thought it would be good to compile these together into a "state of the industry" summary. Since I spend most of my time focused on web application and data security, I'll only cover those areas:

When it comes to web application and data security, if there isn't a compliance requirement, there isn't budget -- Nearly all of the security professionals we've spoken with recognize the importance of web application and data security, but they consistently tell us that unless there is a compliance requirement it's very difficult for them to get budget. That's not to say it's impossible, but non-compliance projects (however important) are way down the priority list in most organizations. In a room of a dozen high-level security managers of (mostly) large enterprises, they all reinforced that compliance drove nearly all of their new projects, and there was little support for non-compliance-related web application or data security initiatives. I doubt this surprises any of you.

"Compliance" may mean more than compliance -- Activities that are positioned as helping with compliance, even if they aren't a direct requirement, are more likely to gain funding. This is especially true for projects that could reduce compliance costs. They will have a longer approval cycle, often 9 months or so, compared to the 3-6 months for directly-required compliance activities. Initiatives directly tied to limiting potential data breach notifications are the most cited driver. Two technology examples are full disk encryption and portable device control.

PCI is the single biggest compliance driver for web application and data security -- I may not be thrilled with PCI, but it's driving more web application and data security improvements than anything else.

The term Data Loss Prevention has lost meaning -- I discussed this in a post last week. Even those who have gone through a DLP tool selection process often use the term to encompass more than the narrow definition we prefer.

It's easier to get resources to do some things manually than to buy a tool -- Although tools would be much more efficient and effective for some projects, in terms of costs and results, manual projects using existing resources are easier to get approval for. As one manager put it, "I already have the bodies, and I won't get any more money for new tools." The most common example cited was content discovery (we'll talk more about this a few points down).

Most people use DLP for network (primarily email) monitoring, not content discovery or endpoint protection -- Even though we tend to think discovery offers equal or greater value, most organizations with DLP use it for network monitoring.

Interest in content discovery, especially DLP-based, is high, but resources are hard to get for discovery projects -- Most security managers I talk with are very interested in content discovery, but they are less educated on the options and don't have the resources. They tell me that finding the data is the easy part -- getting resources to do anything about it is the limiting factor.

The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client -- While it's hard to fully quantify, we think the source code tools cost more per implementation, but WAFs are in slightly wider use.

WAFs are a quicker hit for PCI compliance -- Most organizations deploying WAFs do so for PCI compliance, and they're seen as a quicker fix than secure source code projects.

Most WAF deployments are out of band, and false positives are a major problem for default deployments -- Customers are installing WAFs for compliance, but are generally unable to deploy them inline (initially) due to the tuning requirements.

Full drive encryption is mature, and well deployed in the early mainstream -- Full drive encryption, while not perfect, is deployable in even large enterprises. It's now considered a level-setting best practice in financial services, and usage is growing in healthcare and insurance. Other asset recovery options, such as remote data destruction and phone home applications, are now seen as little more than snake oil. As one CISO told us, "I don't care about the laptop, we just encrypt it and don't worry about it when it goes missing".

File and folder encryption is not in wide use -- Very few organizations are performing any wide scale file/folder encryption, outside of some targeted encryption of PII for compliance requirements.

Database encryption is hard, and not widely used -- Most organizations are dissatisfied with database encryption options, and do not deploy it widely. Within a large organization there is likely some DB encryption, with preference given to file/folder/media protection over column level encryption, but most organizations prefer to avoid it. Performance and key management are cited as the primary obstacles, even when using native tools. Current versions of database encryption (primarily native encryption) do perform better than older versions, but key management is still unsatisfactory. Large encryption projects, when initiated, take an average of 12-18 months.

Large enterprises prefer application-level encryption of credit card numbers, and tokenization -- When it comes to credit card numbers, security managers prefer to encrypt it at the application level, or consolidate numbers into a central source, using representative "tokens" throughout the rest of the application stack. These projects take a minimum of 12-18 months, similar to database encryption projects (the two are often tied together, with encryption used in the source database).

Email encryption and DRM tend to be workgroup-specific deployments -- Email encryption and DRM use is scattered throughout the industry, but is still generally limited to workgroup-level projects due to the complexity of management, or lack of demand/compliance from users.

Database Activity Monitoring usage continues to grow slowly, mostly for compliance, but not quickly enough to save lagging vendors -- Many DAM deployments are still tied to SOX auditing, and it's not as widely used for other data security initiatives. Performance is reasonable when you can use endpoint agents, which some DBAs still resist. Network monitoring is not seen as effective, but may still be used when local monitoring isn't an option. Network requirements, depending on the tool, may also inhibit deployments.

My main takeaway is that security managers know what they need to do to protect information assets, but they lack the time, resources, and management support for many initiatives. There is also broad dissatisfaction with security tools and vendors in general, in large part due to poor expectation setting during the sales process, and deliberately confusing marketing. It's not that the tools don't work, but that they're never quite as easy as promised.

It's an interesting dilemma, since there is clear and broad recognition that data security (and by extension, web application security) is likely our most pressing overall issue in terms of security, but due to a variety of factors (many of which we covered in our Business Justification for Data Security paper), the resources just aren't there to really tackle it head-on.

–Rich

Our Financial System is Under a Coordinated, Sophisticated Attack

By Rich

This is a great day for security researchers, and a bad day for anyone with a bank account.

First up is the release of the 2009 Verizon Data Breach Investigations Report. This is now officially my favorite breach metrics source, and it's chock full of incredibly valuable information. I love the report because it's not based on bullshit surveys, but on real incident investigations. The results are slowly spreading throughout the blogosphere, and we won't copy them all here, but a few highlights:

1. Verizon's team alone investigated cases that resulted in the loss of 285 million records. That's just them, never mind all the other incident response teams.
2. Most organizations do a crap job with security- this is backed up with a series of metrics on which security controls are in place and how incidents are discovered.
3. Essentially no organizations really complied with all the PCI requirements- but most get certified anyway.

Liquidmatrix has a solid summary of highlights, and I don't want to repeat their work. As they say,

Read pages 46-49 of the report and do what it says. Seriously. It’s the advice that I would give if you were paying me to be your CISO.

And we'll add some of our own advice soon.

Next is an article on organized cybercrime by Brian Krebs THAT YOU MUST GO READ NOW. (I realize it might seem like we have a love affair with Brian or something, but he's not nearly my type). Brian digs beyond the report, and his investigative journalism shows what many of us believe to be true- there is a concerted attack on our financial system that is sophisticated and organized, and based out of Eastern Europe.

I talked with Brain and he told me,

You know all those breaches last year? Most of them are a handful of groups.

Here are a couple great tidbits from the article:

For example, a single organized criminal group based in Eastern Europe is believed to have hacked Web sites and databases belonging to hundreds of banks, payment processors, prepaid card vendors and retailers over the last year. Most of the activity from this group occurred in the first five months of 2008. But some of that activity persisted throughout the year at specific targets, according to experts who helped law enforcement officials respond to the attacks, but asked not to be identified because they are not authorized to speak on the record.

...

One hacking group, which security experts say is based in Russia, attacked and infiltrated more than 300 companies -- mainly financial institutions -- in the United States and elsewhere, using a sophisticated Web-based exploitation service that the hackers accessed remotely. In an 18-page alert published to retail and banking partners in November, VISA described this hacker service in intricate detail, listing the names of the Web sites and malicious software used in the attack, as well as the Internet addresses of dozens of sites that were used to offload stolen data.

...

Steve Santorelli, director of investigations at Team Cymru, a small group of researchers who work to discover who is behind Internet crime, said the hackers behind the Heartland breach and the other break-ins mentioned in this story appear to have been aware of one another and unofficially divided up targets. "There seem, on the face of anecdotal observations, to be at least two main groups behind many of the major database compromises of recent years," Santorelli said. "Both groups appear to be giving each other a wide berth to not step on each others' toes."

Keep in mind that this isn't the same old news. We're not talking about the usual increase in attacks, but a sophistication and organizational level that developed materially in 2007-2008.

To top it all off, we have this article over at Wired on PIN cracking. This one also ties in to the Verizon report. Another quote:

"We're seeing entirely new attacks that a year ago were thought to be only academically possible," says Sartin. Verizon Business released a report Wednesday that examines trends in security breaches. "What we see now is people going right to the source ... and stealing the encrypted PIN blocks and using complex ways to un-encrypt the PIN blocks."

If you read more deeply, you learn that the bad guys haven't developed some quantum crypto, but are taking advantage of weak points in the system where the data is unencrypted, even if only in memory.

Really fascinating stuff, and I love that we're getting real information on real breaches.

–Rich

Security Inevitabilities

By Rich

Despite my intensive research into cryonics, I have to accept that someday I will die. Permanently. I don't know when, where, or how, but someday I will cease to exist. Heck, even if I do manage to freeze myself (did you know one of the biggest cryonincs companies is only 20 minutes from my house?), get resurrected into a cloned 20-year-old version of myself, and eventually upload my consciousness into a supercomputer (so I can play Skynet, since I don't really like most people) I have to accept that someday Mother Entropy will bitch slap me with the end of the universe.

There are many inevitabilities in life, and it's often far easier to recognize these end results than the exact path that leads us to them. Denial is often closely tied to the obscurity of these journeys; when you can't see how to get from point A to point B (or from Alice to Bob, for you security geeks), it's all too easy to pretend that Bob Can't Ever Happen. Thus we find ourselves debating the minutiae, since the result is too far off to comprehend.

(Note that I'd like credit for not going deep into an analogy about Bob and Alice inevitably making Charlie after a few too many mojitos).

Security includes no shortage of inevitabilities. Below are just a few that have been circling my brain lately, in no particular order. It's not a comprehensive list, just a few things that come to mind (and please add your own in the comments). I may not know when they'll happen, or how, but they will happen:

• Everyone will use some form of NAC on their networks.
• Despite PCI, we will move off credit card numbers to a more secure transaction system. It may not be chip and PIN, but it definitely won't be magnetic strips.
• Everyone will use some form of DLP, we'll call it CMP, and it will only include tools with real content analysis.
• Log management and SIEM will converge into single products. Completely.
• UTM will rule the day on the perimeter, and we won't buy separate boxes for every function anymore.
• Virtualization and information-centric security will totally fuck up network security, especially internally.
• Any critical SCADA network will be pulled off the Internet.
• Database encryption will be performed inside the database with native functionality, with keys managed externally.
• The WAF vs. secure development debate will end as everyone buys/implements both.
• We'll stop pretending web application and database security are different problems.
• We will encrypt all laptops. It will be built into the hardware.
• Signature AV will die. Mostly.
• Chris Hoff will break the cloud.

–Rich

Friday Summary: April 10, 2009

By Rich

–Rich

A Very Revealing Statement by the PCI Council

By Rich

I was getting a little excited when I read this article over at NetworkWorld about how the PCI council will be releasing a prioritized roadmap for companies facing compliance. It's a great idea- instead of flogging companies with a massive list of security controls, it will prioritize those controls and list specific milestones.

Now before I get to the fun part, I want to quote myself from one of my posts on PCI:

Going back to CardSystems, a large majority of major breaches involve companies that were PCI compliant, including (probably) Hannaford. TJX is an open question. In many cases, the companies involved were certified but found to be non-compliant after the breach, which indicates a severe breakdown in the certification process.

Now on to the fun (emphasis added by moi):

Businesses that are compliant with PCI standards have never been breached, says Bob Russo, general manager of the PCI Security Standards Council, or at least he's never seen such a case. Victims may have attained compliance certification at some point, he says, but none has been in compliance at the time of a breach, he says.

What a load of shit. With the volume of breaches we've seen, this either means the standard and certification process are fundamentally broken, or companies have had their certifications retroactively revoked for political reasons after the fact. As I keep saying, PCI is really about protecting the card companies first, with as little cost to them as possible, and everyone else comes a distant second. It could be better, and the PCI Council has the power to make it so, but only if the process is fixed with more accountability of assessors, a revised assessment/audit process (not annual), a change to real end-to-end encryption, and a real R&D effort to fix the fundamental flaws in the system, instead of layering on patches that can never completely work.

You could also nominate me for the PCI Council Board of Advisors. I'm sure that would be all sorts of fun.

Seriously -- we can fix this thing, but only by fixing the core of the program, not by layering on more controls and requirements.

–Rich

Will This Be The Next PCI Requirement Addition?

By Rich

I'm almost willing to bet money on this one...

Due to the nature of the recent breaches, such as Hannaford, where data was exfiltrated over the network, I highly suspect we will see outbound monitoring and/or filtering in the next revision of the PCI DSS. For more details on what I mean, refer back to this post.

Consider this your first warning.

–Rich

Recent Data Breaches- How To Limit Malicious Outbound Connections

By Rich

Word is slowly coming through industry channels that the attackers in the Heartland breach exfiltrated sniffed data via an outbound network connection. While not surprising, I did hear that the connection wasn't encrypted- the bad guys sent the data out in cleartext (I'll leave it to the person who passed this on to identify themselves if they want). Rumor from 2 independent sources is the bad guys are an organized group out of St. Petersburg (yes, Russia, as cliche as that is).

This is similar to a whole host of breaches- including (probably) TJX. While I'm not so naive as to think you can stop all malicious outbound connections, I do think there's a lot we can do to make life harder on the bad guys.

First, you need to lock down your outbound connections using a combination of current and next-generation firewalls. You should isolate out your transaction network to enforce tighter controls on it than on the rest of your business network. Traditional firewalls can lock down most outbound port/protocols, but struggle with nested/stealth channels or all the stuff shoveled over port 80. Next-gen firewalls and web gateways (I hate the name, but don't have a better one) like Palo Alto Networks or Mi5 Networks can help. Regular web gateways (Websense and McAfee/Secure Computing) are also good, but vary more on their outbound control capabilities and tend to be more focused on malware prevention (not counting their DLP products, which we'll talk about in a second).

The web gateway and next gen firewalls will focus on your overall network, while you can lock of the transaction side with tighter traditional firewall rules and segmenting that thing off.

Next, use DLP to sniff for outbound cardholder data. The bad guys don't seem to be encrypting, and DLP will alert on that in a heartbeat (and maybe block it, depending on the channel). You'll want to proxy with your web gateway to sniff SSL (and only some web gateways can do this) and set the DLP to alert on unauthorized encryption usage. That might be a real pain in the ass, if you have a lot of unmanaged encryption outside of SSL. Also, to do the outbound SSL proxy you need to roll out a gateway certificate to all your endpoints and suppress browser alerts via group policies.

I also recommend DLP content discovery to reduce where you have unencrypted stored data (yes, you do have it, even if you think you don't).

As you've probably figured out by now, if you are starting from scratch some of this will be very difficult to implement on an existing network, especially one that hasn't been managed tightly. Thus I suggest you focus on any of your processing/transaction paths and start walling those off first. In the long run, that will reduce both your risks and your compliance and audit costs.

–Rich

The Most Powerful Evidence That PCI Isn’t Meant To Protect Cardholders, Merchants, Or Banks

By Rich

I just read a great article on the Heartland breach, which I'll talk more about later. There is one quote in there that really stands out:

End-to-end encryption is far from a new approach. But the flaw in today"s payment networks is that the card brands insist on dealing with card data in an unencrypted state, forcing transmission to be done over secure connections rather than the lower-cost Internet. This approach avoids forcing the card brands to have to decrypt the data when it arrives.

While I no longer think PCI is useless, I still stand by the assertion that its goal is to reduce the risks of the card companies first, and only peripherally reduce the real risk of fraud. Thus cardholders, merchants, and banks carry both the bulk of the costs and the risks. And here's more evidence of its fundamental flaws.

Let's fix the system instead of just gluing on more layers that are more costly in the end. Heck, let's bring back SET!

–Rich

How To Tell If Your PCI Scanning Vendor Is Dangerous

By Rich

I got an interesting email right before I ran off on vacation from Mark on a PCI issue he blogged about:

13. Arrangements must be made to configure the intrusion detection system/intrusion prevention system (IDS/IPS) to accept the originating IP address of the ASV. If this is not possible, the scan should be originated in a location that prevents IDS/IPS interference. snip... I understand what the intention of this requirement is. If your IPS is blacklisting the scanner IP's then ASVs don't get a full assessment because they are a loud and proud scan rather than a targeted attack... However, blindly accepting the originating IP of the scanner leaves the hosts vulnerable to various attacks. Attackers can simply reference various public websites to see what IP addresses they need to use to bypass those detective or preventive controls.

I figured no assessor would ask their client to open up big holes just to do a scan, but lo and behold, after a little bit of research it turns out this is surprisingly common. Back to email:

It came up when I was told by my ASV "Authorized scanning vendor" that I had to do exclude their IPs. They also provided me with the list of IP's to exclude. Both [redacted] and [redacted] have told me I needed to do bypass the IDS. When I asked about the exposure they were creating, both told me that their "other customers" do this and it isn't a problem for them.

If your ASV can't perform a scan/test without having you turn off your IDS/IPS, it might be time to look for a new one. Especially if their source IPs are easy to figure out.

For the record, "everyone else does it" is the dumbest freaking reason in the book. Remember the whole jumping off a bridge thing your mom taught you?

–Rich

The Good (Yes, Good) And Bad Of PCI

By Rich

I'm still out at SANS, in a session dedicated to PCI and web application security.

Now, as you readers know, I'm not the biggest fan of PCI. The truth is (this is the "bad" part) it's mostly a tool to minimize the risk of the credit card companies by transferring as much risk and cost as possible to the merchants and processors.

On the other hand (the "good" side), it's clear that PCI is slowly driving organizations which would otherwise ignore security to take it more seriously. I've met with a bunch of security admins out here who tell me they are finally getting resources from the business that they didn't have before. Sure, many of them also complain those resources are only to give them the bare minimum needed for compliance, but in these cases that's still significant.

When it comes to web application security, it's also a mixed bag. On the "good" side, including web application defense in section 6.6 is driving significant awareness that web applications are a major vector for successful attacks. On the "bad" side, 6.6 places code review and WAFs as competing, not complementary, technologies. These tools solve very different problems, something I hope PCI eventually recognizes. I don't totally blame them on this one, since requiring both in every organization within the compliance deadlines isn't reasonable, but I'd like to see PCI publicly recognize that the "either/or" decision is one of limited resources, not that the technologies themselves are equivalent.

One take-away from the event, based on conversations with end users and other experts, is that WAFs are your best quick fix, while secure coding is the way to go for long-term risk reduction.

–Rich