Research

It’s no secret that we are currently working on a new software platform to deliver actionable security research to a broader market, engage folks, and… umm… feed our families. As you might expect, like any software project, it’s running about 30% late and 70% over budget. I just can’t seem to stop making our developers find exactly the right imagery and user experience to best represent the Securosis brand. Mike has coined a new term, ‘analness’, to describe the gyrations we’ve gone through, but I’m okay with that because we have spent years building our reputation and aren’t about to roll out a huge steaming pile of crap just to hit a delivery date. As we close in on the finish line, we faced a huge decision on how to host this. Our current provider is pretty good, but we ran into some issues earlier this year that prompted us to look at alternatives. And we are co-hosted, which won’t work once we start loading sensitive content into a paid service. So we began the long evaluation process of picking the right architecture and host. Well, that and satisfying our paranoia regarding site security. Despite being heavy cloud folks, we eventually decided on a dedicated server model offered by a specialized hosting company. Yes, we understand that’s probably counterintuitive, so here’s why we didn’t go that way. Co-hosting and VPS For the most part our current site is totally fine with our current load, and our hosting provider is a lot more security-conscious than most. I launched securosis.com as a blog over at Bluehost, on a WordPress co-host. It worked totally fine, but as we started expanding it was clear that platform couldn’t meet our growing needs. We decided to switch to a better content management system (ExpressionEngine), and while we could technically run it there, we decided to go with a more specialized provider (enginehosting.com). We have been mostly happy with the change, even though EH is considerably more expensive, because we get a lot more for what we pay. They also have excellent growth options to expand to a Virtual Private Server or even dedicated boxes if needed. But it’s still a co-host model. The one problem we hit earlier this year appeared after a major platform upgrade. Our back end became nearly unusable due to performance problems, and when I submitted a support request they kept blaming our configuration or plugins. We are big boys, and willing to accept when we screw up. We turned our system upside down and couldn’t find anything that would kill the performance of the admin console. As it turned out we were right. Another client in our cluster over-used resources – as I had initially suggested. We were bothered by their lack of investigation, and by the (realized) potential for another customer to impact us. That convinced us we need to get off co-hosting, and into VPS or cloud. We also had to factor in all the security reasons to drop a co-hosted model once we have content we want to protect. VPS vs. Cloud We quickly ruled out VPS. As our knowledge and experience working with various cloud services grew, we saw no reason to pick VPS over a pure cloud model. To be honest, while I see co-hosting surviving for a while, I definitely see the allure of VPS cratering in the next few years, as customers keep comparing VPS offerings against the rapidly evolving public cloud offerings. I decided we would go completely cloud. Aside from the lack of advantages to VPS, we were conscious of the importance of eating our own dogfood, now that we are working so deeply with the Cloud Security Alliance and advising people on cloud projects. Our criteria for a cloud provider including a security conscious shop, judged on both what they publish and checks with various industry connections. We wanted some IPS/firewall and patch management support options to improve our baseline security and reduce our management overhead. As our IT guy, I simply don’t have the time to manage all our patches/fixes myself. If I were caught on an international flight when we needed to block and fix a critical 0day, we could be screwed. That was unacceptable. Other factors included our plan to use a cloud-based WAF. Not that it could block everything, but the combination of blocking basic scans and providing better analytics was attractive. We also factored in performance, as we know our potential audience is self-limiting, and what we are delivering isn’t very CPU intensive. We need a little beef, and more importantly the capability to grow, but we couldn’t forsee a need for anything too crazy. It’s not like we are Netflix or anything (yet). So there we were – I thought we were all set, until… From Cloud to Dedicated I wasn’t fully satisfied with the options I found (all of which cost a heck of a lot more than a basic AWS deployment), but I felt confident that we could get what we need at a reasonable price. Then we mentioned what we were doing to a trusted friends in the industry. For now I won’t mention who we are working with, but someone we highly respect offers dedicated hosting in a special section of a major data center they lease (their own cage). I am not sure they expected us to take them up on the offer. It’s not like they were soliciting our business – this came up over beer. These folks are as paranoid as we are (maybe more), and aside from hosting the site they will implement some stringent and unusual security controls we couldn’t possibly get anywhere else for any reasonable price. Normally they don’t use this model even with their existing clients, and we are going to be their first test case beyond internal infrastructure. As a bonus, their data center guarantees 100% infrastructure uptime. In writing. (Note: this doesn’t mean our boxes, just their network and power). Trusted

I love it when people froth at the mouth once they finally realize the blazingly obvious! For today’s example let’s look at the big Dropbox data privacy controversy. There are a few serious problems with Dropbox, such as not requiring a password after a host is added, making it super easy for someone to pretend to be you (if they get your host ID) and access your data. That’s not great, but there are far worse things out there I worry about. But the big controversy is that… ghasp… Dropbox employees could access your data! But if you know anything about security you know that if you get a nice, pretty web interface; then somewhere, somehow, the odds are an admin at the service provider can access your data. There are techniques around this using creative programming, but one look at the Dropbox code in your browser makes it clear they aren’t using anything like that. This is because the Dropbox web servers need to see your data to show you the web interface. Ergo, the servers can decrypt your data. Ergo, someone at Dropbox can see it. Now this doesn’t need to be true – they could have restricted the web UI to metadata and still encrypted file contents, then used a browser plugin (or maybe even JavaScript) to decrypt the files. But both options entail usability and security tradeoffs. A great example of how to manage issues like these is the CrashPlan backup service. CrashPlan offers a cascade of security options, each with usability tradeoffs, and all available to users. (All these options protect your symmetric encryption key, not the data itself): Protect with your account password. CrashPlan can access and see your data if needed. Protect with a separate data password stored locally. CrashPlan admins can’t access your data (even to restore it). You need to keep and secure an extra password. Set your own encryption key. Can be on a per-machine basis. Very secure, requiring more management. There is, of course, much more to their encryption scheme – this is just the user-controllable portion. Dropbox could do something similar: Standard (perhaps the only option on their free plan): Basic account username/password as they have now. Enhanced Security: Set a personal password, with metadata in the clear. You can manipulate your files, but they can only be downloaded by the local agent (not via a browser) and you need to remember the password (no password restore capability). You can still share public files, which are stored in a separate directory using your account password as on the old system. High Security: Metadata and file data encrypted using your personal passphrase, separate from your account passphrase. Web UI can only manage public files – everything else is accessible only through their client. These would require serious development effort, and I don’t want to gloss over the complexity or importance of implementing this type of security correctly and safely. This stuff is hard. But it would be manageable if they made it a priority. But seriously, people – if you want something free/cheap with a pretty web interface to manage your data, odds are you are trading off security. I use Dropbox extensively and just encrypt the things I consider too private to expose. Share:

Today Verizon released the 2011 Data Breach Investigations Report: our single best source of actual incident data in the security industry, based on comprehensive metrics gathered during hundreds of incident investigations. In the coming weeks there won’t be any shortage of stories on, and analysis of, the DBIR. Rather than rehashing all the talking points we expect other sources to cover well, we will instead focus on actionable guidance based on the report. We will focus on how to read the DBIR, what it teaches us, and how should it change what you do. How to read the DBIR With so much data it’s all too easy to get lost in the numbers. It’s also very easy to lose context and misinterpret what’s in there. First let’s cover the four most important trends: The industrialization of attacks: There is an industry encompassing many actors, from coders to attackers to money launderers. They use automated tools and manage themselves and their operations as businesses – including use of independent contractors. Like any other business, these folks want to maximize profits and minimize risk, and the results of the 2011 DBIR show their work towards these goals – especially compared with the 2009 and 2010 DBIRs. Financial attacks focused on leveraged activities such as credit card skimming, point of sale attacks, and ACH fraud: This ties in with the first point: instead of spending massive resources for high risk/high gain (Gonzalez-style attacks), attackers are hammering the financial system’s weak points with significant automation to broaden scope and expand their scale. All forms of attack are up by all threat actors: If someone writes (or tweets) that APT is a myth or IP loss isn’t a problem based on this report, kick them in the nuts. Hard. Twice. Law enforcement really does catch some of the bad guys: 1,200 arrests over the past several years by the Secret Service alone. Many of these bad guys/gals attack small business. We could use more, given the scale of the problem, but law enforcement is having an impact. I will add my own interpretation, which I have separated from the direct DBIR trends: Successful financial attacks (more often than not) target smaller organizations, whereas complex IP (intellectual property) attacks focus (more often than not) on larger or specialized organizations. So for the first time we see a type of market segmentation by attackers. Using automated systems against weak targets and riding the associated economies of scale can be very lucrative, and it’s not surprising to see these targets multiply. But that doesn’t mean bigger companies, more sophisticated about security, are in the clear. We also see an increase in sophisticated attacks focusing on IP, although these numbers are not as obvious in the DBIR data. And now highlights and where to focus your reading, in no particular order: There was a large increase in the number of incidents investigated in 2010. Even accounting for sampling bias, this is still significant. 141 breaches were evaluated in 2009, and 761 in 2010. Yes, sports fans, that’s a 5x multiple. Such a massive increase skews the trend data, so you need to understand that percentage increases and decreases may obscure important information. For example, there was a significant decline in the percentage of attacks involving SQL injection, yet the actual quantity of reported SQL injection attacks actually increased dramatically. There are more small and medium businesses in the world than large ones. So we should see more attacks against them, and the data skews in that direction this year. As stated clearly in the report and in our briefing, the increased number of incidents is mostly due to massive growth in two attack forms: compromise of remote management tools for point of sale (POS) systems in hospitality and retail, and ATM and credit card skimmers (including employees using handheld skimmers). This data came from the Secret Service and we don’t know if it is means the bad guys have found a new focus, or the Secret Service is paying more attention to these attacks. Either way, the increase is significant. Anecdotal evidence from other sources does seem to indicate attackers are increasingly focused on these areas, especially against smaller companies and outlets. Most of the headlines will focus on the massive drop in lost records from 361 million in 2008, to 144 million in 2009, to 4 million in 2010. You should mostly ignore this. The large numbers were highly likely due to a small number of incidents involving massive quantities of records. As the DBIR itself states, Albert Gonzales alone was responsible for tens (possibly hundreds) of millions of records lost over this time period. Pull out those few distorting large campaigns, and the general trend in lost records evens out. The trend shows more bad guys hitting smaller targets. Your risk of being attacked successfully is greater if you are in a targeted industry, such as hospitality and retail. Each incidence of lost intellectual property was typically counted as a single lost record. So IP theft is inherently ranked much lower in studies like the DBIR than credit card breaches, which always involve more records per incident. But the F-14’s avionics schematics probably command a slightly higher value than a single credit card… The VERIS framework used to collect the data uses a multiple-select system. So if 5 attack methods were used in an single attack, each method is counted. They try to make this clear in the report and don’t misinterpret these findings like most of the armchair analysts (including vendors pushing their own agendas) probably will. For example, SQL injection dropped considerably as an overall percentage of attacks… but if you normalize the data to factor in the large number of skimmers and remote management breaches, injection probably climbs back to the top 3. Figure 6 on page 15 is the most important in the entire report. It shows that most attacks involve hacking and malware against user devices. Network sniffing is barely a blip. Physical attacks are also a major vector (mostly skimming, according to our briefing and the report), but

So you have defined your peer groups and analysis and spent a bunch of time communicating what you found to your security program’s key stakeholders. Now it’s time to shift focus internally. One of the cool things about security metrics and benchmarks is the ability to analyze trends over time and use that data to track progress against your key goals. Imagine that – managing people and programs based on data, not just gut feel. Besides being able to communicate much more authoritatively how you are doing on security, you can also focus on continuously improving your activities. This is a good thing to do – particularly if you want to keep your job. We will harp on the importance of consistency in gathering data and benchmarks over a long period of time, and then getting sustained value from the benchmark by using it to mark progress toward a better and more secure environment. Programs and feedback loops We don’t want to put the cart ahead of the horse, so let’s start at a high level, with describing how to structure the security program so it’s focused on improvement rather than mere survival. Here are the key steps: Define success (and get buy-in up the management stack) Distill success characteristics into activities that will result in success Quantify those activities, determine appropriate metrics, and set goals for those metrics Set objectives for each activity and communicate those objectives Run your business; gather your metrics Analyze metrics; report against success criteria/objectives Identify gaps, address issues, and reset objectives accordingly Wash, rinse, repeat Digging deeply into security program design and operation would be out of scope, so we’ll just refer you to Mike’s methodology on building a security program: The Pragmatic CSO. Communicating to the troops In our last post, on Benchmarking Communication Strategies, we talked about communicating with key stakeholders in the security process, and a primary constituency is your security team. Let’s revisit that discussion and its importance. Your security team needs to understand the process, how benchmark data will be used to determine success, and what the expectations will be. Don’t be surprised to experience some push-back on this new world order, and it could be quite significant. Just put yourself in your team’s shoes for a moment. For most of these folks’ careers they have been evaluated on a squishy subjective assessment of effectiveness and effort. Now you want to move them to something more quantified, where they can neither run nor hide. Top performers should not be worried – at all. That’s a key point to get across. So exercise some patience in getting folks heads in the right spot, but remember that you aren’t negotiating here. Part of the justification for investing (rather significantly) in metrics and benchmarks is to leverage that data in operations. You can’t do that if the data isn’t used to evaluate performance – both good and bad. It’s not a tool, it’s a lifestyle Another point to keep in mind is that this initiative isn’t a one-time thing. It’s not something you do for an assessment, and then forget it in a drawer the moment the auditor leaves the building. Benchmarking, done well, becomes a key facet of managing your security program. This data becomes your North Star, providing a way to map out objectives and ensure you stay on course to reach them. We have seen organizations start with metrics as a means to an end, and later recognize that they can change everything about how operational efforts are managed, perceived, and supported within the organization. The lack of security data has hindered acceptance of benchmarking in the security field, but it’s time to revisit that. As per usual, there are some caveats to data-driven management. No one size fits all. We see plenty of cultural variation, which may require you to take a less direct path to the benchmark promised land. But there can be no question about the effectiveness of quantifying activity, compared to not quantifying it. If you have gotten this far, successfully implemented this kind of benchmark, and institutionalized it as a management tool, you are way ahead of the game. But what’s next? Digging into deeper and more granular metrics, such as the metrics we defined as part of our Project Quant research. So we will discuss that next. Share:

It’s tax day. You don’t have time to read this. I don’t have time to write it. Actually, my accountant is taking care of my taxes (I don’t trust myself with them). What’s really sucking down my time is preparing all the hands-on portions of the Cloud Security Alliance training. For the second time. We decided to split the class into two days, which means I have the opportunity to both tune the material and add new material. The cloud security portions of this are actually pretty straightforward – the harder part is scripting all the instances and configurations to focus the students on the important security bits without them having to learn things like MySQL, UNIX command lines (since, you know, auditor types will be in the class) and so on. That means I get to figure out all the scripting. Which isn’t a big deal, except I’m working with programs I don’t really deal with on a day to day basis. So there’s a lot of learning involved, and things that used to be instinctive when I was working as an admin now involve multiple web searches and mistakes to get correct. And little things like figuring out the mechanics of running a private cloud for 40 students on a single laptop and still providing some hands-on, as opposed to just an instructor demo. But I’m loving it. So go away and do your taxes. I need to play. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading post on Cloud DB Security. Rich and Adrian quoted on our DBQuant press release. The Network Security Podcast, episode 237. Favorite Securosis Posts Adrian Lane: Database Trends. Mike Rothman: Our insanely comprehensive database security framework. No one else does this kind of research. It’s awesome to see it in its entirety. And we provide it at no cost. You’re welcome. David Mortman: Database Trends. Rich: Software vs. Appliance: Understanding DAM Deployment Tradeoffs. Other Securosis Posts Security Benchmarking, Going Beyond Metrics: Defining Peer Groups and Analyzing Data. Security Benchmarking, Going Beyond Metrics: Communications Strategies. Incite 4/13/2011: Jonesing for Air. Favorite Outside Posts Mike Rothman: Security vendors should face the music, even if they hate the tune. Bill Brenner nails it. Even when a review goes south, there are ways to handle it. Scorched earth on a well-respected testing house isn’t a winning strategy. David Mortman: How Dropbox sacrifices user privacy for cost savings. reppep: Cloud validation: 8 hours of 10,000-core computation for $8k. Okay, it’s still not for everybody, but this demonstrates that “cloud computing” does have a point. Adrian Lane: Russian Security Service proposes ban on Gmail, Skype, Hotmail. Skype a threat to National Security? Government’s the same all over. Research Reports and Presentations Measuring and Optimizing Database Security Operations (DBQuant). Woo hoo!!! Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Top News and Posts Veris Community Project Update The Web’s Trust Issues. Private records of 3.5 million people exposed by Texas. Hack attack spills web security firm’s confidential data. Adobe to Patch Flash Zero Day on Windows, Mac on Friday. DOJ Shuts Down Botnet, Disables Infected Systems Share:

Some projects take us a few days. Others? More like 18 months. Back before Mike even joined us, Adrian and I started a ‘quick’ project to develop a basic set of metrics for database security programs. As with most of our Project Quant efforts, we quickly realized there wasn’t even a starting framework out there, never mind any metrics. We needed to create a process for every database security task before we could define where people spent their time and money. Over the next year and a half we posted, reposted, designed, redesigned, and finally produced a framework we are pretty darn proud of. To our knowledge this is the most comprehensive database security program framework out there. From developing policies, to patch management, to security assessments, to activity monitoring, we cover all the major database security activities. We have structured this with a modular set of processes and subprocesses, with metrics to measure key costs at each step. The combination of process framework and metrics should give you some good ideas for structuring, improving, and optimizing your own program. Here’s the permanent home for the report, where you can post feedback and which will include update notices: Measuring and Optimizing Database Security Operations (DBQuant). We broke this into an Executive Summary that focuses on the process, and the full report with everything: Executive Summary. (PDF) The Full Report. (PDF) Special thanks to Application Security Inc. for sponsoring the report, and sticking with us as we pretended to be PhD candidates and dragged this puppy out. Share:

I have always believed that security – both physical and digital – is a self-correcting system. No one wants to invest any more into security than they need to. Locks, passwords, firewalls, well-armed ninja – they all take money, time, and effort we’d rather spend getting our jobs done, with our families, or on personal pursuits. Only the security geeks and the paranoid actually enjoy spending on security. So the world only invests the minimum needed to keep things (mostly) humming. Then, when things get really bad, the balance shifts and security moves back up the list. Not forever, not necessarily in the right order, and not usually to the top, but far enough that the system corrects itself enough to get back to business as usual. Or, far more frequently, until people perceive that the system has corrected itself – even if the cancer at the center merely moves or hides. Security never wins or loses – it merely moves up or down relative to an arbitrary line we call ‘acceptable’. Usually just below, and sometimes far below. We never fail as a whole – but sometimes we don’t succeed as well as we should in that moment. Over the past year we have gotten increasing visibility into a rash of breaches and incidents that have actually been going on for at least 5 years. From RSA and Comodo, to Epsilon, Nasdaq, and WikiLeaks. Everyone – from major governments, to trading platforms, to banks, to security companies, to grandma – has made the press. Google, Facebook, NASA, and HBGary Federal. We are besieged from China, Eastern Europe, and Anonymous mid-life men pretending to be teenage girls on 4chan. So we need to ask ourselves: Now what? The essential question we as security professionals need to ask is: is the quantum dot on the wave function of security deviating far enough from acceptable that we can institute the next round of changes? We know we can do more, and security professionals always believe we should do more, but does the world want us to do more? Will they let us? Because this is not a decision we ever get to make ourselves. The first big wave in modern IT security hit with LOVELETTER, Code Red, and Slammer. Forget the occasional website defacement – it was mass malware, and the resulting large-scale email and web outages, that drove our multi-billion-dollar addiction to firewalls and antivirus. Up and down the ride we started. The last time we were in a similar position was right around the time many of the current trends originated. Thanks to California SB1386, ChoicePoint became the first company to disclose a major breach back in 2005. This was followed by a rash of organizations suddenly losing laptops and backup tapes, and the occasional major breach credited to Albert Gonzales. PCI deadlines hit, HIPAA made a big splash (in vendor presentations), and the defense industry started quietly realizing they might be in a wee bit of trouble as those in the know noticed things like plans for top secret weapons and components leaking out. And there were many annual predictions that this year we’d see the big SCADA hack. The combined result was a more than incremental improvement in security. And a more than incremental increase in the capabilities of the bad guys. Never underestimate the work ethic of someone too lazy to get a legitimate job. In the midst of the current public rash of incidents, we have also seen far more than an incremental increase in the cost and complexity of the tools we use – not that they necessarily deliver commensurate value. And everyone still rotates user passwords every 90 days, without one iota of proof that any of the current breaches would have been stymied if someone had added another ! to the end of their kid’s birthday. 89 days ago. Are we deep into the next valley? Have things swung so far from acceptable that it will shift the market and our focus? My gut suspicion is that we are close, but the present is unevenly distributed — never mind the future. Share:

The objective of the Quick Wins process is to get results and show value as quickly as possible, while setting yourself up for long-term success. Quick Wins for DLP Light is related to the Quick Wins for DLP process, but heavily modified to deal both with the technical differences and the different organizational goals we see in DLP Light projects. Keep this process in perspective – many of you will already be pretty far down your DLP Light path and might not need all these steps. Take what you need and ignore the rest. Prepare There are two preparatory steps before kicking off the project: Establish Your Process Nearly every DLP customer we talk with discovers actionable offenses committed by employees as soon as they turn the tool on. Some of these require little more than contacting a business unit to change a bad process, but quite a few result in security guards escorting people out of the building, or even legal action. Even if you aren’t planning on moving straight to enforcement mode, you need a process in place to manage the issues that will crop up once you activate your tool. You should set up two different processes to handle the three common incident categories: Business Process Failures: DLP violations often result from poor business processes, such as retaining sensitive customer data and emailing unencrypted healthcare information to insurance providers. This process is about working with the business unit to fix the problem. Employee Violations: These are often accidental, but most DLP deployments result in identification of some malicious activity. Your process should focus on education to avoid future accidents; as well as working with business unit managers, HR, and legal to handle malicious activity. Security Incidents: Traditional security incidents, usually from an external source, which require response and investigation. Determine Existing DLP Capabilities The next step is to determine which DLP Light capabilities you have in-house, even if the project is driven by a particular tool. You might find you already have more capability than you realize. Check for existing DLP features in the main technology areas covered in our last post. It’s also worth reviewing whether you are current on product versions, as DLP features might be cheap or even free if you upgrade (discounting upgrade costs, of course). Build a list of the DLP Light tools and features you have available, with the following information: The tool/feature Where it’s deployed Protected “channels”: Network protocols, storage locations, endpoints, etc. Content analysis capabilities/categories Workflow capabilities: DLP-specific vs. general-purpose; ability to integrate with SIEM and other management tools This shouldn’t take long and will help you choose the best path for implementation. Determine Objective The next step is to determine your goal. Are you more concerned with protecting a specific type of data? Or do you want to look more broadly at overall information usage? While the full-DLP Quick Wins process is always focused on information gathering vs. enforcement, this isn’t necessarily the case in a DLP Light project. No matter you specific motivation, we find that individual projects then sift into three main categories: Focused Monitoring: The goal is to track usage of, and generate alerts on, a specific kind of information. This is most often credit card numbers, healthcare data, or other personally identifiable information. Focused Enforcement: You concentrate on the same limited data types as above, but instead of merely alerting you plan to enforce policies and block activity. General Information Gathering: Rather than focusing on a single type of data, you use tools to get a better sense of information usage throughout the organization. You turn on as many policies to monitor information of interest as possible. Choose Deployment Type This is a three-step process for making the final decisions required to deploy: Map desired coverage channels: Determine where you want to monitor and/or enforce – email, endpoints (USB), etc. List every place you want to cover vs. what you know you already can cover with your existing capabilities. This also needs to map to your objective, and content analysis requirements. Match desired to existing coverage: Now figure out what you have and where the gaps are. Fill the gaps: Obtain any additional products or licenses so that your project can meet your objectives. Your entire project might be as simple as, “we want to catch credit card numbers in email using our existing tool”, in which case this entire process up to now probably took about 10 seconds. But if you need a little more guidance, this will help. Implement and Monitor Now it’s time to integrate the product (if needed), turn it on, and collect results. The steps are: Select content analysis policies: For a focused deployment, this will only include the policy that targets the specific data you want to protect, although if you use multiple products that aren’t integrated you will use the most appropriate policies in each tool. For a general deployment you turn on every policy of interest (without wrecking performance – check with your vendor). Install (if needed) Integrate with other tools/workflow: If you need to integrate multiple components, or with a central workflow or incident management tool, do that now. Turn on monitoring We have a few hints to improve your chance of success: Don’t enable enforcement yet – even if enforcement is your immediate goal, start with monitoring. Understand how the tool will can impact workflow first, as we will discuss next. Don’t try to handle every incident at first. You will likely need to tune policies and educate users over time before you have the capacity to handle every incident – depending on your focus. Handle the most egregious events now and accept that you will handle the rest later. Leverage user education. Users often don’t know they are violating policies. One excellent way to reduce your incident volume is to send them automated notifications based on policy violations. This has the added advantage of helping you identify the egregious violators later on. Analyze At this point you have focused your project, picked your tools, set your policies, and started monitoring. Now it’s

DLP Light tools cover a wide range of technologies, architectures, and integration points. We can’t highlight them all, so here are the core features and common architectures. We have organized them by key features and deployment location (network, endpoint, etc.): Content Analysis and Workflow Content analysis support is the single defining element for Data Loss Prevention – “Light” or otherwise. Without content analysis we don’t consider a tool or feature DLP, even if it helps to “prevent data loss”. Most DLP Light tools start with some form of rule/pattern matching – usually regular expressions, often with some additional contextual analysis. This base feature covers everything from keywords to credit card numbers. Most customers don’t want to build their own rules, so the tools come with pre-built policies, which are sometimes updated as part of a maintenance contract or license renewal. The most common policies identify credit card data for PCI compliance, because that drives a large portion of the market. We also see plenty of PII detection, followed by healthcare/HIPAA data discovery – both to meet clear compliance requirements. DLP Light tools and features may or may not have their own workflow engine and user interface for managing incidents. Most don’t provide dedicated workflow for DLP, instead integrating policy alerts into whatever existing console and workflow the tool uses for its primary function. This isn’t necessarily better or worse – it depends on your requirements. Network Features and Integration DLP features are increasingly integrated into existing network security tools, especially email security gateways. The most common examples are: Email Security Gateways: These were the first non-DLP tools to include content analysis, and tend to offer the broadest policy/category coverage. Many of you already deploy some level of content-based email filtering. Email gateways are also one of the main integration points with full DLP solutions: all the policies and workflow are managed on the DLP side, but analysis and enforcement are integrated with the gateway directly rather than requiring a separate mail hop. Depending on your specific tool, internal email may or may not be covered. Web Security Gateways: Some web gateways now directly enforce DLP policies on the content they proxy, for example preventing files with credit card numbers from being uploaded to webmail and social networking services. Web proxies are the second most common integration point for DLP solutions because, as we described in the Technical Architecture section, they proxy web and FTP traffic and make a perfect filtering and enforcement point. These are also the tools you will use to reverse proxy SSL connections to monitor those encrypted communications, which is a necessity for scanning and blocking inbound malicious content. Unified Threat Management: UTMs provide broad network security coverage, including at least firewall and IPS capabilities, but also usually web filtering, an email security gateway, remote access, and web content filtering (antivirus). These provide a natural location for adding network DLP coverage. Intrusion Detection and Prevention Systems: IDS/IPS tools already perform content inspection, and so are a natural location for additional DLP analysis. This is usually basic analysis integrated into existing policy sets, rather than a new full content analysis engine. SIEM and Log Management: All major SIEM tools can accept alerts from DLP solutions, and many can correlate them with other collected activity. Some SIEM tools also offer DLP features, depending on what kinds of activity they can collect for content analysis. We have placed this in the network section because that’s what they most commonly integrate with, but they can also work with other DLP deployment locations. Log management tools tend to be more passive, but increasingly include some basic DLP-like features for analyzing data. Endpoint Features and Integration DLP features have appeared in various endpoint tools aside from dedicated DLP products since practically before there was a DLP market. This presence continues to expand, especially as interest grows in controlling USB usage without unacceptable business impact. Endpoint Protection Platforms: EPP is the term for comprehensive endpoint suites that start with anti-virus, and may also include portable device control, intrusion prevention, anti-spam, remote access, Network Admission Control, application whitelisting, etc. Many EPP vendors have added basic DLP features – most often for monitoring local files or storage transfers of sensitive information, and some with support for network monitoring and enforcement. USB/Portable Device Control: Some of these tools offer basic DLP capabilities, and we are seeing others evolve to offer somewhat extensive endpoint DLP coverage – with multiple detection techniques, multivariate policies, and even dedicated workflow. When evaluating this option, keep in mind that some tools position themselves as offering DLP capabilities but lack any content analysis – instead relying on metadata or other context. ‘Non-Antivirus’ EPP: Some endpoint security platforms are dedicated to more than just portable device control, but are not designed around antivirus like other EPP tools. This category covers a range of tools, but the features offered are generally comparable to other offerings. Overall, most people deploying DLP features on an endpoint (without a dedicated DLP solution) are focused on scanning the local hard drive and/or monitoring/filtering file transfers to portable storage. But as we described earlier you might also see anything from network filtering to application control integrated into endpoint tools. Storage Features and Integration We don’t see nearly as much DLP Light in storage as in networking and endpoints – in large part because there aren’t as many clear security integration points. Fewer organizations have any sort of storage security monitoring, whereas nearly every organization performs network and endpoint monitoring of some sort. But while we see less DLP Light, as we have already discussed, we see extensive integration on the DLP side for different types of storage repositories. Database Activity Monitoring and Vulnerability Assessment: DAM products, many of which now include or integrate with Database Vulnerability Assessment tools, now sometimes include content analysis capabilities. Vulnerability Assessment: Some vulnerability assessment tools can scan for basic DLP policy violations if they include the ability to passively monitor network traffic or scan storage. Content Classification, Forensics, and Electronic Discovery: These tools aren’t dedicated to

Okay folks – raise your hands for this one. How many of you get an obvious spam message from a friend or family member on a weekly basis? For me it’s more like monthly, but it sure is annoying. The problem is that when I get these things I have a tendency to try and run them down to figure out exactly what was compromised. Do the headers show it came from their computer? Or maybe their web-based email account? Or is it just random spoofing from a botnet… which could mean any sort of compromise? Then, assuming I can even figure that part out, I email or call them up to let them know they’ve been hacked. Which instantly turns me into their tech support. This is when things start to suck. Because, for the average person, there isn’t much they can do. They expect their antivirus to work and the initial reaction is usually “I ran a scan and it says I’m clean”. Then I have to tell them that AV doesn’t always work. Which goes over great, as they tell me how much they spent on it. Depending on what I can pick up from the email headers we then get to cover the finer points of changing webmail passwords, checking for silent forwards, and setting recovery accounts. Or maybe I tell them their computer is owned for sure and they need to nuke it from orbit (backup data, wipe it, reinstall, scan data, restore data). None of that is remotely possible for most people, which means they may have to spend more than their PoS is worth paying the Geek Squad to come out, steal their drunken naked pictures, and lose the rest of their data. After which I might still get spam, if the attacker sniffed their address book and shoveled onto some zombie PC(s). Or they ignore me. I had a lawyer friend do that once. On a computer used sometimes for work email. Sigh. There’s really no good answer unless you have a ton of spare time to spend hunting down the compromise… which technically might not be them anyway (no need to send the spam from the person you compromised if another name in the social network might also do the trick). For immediate family I will go fairly deep to run things down (including getting support from vendor friends on occasion), but I have trained most of them. For everyone else? I limit myself to a notification and some basic advice. Then I add them to my spam filter list, because as long as they can still read email and access Facebook they don’t really care. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike quoted on metrics in Dark Reading. Adrian quoted in ComputerWorld on McAfee’s acquisition of Sentrigo. Favorite Securosis Posts Rich: PROREALITY: Security is rarely a differentiator. There’s a bare minimum line you need to keep customer trust. Anything more than that rarely matters. Adrian Lane: Captain Obvious Speaks: You Need Layers. Mike Rothman: File Activity Monitoring: Index. You’ll be hearing a lot about FAM in the near future. And you heard it here first. Other Securosis Posts White Paper: Network Security in the Age of Any Computing. Incite 3/30/2011: The Silent Clipper. Comments on Ponemon’s “What Auditors think about Crypto”. Quick Wins with DLP Light. FAM: Policy Creation, Workflow, and Reporting. FAM: Selection Process. Security Benchmarking, Going Beyond Metrics: Introduction. Security Benchmarking, Going Beyond Metrics: Security Metrics (from 40,000 feet). Favorite Outside Posts Rich: Errata Security: “Cybersecurity” and “hacker”: I’m taking them back. If I try to describe what I do (security analyst) they think I’m from Wall St. If I say “cybersecurity analyst” they get it right away. To be honest, I really don’t know why people in the industry hate “cyber”. You dislike Neuromancer or something? Adrian Lane: The 93,000 Firewall Rule Problem. Mike Rothman: The New Corporate Perimeter. If you missed this one, read it. Now. GP is way ahead on thinking about how security architecture must evolve in this mobile/cloud reality. The world is changing, folks – disregard it and I’ve got a front end processor to sell you. Rich: BONUS LINK: The writing process. Oh my. Oh my my my. If you ever write on deadline and word count, you need to read this. Research Reports and Presentations Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Top News and Posts European Parliament computer network breached. BP loses laptop with private info on 13,000 people. BP Spills Data Too. The DataLossDB project welcomes Dissent! As we mentioned in the intro, you should support this project. GoGrid Security Breach. Restaurant chain fined under Mass privacy law. Mass SQL Injection Attack. NSA Investigates NASDAQ Hack. Dozens of exploits released for popular SCADA programs. Twitter, JavaScript Defeat NYT’s $40m Paywall. Blog Comment of the Week For the past couple years we’ve been donating to Hackers for Charity, but in honor of Dissent joining the DataLossDB project we are directing this week’s donation ($100) to The Open Security Foundation. This week’s best comment goes to SomeSecGuy, in response to PROREALITY: Security is rarely a differentiator. TJ Maxx’s revenues went UP after their big breach. What mattered more to its customers than security? A good deal on clothes, I guess. There probably is a market segment that cares more about security than other factors but I don’t know what it is. Price is typically the primary driver even for business decisions. Share: