Research

Database Activity Monitoring may not carry the same burden of hype as Data Loss Prevention, but it is one of the most significant data and application security tools on the market. With an estimated market size of $40M last year, and predictions of $60M to $80M this year, it rivals DLP in spending. Database Activity Monitoring also carries the best DAM acronym in the industry Sorry, couldn’t help myself. DAM is an adolescent technology with significant security and compliance benefits. The market is currently dominated by startups but we’ve seen large vendors starting to enter the space, although products are not currently as competitive as those from smaller vendors. Database Activity Monitoring tools are also sometimes called Database Auditing and Compliance, or various versions of Database Security. There’s a reason I’ve picked DAM as the second technology in my Understanding and Selecting series. I believe that DLP and DAM form the lynchpins of two major evolving data security stacks. DLP, as it migrates to CMF and CMP, will be the center of the content security stack; focused on classifying and protecting structured and unstructured content as it’s created and used. It’s more focused on protecting data after it’s moved outside of databases and major enterprise applications. DAM will combine with application firewalls as the center of the applications and database security stack, providing activity monitoring and enforcement within databases and applications. One protects content in a structured application and database stack (DAM) and the other protects data as it moves out of this context onto workstations and storage, into documents, and into communications channels (CMP). Defining DAM Database Activity Monitors capture and record, at a minimum, all Structured Query Language (SQL) activity in real time or near real time, including database administrator activity, across multiple database platforms, and can generate alerts on policy violations. While a number of tools can monitor various level of database activity, Database Activity Monitors are distinguished by five features: The ability to independently monitor and audit all database activity, including administrator activity and SELECT transactions. Tools can record all SQL transactions: DML, DDL, DCL, (and sometimes TCL) activity. The ability to store this activity securely outside of the database. The ability to aggregate and correlate activity from multiple, heterogeneous Database Management Systems (DBMS). Tools can work with multiple DBMS (e.g., Oracle, Microsoft, IBM) and normalize transactions from different DBMS despite differences in their flavors of SQL. The ability to enforce separation of duties on database administrators. Auditing activity must include monitoring of DBA activity, and solutions should prevent DBA manipulation of and tampering with logs and activity records. The ability to generate alerts on policy violations. Tools don’t just record activity, they provide real-time monitoring and rule-based alerting. For example, you might create a rule that generates an alert every time a DBA performs a SELECT query on a credit card column that returns more than 5 results. Other tools provide some level of database monitoring, including Security Information and Event Management (SIEM), log management, and database management, but DAM products are distinguished by their ability to capture and parse all SQL in real time or near real time and monitor DBA activity. Depending on the underlying platform, a key benefit of most DAM tools is the ability to perform this auditing without relying on local database logging, which often comes with a large performance cost. All the major tools also offer other features beyond simple monitoring and alerting, ranging from vulnerability assessment to change management. Market Drivers DAM tools are extremely flexible and often deployed for what may appear to be totally unrelated reasons. Deployments are typically driven by one of three drivers: Auditing for compliance. One of the biggest boosts to the DAM market has been increasing auditor requirements to record database activity for SOX (Sarbanes-Oxley) compliance. Some enterprises are required to record all database activity for SOX, and DAM tools can do this with less overhead than alternative approaches. As a compensating control for compliance. We are seeing greater use of DAM tools as a compensating control to meet compliance requirements even though database auditing itself isn’t the specified control. The most common example is using DAM as an alternative to encrypting credit card numbers for PCI compliance. As a security control. DAM tools offer significant security benefits and can sometimes even be deployed in a blocking mode. They are particularly helpful in detecting and preventing data breaches for web facing databases and applications, or to protect sensitive internal databases through detection of unusual activity. DAM tools are also beginning to expand into other areas of database and application security, as we’ll cover in a future post. Today, SOX compliance is the single biggest market driver, followed by PCI. Despite impressive capabilities, internally-driven security projects are a distant third motivation for DAM deployments. Use Cases Since Database Activity Monitoring is so versatile, here are a few examples of how it can be used: To enforce separation of duties on database administrators for SOX compliance by monitoring all their activity and generating SOX-specific reports for audits. If an application typically queries a database for credit card numbers, a DAM tool can generate an alert if the application requests more card numbers than a defined threshold (often a threshold of “1”). This can indicate that the application has been compromised via SQL injection or some other attack. To ensure that a service account only accesses a database from a defined source IP, and only runs a narrow range of pre-approved queries. This can alert on compromise of a service either a) from the system that normally uses it, or b) if the account credentials are stolen and used from another system. For PCI compliance you can encrypt the database files or media where they’re stored, then use DAM to audit and alert on access to the credit card field. The encryption protects against physical theft, while the DAM protects against insider abuse and certain forms of external attack. As a change and configuration management

As my readers know, I’m not the biggest fan of consumer DRM. I hate being treated like a criminal when I’m not, and I don’t believe anyone has the right to control more of my systems than I do. Something about my security being compromised to provide better security for some corporate entity whose products I may or may not purchase just bugs me. A while back I posted how the Barenaked Ladies distribute their content without DRM. Not for free, but once you buy it you’re free to use it as you wish. I like that. Now, thanks to TechCrunch, we learn that Madonna is leaving the record labels and working with Live Nation to distribute content directly. Nine Inch Nails, Radiohead, and a few others are also jumping the record label ship. Yahoo! Music stated they won’t distribute music with DRM. With MySpace and other social networking sites for promotion, low-cost digital distribution of content either directly to consumers or through online stores, and general frustration and anger with record company pricing, practices, and treatment of artists, it’s hard to see how the companies will survive. It won’t be an immediate death- years if not decades, but now that some of the biggest names in the business are running into independence the writing is clearly on the wall. And the record companies can take their damn DRM with them. Now it’s time to get cracking on the MPAA… Share:

I was reading a post over at Layer8 and it got me thinking about trust. Shrdlu attended a talk by Larry Ponemon where he took away this little tidbit: The trust given to an organization depends not only on how well it protects information, but also on how transparent it is. A long time ago I spent some time thinking about trust and digital relationships. I broke it down into three components: Intent, Capability, and Communications: Intent: How an organization (or person) intends to act within a relationship. This is their true intent, not necessarily what they communicate as their intent. For example, we collect credit card data solely to perform online transactions, and will protect it from unauthorized disclosure. Capability: Does an organization have the capability to meet its intent? For example, does it collect card numbers and only use them for transactions, but use security which could not stop a targeted attack? Communications: Does an organization effectively and accurately communicate its intentions and capabilities? If any of these factors fails, so does trust. Let’s look at some examples in the security world. Some vendors, I don’t even need to bother naming them, make outlandish claims about the security of their products that do not reflect reality. Then, when breaches occur, they spin the facts rather than admitting to an honest mistake. Result? No one trusts those vendors anymore. I remember our home town bank as a kid. We’d walk in and it was all marble and stone, with a huge walk-in vault surrounded by guards at the far end. Placing the vault where customers can see it doesn’t improve security, but it clearly communications of a capability to protect your money. These days, no one cares. Why? The world changed and with the FDIC and electronic banking we are far less concerned about a bad guy with a mask stealing our money. Heck, they could steal the entire bank, foundation and all, and we still wouldn’t be out a dime. Breach disclosure is another example of trust. If a company loses my personal information and clearly communicates how it was protected, how it was lost, and a reasonable plan for preventing a recurrence, I am not very likely to leave them. If, on the other hand, they attempt to cover it up, shift blame, or clearly lie about their intent or capability to protect my information, I am far more likely to switch to another provider. A privacy example? Years ago I cancelled my Amazon account after they changed their privacy policy and started sharing my data. The policy in effect when I signed up stated my information would be kept private. They then summarily changed it without my permission. They clearly either lied about, or changed, their intent, and lost me as a customer. It took me 5 years before I bought from them again. It’s very simple: trust is built on what you intend to do, your ability to do it, and your ability to communicate both. Share:

Once again Martin and I recorded late enough in the day that I could enjoy a fine beer during the taping (Moose Drool this week). I also need to shout out to Paul and Larry and Pauldotcom Security Weekly; based on their advice I picked up a WRTSL54GS for some wireless access point hacking. Too bad I bricked it… by opening the box. Needless to say that one is on its way back to the online store, and a new one is headed to me. I’ve been working on this pet project of mine for a year and really hope this is the right box to get the job done. Also, congrats to Martin on re-entering the world of the gainfully employed. He starts with Trustwave on Tuesday. Show Notes: Microsoft AutoRuns PGP Flaw not really a flaw at all Securosis: Slashdot bias and much ado about nothing PGP encryption issue Slashdot: Undocumented bypass in PGP whole disk encryption Securology: PGP whole disk encryption – barely acknowledged intentional bypass Retailers vs. PCI Securosis: Retailers btch slap PCI Security Standards Council Techtarget: National Retail Federation takes aim at PCI DSS Council SC Magazine: Retail Lobby offers alternative to PCI standards Network Security Blog: Merchants mad about credit card retention iPhone Jailbreak (missed the link on this one) Suit against Apple for bricking iPhones Six ticks to Midnight: One plausible journey from here to a total surveillance society Tech Liberation Front Onstar to stop supports RSA Speaking on Security interviews Shon Harris, and I get a mention too. CIO.com: Hacker Economics 1: Malware as a service Tonight’s Music: The Moon is Full by Albert Colins, Johnny Copeland and Robert Cray Network Security Podcast, Episode 80, October 9, 2007 Time: 46:51 Share:

Meerkat Manor, via the Guerilla CISO. Here’s an excerpt: 09 October 2007: Dear diary, I drew sentry duty for the third day this week. I know it’s my solemn duty to protect the clan, but my risk assessment has determined that, although a predator is a high-impact event, it is a low rate-of-occurance activity and so I think a better use of my time is in foraging for stray eggs. Besides, if the predators come and eat us all, it’s not like I’ll have to face the Meerkat Manor Board of Directors. 10 October 2007: Dear diary, I grow tired of the incessant looking for predators. I mean, why do us meerkats focus exclusively on detective controls which use up to 15% of our available manpower when we could just as easily reduce the sentries to 5% of our efforts and put in place corrective controls such as trap holes and punji sticks to reduce the threats to our home? The true cost savings is that the effort for corrective controls is a one-time installation where sentry duty is a recurring bill. Didn”t the alpha-pair learn anything in their Masters in Meerkat Administration classes? 11 October 2007: Dear diary, today I instituted a metrics program to gauge the effectiveness of our sentry program and to determine if we are getting the best level of risk for the time that we are investing. So far, I”ve made a bar chart to analyze the total number of predator alerts versus the total number of predator intrusions. I think I have a business case to slowly reduce the ratio of sentries to foragers during the day. Share:

Data classification is one of the most essential tools of data security. It enables us to leverage business priorities into technical and physical controls over the management and protection of data. Applying data security controls without data classification is like trying to protect a pile of cash in an open field filled with piles of leaves by air dropping concrete barricades from 10,000 feet. At night. It’s also hard. Really hard. So hard that outside of a few companies in a few industries, mostly financial services, energy production, military/intelligence, and some manufacturing, I’m not sure I’ve ever seen someone with a useful and effective classification program. I’ve talked with hundreds, possibly thousands, of organizations struggling with data classification. Some give up, others blow wads of cash on consultants that don’t really give them what they want, and others have a well documented, detailed program that everyone ignores. Data classification is so hard because it is both Non-intuitive and instinctive. Instinctive in that we all innately classify everything we see. From people, to movies, to enterprise data, we humans are judgmental classification machines. We classify as good vs. bad, threat vs. non-threat, important vs. irrelevant. Non-intuitive because in an organization we’re asked to classify not based on our instincts, but based on policies designed by someone else. Thus the first problem with data classification isn’t because we can’t classify, it’s because we always classify. We just classify based on our instincts, not a piece of paper on a shelf. When they differ, our instincts win. The second problem with data classification is that we overlay it onto business process, rather than building it in. Classification becomes a task outside of the processes we engage in to complete our job; it’s an “add on” that slows us down, and is simple to ignore. The third problem with data classification is that we fail to provide employees with the tools to get the job done. It’s not only manual and non-intuitive, but we don’t provide the technical tools needed to even make it meaningful. Quarterly assessments in a spreadsheet aren’t very useful. The fourth problem with data classification is that it’s static. We tend to classify data at the time of creation or based on where it’s stored, but that’s never revised based on changing use and business context. Data’s sensitivity varies greatly over its lifecycle and based on how it’s being used; few data classification systems account for this. The fifth, and final, problem with data classification is that it’s usually too complicated. The classification scheme and process itself is even less intuitive than asking someone to classify against their instincts. We use terms like, “sensitive but unclassified” that have little meaning outside the world of the military/government. But that doesn’t mean all hope is lost. As I mentioned before, there are places where data classification works well, mostly because they’ve adapted it for their specific environment. The military does a good job of overcoming these obstacles- data classification is built into the culture, which redefines native instincts to include enterprise priorities. It’s baked into the process of handling information and essential to business (yes, the military is a business) processes. Technology systems are specifically designed and chosen due to their suitability to handle classified data. No, it’s not perfect, but it does work. That doesn’t mean that military classification works in private enterprise. It doesn’t. It fails. Badly. Which is unfortunate, because that’s how all the books tell you to do it. Over the next two posts I’ll suggest something I call Practical Data Classification. It’s designed to provide organizations an effective model that integrates with existing enterprise practices and culture, while still providing value. It’s not for you military or financial types that alreaady do this well; consider it data classification for the rest of us. Share:

Despite my departure from the analyst world, thanks to the blog some of the vendors out there are still keeping me updated on their products. I also still have to track big swaths of the market to support my consulting work. While I don’t intend to this blog to just spew PR dribble, I do see some cool stuff every now and then that’s worth mentioning. Disclaimer: I do not currently have a business relationship with any of the vendors/products in today’s post, but based on the nature of my business I do work with vendors and often have discussions about potential projects. I will disclose these relationships when I can, and while I strive to remain objective no matter who I work with you should never go buy something just because I said it was cool. Do the research, get balanced opinions, trust no one. I’m not endorsing these products over their competitors, just highlighting some interesting advances, and you’ll probably see competing products pop up in other posts over time. Here are a few things that have caught my eye: First up is SafeBoot, just acquired by McAfee. Overall I think the acquisition is positive, but there’s really no reason to consolidate whole drive encryption with endpoint DLP. File-level encryption linked to DLP is more interesting, but also very challenging and I suspect at least a couple years out for McAfee other than some basic content like Social Security Numbers. It’s wait and see on this one, but SafeBoot stands up on its own. Next is Guardium, who just updated their product for the mainframe. Guardium briefed me last Friday on this and I meant to get something up earlier. This is a really smart move, especially since they partnered with Nuon Neon who sells to the mainframe buying center. They can now offer full database monitoring (including SELECT queries) on the mainframe outside of network sniffing (which misses certain kinds of connections). Why you care? Now you have an independent way to enforce separation of duties on mainframe administrators without interfering with how they work or affecting performance. And you can integrate the policies for alerts, and the logs, with all your other database monitoring. I think I was more excited about this one than the guys giving me the briefing- it’s one of these “small but big” markets. An industry contact I work with pointed me towards Palo Alto Networks and I had a brief conversation with them about a month ago. Basically, they parse and secure network traffic based on the application, not just port and protocol. This is a big problem for things like DLP solutions that don’t really like it (or work as well) when they have to figure out which application is tunneling over port 80 this week. I think these guys have a lot of partnership opportunities down the road. Last up today is Vontu, who just released version 8. The news here is increasing their endpoint capabilities to start blocking and integration with document management systems. This release isn’t notable for any new world-changing feature, but because most of the work was on the back end and increasing the capabilities of the product line. DLP is settling down a bit and focusing on maturing, rather than land-grabbing with hyped up features. I’ve had some other DLP briefings lately and I’m seeing this focus on maturing the platforms across the board; moving from start-ups to mature products is some seriously hard work. Blocking activity on the endpoint is a big deal and it’s nice to see Vontu add it (a few competitors also have their own flavor of it, so it’s not unique). That’s it for now. I probably won’t do these more than once a month or so and I’ll only include any updates that seem interesting to me either because they are innovative of because they show an industry trend. I’m happy to take briefings from just about anyone, but that by no means guarantees a mention on the blog. Now back to the absolutely thrilling world of data classification… Share:

In over thirteen years with mountain rescue and five years as a ski patroller I participated in countless search and avalanche drills, and a fair number of real incidents. Search in the real world, as in the computing world, is difficult due to the need to balance performance with thoroughness. In a rescue situation you need to find the victim as quickly as possible; a thorough search has a higher Probability of Detection (POD), but takes longer. Assuming you’re looking for a live victim this time can mean the difference between a rescue and a recovery. Since detailed searches also take time to gather resources (searchers), most searches/rescues start with what’s called a hasty. A hasty search is light and fast- you send out a smaller, faster team to scour the area for obvious clues. The probability of detection is low, but you don’t need a 50 person team with full gear to find a half-burried skier in an obvious tree well in the middle of a deposition zone (where all the snow ends up after an avalanche). I’ve been on a bunch of hasty teams in real-world searches (no avalanches) and would guess that we found the victim before the big search was launched somewhere around 20-30% of the time. A hasty is effective because it’s designed to maximize speed while finding anything obvious in critical situations. We can adapt the principle of the hasty for data classification. Many classification programs fail because they attempt to solve the entire problem while taking too long to protect the critical assets. In a hasty classification program you focus on a single critical data type and roll out classification enterprise wide. Rather than overwhelming users with a massive program, focus on one kind of data that’s clearly critical in a very focused program to protect it. It’s a baby step to protect a critical asset while slowly changing user habits. Data Classification Type 1: Hasty Classification The short version: Pick one critical type of data. I suggest credit card numbers, Social Security Numbers, or something similar. Have business units tell you where they use it and store it. Issue security policies for how that data needs to be secured. Work with units to secure the systems Security helps the business units secure the data, while audit plays the enforcement role. This makes security the good guys. Keep it updated with ongoing audits and regular “compliance” reporting of where and how data is used and stored. Same process, with more details: Design your basic classifications. I suggest no more than 3-4, and use plain English. For example, “Sensitive/Internal/Public”. If you deal with personally identifiable information (PII) that can be a separate classification, and call it PII, NPI, HIPAA, or whatever term your industry uses. Pick one type of critical data that is easy to recognize. I highly recommend PII- credit card numbers, Social Security Numbers, or something similar. Get executive approval/support- this has to come from as high as possible. If you can’t get it, and you care about security, update your resume. Beating your head against a wall is painful and only annoys the wall and anyone within earshot. Issue a memo requiring everyone to identify any business process or IT system that contains this data within 30/60/90 days. Collect results. While collecting the results, finalize security standards for how this data is to be used, stored, and secured. This includes who is allowed to access it (based on business unit/role), approved business processes (billing only, or billing/CRM, etc.), approved applications/systems (be specific), where it can be stored (specific systems and paper repositories), and any security requirements. Security requirements should be templates and standards with specific, approved configurations. Which software, which patch level, which configuration settings, how systems communicate, and so on. If you can’t do this yourself, just point to open standards like those at cisecurity.org. Issue the security standards. Require business units to bring systems into compliance within a specific time frame, or get an approved exception. IT Security works with business units to bring systems/processes into compliance. They work with the business and do not play an enforcement role. If exceptions are requested, they must figure out how to secure the data for that business need, and the business will be required to adopt needed alternative security controls for that business process. After the time period to bring systems into compliance expires, the audit group begins random audits of business units to ensure reporting accuracy and that systems are in compliance with corporate standards. Business units periodically report (rolling schedule) on any changes on use or storage of the now-classified data. Security continuously evaluates security standards, issues changes where needed, and helps business units keep the data secure. Audit plays the enforcement role of looking for exceptions. I know some of you are sitting there going, “This is the easy way? I’d hate to see the hard way!” The hasty classification is really an entire data classification program, but focused on one single kind of easily identified data. When you think about it, you’re just picking that critical data, figuring out where it is, helping secure it, and using audit to make sure you’re doing what you think you’re doing. When I discuss this with people I prefer to lay out all the steps in detail, but most of you will adapt it to suit your own environment. The key is to keep it simple, pick one data type to start, and separate between those securing the data, and those verifying that the data is secure. In our next post on this topic we’ll talk about how to grow this into a complete program. I’m even working on pretty pictures! Share:

History is a funny thing. It’s amazing that what many children see in early schooling as a boring collection of facts is neither boring nor factual. On a good day we might get some dates correct, but there isn’t a “fact” in history that isn’t open to interpretation. This is as it should be; think about all the factors that went into a major life decision- say a marriage or picking your college. Now distill everything involved in that decision into a paragraph, stick it in a drawer for a couple decades, pull it out, and see if it still matches your memories and accurately reflects the situation. If you don’t have a few decades to spare, the answer is, “it doesn’t.” The main problems with history are actually those we see in computer science- bandwidth, compression, indexing, and search. We can’t possibly collect and store all the bandwidth of human interaction, so we drop into “sampling mode” and further compress it for long-term storage. We then rely on imperfect indexing to organize the data, and flawed search protocols to find what we need. We don’t collect everything, lose large amounts of data in compression, poorly index it, and rely on primitive search tools. No wonder history is open to interpretation. Take the Maginot Line. And Encryption. For those of you who aren’t military history buffs, the Maginot Line was a series of interlocking defenses, sometimes 25 kilometers deep, that the French built after WWI to keep the Germans out. In popular security culture the term is often used as an analogy to describe a misguided investment designed to fight the last war that’s easily circumvented. In marketing films of the time the Maginot Line was promoted as being an invincible defense for France. A folly painfully realized when the German invasion succeeded in only a month. A metaphor for a failure of hubris. Reality is, of course, open to interpretation. Another interpretation of the Maginot Line is that it completely succeeded in its defined task, preventing a frontal assault along the Franco-German border. The Maginot Line held, but the other defensive layers- the Ardennes and the French Army along the Belgian border- failed. The Maginot Line was designed for a mission it effectively met, but other design flaws in the defense in depth of France lead to the German occupation. Which brings us to encryption. The first version of the PCI Data Security Standard called encryption, “the ultimate data security technology”. Wrong. Encryption is a powerful technology, but probably the most-misunderstood in the context of what it provides for data security. With the McAfee acquisition of SafeBoot for $350M, encryption is in the headlines again. A while ago I wrote the Three Laws of Data Encryption to help users get the most value out of encryption. I really do think of encryption as the Maginot Line of data security. It’s powerful, nigh invincible, if used correctly, but easily circumvented if your other security controls aren’t properly designed. For example, if you have a large application connected to a large database full of encrypted credit card numbers, and that application is subject to SQL injection, odds are your encryption is worthless. Laptop encryption protects you from stolen laptops, but is useless against malicious software running in the context of the user. As I keep walking through the Data Security Lifecycle you’ll see a lot of posts on encryption; it’s a fundamental technology for protecting content. But when big companies start throwing around hundreds of millions of dollars I think it’s an opportune time to step back and remind ourselves of the problem we’re trying to solve, and how the different parts of the solution fit together. If we want a real-world example we need to look no further than TJX. Rumor has it that cardholder data was encrypted, but the attackers sniffed an unencrypted portion of the communications to perform transactions. The encryption worked perfectly, but the breach still succeeded. Share:

Jeremiah posted these questions on dealing with website vulnerabilities. Here are my quick answers (I have to run- sorry for the lack of links, but you can Google the examples): Lets assume a company is informed of a SQLi or XSS vulnerability in their website (I know, shocker) either privately or via public disclosure on sla.ckers.org. And that vulnerability potentially places private personal information (PPI) or intellectual property at risk of compromise. My questions are: 1) Is the company “legally” obligated to fix the issue or can they just accept the risk? Think SOX, GLBA, HIPAA, PCI-DSS, etc. Definitely no for intellectual property. Definitely no for SOX- SOX says you’re free to make as many dumb mistakes and lose as much money as you want, as long as you report it accurately. Other laws are a toss-up, but generally there is no obligation unless there is evidence that a breach occurred. For PCI-DSS you have to remediate or document compensating controls for any network vulnerabilities at the time of your audit (and this expands to applications with 1.1), but there is no definitive requirement for immediate remediation. California AB1950 is the big question mark in this area and I’m unsure on enforcement mechanisms. The regulations are very unclear and unhelpful here, and it’s quite likely a company can accept the risk. But if a breach occurs, they may be held negligent. Take a look at the PetCo case where the FTC mandated a security program after a breach, and Microsoft/MSN. The companies were held liable for losing customer data, but not because of any of the usual regulations. There is almost no case law that I’m aware of. 2) What if repairs require a significant time/money investment? Is there a resolution grace period, does the company have to install compensating controls, or must they shutdown the website while repairs are made? No. Most regulations only require breach notification or remediation of flaws discovered through auditing. Reasonable person theory probably applies if there is a breach with losses and it goes to court. I’ve read all of the regulations- none mention a specific time period. 3) Should an incident occur exploiting the aforementioned vulnerability, does the company bear any additional legal liability? They may carry liability due to negligence. See the cases I mentioned above. 4) If the company’s website is PCI-DSS certified, is the website still be considered certified after the point of disclosure given what the web application security sections dictate? Unknown because there are no public cases that I can find. I believe you remain certified until the next audit. In the case of Cardsystems, they were PCI certified when the breach occurred and immediately re-audited and de-certified following public disclosure of the breach. That’s one problem with PCI-DSS- it’s very audit-reliant and changes between audits don’t directly affect certification. 5) Does the QSA or ASV who certified the website potentially risk any PCI Council disciplinary action for certifying a non-compliant website? What happens if this becomes a pattern? No known cases of disciplinary action, but an audit insider might know of one. Disciplinary action will most likely only take place if the audit failed to follow best practices and a large breach occurs, or if there is (as you mention) a pattern. None of this is formalized to my knowledge. I’ve spent a lot of time researching and discussing all the various data protection and breach disclosure regulations. Organizations generally only face potential liability if they either falsify documentation for auditing or certification, or suffer a breach and are later shown to be negligent. I am unaware of legal enforcement mechanisms if there is a known vulnerability, but no definitively unapproved disclosure of information. This is an inherent risk of audit-based approaches to data protection. Share: