Security and Risk Management Strategies Blog

“Caution – the delicious beverage you are about the consume is extremely hot!” – Where PCI may take us

Blogger: Diana Kelley

The TJX “computer intrusion”, first reported in December of 2006, set off serious alarm bells and repercussions for entities that store and process credit cardholder information. Card protection standards are not new, but it was the TJX intrusion that ratcheted up the compliance heat significantly.

As is often the case, when an industry is deemed to be unable to regulate itself, lawyers and lawmakers stepped in. Lawyers lost no time in filing suits against TJX (details on most of these can be found in the TJX March 28, 2007 10K filing and lawmakers weren’t far behind. Minnesota passed the Plastic Card Security Act in June of 2006. And other states, including Massachusetts and California have similar bills under review.

The lawsuits, and the current and proposed state laws, are significant because, for the first time, payment for damages would be paid by the entities deemed responsible for the data loss. Specifically, the cost to card issuing entities, such as banks, would be remunerated for costs incurred in the course of notifying affected consumers and issuing them new credit cards. Cost per consumer/card vary, but is commonly reported as being between US $12 and $15. Note that the consumer damages for lost credit card information is a different issue. Although no consumer wants to hear that their credit card number is being used fraudulently, the actual dollar amount of damages is low. Consumer liability for fraudulent use of a credit card is capped at $50 dollars, but it is rare that an issuing bank makes the customer pay even this amount.

Now, here’s the fun part – being PCI compliant doesn’t let the entity that lost the credit card data off the hook. Compliant entities that lost data are still responsible for having lost that data. If the lawyers arguing for the prosecution can convince a judge or jury that retailer A really is liable for the damages the cost could be financially devastating. If, for example, TJX had to pay for card replacement costs for even one quarter of the card numbers lost settlement would be around US $135million (45000000/4*12). How many retailers, even large ones, could absorb that kind of loss?

But let’s flip the case around -  in the TJX instance there was relatively a clear path from the TJX databases to the fraudsters. But it won’t always be so easy to close the loop. Just because PANs 1-100 were stolen from retailer A – it doesn’t prove that the fraudsters using PANs 1-100 got them from retailer A. If a single source of resale of PANs 1-100 can be found – it would be easier to draw the line between the two. But what if credit card sellers get smart – add more layers between those who steal the PANs and those who sell them and also mix batches of available PANs from different thefts? This would benefit the thieves by making it harder to pin a specific theft on a group of people – but it also could benefit the retailers who may claim that there’s not enough hard evidence that the breach of PAN data from their database is the reason those PANs were for sale on the open market. And a smart defense lawyer will know this and argue this point.

So what’s the solution? Is there one? Being PCI compliant can decrease the risk of losing card data, but doesn’t eliminate it. And it doesn’t provide protection against lawsuits or legal violations. And all the risk protections in the world, can’t guarantee data will never go missing.  Yet retailers and banks are going to look for ways to protect themselves. Which is why I’ve been thinking we might start seeing this on the doors to stores that accept credit cards: “Consumers be advised use of credit cards could lead to loss of credit data – use at your own risk.” And have to sign an agreement with our issuing banks that states: “Credit card use may lead to loss of credit data, if your card information is lost you will be charged a $15 replacement fee per card.” Heck, the fraud monitoring services could even tack on an extra $20 per year for “free” card replacement.

Granted, playing up the security of credit cards is something the industry has done for a long time, but consumers are hooked now. And addictive substances that come with warning labels don’t stop use. The beverage you are about to consume is extremely hot and the credit card number you’re about to use may be lost. Proceed at your own risk.

"Security Failures": Is the sky REALLY falling?

Blogger: Pete Lindstrom

It is fairly common in the security community to lament that security is failing. In fact, it is so common as to essentially be conventional wisdom. I was on a panel in early August when a question arose that suggested this failure as some sort of fact. When I suggested that it wasn’t clear to me that security actually was failing, it made for one of the more humorous moments of the workshop… at least for the audience who laughed in unison at my apparently ridiculous statement.

The notion that security is failing is an interesting one simply because it is a matter of opinion. There are a handful of ways to measure and then evaluate this hypothesis that are more exact and provide insight into the nature of risk management and differences in operational objectives for security. Here are some of these, taken from the position of defining success (we security folks are much too pessimistic for our own good ;-)):

"Success is the complete absence of failure" – given that anecdotal evidence of compromises is used to suggest failure, it only takes one or a handful of incidents to support a hypothesis revolving around success as the complete absence of failure. This appears to be the most prevalent condition described by security professionals to support their belief that security is failing.

"Success means that benefits are greater than the costs" – at the opposite extreme from absolute success is a minimum requirement for success that allows for a high degree of failure. In this case, an environment can fail to the extent that the costs associated with failure do not exceed the benefits associated with IT to begin with.

These two extremes create ends on spectrum that may be used to evaluate success. On the total success side, security professionals provide a critical view of information systems risk that is unattainable (consider an analog in the physical world where the police force in New York City decided to eradicate murders and that a single murder was unacceptable). The real challenge here is that this type of attitude fosters a level of extreme risk aversion and may create the perception of security professional as Chicken Little. While the sky may be falling to us, it is not necessarily so to the rest of the world.

At this other end of the spectrum is where I believe most IT professionals and savvy businesspeople are. That is, they are willing to tolerate some level of "failure" – that is, a number of incidents whose costs are considered reasonable within the scope of the benefits provided by IT. There are many real world analogs once again – for example, shrinkage in the retail world measures the level of theft of inventory, and credit card fraud may be rampant to some, but the credit card industry is very content to make a lot of money even in the face of this fraud. Of course, it is even easier to sustain losses when they are borne by the merchants, but you also don’t see a lot of merchants abandoning credit cards altogether (some do) because the benefits outweigh the risks.

It seems fairly clear that most organizations (i.e. decisionmakers outside of the security profession) favor this latter extreme. The evidence is simple – the growth of IT budgets overall. It would be irrational to continue spending on IT if it were failing. So, either all decisionmakers are irrational (perhaps plausible ;-)) or security is succeeding at least to a level where it is still useful to use information systems.

The notion that security professionals are at one end of the spectrum and decision-makers are at the other is an important one. It highlights the possibility that for all of our talk about synchronizing with businesses, we really are often quite different. This notion hit home personally and ironically during that workshop panel incident mentioned earlier – while everyone laughed at the notion that perhaps security wasn’t failing, at the same workshop the mantra was always about thinking, acting, and speaking in conformity with the business.

Practically speaking, maintaining status quo should never really be an objective, especially in the face of some level of failure. So what is the option? The third alternative is the service-level agreement:

"Success is meeting a specified service-level agreement (SLA)" – an SLA typically recognizes that absolute goals may not be attainable and so we strive to maximize effectiveness while being practical about the existence of some small tolerable of failure. While this is the most common way to measure other IT operational characteristics, it is an atypical one in security. This is not due to inappropriateness, it is simply because there are no universally-agreed upon measures that could make up an SLA at this time. The most useful candidates are not heavily used at this stage. 

In order to create an SLA, we must come up with objectively measurable items. Presumably, these items should also make sense. The most likely candidate for SLAs with respect to security is a measure around control success. Makes sense, doesn’t it, to have an SLA that cuts to the heart of our protection mechanisms?

There is good news here – the health care community has already created a paradigm for measuring the outcome of tests (in our world, "controls"). That is, every test takes event inputs that are either "good" or "bad" by our definitions (i.e. lead to an unwanted outcome) and our measures of control will either recognize this or not. A good event that is recognized as such is a success, as is a bad event that is recognized as bad. These are true positives and true negatives as determined by the test itself. Control failures are well-defined, too – false positives and false negatives are created from good events identified as bad and vice versa.

We are much better off as a profession considering a more tolerant view of information security. That doesn't mean we shouldn't strive for the best, it simply factors in some level of incident occurrence. While this might seem like we are giving ourselves a break, it really means that we are less likely to promote policies and seek controls that are impractical or worse. But the opposite extreme is no panacea – we certainly should be looking for ways to get better, as it almost always appears obvious what could have been done differently to prevent any specific incident after the fact.

The real challenge for the security profession is to create practical SLAs that are both tolerant in a small way yet challenging nonetheless. There is plenty of room in between the two extremes.

Financial Services Roundtable Plans for Changing the Game

Blogger: Dan Blum

Once upon a time, King Arthur’s Knights of the Round Table gathered to plan the defense of the realm. So it was this summer near Wall Street, where I attended a private roundtable meeting with some leading thinkers from a number of large financial institutions (FIs). Just as England faced innumerable invasions and rebellions, so FIs currently confront a rising tide of attacks in these Dark Ages of cybercrime.

Today’s knights and ladies of information security from leading FIs attending the roundtable have become convinced that our desktop protection and consumer authentication models are broken, and have to change. They favor a paradigm shift towards strong endpoint execution controls and risk based (or contextual) authentication.

Not surprisingly, they have worrisome things to say about the evolution of the threat. One CISO noted that his organization has seen attackers impersonating OTC, IRS, SEC officials in phishing attacks aimed at specific employees; externally he estimates that as many as 25% of consumer workstations are compromised.

Security departments at major FIs generally aren’t lacking for funding or top level support; executive management knows that they and their business model are always under attack. But still, they face serious challenges in confronting the threat. There are issues with deploying defenses and getting internal buy in to follow security policies to the letter. For example: “Data leakage protection products are mostly about detection. They are big, noisy and not very useful. They tell you about the fire after the house has burned down and you don’t have enough people to find the real fires and fight them amidst all the noise.” Meanwhile, attackers are always innovating, forcing FIs to adopt overpriced point solutions that don’t integrate well with their existing control environment. And after they are finally able to integrate, test and deploy point solutions, criminals always seem find a new attack vector.

There was a palpable sense at the roundtable that the cybercrime situation is not under control, and we are not winning the battle. The CISOs and other leaders of information security in attendance feel some urgency about getting the industry to make fundamental changes in endpoint execution control and risk based authentication. I also heard issues on the technical management side that should be addressed. (Historians say the real King Arthur’s success in repelling invasion for a generation came not just from strength and unity of purpose, but also from superior organizational and logistical innovations). The following are some ideas we discussed together at the roundtable about endpoint execution control and risk based authentication, as well as my own thinking on security management frameworks.

The information security industry needs to change the game in three critical areas:

Endpoint execution control: FIs doubt that signature-based anti-malware can keep up, and are not overly hopeful about the behavioral detection algorithms every vendor seems to be touting. One CISO’s company had been hit by targeted attacks which the incumbent anti-malware vendor failed to detect. He favors a whitelisting approach for application control: “You can manage what you can control, you can control what you can describe. But the description has to be provided by the application vendor, and it has to provide enough contextual information for risk management.” At Burton Group, we’ve researched multiple whitelisting schemes for endpoint protection, including host intrusion prevention system (HIPS) vendors, Vista’s User Account Control (UAC) on a restrictive setting, and BeyondTrust Privilege Manager. We expect that significant progress can be made using whitelisting to safeguard enterprise desktops, but cleaning up the consumer workstation mess will be a harder nut to crack.

Risk based authentication should ride to the rescue. One CISO envisions simple authentication evolving into “risk based authorization with NAC [a security assessment of the client] and other contextual data.” We’re far away from that today in the consumer space and authentication tokens alone won’t help: one roundtable participant has already met institutional users who have boxes of tokens for different hedge funds. Could a managed service someday deliver more secure and convenient authentication across multiple FIs? One significant constraint was mentioned at the roundtable: “We are looking for authentication [tools or services] that cost less than a quarter per user.” Many FIs are already using passive risk analytics that don’t directly involve the consumer user and endpoint. Longer term more active risk analytics (such as issuing a real time challenge to the user) should be considered. And at the same time, keep watching the Internet authentication space, where a user-centric identity interop event at Burton Group’s Catalyst conference showed considerable progress.

Security management frameworks: Platform vendors need to stop trying to take over the world by locking customers into proprietary interfaces. Point solution vendors need to build to open platforms if there’s to be any hope of improving the FI’s ability to deploy innovations that confer lasting benefit against attackers. To illustrate the limitations, the roundtable estimated it takes roughly one year to roll out significant new security functionality, but just weeks or months for attackers to make inroads against it or learn how to go around it. Why should every security product have to duplicate console, agent, update mechanisms, workflow, event logging, reporting and more? The first step in getting to better defined security management frameworks is for the vendors and customers to understand security will continue to be a multi-vendor, best of breed endeavor (see our long tail of risk paper for justification of this theory). The most promising near term path to security management frameworks is to fast track common event formats, the Trusted Computing Group’s Statement of Health Protocol and other standards.

In conclusion, it’s clear the industry has hard work ahead. It won’t be easy: As we’ve described in our Malware Predictions 2007 podcast, for example, malware will continue to be a tough enemy. Burton Group will continue exploring these areas and posting its ideas, and we would like your feedback. The roundtable will meet again. I’m confident that, over time, the industry can come up with some game changing approaches.

Picture source: http://users.skynet.be/keltic/edit07.html

WHAT IS OPENID FOR?

Blogger: Bob Blakley

There’s been a bit of a dust-up over OpenID recently in the blogosphere. First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID. Then Stefan Brands amplified the critique in a long blog post. David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems. I have less confidence than David, but I’ll leave that topic for later. What I’d like to do first is talk about getting the horse before the cart.

What I’d really like to see, as a security guy, is a problem statement and a risk analysis. Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:

1. What are the assets to be protected?

What do OpenID’s designers intend it to be used to protect? Blog comment lists? Blog entries? Persistent consumer accounts on commercial servers? Persistent employee accounts on corporate servers?

2. What are the services to be offered?

What services do OpenID’s designers intend it to offer? Authentication of users as the legitimate possessors of OpenID URLs? Linkage of OpenID URLs to user accounts on web-facing systems? Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?

3. What quality of protection is claimed for these services?

Is the OpenID protocol intended to protect against phishing? Is it intended to protect against man-in-the-middle attacks? Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code? Is it intended to protect against session-splicing or session hijacking? Is it intended to protect against active or passive wiretapping?

4. What is the threat model?

What threats is OpenID designed to protect against? Accidental failures at a participating party? Malicious behavior by users? Malicious behavior by relying parties? Malicious behavior by OpenID providers? Wiretappers? Hackers attempting to penetrate a relying party? Hackers attempting to penetrate a provider? Hackers attempting to penetrate a client system? Cryptanalysts?

5. What is the trust model?

Who trusts whom to do what? Does the user trust the OpenID provider to actually check his password? Does the provider trust the relying party not to send maliciously constructed OpenID URL strings? Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times? Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov”?)

All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these. The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.