Research

First, for our non-technical readers who want to know more about this Firesheep/sidejacking thing, check out my relatively non-geeky article over at TidBITS. After that, George Ou put together a great sidejacking security scorecard for a double fistful of major online services. He rates each site’s risk across their various services for full hijacking and full and partial sidejacking. Needless to say, very few services fare well. Being a Mac geek, one service not mentioned is Apple’s MobileMe. I did some poking myself, and MobileMe both uses full-session SSL for all sessions, and sets a secure credential cookie so it won’t pass over basic HTTP. Also, the default for all MobileMe sync services is encrypted connections (I don’t have time to confirm with Wireshark, so I’m currently accepting other articles for that statement). See… a reason Apple should buy Twitter 😉 Share:

In our last post we introduced some of the key principles of incident response. Today we will focus on the major roles and organizational structure. Organizational Structure As we return to our IT security focus, the incident response organization consists of two major kinds of resources: those dedicated completely to response, and those with other primary functions who get pulled into incidents as needed depending on the scope or nature. For example, the legal team isn’t necessarily involved in every incident, but clearly plays an important role in anything with legal or regulatory consequences. Also, a smaller organization might have no dedicated resources, while a larger one may have a full time team with defined roles, which deals with multiple overlapping incidents. That’s okay because the structure and system can expand and contract as needed if you follow the ICS principles. Resources These individuals and roles may not spend all their time on incident response, but are the key roles to fill when an incident occurs. One person can fill multiple roles, especially for a smaller incident or organization, but only if they have the right skill set. Team Lead/Incident Commander: The person with overall responsibility and accountability for the direct management of incidents. Typically reports to the CISO, CIO, or even CEO, but following unity of command, should definitely only be accountable to a single manager. When an incident triggers, the first person to respond is the incident lead until they hand off responsibility to someone of equal or higher authority. That way someone is always in charge, even if only for the first few minutes. Command is then handed off to higher and higher levels as needed. When you have a full-time team, the team lead/manager is also responsible for ongoing training, program development, and so on. Network Analysts: Experts in analyzing network packets/traffic, including forensic captures. Analysis includes ongoing monitoring, as well as deeper investigation during incidents. Systems Analysts: Experts in analyzing endpoints and servers. Forensics Analysts: Often a subspecialty of systems analyst, these individuals have deeper training in forensic investigation – which includes both the technical skills for the forensics examination of a system, and the legal training to properly handle evidence if there may be legal considerations (keep in mind that merely firing someone may lead to civil legal action). SIEM/Log Management Analysts: Individuals experienced in monitoring SIEM output and log analysis. Network, Systems, Database, and Application Administrators: Those individuals responsible for the maintenance of systems and networks. It is their responsibility to implement defensive mitigations during and after an incident, and to clean up affected systems. A firewall/IPS administrator might be responsible for closing the entry or egress points being used by the attacker. Systems administrators might roll out patches or configuration changes to host firewalls. A DBA might change account permissions or close out connection methods. This is a rather large bucket, and in most organizations these people operate at the direction of dedicated incident responders or other members of the security team. Legal, Human Resources, and Risk: Any time an incident might involve legal action, employees, or a material costs, you should involve any required combination of these business units. Communications/PR: If an incident has public impact, such as breach notifications, it’s critical to involve those responsible for organizational communications. Accounting/Finance: Incident response costs money. It’s important to include the bean counters early, even if only to pay for the pizza and Red Bull. They can also take responsibility for tracking ongoing incident costs so those of you responsible for stopping and cleaning the problem don’t have to spend your time spinning accounting spreadsheets. Logistics: This role can be a bit nebulous, but includes those responsible for getting the things you need during an incident. It may be someone from finance, the purchasing team, or the security team. Basically it’s someone with a credit card and the authority to use it. They keep people fed, purchase needed hardware and software, and hire outside experts. Communications: Those responsible for making sure responders (and management) can communicate. You might only need this role in a big incident, but make sure you identify people ahead of time who can keep you talking – via cell phones, landlines, email, IM, or whatever other mechanism isn’t totally pwned. Executive Management: We list them last, but they are ultimately responsible for everything in the organization – including incidents. Except in the organization’s very largest incidents, they probably won’t be involved directly. Yes, that is a large number of potential roles, but remember that not all are needed for every incident, and the same person might fill multiple roles based on organization and incident size. For example, in a small or mid-sized organization it isn’t unusual to have the team lead also be the network and systems analyst, and possibly also responsible for cleaning systems or reconfiguring the firewall. In terms of structure, here is one approach:   Finally, don’t forget our key concepts for the organizational structure: People should only report to a single manager. Any manager should only command 3 to 7 other people, ideally 5. The organizational structure fills in resources as needed. You don’t need everything, and what you do need you don’t need all the time. This is a scaffold to build on, not a permanent building. Share:

Imagine you’re a young, skilled techie just starting your career. Maybe you’re fresh out of school, or still in an internship program. Or maybe you’ve been out of school for a few years, working your way up through various companies in the industry. You came from a normal background – possibly you thought about the military at some point, but the allure of working in technology drew you into the private sector. Your skills are solid, you produce at work, and you don’t get into any trouble beyond the usual for your age. Then one day you’re contacted by someone in the government who was sent your way by a buddy from school, or maybe an old professor. They need someone with your skills to help them out with a project. Perhaps it’s to join their agency directly. Or maybe they merely ask you to take a look at something for them – sort of steering you toward a bit of a grey area you wouldn’t normally explore because you don’t want to get in trouble. They tell you it’s a matter of national security, and this is finally your opportunity to give back to your country without having to get shot at. Heck, maybe you spent time in the military and this is a great opportunity to continue your service on a volunteer basis without getting stuck with crappy military pay and travel/deployment requirements. Perhaps you already work for a foreign company your government friends are worried may be a risk to national security. All they want is for you to provide a little information, or maybe plug a USB drive into a system in the office for a few minutes. Or maybe you’ve been working for them on some projects for a while, even if they don’t really pay you and merely “suggest” things for you to look at. You’ve done a good job and they ask you to apply for some work or study abroad in another country. Or for a foreign company in your country. Either way, all they’re asking for is you to further your education and career, maybe helping your country out a little along the way. Ethically this is no different than joining the military, an intelligence agency, or working for a private contractor or university on government projects. You are serving your country while advancing you career – pretty much the best of both worlds. You can’t talk much, if at all, about it with your friends and family, but you sleep at night with the satisfaction that you’re able to blend the needs of your nation with your own personal development goals. Did I mention you grew up outside Shanghai? The thing about espionage is that there are no good guys or bad guys. Merely patriotic individuals living in different places who believe, with complete conviction, that they are doing the right thing and serving the public good. Share:

What a wild few weeks. Talk about been there, done that, got the t-shirt. It all started October 9th, when I finally achieved a goal I’ve been chasing for well over a decade, and completed my first Olympic-distance triathlon. (1.5K swim, 40K bike, 10K run – those are distances, not dollar values). I first learned about triathlon when I was working as a medic for a race in Boulder – probably back in 1992. Being the young, aggressive type, I thought any sport where you write your number on your arms and legs in permanent ink had to be hard core. I spent most of those years competing in a sport where you hit people in the face a lot (I guess that’s kind of hard core too), but in the late 90’s I started traveling a lot for work, which made staying competitive at the level I was at pretty much impossible. Getting frustrated by not being able to make it to the next level (I was competing nationally, but only winning locally), and spending a lot of time injured due to overtraining, I decided to give tri a shot. At least I could run, and often swim or bike, when on the road. But then I got sick… really sick. As in people started calling me “liver boy” because some virus attacked my third favorite part of my body and I couldn’t drink for over a year, never mind sustain hard workouts. But I recovered, started working with a swim coach, and then got distracted by getting married and traveling even more. And then I tore my rotator cuff and had surgery. And then had a kid. And… you get the idea. About 4-5 months ago I was finally injury-free and working out regularly again, and decided to give it another shot. Started riding with a bike group and then joined a masters swim program. I figured another 3 months of training and I’d be ready, but my swim coach pushed me to race and I gave it a shot. I may have finished near the back, but I finished. Easily. And now I’m hooked. Next up is a marathon, and maybe a half-Ironman in a year or so. Then back to the booze. The day after the tri I boarded a plane and headed off to London for RSA Europe. Chris Hoff and I spent a bunch of (platonic) private time together, and it turns out we’ve been working on some extremely complementary research that we’re going to combine for our joint RSA presentation this year. I was also really happy my work passed the sniff test, because Chris spends a heck of a lot more time on cloud than I ever will, and if the research holds up for him I know it’s solid. Then back home for 3 days, and back on a plane to China. I was again presenting with Hoff, and we managed to sneak out for a few hours to visit the Forbidden City. Which is quite welcoming, if you buy a ticket. They have beer. All reds for some reason. On a sour note, the day before the tri I got word that a very good friend died of cancer. Jim launched my technology career and changed the course of my life in ways that are hard to describe. A little over a year ago we started on some collaborative smart grid research, soon after which he found out about the cancer he never recovered from. Jim deserved better. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in China. In Chinese. Mike quoted in Dark Reading on SIEM and cloud. Dave Lews and David Mortman get a mention in an article on SecTor. Rothman again, this time on consolidation. Rich talks about China and Europe on The Network Security Podcast Favorite Securosis Posts Mike Rothman: The Thing about Espionage. Clearly a fine line between good and bad. But I do think there is right and wrong. And regardless of how you slice it, if it’s called espionage, it’s probably wrong. Adrian Lane: React Faster and Better: Incident Command Principles. Rich: Can we ever break IT?. (We’re light on posts this week, so we’ll leave it at that.) Other Securosis Posts React Faster and Better: Roles and Organizational Structure. SunSec Rises on November 3rd. Incite 10/27/2010: Traffic Ahead. NSO Quant: The Report and Metrics Model. Everything You Ever Wanted to Know about DLP. Favorite Outside Posts Adrian Lane: Robert Graham’s FireSheep analysis. Mike Rothman: Cloud Creates SIEM Blind Spot. Keep in mind the cloud changes the rules for how we do things like monitoring. And I’m quoted. Enjoy the gratuitous pat on my own back… Chris Pepper: iPhone Jailbreak Tool Sets Stage for Mobile Malware. Eric Monti demonstrates that “jailbreak” = “remote root exploit”. Gunnar Peterson: Paypal enables billing and payments on Azure cloud. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics – Device Health. NSO Quant: Manage Metrics – Monitor Issues/Tune IDS/IPS. Research Reports and Presentations Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution, v2.0. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Top News and Posts Koobface Worm Targets Java. NSA Declassified Documents. Interesting stuff. Adobe Flash Bug. Perhaps we should leave a permanent reference in the Friday summary for Flash vulnerabilities and just update the link du jour. Idiocy tool. Just to remind people they are insecure. Firesheep launched. Critical Firefox Bug. LinkedIn Drive-by Malware Attack. 19 Arrested in Zeus Malware Bank Heists. Oracle claims Google directly copied Java code. Silver Tail Systems gets In-Q-Tel funding. Banks weak against skimming attacks. PCI Council releases a “sort of” update. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Mike Fratto, in response to The Thing About Espionage. Rich, based on your definition, the good guys are us and the bad guys are them for any definition of “us”

For those of you in the Phoenix area, or with way too many frequent flier miles and too much spare time, the Phoenix OWASP chapter is organizing a SunSec meetup after their meeting on November 3rd. It has been a long time since we had a real SunSec, after getting off to a good start a few years ago. This is a great excuse to meet up with local security folks over your favorite frosty beverages. SunSec will be held from 6:30 onward on November 3rd at SunUp Brewing. Share:

I know what you’re thinking to yourself right now: “They promised me a cool series of posts on the cutting edge of incident response, and now we’re talking management principles and boxes on an org chart? What a rip.” But believe it or not, the most important aspect of incident response is the right organization, followed by the right process. How do I know this? Because I’ve been through a ton of incident response training with local and federal agencies, and have directly responded to everything from single-rescuer ski accidents to Hurricane Katrina. (And a few IT things in the middle, but those don’t sound nearly as exciting). While working as an emergency responder I fall under something known as the National Incident Management System, which uses a formalized process and structure called the Incident Command System (ICS). ICS consists of a standard management hierarchy and processes for managing temporary incidents of any size and nature. ICS was originally developed for managing large wildfires in the 1970s, and has since expanded into a national standard that’s also used (and adapted) by a variety of other countries and groups. While our React Faster and Better series won’t to teach you all of ICS, everything we will talk about in terms of process and organization is adapted directly from it. There’s no reason to reinvent the wheel when you have something with over 30 years of battle-hardened testing available. Additionally, those of you in larger companies or verticals like healthcare or public utilities may be required to learn and use ICS in your own incidents. Incident Command System Principles ICS solves a lot of the problems we encounter in incidents. Its focus is on clear communications and accountability, with a structure that expands and contracts as needed, allowing disparate groups to combine even if they’ve never worked together before. ICS includes 5 key concepts: Unity of command: Each person involved in an incident only responds to one supervisor. Common terminology: It’s hard to communicate when everyone uses their own lingo. Common terminology applies to both the organizational structure (with defined roles, like “Incident Commander”, that everyone understands) and use of plain English (or the language of your choice) in incident communications. You can still talk RPC flaws all you want, but when communicating with management and non-techies you’ll use phrases like “The server is down because we were hacked.” Management by objectives: Responders have specific objectives to achieve, in priority order, as defined in a response plan. No running around fighting fires without central coordination. Flexible and modular organization: Your org structure should expand and contract as needed based on the nature and size of the incident. The organizational structure can be as small as a single individual, and as large as the entire company. Span of control: No one should manage less or more than 3-7 other individuals, with 5 being the sweet spot. This one comes from many years of management science, which have repeatedly confirmed that attempting to directly manage more is ineffective, while managing less is an inefficient use of resources. If you want to learn more about ICS you can run through the same self-training course used by incident responders at FEMA’s online training site. Start with ICS 100, which covers the basics. While the process we’ll outline in this series is based on ICS principles, it’s specific to information security incident response. We won’t be using terms like “branch” and “section” because they would distract from our focus, but you can clearly plug them in if you want to standardize on ICS. But if you need the Air Ops branch for a cyberattack, something is very very wrong. For the next post we will focus on three of the key concepts related to organizational structure: unity of command, flexible and modular organization, and span of control, as we talk about the key response roles and structure. Share:

Way back when I converted Securosis from a blog into a company, my very first paper was (no surprise) Understanding and Selecting a DLP Solution. Three or so years later I worried it was getting a little long in the tooth, even though the content was all still pretty accurate. So, as you may have noticed from recent posts, I decided to update and expand the content for a new version of the paper. Version 1.0 is still downloaded on pretty much a daily basis (actually, sometimes a few hundred times a month). The biggest areas of expansion were a revamped selection process (with workflow, criteria, and a selection worksheet) and more details on “DLP features” and “DLP Light” tools that don’t fit the full-solution description. This really encapsulates everything you should need to know up through acquiring a DLP solution, but since it’s already 50+ pages I decided to hold off on implementation until the next paper (besides, that gives me a chance to scrum up some extra cash to feed the new kid). I did, however, also break out just the selection worksheet for those of you who don’t need the entire paper. Not that it will make any sense without the paper. The landing page is here: Understanding and Selecting a DLP Solution. Direct download is at: Whitepaper (PDF) Very special thanks to Websense for licensing the paper and worksheet. They were the very first sponsor of my first paper, which helped me show my wife we wouldn’t lose the house because I quit my job to blog. Share:

So you might have heard there’s this thing called ‘Stuxnet’. I was thinking it’s like the new Facebook or something. Or maybe more like Twitter, since the politicians seem to like it, except Sarah Palin who is totally more into Facebook. Anyway, that’s what I thought until I realized Stuxnet must be a person. Some really bad dude with some serious frequent flier miles – they seem to be all over Iran, China, and India. (Which isn’t easy – I had to get visas for the last two and even a rush job takes 2-3 days unless you live next to the embassy). I know this because earlier today I tweeted: Crap. I just watched stuxnet drive off with my car flipping me the bird. Knew I should have gotten lojack. Then a bunch of people responded: @kdawson: @rmogull Funny, though I would have pictured Stuxnet as more the Studebaker type. @akraut: @rmogull The downside is, Stuxnet can still get your car even after you disable the starter. @st0rmz: @rmogull I heard Stuxnet was running for president with drop database as his running mate. @geoffbelknap: @rmogull Haven’t you seen Fight Club? Turns out you and stuxnet are the same person… That would explain a lot. Especially why my soap smells so bad. But I don’t know how I could pull it off… some random company that promises visas for China has my passport, so it isn’t like I’m able to leave the country. I’m pretty sure I can trust them – the site looked pretty professional, it only crashed once, and there’s a 1-800 number. Besides, it was one of the top 3 Bing results for “China visa” so it has to be safe. And don’t forget to attend the SearchSecurity/Securosis Data Security Event in San Francisco on Oct 26th! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences James Arlen spoke at the EnergySec conference last week. Rich was mentioned by Alex Williams on ReadWriteWeb about the chance the government will mandate CALEA-type backdoors in any communications or encryption software. Rich also quoted on the same thing at Federal Computer Week Favorite Securosis Posts Adrian Lane: Application Monitoring, Part 1. David Mortman: A Wee Bit on DLP SaaS. Mike Rothman: DLP Light and DLP Features. DLP is evolving and Rich walks you through it. Rich: Proposed Internet Wiretapping Law Fundamentally Incompatible with Security. (Yep, I picked my own. Live with it.) Other Securosis Posts Monitoring up the Stack: Application Monitoring, Part 1. Monitoring up the Stack: DAM, part 2. Incite 9/29/2010: Reading Is Fundamental. NSO Quant: The End is Near! Attend the Securosis/SearchSecurity Data Security Event on Oct 26. Monitoring up the Stack: DAM, Part 1. Favorite Outside Posts Adrian Lane: I know what the law says. Or do I? Interested to see if this holds up to scrutiny. And using the same disclaimer Jack did, the AG’s interpretation does not make sense. David Mortman: Feel the dark side of Intellectual Property Rights. You know you want to… Mike Rothman: Things I hate about security reports, a rant. Most technical folks don’t write very well. It’s a problem and some of these tips are useful. Chris Pepper: CIA Drones May Have Used Illegal, Inaccurate Code. Crazy story & accusations! James Arlen: Good food for thought on the ‘whys’ of the battle: CIO/CSO disconnect. Rich: Why Russia and China think we are fighting cyberwar now. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics – Device Health. Research Reports and Presentations Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Data Encryption 101: A Pragmatic Approach to PCI. White Paper: Understanding and Selecting SIEM/Log Management. White Paper: Endpoint Security Fundamentals. Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Top News and Posts LinkedIn Drive-by Malware Attack. 19 Arrested in Zeus Malware Bank Heists. More Stuxnet Details. Tahoe Least Authority File System looks interesting. Microsoft pushes emergency patch for the padding oracle attack. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Paul, in response to Understanding DLP Solutions, “DLP Light”, and DLP Features. Rich, nice update! It seems worth amplifying that DLP Light is going to give you multiple reporting points, requiring you to work with each product’s reporting output or console to see what’s going on. SIEM is a solution, but to provide the simplicity the typical DLP Light user might need, the SIEMs are going to need to provide pre-built correlation rules across the DLP Light components. Share:

I’m nearly done with a major revision to the very first whitepaper I published here at Securosis: Understanding and Selecting a Data Loss Prevention Solution, and one of the big additions is an expanded section talking about DLP integration and “DLP Light” solutions. Here is my draft of that content, and I wonder if I’m missing anything major: DLP Features and Integration with Other Security Products Up until now we have mostly focused on describing aspects of dedicated DLP solutions, but we also see increasing interest in DLP Light tools for four main use cases: Organizations who turn on the DLP feature of an existing security product, like an endpoint suite or IPS, to generally assess their data security issues. Users typically turn on a few general rules and use the results more to scope out their issues than to actively enforce policies. Organizations which only need basic protection on one or a few channels for limited data types, and want to bundle the DLP with existing tools if possible – often to save on costs. The most common examples are email filtering, endpoint storage monitoring, or content-based USB alerting/blocking for credit card numbers or customer PII. Organizations which want to dip their toes into DLP with plans for later expansion. They will usually turn on the DLP features of an existing security tool that is also integrated with a larger DLP solution. These are often provided by larger vendors which have acquired a DLP solution and integrated certain features into their existing product line. To address a very specific, and very narrow, compliance deficiency that a DLP Light feature can resolve. There are other examples, but these are the four cases we encounter most often. DLP Light tends to work best when protection scope and content analysis requirements are limited, and cost is a major concern. There is enough market diversity now that full DLP solutions available even for cost-conscious smaller organizations, so we suggest that if more-complete data protection is your goal, you take a look at the DLP solutions for small and mid-size organizations rather than assuming DLP Light is your only option. Although there are a myriad of options out there, we do see some consistencies between the various DLP Light offerings, as well as full-DLP integration with other existing tools. The next few paragraphs highlight the most common options in terms of features and architectures, including the places where full DLP solutions can integrate with existing infrastructure: Content Analysis and Workflow Most DLP Light tools start with some form of rules/pattern matching – usually regular expressions, often with some additional contextual analysis. This base feature covers everything from keywords to credit card numbers. Because most customers don’t want to build their own custom rules, the tools come with pre-built policies. The most common is to find credit card data for PCI compliance, since that drives a large portion of the market. We next tend to see PII detection, followed by healthcare/HIPAA data discovery; all of which are designed to meet clear compliance needs. The longer the tool/feature has been on the market, the more categories it tends to support, but few DLP light tools or features support the more advanced content analysis techniques we’ve described in this paper. This usually results in more false positives than a dedicated solution, but for some of these data types , like credit card numbers, even a false positive is something you usually want to take a look at. DLP Light tools or features also tend to be more limited in terms of workflow. They rarely provide dedicated workflow for DLP, and policy alerts are integrated into whatever existing console and workflow the tool uses for its primary function. This might not be an issue, but it’s definitely important to consider before making a final decision, as these constraints might impact your existing workflow and procedures for the given tool. 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 most policy/category coverage. Many of you already deploy some level of content-based email filtering. Email gateways are also one of the top 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. Web Security Gateways: Some web gateways now directly enforce DLP policies on the content they proxy, such as preventing files with credit card numbers from being uploaded to webmail or social networking services. Web proxies are the second most common integration point for DLP solutions because, as we described in the Technical Architecture section [see the full paper, when released], 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, since that’s a critical capability these tools require to block inbound malicious content. Web gateways also provide valuable context, with some able to categorize URLs and web services to support policies that account for the web destination, not just the content and port/protocol. Unified Threat Management: UTMs provide broad network security coverage, including at least firewall and IPS capabilities, but usually also web filtering, an email security gateway, remote access, and web content filtering (antivirus). These are a natural location to add network DLP coverage. We don’t yet see many integrated with full DLP solutions, and they tend to build their own analysis capabilities (primarily for integration and performance reasons). Intrusion Detection and Prevention Systems: IDS/IPS tools already perform content inspection, and thus make a natural fit for additional DLP analysis. This is usually basic analysis integrated into existing policy sets, rather than a new, full content analysis engine. They are rarely integrated with a full DLP solution, although we do expect to see this

Here’s some more content that’s going into the updated version of Understanding and Selecting a Data Loss Prevention Solution (hopefully out next week). Every now and then I get questions on DLP SaaS, so here’s what I’m seeing now… DLP Software as a Service (SaaS) Although there aren’t currently any completely SaaS-based DLP services available – due to the massive internal integration requirements for network, endpoint, and storage coverage – some early SaaS offerings are available for limited DLP deployments. Due to the ongoing interest in cloud and SaaS in general, we also expect to see new options appear on a regular basis. Current DLP SaaS offerings fall into the following categories: DLP for email: Many organizations are opting for SaaS-based email security, rather than installing internal gateways (or a combination of the two). This is clearly a valuable and straightforward integration point for monitoring outbound email. Most services don’t yet include full DLP analysis capabilities, but since many major email security service providers have also acquired DLP solutions (sometimes before buying the email SaaS provider) we expect integration to expand. Ideally, if you obtain your full DLP solution from the same vendor providing your email security SaaS, the policies and violations will synchronize from the cloud to your local management server. Content Discovery: While still fairly new to the market, it’s possible to install an endpoint (or server, usually limited to Windows) agent that scans locally and reports to a cloud-based DLP service. This targets smaller to mid-size organizations that don’t want the overhead of a full DLP solution, and don’t have very deep needs. DLP for web filtering: Like email, we see organizations adopting cloud-based web content filtering, to block web based attacks before they hit the local network and to better support remote users and locations. Since all the content is already being scanned, this is a nice fit for potential DLP SaaS. With the same acquisition trends as in email services, we also hope to see integrated policy management and workflow for organizations obtaining their DLP web filtering from the same SaaS provider that supplies their on-premise DLP solution. There are definitely other opportunities for DLP SaaS, and we expect to see other options develop over the next few years. But before jumping in with a SaaS provider, keep in mind that they won’t be merely assessing and stopping external threats, but scanning for extremely sensitive content and policy violations. This may limit most DLP SaaS to focusing on common low hanging fruit, like those ubiquitous credit card numbers and customer PII, as opposed to sensitive engineering plans or large customer databases. Share: