Compliance and Security : A Rocky Relationship Dr. Anton Chuvakin WRITTEN : 2004 DISCLAIMER: Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around. Introduction Security incidents can wreak catastrophic results on organizations. Such incidents may involve hacking, malware outbreaks, economic espionage, intellectual property theft or loss, network access abuse, theft of IT resources, and many more problems. This, by the way, is not some security salesman propaganda – events of that sort constitute daily reality for security professionals all over the world. On top of this, recent regulatory mandates directly affect how organizations should deal with such occurrences. In this chapter, we will try to explore the rocky relationship between regulatory compliance and information security - as well as with risk. Today’s Security for Managers Before delving into this relationship, we need to explore modern security landscape and provider our readers with an overview of information security. Security at an organization starts from a security policy. A properly drafted and implemented security policy serves to protect information, systems and even people; it sets guidelines for expected employee behavior, and authorizes security personnel to monitor, probe, investigate, define, and determine the consequences of violating the policy. More generally, security policies help define the company's overall stance on security issues and minimize internal and external risk exposure. What is even more relevant for this chapter is that a policy will also incorporate guidelines from various corporate regulations. Of course, simply having a security policy is only half the battle. A recent study found that many IT professionals either knowingly ignore their company security policies or inadvertently break the code because they are simply unaware of the guidelines. For example, more than half of the 890 respondents said that they had copied confidential company information onto USB memory sticks, even though 87% of them admitted they knew this action is explicitly disallowed by their company's security policy. Of course, no less disturbing is that 33% of respondents had sent workplace documents home as e- mail attachments, even though almost half of them had no idea whether or not that practice violated their company's security policy. Thus, the other half of the battle in implementing security policies is ensuring that all employees are aware of the policy's stipulations and that the policy includes a chain of responsibility for implementation and enforcement. Moreover, some evidence points at the fact that security pros are no better than regular IT users about complying with policies that they see as "stupid." In recent years, even major publications such as the Wall Street Journal have record macr published tips that would violate security policy at most organizations, such as sending corporate files to your own private web mail account. On the technology , most security gear is built to follow the well-known security maxim "prevention-detection-response" which covers three components, all crucially important for an organization‟s security posture. Mostly prevention-focused technologies – such as firewalls, anti-virus or intrusion prevention systems - seem favored by many as the primary component of organization defense. Detection capabilities such as intrusion detection systems or network anomaly detection or even log analysis - follow closely behind. At the same time, everybody who is even slightly involved with security knows that prevention technologies will fail at some point. It's necessary to have an additional layer to detect the consequences of a breach. Thus few question the need for comprehensive network monitoring aimed at increasing control over what should be "your" network but is sometimes "owned" by the attackers as well. Note that detection will also fail at some point, leading us into incident response. As a result, response capabilities have a unique characteristic lacking in the other two components: It is impossible to avoid and there is no magic security device that will respond to an incident. While it is not uncommon for an organization to have weak prevention and nearly nonexistent detection capabilities, response will always be necessary, since organizations are forced into response mode when they are attacked. Let‟s cover all of the above briefly. While intrusion-detection technologies are clearly not a hot new thing anymore, they are still the subject of active industry debate. Since the infamous "IDS Is Dead" piece was published by Gartner Inc. in 2003, the discussion about the relevance of intrusion-detection systems to today's world of commercial malware and Web exploits rages on. Furthermore, the relationship of IDS to newer technologies such as intrusion-prevention systems (IPS) and network-behavior anomaly detection (NBA) systems is also commonly discussed in the security community. No matter what technologies become fashionable, the need for intrusion detection is constant. Whether you choose to implement an IDS is less important than having a process that enables you to know what is going on and to detect intrusions. Thus, enlightened companies will consider even their end users to be, metaphorically speaking, a kind of IDS, since users will sometimes serve as indicators of suspicious behavior. On the opposite end of the spectrum are those less-enlightened company executives that chose to go with "CNN is our IDS" and that only learn that their networks were compromised when the news shows up in the media. Don't be those guys! Finally, digital forensics is the process of using the scientific method to examine digital media in order to establish facts for legal purposes, especially judicial review. It involves the systematic inspection of IT systems, especially data-storage devices, for evidence of a civil wrongdoing or criminal act. Because of its focus on facts and scientific method, computer forensics processes must adhere to courtroom standards of admissible evidence, which severely complicates some of the otherwise simple data-analysis tasks such as looking at logs to determine who connected to the system. Thus, forensic investigation of computer evidence is different from a routine review of logs and system data, which often produces "hunch- quality data" and not facts. A common example of a computer forensic investigation is a search for child pornography, during which an investigator removes a hard drive from a computer, loads the disk into a forensics tool and reviews the contents to find illegal image files that a user is hiding or thought he had deleted. However, digital forensics has a broader reach than this case, and electronic evidence can be collected from a variety of sources, including network gear, desktops and servers, mobile devices, and databases. Review of data produced by these IT components can, for example, show investigators of a data breach whether company employees have accessed confidential data, what steps they took to obtain the data and what they did with it. This is where the link between log data and computer forensics becomes most obvious -- logs become the first place to look during the investigation. Even though sometimes seen as difficult to analyze, logs are still easier to obtain and review than full disk contents. If logs are generated, they can help to figure out the who, what, where, when and how of user and system activities. Having control over forensics processes from data gathering to "chain of custody" protection is seen as key by many of the compliance mandates. Today’s Compliance for Managers What are some of those regulations that affect security today. Here are a few examples. Sarbanes-Oxley Act of 2002 or SOX is often seen as a grand-daddy of regulations affecting security. Most of the security mandates are derived from SOX section 404 which covers the adequacy of the company's internal control over financial reporting. SOX section 404 leads to a lot of security technology and services purchases. The Federal Information Security Management Act (FISMA) of 2002, which was created to strengthen government computer and network security, requires federal agencies to set up incident response capabilities in keeping with the guidelines put forth by the National Institute of Standards and Technology. These guidelines include the establishment of a protected central repository, preferably online, for all certification and accreditation documentation, acquisition-related information, risk and vulnerability assessments, compliance surveys, security incident reporting and remediation results, and external security audits. Specifically, NIST SP 800-53 lists a variety of security controls (including intrusion-detection controls) that need to be in place to protect a federal information system. NIST 800-61 (also known as the "Computer Security Incident Handling Guide") describes detailed technical, procedural and policy guidelines for federal agencies working to put into practice comprehensive incident response and computer forensics capabilities, including procedures for detecting, reporting and responding to security incidents. The Health Insurance Portability and Accountability Act, which strives to protect individuals' medical records, requires organizations to clearly determine the goals of incident response -- a process that should include a strong understanding of what constitutes a security incident (defined as attempted or successful unauthorized access, use, disclosure, modification or destruction of information and/or interference with system operations in an IT system). HIPAA requires the creation of a security incident response team or another reasonable and appropriate response and reporting mechanism. Among other things, organizations subject to HIPAA should have both an incident response plan and an IR team, as well as a method to classify security incidents. NIST SP 800-66, “An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act Security Rule”, details security management requirements for the securing of electronic protected health information. The Payment Card Industry Data Security Standard takes a slightly different approach to incident response than FISMA does, since it strives to protect different types of data. PCI DSS requires companies to maintain a clear and comprehensive information security policy, deploy security various technology controls as well as validate compliance with the mandate via an on-site assessment or a self-assessment and vulnerability scanning. We will use PCI DSS as an example regulation in the next section. PCI DSS was unified from card brand individual security mandates, established to increase the security of card-accepting merchants and thus reduce the risk of electronic credit card transactions. Historically, PCI security requirements came from card brands trying to deal with a deluge of card fraud. Since early 2000s, payment card data theft has hit organizations of all sizes. The biggest known breach to date was the theft and sale of more than 100 million credit and debit card numbers from a major card processor. As of today, compliance with PCI is mandatory for any merchant or any other organization that accepts payment cards as all deadlines for compliance have already passed. Compliance and Security Let‟s now delve into the relation between security and compliance. For example, one of the best known and most impactful regulations is PCI DSS. Payment Card Industry Data Security Standard (PCI DSS or, often, just PCI) has literally revolutionized the way many organizations treat security. While many regulations promised to “take information security from the wire closet to the boardroom”, PCI actually accomplished that for many organizations, and not only the large ones. While following all of the PCI DSS guidance will not magically “make you secure” or prevent all possible incidents, the standard contains many of the commons sense security requirements. Let us now look at how organizations approach compliance projects and what impact they have on the organization security in order to better explain the relation between compliance and security. In particular, do they approach compliance requirements literally, as a simple compliance checklist defined in PCI DSS documentation? Or do they assess what the compliance requirements seek to accomplish and how to apply it to their business? In addition, we will look at how to simplify this process for those who consider both compliance and information security to be overly complicated. Many security professionals often highlight the fact that since security was the motivation to establishing the compliance requirements, addressing security will lead to compliance (it will obviously lead to security as well). Thus, the “Security FIRST!” slogan was born. However, addressing security is very challenging, given today‟s complex networks, rapidly developed applications, growth of “Web 2.0,” and other advances in information technology. Dr. Dan Geer, a noted security expert, once said that “security is perhaps the most difficult intellectual profession on the planet.” As a result, many organizations have not been able to focus on security and instead have been looking for “an easy way out” of its complexities. Compliance vs. Security It might be something that few people admit, most experts criticize and – that is the inconvenient truth! – a lot of people actually do. Namely, despite all the talk about “„compliant‟ does NOT mean „secure‟”, “unified compliance” and “do security first!” (succinctly highlighted by one expert in his presentation called “How Focusing on Compliance Can Get You Killed!”), there is a sizable population that treats compliance in general and PCI DSS compliance in particular as just another tactical IT project implemented in a silo‟ed and minimalistic way. To illustrate this, let‟s picture this fictional situation: a medium-size organization‟s management finally “gets the PCI message” and decides that it is important to deal with compliance. What happens next? In the “compliance first” mindset, illustrated here, the management summons an IT manager hands him a copy of the 12 PCI DSS requirements, a mandate to “do this!”, and no additional IT budget. As a result, the IT manager is supposed to “address PCI compliance,” while working under these constraints. What happens next? The IT manager reviews the requirement list and notices that he already has some of the things implemented. For example, a network diagram (PCI Req 1.1.2) is proudly displayed on his cubicle wall. How about the rest of the guidelines though? Here is how some of the requirements, his responses and some of his unspoken thoughts stack up: Requirement 5.1 “Deploy anti-virus software on all systems commonly affected by malicious software” - Upon reading this, the IT manager will happily confirm “OK, we have anti-virus! Great!” However, thinking whether it is deployed on all „at-risk‟ systems will likely be left alone as “too complicated.” Requirement 5.2 “Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.” In this case the manager will probably think something along the lines of “What do they mean here? I guess the anti-virus tools do run, don‟t they?” Similarly, a more complex issue of antivirus audit logs, mentioned in this Requirement, will likely be skipped or “deferred.” Requirement 6.6 “… Installing a web-application firewall in front of public-facing web applications” Thinking that this requirement actually refers to a network firewall deployed in front of a website (Web site + firewall = web firewall …) is actually not that uncommon! Every security professional, however, will know that in reality this refers to a different dedicated application security device: WAF or web-application firewall. In this company‟s case, the IT manager will probably not think along these lines. Requirement 10.6 “Review logs for all system components at least daily.” The IT manager might remember that syslog server that was deployed a few months ago is still there. While only thinking of syslog servers when logging is discussed in not uncommon, PCI DSS Requirement 10.6 actually covers log review and just “having the syslog server up” will not satisfy it. Requirement 11.4 “Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises.” Similarly, installing and launching Snort with the intention of looking at IDS/IPS alerts later is what often comes to mind here. Many IT managers have heard that “IDS is a pain,” but they still hope that deploying an NIDS will “make them compliant.” Overall, the IT manager goes requirement by requirement and figures out what is on his network vs. what is in the document; sometimes he plans to make a change here and there. After looking at the last Requirement 12 and making these changes, he considers himself “done” with PCI DSS project. Is this organization compliant now? The answer is “It depends.” If they are not to be audited, they might well consider themselves “compliant with PCI DSS” as long as they can pass the scanning requirements (Requirement 11.2). But will they be considered compliant if they are audited after a breach? Is this organization more secure now? The answer also is “It depends.” There is a good chance that if the IT manager was aware of the risks to his company (and few smaller organizations are) and have taken simple actions to deal with these particular risks (and almost no such organization does), he would have been more secure. However, there is definitely some possibility that the security of this organization has improved due to the PCI DSS effort. For example, if the IT manager changed the password policy to a more stringent one or disabled a few default accounts, then for sure the organization‟s security would have improved. In any case, this organization now feels better about answering the compliance self- assessment questionnaire and getting scanned for compliance validation. PCI Validation via Scanning PCI DSS Requirement 11.2 calls for quarterly external scans by a PCI Approved Scanning Vendor (ASV). Such scan must come up with no “PCI-scope vulnerabilities” Here is an example of vulnerabilities considered to be reasons for PCI scan failure: “Vulnerabilities with a CVSS v2.0 base score of either 4.0 or higher will cause PCI compliance to fail on the scanned IPs. Vulnerabilities that may lead to SQL injection attacks and cross-site scripting will result in a non-compliant status on the corresponding IP.” ASV scanning serves as a simple validation mechanism for PCI requirements as well as help to make organizations aware of possible vulnerabilities to card holder data. As everybody in the security profession realizes, new vulnerabilities in software applications and platforms are discovered daily; frequent vulnerability scanning helps organizations identity them and then remediate, thus increasing security. This would be an example of “Security FIRST!” thinking. On the other hand, what happens at a “Compliance first!” organization? Specifically, what happens if such an organization rescans their PCI environment, right before planning to submit the report on compliance to their acquiring bank and then finds out that new vulnerabilities have recently been discovered in the software they use? Sadly, it is not uncommon that an organization will consider this situation to be the one where “somebody broke their compliance.” In fact, sentiment such as the following might well occur: “Why is this scan showing vulnerabilities if we were just about to report the success of our compliance project? Why are you breaking our hard-earned PCI compliance? How about we replace you with another product that just shows us compliant?” To summarize, it really doesn‟t matter how many times security experts pontificate about “security first!” If some organizations don‟t “get security” with all of its complexities and ignore it for years, “compliance first” becomes a real choice for them. At least they can understand it! And then later, “compliance first” becomes “compliance ONLY,” “checklists” replace “risk awareness,“ “flowcharts” replace thinking about their threats and vulnerabilities. What happens next? Obviously, they get hacked and have their credit card data stolen! And CNN writes a great inspirational story about them! To top it off, the PCI Council also fines them since they were NOT even compliant... At this moment, they suddenly get a security epiphany! As a result, making the choice “Security FIRST” or “Compliance FIRST” is not that hard. Still, if upon reading this, you excitedly choose „Compliance First!"‟, please at least make sure that “Security SECOND” happens. A useful reminder here would be that HMS “Titanic” (which, as we all know, sunk in 1912 upon colliding with an iceberg). It was reported that the ship “did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes in the size and design of ships of this kind. Those regulations indicated that all passenger ships over 10,000 tons required 16 life boats, and that‟s how many the Titanic had.” In other words, “Titanic” was compliant, a perfect example of “Compliance First!” As a result, security end up being very hard for an organization - and PCI compliance might not be easy either. Thus we need to think about how to make it easier for organizations to focus on getting compliant while improving their security. So, how does one make PCI compliance easier, while improving security in the process? Making PCI easier while also improving security will make lives of many IT security professionals easier as well. To start, let‟s recall that there were times when only an expert was able to perform a magic of a vulnerability scan. Today, nobody would argue that vulnerability management is much easier even though it cannot be said that “it became easy.” In any case, when people think about “making compliance easier” they often split into two groups. The first group would often ask to “make compliance easier” by letting them just “skip” the requirements. It is reported that sometimes they would be inclined to just say “Yes” on the self assessment questionnaire without thinking what is really involved in satisfying the requirements that it covers. The second broad group typically knows that their security program makes them PCI – compliant; they engage just to make it easier for them to prove it. As one can guess, the organizations that fit into group #1 and group #2 are very different: while some in group #1 might confuse a firewall with a fire extinguisher, the #2 group is often concerned with relating their “risk-focused” approach to PCI‟s mostly “control-focused” approach. Moreover, in group #1 people sometimes say things like “PCI is already easy; you just need to „get scanned‟ and answer „Yes‟ to a set of questions.” Still, it is possible to make PCI easier while focusing on security even for those who just “want it gone:” make doing the right thing (that leads to risk reduction) easier for them while making doing the wrong thing (that increases risk for their business) harder. On the other hand, while in group #2, one sometimes hears things like “we have a good security program and we manage our information risk well – why should we spend extra time on PCI? We are probably in a good shape already!” These organizations are likely doing a good job with security and want to use all that they do for security to quickly “prove compliance.” In this case, making PCI easier will include making it easier to assess, validate and prove compliance and overall make the whole “audit experience” a little less painful and less costly. And, it goes without saying, without sacrificing any of their hard-built security programs! To conclude, if you refuse to make an effort to understand information security and risk (despite all of the complexities), PCI compliance becomes a way to make certain decision to accept risks “illegal.” In other words, if you refuse to understand your risks and then to plan controls to address them, compliance becomes a “boilerplate” list of controls that you just have to do. Whatever your situation is, there are ways to compliance while building or preserving security: make proving compliance easier, make boring audit process simpler thus allowing more time for becoming more secure (but not “more secure than needed”), make choosing the right thing easier (and the wrong thing harder)… Even the choice between “Security First!” and “Compliance First!” becomes easier as a result. Myths of Security and Compliance Our first myth is: compliance is too hard. Sometimes it is also called too expensive, too complicated, too burdensome, just too much for a small business, too many technologies or even just “unreasonable.” The reality is that many regulations mandate common sense, baseline security practices, which every organization needs to take into account when planning their IT and business operations. Regulatory compliance, such as PCI DSS, only seems hard if you were not doing anything for security of your data before. Still, it might not be easy for a large, distributed organization, but it clearly much easier than creating and running a well-managed security program based on a good understanding of your risk. Still, you can make compliance harder for making the wrong decisions. For example, developing your own web application complete with credit card processing will increase your scope likely beyond your ability to handle. On the opposite, using a 3 rd party checkout service will do just the opposite and make both compliance and data security easier. The next myth seems mostly driven by the media: it claims that “Recent card data breaches prove compliance irrelevant.” I suspect it stems from the fact that reporting failures and other “bad stuff” typically draws more listeners, readers and watchers compared to reporting successes and thus attracts more media attention. However, it encourages some organizations to develop a negative mindset and thus to perform a bad job with compliance and data security and then suffer from a devastating data breach. Again, the reality is exactly the opposite: data breaches remind us that basic security, mandated by PCI DSS and other regulations, is necessary, not sufficient, but you have to start from the basics before you can advance in your security education. As you learn more about security, you usually come to realize that nothing guarantees breach free operation. Finally, one of my colleagues likes to say that every breach proves that compliance is even more necessary as a motivating force for security. For example, PCI DSS is a great start for security, but a really bad finish, as we discover in the next myth The next myth is probably the scariest one: compliance is all we ever need to do for security. People in the grasp of this myth would proclaim dangerous things such as: “We have PCI compliance handled - we are secure now” “We worked hard and we passed an „audit‟; now we are secure!” It often leads organizations to focus on “pleasing the assessor” and then forgetting that a happy assessor does not mean that your organization is protected from information risks. This myth is actually wrong on multiple levels! First, validating compliance via an assessment or self-assessment does not mean that you are done with compliance (since you now need to maintain it!) and it certainly does not mean that you are done with security. In addition, it doesn‟t mean that you are secure, just that you validated PCI compliance and hopefully made an honest step towards reducing your risk! The reality is again different. As we mention above, PCI DSS is basic security; it is a necessary baseline, a lower watermark, which was never meant to be the “end state” of guaranteed secure data. No external document, even well-written and followed with utmost diligence, can guarantee that, just as excellent police work can never guarantee “crime-free” environment. Finally, different regulation apply to protection of different data. HIPAA covers patient information, SOX covers financial record, which PCI is about cardholder data security. In particular, PCI does not touch the rest of your private or regulated information, not your organization intellectual property, not identity information such as SSNs, etc. It also covers confidentiality, and not availability of such data. Thus, you are certainly not “done with security” even if you maintain ongoing compliance with a particular regulation. For example, one of notable PCI QSAs likes to say that you likely need PCI+” or even “PCI++” to deal with risks to your data today. The next myth is the opposite: compliance is easy: we just have to make that auditor or assessor happy. As organization become more familiar with PCI DSS and other regulations, some start to feel that compliance is not that scary, because they succumb to misconceptions that “compliance=security.” A slightly simplified reality is that a typical small merchant which processes cards online would at least need to do the following: a) Get a network vulnerability scan of the external systems, resolve the vulnerabilities found and then rescan to verify that. b) Do the things that the self-assessment questions refer to and maintain evidence that they were performed; then answer the questions affirmatively c) Keep doing a) every quarter and b) every year until you no longer wish to accept credit cards. In other words, achieve compliance validation and then maintain compliance for as long as you plan to deal with payment card data. You can only answer „yes‟ if you have ground for saying „yes‟ on the questionnaire and can prove it, even with no auditors or acquiring banks looking over your shoulder. Final myth is simply a view that “Compliance Is Toothless.” This myth shows a completely wrong worldview of compliance and security; a dangerous delusion which is wrong on several levels. First, it embodies the view that data security can only happen due to regulatory pressure. This myth is often used to justify not doing anything about data security with examples like these: “Even if breached and also found non-compliant, our business will not suffer.” “We read that companies are breached and then continue being profitable; so why should we care?” Second, in addition to it being a wrong mindset, it is also simply wrong. Many regulations including PCI DSS pack a lot of bite which includes fines, possible lawsuits, mandatory breach disclosure costs, investigation costs, possible card processing rate increases, cost of additional security measures and cost of victim credit monitoring. Admittedly, not every breach will incur all of the above, but some are simply unavoidable. Overall, it is much more useful to think of customer and cardholder data protection as your “social responsibility” and not as something you do because of some scary “PCI teeth” somewhere! Conclusions What will happen with compliance and security in the near future? How will “Enterprise 2.0” deal with “Regulations 2.0?” In particular, what are some of the biggest security challenges for organizations using Enterprise 2.0 technologies such as web applications and web services, cloud computing and social networks. Security challenges start from a nearly complete diffusion of where your corporate data can reside (distributed storage), can be processed (outsourced processing) and can be "accidentally" found (that mobile device or a netbook). Next, let's now mix it with an amalgam of vertical, national and cross-border regulations, mandates and laws. Add a sprinkle of other new technologies, such as virtualization. Top off with ever-increasing cybercrime, spiced with a still-low chance of criminal prosecution and you get today's Security Challenge Cocktail! Will it get better? Only after it becomes worse-and only if you are an optimist. More over, these challenges are evolving rapidly and will continue to do so, possibly at an increasing rate. The key thing is that all the new challenges go on top of the old challenges, rather than replace them. This is scary. So, we used to think that custom malware, DDoS and insider attacks were bad; now we focus on so-called "web 2.0" threats and data loss and theft, but also have to continue focusing on the threats that were "hot" in the past decade; none really went away. I was thinking about it and I wanted to name one BIG information security problem that has actually been "solved" or at least effectively "dealt with"-and failed to do so. Even something as simple as spam isn't really solved, but mitigated. What complicates this is that the traditional view of security as “castle defense” is as good as gone. In the near future, many organizations will have no idea whatsoever where their data is. On top of that, you have no idea where your regulated and sensitive data is. You have no idea how it is protected (if it is protected at all) wherever it is located or passing. And, technically, you are still on the hook for complying with regulations concerning that data, despite the fact that you have no idea where it is. As problems go on top of other problems, so do the tools that help solve the problems. Do not believe those who say that "firewalls are useless" or "anti-virus is dead." They still solve old problems that still need to be solved, plus some of the tools found new uses. For example, you used to think that a firewall blocks access from the untrusted Internet to your network-and that is still somewhat true. However, now firewall also helps you block attempts to extrude the data from your network by blocking suspicious connections from the inside to outside. Among newer tools, log management and security information management, data loss prevention (DLP) and web application security scanning are rapidly gaining ground as useful for dealing with today's challenges. Finally, what is the best way to survive this epic battle with new threats, new regulations and new technology. One way is: "Drop that data!" Accept that you have failed to protect the data and stop obsessing about doing it. Choose to change your business process (whether via cloud computing or outsourcing or whatever) in such a way that reduces (or, ideally, eliminates) the spread of sensitive data to remote offices, laptops, mobile devices, untrusted partner systems, etc. For example, when reading about recent data breaches and losses, I always wonder, "Why did that lost laptop contain the social security numbers of 200,000 people? What was their security team thinking?" Eliminate the data if you cannot adequately protect it. It is not easy, for sure, but you already know that protecting the data spread across your whole network and a set of other networks and the Internet is impossible... ABOUT THE AUTHOR: This is an updated author bio, added to the paper at the time of reposting in 2011. Dr. Anton Chuvakin (www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. Anton leads his security consulting practice www.securitywarriorconsulting.com, focusing on logging, SIEM, security strategy and compliance for security vendors and Fortune 500 organizations. He is an author of books "Security Warrior" and "PCI Compliance" (www.pcicompliancebook.info) and a contributor to "Know Your Enemy II", "Information Security Management Handbook"; and now working on a book about system logs. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org). His blog www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes (including his own SANS class on log management) and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on advisory boards of several security start-ups. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.