Research

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:

I am working on an encryption project – evaluating an upcoming product feature for a vendor – and the research is more interesting than I expected. Not that the feature is uninteresting, but I thought I knew all the answers going into this project. I was wrong. I have been talking with folks on the Twitters and in private interviews, and have discovered that far more organizations than I suspected are configuring their systems to automatically skip preboot authentication and simply boot up into Windows or Mac OS X (yes, for real, a bunch are using disk encryption on Macs). For those of you who don’t know, with most drive encryption you have a mini operating system that boots first, so you can authenticate the user. Then it decrypts and loads the main operating system (Windows, Mac OS X, Linux, etc.). Skipping the mini OS requires you to configure it to automatically authenticate and load the operating system without a password prompt. Organizations tend to do this for a few reasons: So users don’t have to log in twice. So you don’t have to deal with managing and synchronizing two sets of credentials (preboot and OS). To reduce support headaches. But the convenience factor is the real reason. The problem with skipping preboot authentication is that you then rely completely on OS authentication to protect the device. My pentester friends tell me they can pretty much always bypass the OS encryption. This may also be true for a running/sleeping/hibernating system, depending on how you have encryption configured (and how your product works). In other words – if you skip preboot, the encryption generally adds no real security value. In the Twitter discussion about advanced pen testering, our very own David Mortman asked: @rmogull Sure but how many lost/stolen laptops are likely to be attacked in that scenario vs the extra costs of pre-boot? Which is an excellent point. What are the odds of an attacker knowing how to bypass the encryption when preboot isn’t used? And then I realized that in that scenario, the “attacker” is most likely someone picking up a “misplaced” laptop and even basic (non-encryption) OS security is good enough. Which leads to the following decision tree: Are you worried about attackers who can bypass OS authentication? If so, encrypt with preboot authentication; if not, continue to step 2. Do you need to encrypt only for compliance (meaning security isn’t a priority)? If so, encrypt and disable preboot; if not, continue to step 3. Encrypt with preboot authentication. In other words, encrypt if you worry about data loss due to lost media or are required by compliance. If you encrypt for compliance and don’t care about data loss, then you can skip preboot. Share:

Define Needs The first step in the process is to determine your needs, keeping in mind that there are two main drivers for File Activity Monitoring projects, and it’s important to understand the differences and priorities between them: Entitlement management Activity monitoring Most use cases for FAM fall into one of these two categories, such as data owner identification. It’s easy to say “our goal is to audit all user access to files”, but we recommend you get more specific. Why are you monitoring? Is your primary need security or compliance? Are there specific business unit requirements? These answers all help you pick the best solution for your individual requirements. We recommend the following process for this step: Create a selection committee: File Activity Monitoring initiatives tend to involve three major technical stakeholders, plus compliance/legal. On the IT side we typically see security and server and/or storage management involved. This varies considerably, based on the size of the organization and the complexity of the storage infrastructure. For example, it might be the document management system administrators, SharePoint administrators, NAS/storage management, and server administration. The key is to involve the major administrative leads for your storage repositories. You may also need to involve network operations if you plan to use network monitoring. Define the systems and platforms to protect: FAM projects are typically driven by a clear audit or security goal tied to particular storage repositories. In this stage, detail the scope of what will be protected and the technical specifics of the platforms involved. You’ll use this list to determine technical requirements and prioritize features and platform support later. Remember that needs grow over time, so break the list into a group of high-priority systems with immediate requirements, and a second group summarizing all major platforms you may need to protect later. Determine protection and compliance requirements: For some repositories you might want strict preventative security controls, while for others you may just need comprehensive activity monitoring or entitlement management to satisfy a compliance requirement. In this step, map your protection and compliance needs to the platforms and repositories from the previous step. This will help you determine everything from technical requirements to process workflow. Outline process workflow and reporting requirements: File Activity Monitoring workflow varies by use. You will want to define different workflows for entitlement management and activity monitoring, as they may involve different people; that way you can define what you need instead of having the tool determine your process. In most cases, audit, legal, or compliance, have at least some sort of reporting role. Different FAM tools have different strengths and weaknesses in their management interfaces, reporting, and internal workflow, so think through the process before defining technical requirements to prevent headaches down the road. By the end of this phase you should have defined key stakeholders, convened a selection team, prioritized the systems to protect, determined protection requirements, and roughed out process workflow. Formalize Requirements This phase can be performed by a smaller team working under the mandate of the selection committee. Here, the generic needs from phase 1 are translated into specific technical features, and any additional requirements are considered. This is the time to come up with criteria for directory integration, repository platform support, data storage, hierarchical deployments, change management integration, and so on. You can always refine these requirements after you begin the selection process and get a better feel for how the products work. At the conclusion of this stage you will have a formal RFI (Request For Information) for vendors, and a rough RFP (Request For Proposals) to clean up and formally issue in the evaluation phase. Evaluate Products As with any products, it can be difficult to cut through the marketing materials and figure out whether a product really meets your needs. The following steps should minimize your risk and help you feel confident in your final decision: Issue the RFI: Larger organizations should issue an RFI though established channels and contact the leading FAM vendors directly. If you’re a smaller organization start by sending your RFI to a trusted VAR and email the FAM vendors which appear appropriate for your organization. Perform a paper evaluation: Before bringing anyone in, match any materials from the vendor or other sources to your RFI and draft RFP. Currently few vendors are in the FAM market, so your choices will be limited, but you should be fully prepared before you go into any sales situations. Also use outside research sources and product comparisons. Bring in vendors for on-site presentations and demonstrations: Instead of a generic demonstration, ask each vendor to walk through your specific use cases. Don’t expect a full response to your draft RFP – these meetings are to help you better understand the different options and eventually finalize your requirements. Finalize your RFP and issue it to your short list of vendors: At this point you should completely understand your specific requirements and issue a formal, final RFP. Assess RFP responses and begin product testing: Review the RFP results and drop anyone who doesn’t meet any of your minimal requirements (such as platform support), as opposed to ‘nice-to-have’ features. Then bring in any remaining products for in-house testing. You will want to replicate your highest volume system and its traffic if at all possible. Build a few basic policies that match your use cases, and then violate them, so you get a feel for policy creation and workflow. Select, negotiate, and buy: Finish testing, take the results to the full selection committee, and begin negotiating with your top choice. Internal Testing In-house testing is the last chance to find problems in your selection process. Make sure you test the products as thoroughly as possible. And keep in mind that smaller organizations may not have the resources or even the opportunity to test before purchase. A few key aspects to test are: Platform support and installation: Determine agent or integration compatibility (if needed) with your repositories. If you plan to use agents or integrate with a document management system, this is one

Once again, I have knocked off a series of posts for a new white paper. The title is “Understanding and Selecting a File Activity Monitoring Solution”. Although there are only a few vendors in the market, this is a technology I have been waiting a few years for, and I think it’s pretty useful. There are basically two sides to it: Entitlement management: Collecting all user privileges in monitored file repositories, linking into your directory servers, and giving you a highly simplified process for cleaning up all the messes and managing things better when moving forward. Activity monitoring: Full activity monitoring for all your file repositories in scope… including alerting for policy violations. It’s pretty cool stuff – imagine setting a policy to alert you any time someone copies an entire directory off the server instead of a single file. Or copying 30 files in a day, when they normally only open 1 or 2. And that’s just scratching the surface of the potential. The links to all the posts are below, and I could use any feedback you have before we convert this puppy to a paper and post it. (If you are seeing this in RSS, you will have to click the post to see all the links, because I’m too lazy to add them in manually). Share:

Now that we have covered the base features it’s time to consider how these tie in with policies, workflow, and reporting. We’ll focus on the features needed to support these processes rather than defining the processes themselves. Policy Creation File Activity Monitoring products support two major categories of policies: Entitlement (Permissions/Access Control) policies. These define which users can access which repositories and types of data. They define rules for things like orphaned user accounts, separation of duties, role/group conflicts, and other situations that don’t require real-time file activity. Activity-based polices. These alert and block based on real-time user activity. When evaluating products, look for a few key features to help with policy creation and management: Policy templates that serve as examples and baselines for building your own policies. A clean user interface that allows you to understand business context. For example, it should allow you to group categories, pool users and groups to speed up policy application (e.g., combine all the different accounting related groups into “Accounting”), and group and label repositories. This is especially important given the volume of entries to manage when you integrate with large user directories and multi-terabyte repositories. New policy wizards to speed up policy creation. Hierarchical management for multiple FAMs in the same organization. Role-based administration, including roles for super administrators and assigning policies to sub-administrators. Policy backup and restore. Workflow As with policy creation, we see workflow requirements focusing on the two major functions of FAM: entitlement management and activity monitoring. Entitlement Management This workflow should support a closed-loop process for collection of privileges, analysis, and application of policy-based changes. Your tool should do more than merely collect access rights – it should help you build a process to ensure that access controls match your policies. This is typically a combination of different workflows for different goals – including identification of orphan accounts with access to sensitive data, excessive privileges, conflict of interest/separation of duties based on user groups, and restricting access to sensitive repositories. Each product and policy will be different, but they typically share a common pattern: Collect existing entitlements. Analyze based on policies. Apply corrective actions (either building an alerting/blocking policy or changing privileges). Generate a report of identified and remediated issues. The workflow should also link into data owner identification because this must often be understood before changing rights. Activity Monitoring and Protection The activity monitoring workflow is very different than entitlement management. Here the focus is on handling alerts and incidents in real time. The key interface is the incident handling queue that’s common to most security tools. The queue lists incidents and supports various sorting and filtering options. The workflow tends to follow the following structure: Incident occurs and alert appears in the queue. It is displayed with the user, policy violated, and repository or file involved. The incident handler can investigate further by filtering for other activity involving that user, that repository, or that policy over a given time period (or various combinations). The handler can assign or escalate the incident to someone else, close the incident, or take corrective actions such as adjusting the file permissions manually. The key to keeping this efficient is not requiring the incident handler to jump around the user interface in a manual process. For example, clicking on an incident should show its details and then links to see other related incidents by user, policy, and repository. Incidents should also be grouped logically – an attempt to copy an entire directory should appear as one incident, not one incident for each of 1,000 files in the repository. Any FAM product may also include additional workflows, such as one for identifying file owners. Reporting One of the most important functions for any File Activity Monitoring product is robust reporting – this is particularly important for meeting compliance requirements. Aside from a repository of pre-defined reports for common requirements such as PCI and HIPAA, the tool should allow you to generate arbitrary reports. (We hate to list that as a requirement, but we still occasionally see security tools that don’t support creation of arbitrary reports). Share:

Introduction Our entire profession is called “information security”, but surprisingly few of our technologies focus on actually protecting the data itself, as opposed to the infrastructure surrounding it. Data Loss Prevention emerged nearly 10 years ago to address exactly this problem. By peering inside files, network traffic, and other sources – and understanding both content and context – DLP provides new capabilities comparable to when we first started looking inside network packets. The Data Loss Prevention market is split into two broad categories of tools – full suites dedicated to DLP, and what we call “DLP Light”. There is lots of confusion about the differences between these approaches… and even their definitions. In this series we will focus on DLP Light – what it is, how it works, and how to rapidly take advantage of it. (For more information on full-suite Data Loss Prevention, see our white paper Understanding and Selecting a Data Loss Prevention Solution. Defining DLP Light We are talking about a subset of Data Loss Prevention, so we need to start with our definition of DLP: Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use, through deep content analysis. A full DLP suite includes network, storage, and endpoint capabilities; as well as a range of deep content analysis techniques such as document fingerprinting. DLP Light tools include a subset of those capabilities; they are generally features of, or integrated with, other security products – such as endpoint protection platforms, email security gateways, and next-generation firewalls. DLP Light tools tend to have some or all the following characteristics: Focused on a subset of ‘channels’. A DLP Light tool might focus on portable storage, email, web traffic, other channels, or a combination. Fewer/simpler content analysis techniques. Rather than providing a wide range of deep content analysis techniques, many of which are resource-intensive, DLP Light products tend to include a smaller set of techniques, or even a single method. The most common is pattern matching, which is the most commonly used technique in both full and Light DLP deployments. Less dedicated workflow. DLP Light tools are often integrated with, or features of, other security tools. As such, they lack the full self-contained workflow found in full DLP suites. You might ask, “So how is this still DLP?” The key defining characteristic of both full DLP and DLP Light is content analysis. If a tool can peer into network traffic or a file and sniff out something like a credit card number, it’s DLP. If all it does is rely on tagging/labeling, metadata, or contextual information… it isn’t DLP. The Role of DLP Light DLP Light plays an important role in a few different use cases: Organizations that already use the product the DLP Light tool integrates with – such as email security gateways – often want to start protecting sensitive data while constraining costs. Organizations that don’t require dedicated DLP tools. This is often due to less stringent or more circumscribed data security requirements. Organizations that want to scope out their DLP problem before investing in a dedicated tool. DLP Light can play a valuable role in helping assess data security risk. Organizations that want to start small and grow into full DLP. There is a bit of overlap between these cases, but they reflect the most common reasons we see people using DLP Light. Dedicated Data Loss Prevention is extremely powerful, but not appropriate for everyone. Next we will cover the technology side of DLP Light, and then we will finish with the Quick Wins process for rapidly deriving value from your implementation. Share: