Those of us who are aware of the interconnectedness of devices in our lives might just consider how vulnerable they are.
What we might not be considering in this interconnected age is how hackable we are. That's right, you and me. We might not consider it because it's always been the case. The hackable you isn't new. Cons have been around for thousands of years. Some people learn to avoid them, some don't. The con artist changes shape to avoid detection, but the best defense remains a bit of (not so) common sense. If it smells bad, don't eat it.
The problem is the intersection of rapidly changing technology and comparatively slow evolution of common sense. I'm involved in technology on a daily basis as part of my profession. Even for me, there's something new to learn every single day. Imagine if I were a construction worker, retired insurance salesman, truck driver or, well, most anyone else. How could I possibly be expected to keep up? All it takes for a criminal to execute a successful con is to successfully span that tiny, but hugely variable, border between tech-reality and tech-nonsense. A half truth here or a plausible new feature there and an attacker can achieve 'soft authentication,' gaining trust and making off with the proverbial money (which, by the way, may not be actual money, but information that leads to actual money).
What do you do? How do you protect yourself? It's best that we all go a little bit crazy. What I mean is that we up our paranoia just a bit past normal (I know, I know, if we all do this, it becomes normal). Don't accept the apparent reality so readily. Instead, do a little verification. Act on the yellow flags as much as the red flags. Only allow trust to be earned when you are absolutely sure who is earning it.
Last week I attended the Secure360 conference in St. Paul, MN. It's one of my favorites because of it's local focus, lack of hyperbolic hype, and high concentration of nCircle customers. While I couldn't attend as many of the sessions as I wanted to, I came away with at least one conclusion worth sharing, thanks to @securityincite.
As an industry, we talk a lot about technology, especially shiny new technology. I find that there's a polarization around information security and the cloud: the cloud changes everything vs. the cloud changes nothing.
On the one hand we have a set of, um, cloud evangelists touting how different the cloud is. They're out to shatter paradigms and demonstrate that everything you do will be done differently (and better) in the cloud. On the other hand, we have the perpetual cynics who point out that all the stuff that's really hard in your data centers is just as hard, if not harder, in the cloud. And they're both right.
As is so often the case in any polarized dialogue, the somewhat-less-exciting reality is somewhere in the middle. There is some commonality between these two sides, however, and it's in what neither seems to be talking about: the cloud is missing assurance.
As security practitioners and industry participants, the idea that technology and operations need assurance processes should be second nature. It's our jobs to ask the inevitable and perpetual question, "how do you know?" We struggle today with answering this question in our on premise environments, and the mix of infrastructure ownership in the cloud only complicates the situation. That certainly doesn't mean we should stop asking; only that we should ask a little more often and a little louder.
That's a lofty title for a short post about an article someone else wrote, but it is what I want to discuss. George V. Hulme put together a pretty decent article called "Embedded system security much more dangerous, costly than traditional software vulnerabilities." The title is somewhat misleading, however, because what he actually means by 'embedded systems' is control systems or SCADA. The situation, for those of you who haven't been following, is that the control systems used to manage our critical energy infrastructure are horribly vulnerable to attack. The vendors don't patch them, however, so despite the well known problems and the credible threat, the institutions that literally keep the lights on remain at risk.
Once you get through the interesting bits about why the SCADA vendors are in the position they are today, there's a general conclusion about why the situation persists: money. It's too expensive to patch these systems, so they don't get patched. "End users can't patch embedded systems," says Kube. "It's not that they technically can't, it's that it's incredibly expensive and they just don't do it."
I won't argue that point, but I think there's a important, yet subtle additional point to be made about why the situation persists. It's still cost, but not the cost to patch.
The fact is that there are lots of embedded systems that can be much more easily patched than the SCADA systems. Most enterprises run a ton of them from vendors like Cisco, Juniper, Foundry, even nCircle. And many many homes run WAPs and game consoles that have the same properties. So this isn't a problem with patching embedded systems in general. Why is it that these emedded systems are so very patchable and the SCADA systems are not?
Cost of replacement.
If my Xbox has a defect or my switch has a vulnerability and the vendor won't patch it, I replace them. Sure, there's cost, but it's relatively small. This relative ease of replacement ensures that vendors have to service the market in an ongoing capacity. The SCADA systems are so expensive to replace that the vendors can remain fairly confident their customers simply won't.
The solution is for a well-funded competitor to enter the market with a solid replacement strategy and a value proposition around ongoing support that crushes the existing vendors. That's not an easy proposition (note: well-funded), but it could be a very profitable one.
Every so often a phrase just gets stuck in my head and makes me chuckle for a couple of days. This article about the validity of cybercrime statistics produced the phrase "absurdly bad statistical methods," which produced an image like this in my head:
Of course, you'll never find the standard deviation if you divide by pancake.
Every day in the realm of Information Security, we face data on risk, on vulnerability, on criminal activity. There are boatloads of facts, not FUD, out there to drive prioritization and decision making. Yet we continue to fail, over and over again. The adversaries win, over and over again. Money is stolen, systems are damaged, havoc is wreaked. If you're not sure about the reality of the situation, look at these:
Threat, Adversaries and Optimism
Ok, so the problem is real. There's real threat out there to deal with. It's so very easy to focus on the threat, and we do. And this focus on threat feeds our self delusion. There are such succulent statistics, such delicious dramas, and we can make demonstrable progress through analysis. This kind of progress fuels our sense of optimism. We feel better because we have a chart, a graph, a count, a trend!
But progress through analysis only counts when analysis is the goal. Unless your title contains the term 'analyst,' you're missing something. In fact, the proliferation of 'analyst' titles in information security could be construed as evidence of this very problem: too much analysis, too little action.
Compliance as Artificial Threat
When adversaries continue to win and losses continue to occur, it's common for compliance to enter as the solution. Your goal is to stop data/financial loss, but that hasn't happened, so clearly you're not doing the right things, so we'll impose the right things onto the organization via a law or regulation. Compliance is how those with authority-not-authortization assert power. In order to make sure you pay attention, they include sufficient motivation through penalties. In other words, if you don't take the right actions, something painful will happen. Sounds like a threat to me. The variable here is the threat-agent, not the threat. Managing compliance as threat is just as flawed as any other threat-centric methodology. Compliance should be managed as risk instead, and should be managed in the overall context of risk to the organization.
Risk Requires Value
In order to have risk, you must have something of value. Value, like risk, is personal. Since we all know that corporations are people, this makes perfect sense. As an organization, the assets I value may differ from those that an adversary values. If information security is responsible for risk management, even if we limit that scope to information assets or technology, it follows that Information Security must know more about the business than just about any other group. InfoSec can't protect assets of value if it doesn't know what they are, so we need to understand which assets (servers, desktops, databases and data, applications, etc) are of value. InfoSec often has to make prioritization decisions, so we need to know which business processes these assets support, and the relative value to the business of each. Let me re-iterate that, Information Security must know the relative value of every process that supports the business in order to make the right decisions about which risk management actions to take. What other group in a business needs that knowledge? Yet we find that InfoSec is often the least cognizant of business process and value.
Overcoming our Genetic Heritage
How do we cut through our imposed self delusion and move from the false progress of analysis to meaningful action? There are two steps:
- Establish Information Security objectives that are tied to business value.
- Tie the Information Security objectives to real metrics that measure progress.
It's entirely possible that you're doing some of this already. It seems common from my experience that organizations establish InfoSec objectives, have a metrics program, or measure progress of their work. In fact, the isolated implementation of pieces of this strategy is so common that we often feel like this is common sense. The power here, however, is realized only from a complete implementation. Objectives that aren't tied to business value don’t cut it. Measuring progress with bogus metrics doesn't count. Why not use an attack path analogy to test your implementation's completeness here?
Will the action you are taking (or actions you take) positively affect a specific metric? Does that metric measure progress for a specific objective? Is that objective tied to a specific business value that you can articulate? If not, it's time to figure out which connection is missing and fill in the blanks, or consider whether that action, that product or that project are really necessary.
There's a draft law making its way through the European Union Parliament that bears some scrutiny if you work in the Information Security sector. First of all, I'm completely in favor of prosecuting criminals who steal data, damage the systems of others,and create service disruption. I'd say 'engage in illegal activities' here, but since we're talking about the definition of what's illegal, that would be a bit circular. Because I'm in favor of prosecution and punishment, I think it's very important to examine proposed laws before they get passed. Getting these right is important because if they're not, then they simply won't be effective.
What's in this proposed EU law? There's discussion of actual attacks, attack methods and tools.
Attacks are Illegal
"The proposal would establish harmonised penal sanctions against perpetrators of cyber attacks against an information system - for instance a network, database or website. Illegal access, interference or interception of data should be treated as a criminal offence"
In principle, I don't have any major issues with this statement. The devil is in the details, of course. What constitutes "illegal access" for example? If a system provides unauthenticated access and I take advantage of it, is that illegal? What if a programming error provides access to functionality I shouldn't have? The network statement is equally vauge. An open wireless network is a good example there.
Attack Methods
"The maximum penalty to be imposed by Member States for these offences would be at least two years' imprisonment, and at least five years where there are aggravating circumstances such as the use of a tool specifically designed to for large-scale (e.g. "botnet") attacks, or attacks cause considerable damage (e.g. by disrupting system service), financial costs or loss of financial data."
It's hard to argue with this bit because it's predicated on already being convicted of committing an offense. This is all about the severity of the penalty.
Tools
"The proposal also targets tools used to commit offences: the production or sale of devices such as computer programs designed for cyber-attacks, or which find a computer password by which an information system can be accessed, would constitute criminal offences"
Whoa! Red flag! There are many, many problems here. Let's start with the dead obvious. Those who are responsible for securing information must use the same tools as the criminals. I'd guess that someone made an analogy somewhere in here to criminals and guns. It's a gravely flawed comparison because there's no Internet police force corollary. Making the tools illegal amounts to delivering a huge advantage to the adversary, plain and simple. Interestingly, this parargraph does say 'production or sale' and not posession.
But let's focus on tools "which find a computer password by which an information system can be accesced" for a moment. Here's the thing, this make the whole Internet illegal. If want to find a default password, I google for it. Now, that might not be the intent, but the language as stated would certainly include it. Of course, help information that includes default credentials or tells a user how to recover lost administrative access would be similarly illegal.
This isn't law yet, but now is the time to comment and speak up.
The Utah Department of Health seems to have been compromised to the tune of 181,000 client records and 25,096 social security numbers. This paragraph caught my attention and my response is just too long for a tweet.
"DTS had recently moved the claims records to a new server, which had a configuration error at the authentication level, allowing hackers to circumvent the security system. DTS says it shut down the affected server, implemented new security measures, is review[ing] every server in the state to ensure proper security measures are in place, identified where the breakdown occurred, and has implemented new processes to ensure this type of breach will not happen again."
First, I corrected the quote in the article, which isn't actually quoted, but is basically a cut-n-paste from the UDOH site. I'm going to assume, which is always dangerous, that the DTS didn't move all of these sensitive records without some kind of project plan. It doesn't say this was an emergency move or disaster recovery, though it's possible it was. My assumption, however, is that this was a planned event. Given that assumption, how is it possible that a server was set up for the purpose of housing these records, but no one validated the configuration?
Perhaps they did. Perhaps part of the plan was a step for validating the configuration of the new server and someone just make a mistake in execution. I'd believe that, even accept it. But in this day and age, when you're storing and processing sensitive information, there's no reason you can't a) encypt it and b) validate the server, network and database configuration on an hourly basis (or more frequently).
You know what's not boring? Threat! Threat is downright exciting. First, there's an adversary to consider. Threat is directed, aggressive and time-sensitive. Threat involves people running through hallways, big flatscreens with cool looking graphics and last minute saves. Threat is the stuff of which movies are made.
A movie about risk management looks like this:
The fact is that dealing with threats, while more interesting, is less effective than good risk management. When someone says something like 'the fact is,' it's best to back it up with, well, facts of some kind. But before I lay the facts on the proverbial table here, let's define the terms we're using for this conversation.
Threat vs. Risk
What seems clear from the myriad of discussions on this topic across the Interwebs is that threat includes an 'actor' component, even if that actor is a thing/event rather than a person/group, and risk includes a damage calculation of some sort. I like this image as a visual description of threat:
And I like this paragraph, from a decidedly 'security with guns not bytes' source that looks something like this:
"Simply put, ‘threat’ is a function of the enemy’s capability and intent to conduct attacks, whereas ‘risk’ is a function of the probability that your organisation will be involved in an attack (either as a deliberate target or just in the wrong place at the wrong time) and the harm that such an attack would cause. Even more simply, ‘threat’ = capability x intent, whereas ‘risk’ = probability x harm."
Interesting that these physical security guys have such a compatible understanding, but that's a different subject.
Acknowledging that we could spend a significant amount of time debating the nuances of risk vs. threat, I'll suggest that we have enough information to move on with the point of this particular post.
FACT 1: If you ascribe to the concept that threat is a component of risk, like ISO 27005, then by definition the practice of threat management would be a subset of risk management. Therefore, threat management is by definition less effective than risk management.
FACT 2: If like those guys with guns, you calculate threat and risk separately, then risk management focuses on managing potential harm to your organization (probability x harm) and threat management focuses on the enemy (capability x intent). Now if you were paying attention before, you should have asked 'effective at what' when I said that risk management is more effective than threat management. This is so often where information security gets wrapped around an axel: we don' t all have the same goal in mind. Here are some possible goals for both threat and risk management:
- Managing and/or reducing risk
- Preventing loss of revenue from an incident
- Maintaining uptime
- Keeping your job
- Minimizing the impact of incidents
- Achieving compliance
- Implementing a new technology
There are likely others too. My point is that unless you have agreed to an objective, any conversation about effectiveness is actually pointless. If your objective is to prevent loss of revenue, then you must focus on risk management because it incorporates the value to the business of the assets involved (not the value to attacker). The same goes for any other objective that is business focused, for that matter.
But why is risk boring and threat exciting? Risk is about nothing happening, and threat is full of human emotion and conflict. It's as simple as that.
One of the metrics collected and shared in the Vulnerability Management Benchmark is Average Days Since Last Scan, otherwise known as scan frequency. It's available for free as part of the Basic package. This metric was a fairly surprising one for me to watch develop in the Benchmark community. Over about a decade of working with customers on VM programs, I can't help but have developed my own impression of how often organizations run vulnerability assessment scans in their environments. Most organizations have a monthly scan cadence; some work towards weekly or even daily, and a few outliers work on a quarterly schedule. Based on this anecdotal evidence, I had assumed that average scan frequency would end up being around 30 days. I was definitely wrong. Here's the Average Days Since Last Scan scorecard for the last six weeks:
You can see that the line has been hovering between 53 and 70 days, ending up at 67. I suspect there are two things happening here that have pushed the average up.
The Best Intentions
We all know how our best intentions sometimes don't work out. Well, the same can be true of an organization. It may be that the Vulnerability Management program specifies monthly scans, but delays happen, outages occur, and assets don't get scanned. It may very well be that what we're seeing in this Benchmark metric is the reality of life in the enterprise. A plan for 30 days comes out with an average of 60. It might be that planning for a 15 day turn around would come out closer to 30.
Outside Influence
In the Basic Benchmark package, we're rolling up everything contributed. This data set includes, and doesn't distinguish between, external and internal scans. It may be that we're seeing the influence of an externally mandated cadence being expressed in this metric. PCI requires quarterly scans by an Approved Scanning Vendor , and that distribution of ASV scan schedules may drive a schedule of 'preparatory' scans, which in turn drive the average up (more scans occurring, but less frequently). This trend, however, is really only evident over a longer period of time. Finally, there' s a general push towards more continuous monitoring, driven in part by the Federal government. As this trend continues, we'll likely see more frequent scans across the board.
Of course, you should be wondering how your organization compares to the Benchmark. If you want to find out, join the Vulnerability Management community. Remember, the community isn't just nCircle customers. If you're using a different vulnerability scanning tool, it's still completely free to see your metrics compared to the Benchmark. When you want to drill further into the details, compare and slice in different ways, then the Benchmark Premium package is available as a simple upgrade.
I haven't talked much about the other Benchmark Communities, but they're available as well. It might be interesting to join the Configuration Auditing and Vulnerability Management communities to compare change rate in your environment to trends for average risk, but that's a completely different blog post.
Remember, keep in touch with the VM Benchmark on Twitter: @BenchmarkVM
Until now, the information security community has relied on rumors, conversations and sparse breach reports to develop some kind of consensus on what vulnerability management metrics should look like. The metrics themselves haven't been hard to come by, but how do you know if you're doing well or not? How can an organization truly assess the performance of their vulnerability management program without an industry standard benchmark that provides a comparative metric for the rest of the world?
At the RSA show in February we introduced nCircle Benchmark, giving the security community the first product that actually allows you to compare your metrics to those of your peers. Since then, we've added new Metrics Packs, new capabilities and most importantly hundreds of new community members. Those of you who have already joined a benchmark community know what the combined benchmark results look like. For those of you who haven't joined yet, I'm going to give you a preview of the Vulnerability Management Benchmark right now. This is the last six weeks of average host risk scores for the Benchmark community.
For this Benchmark metric we're using the industry standard Common Vulnerability Scoring System (CVSS) base score. We've calculated the average of the aggregate CVSS Base scores for each contributed asset and trended that data over six weeks. There are hundreds of thousands of assets included in this benchmark, and it's growing with every new community member.
If you're wondering how your risk scores compare to those of the Benchmark, you can join the community and see this scorecard with your data included for comparison for free as part of the Basic package. There is no other way to compare your risk score to your peers, and there's no reason, budget or otherwise, that you shouldn't be able to speak authoritatively to your peers, management, and board about how your Vulnerability Management program is performing. This data is only available from nCircle Benchmark. You don't even have to be an nCircle IP360 user to join and contribute. If you're using Qualysguard or Rapid7, you can still join the Vulnerability Management Benchmark community (and lots of you already have).
The Basic package includes scorecards for average risk score, average scan frequency, vulnerability distribution by platform and vulnerability distribution by severity. You'll see more of the Vulnerability Management Benchmark here in the future, but you can see it for yourself today, including the comparison of your metrics, by joining the community.
Welcome to a world in which you know where you stand.
Don't forget that Benchmark isn't just for Vulnerability Management. There are communities for configuration auditing, endpoint security, anti-virus, identity and access management and more. Each of these has a Basic package that's available free of charge as well. If you like what you see there and want to drill into the details or create your own scorecards, there are Standard and Premium packages too. And you can keep up with the VM Benchmark community on this blog and on twitter @benchmarkVM.
We're thrilled to announce that Configuration Compliance Manager version 5.10 is available now. While there are a whole bunch of useful features in this release, the integration with Cyber-Ark's Application Identity Manager, part of their Privileged Identity Management Suite, is especially interesting. This new feature allows joint nCircle/Cyber-Ark customers to leverage their existing secure credentials management infrastructure for configuration auditing and policy compliance with CCM. The configuration is simple and quickly facilitates more comprehensive scanning. Here’s a little bit about how it works.
One of the tasks we undertook in CCM 5.10 was to review the scan credentials management screens for usability improvements. We've updated these screens to make adding simple credentials as easy as possible, but support the complexity required by our enterprise customers as well. One of the credential types you can select is now Cyber-Ark.
Once you’ve entered the required information and saved the credential, you can use it just like any other credential within a scan task. CCM will dynamically request the credentials from Cyber-Ark as required and will update the credentials if they change in Cyber-Ark. The credentials aren’t stored to disk in CCM at all, providing the maximum security for your credentials possible.
All of this is intended to make the process of obtaining credentialed access to assets in your environment as easy as possible. The owners of those credentials retain complete control over them through Cyber-Ark and CCM gets the access required for the most comprehensive, agentless assessment possible.
(This post is a taste of my presentation at the nCircle booth at RSA. Come by and see it if this is interesting).
Web application risk is a hot topic these days, but there's something missing from the discussion. Vendors seem to be focused on addressing web application risk in a vacuum. They limit their marketing and products to custom web applications and ignore two things: vendor supplied web applications and what I'll call the dependency risk of web applications.
When you choose to deploy a web application, you're deploying much more than just that web app. There is, of course, the web application itself.
Whether it's custom built or vendor supplied, the web application can be vulnerable to things like cross-site scripting, SQL injection or cross-site request forgery. Think about all the products you've deployed that are managed via a web interface. They're all potential sources of web application risk. But the risk doesn't stop there. That web application has to run on some kind of HTTP server.
The web server itself can be vulnerable to buffer overflows, directory traversal, cross-site scripting (again) and other conditions. But wait, there's more. That web server has to run on some platform, whether hardware or virtual, you've got an execution space that can also be vulnerable. There are a near infinite number of vulnerabilities that might exist on the OS or other applications running the web server itself.
Finally, there's likely a database somewhere on the back-end. It may have sensitive data or may be vulnerable itself or may run on yet another vulnerable platform.
The point here is that scanning just your customer-built web applications or scanning them with a completely separate tool just doesn't cover the whole problem. You can't make good risk mitigation decisions without a clear view of the entire risk context.
Whether you're a customer, colleague, partner or prospect, stop by the booth and say hello this week.
But this article misses an important point, or rather only touches on it in a single paragraph. Seth Peter, CTO at NetSPI, points out that "[t]he same rigor that a financial institution or big box retailer puts into their credit card collection needs to be replicated on a smaller scale."
How should/does PCI handle 'retailers' who aren't permanent? We don't know for sure how the Coleman campaign processed transactions, but we do know that they were storing card data that PCI requires you not store (security codes). It's not just PCI that makes this requirement, however, but Minnesota state law (H.F. 1758).
In other words, the Coleman campaign possibly violated the law by not notifying donors of compromised data, may be in violation of PCI (with fines?) by storing the data insecurely, and likely violated the law by storing the data for more than 48 hours after the transaction.
That being said, and left to law enforcement, we're left with a question of how PCI deals with transient retailers. The Coleman campaign (though existing longer than most) isn't a permanent retailer, so the PCI lifecycle can't really apply. What does it mean to get an annual audit if you don't exist for the whole year? What would the 2009 QSA audit for Coleman's campaign look like if it's conducted in December? What about ASV scans?
Yet, at the same time that risk might be reduced by the limited duration of the 'retailer,' entities like political campaigns present a higher risk of compromise. Here are a few things that PCI could do to deal with these situations:
1. Define a merchant tier for ephemeral entities
2. Require that they get audited by a QSA prior to starting processing or that they *completely* outsource the processing operations.
3. Require that they get an ASV scan prior to and during their operating period.
These three things can bring them into compliance and reduce risk using existing PCI mechanisms on a tighter time scale.
California pioneered laws around data breach disclosure with SB-1386, requiring that companies inform consumers when their data has been compromised. Now, state senator Joe Simitian wants to update the law with SB-20. The primary change is greater specificity around what information must be included in the notifications, and a requirement that breaches of a certain size generate notification to the state attorney general. While these are largely good changes, I still think the law misses the one question that most consumers really want answered when their data has been compromised: What should I do about it? Of course, that's a hard question to answer, so it's not surprising that it hasn't been adequately tackled.
You have to love a study run by a vendor where the results clearly demonstrate a problem that very vendor solves. What a pleasant surprise!
Sarcasm aside, Damballa concluded that anti-virus misses a whole bunch of malware. We've seen this conclusion before. Their opinion is that they can protect you from your own compromised machines with their product.
When I read about these sorts of reactive technologies, I have a mixed response. Responding to the fire *is* important, but preventing the fire is always more important. I'm surprised that the industry continues to come up with new reactive technologies.
merchant account providers are charging their merchants. Although not part of the interview, these fees are clearly part of the distributive nature of a regulation like PCI. In the end, the liability that the card brands previously held in its entirety is being distributed all the way down to the merchants themselves.
Earlier this week, someone asked me this question:
"What should the PCI Council be working on next to protect card holder data?"
I thought about this for a while, and decided that the only honest answer is nothing.
I will acknowledge up front that the PCI DSS is lacking in a number of ways, that it could be changed to better protect card holder data and that even a fully compliant merchant still puts card holder data at risk. I'll also ask this question, fair minded reader: Who cares?
As one who holds a few cards, I care. A merchant who wants my business *might* care, but only if they think that the strength of my conviction is such that I might not shop there. The PCI Council is the furthest from caring in this chain, and the successful adoption of the PCI DSS will only make them care less. How so? Well, it's all about revenue and liability.
The PCI Council represents the card companies, who are *gasp* in it for the money. For them, card holder data theft is a liability. It hurts their bottom line if they have to pay out and it hurts their bottom line if card holders don't use their cards. In other words, they can't make themselves liable and they can't make the card holder's liable; neither option is viable for their business. The PCI DSS allows them to place liability at the merchant, which is largely appropriate given their relationship to the card data.
The PCI DSS protects two ways:
Basically, the merchant chooses one of two states: Compliant or Non-Compliant. If they're compliant, then they're less likely to have a breach and compliance can also instill card holder confidence. If they're non-compliant, then they're electing to take on the risk and liability of any breach that occurs. In either circumstance, the card companies have successfully limited their liability.
Hannaford, Hannaford, Hannaford. I know what you're thinking. What about a compliant merchant that experiences a breach?! Well, here's the test. Theoretically, Hannaford shouldn't be liable. I'd argue that it's in the card companies best interest to pay out in this case. They solidify the positioning of PCI and probably increase adoption by merchants too. We'll just have to wait and see how it plays out.
MattW
