Research

In our last post we finished our review of DLP content discovery best practices by discussion rolling out and maintaining your deployment. Today we’re going to focus on a couple of use cases that illustrate how it all works together. I’m writing these as fake case studies, which is probably really obvious considering my lack of creativity in the names. DLP Content Discovery for Risk Reduction and to Support PCI Audit RetailSportsCo is a mid-sized online and brick-and-mortar sporting goods retailer, with about 4,000 headquarters employees and another 2,000 retail employees, across 50 locations. They classify as a Level 2 merchant due to their credit card transaction volume and are currently PCI complaint, but struggled through the process and ended up getting a series of compensating controls approved by their auditor, but only for their first year. During the audit it was discovered that credit card information had proliferated uncontrolled throughout the organization. It was scattered through hundreds of files on dozens of servers; mostly Excel spreadsheets and Access databases used, and later ignored, by different business units. Since storage of unencrypted credit card numbers is prohibited by PCI, their auditor required them to remove or secure these files. Audit costs for the first year increased significantly due to the time spent by the auditor validating that the information was destroyed or secured. RetailSportsCo purchased a DLP solution and created a discovery policy to locate credit card information across all storage repositories and employee systems. The policy was initially deployed against the customer relations business unit servers, where over 75 files containing credit card numbers were discovered. After consultation with the manager of the department and employee notification, the tool was switched into enforcement mode and all these files were quarantined back into an encrypted repository. In phase 2 of the project, DLP endpoint agents were installed on the laptops of sales and customer relations employees (about 100 employees). Users and managers were educated, and the tool discovered and removed approximately 150 additional files. Phase 3 added coverage of all known storage repositories at corporate headquarters. Phase 4 expanded scanning to storage at retail locations, over a period of 5 months. The final phase will add coverage of all employee systems in the first few months of the coming year, leveraging their workstation configuration management system for a scaled deployment. Audit reports were generated showing exactly which systems were scanned, what was found, and how it was removed or protected. Their auditor accepted the report, which reduced audit time and costs materially (more than the total cost of the DLP solution). One goal of the project is to scan the entire enterprise at least once a quarter, with critical systems scanned on either a daily or weekly basis. RetailSportsCo has improved security and reduced risk by reducing the potential number of targets, and reduced compliance costs by being able to provide auditors with acceptable reports demonstrating compliance. DLP Content Discovery to Reduce Competitive Risk (Industrial Espionage) EngineeringCo is a large high-technology manufacturer of consumer goods with 51,000 employees. In the past they’ve suffered from industrial espionage, when the engineering plans for new and existing products were stolen. They also suffered a rash of unintentional exposures and product plans were accidentally placed in public locations, including the corporate website. EngineeringCo acquired a DLP content discovery solution to reduce these exposure risks and protect their intellectual property. Their initial goal was to reduce the risk of exposure of engineering and product plans. Unlike RetailSportsCo, they decided to start with endpoints, then move into scanning enterprise storage repositories. Since copies of all engineering and product plans reside in the enterprise content management system, they chose a DLP solution that could integrate and continuously monitor selected locations and automatically build partial-document matching policies for all documents. The policy was tested and refined to ignore common language in the files, such as corporate headers and footers, which initially caused every document using the corporate template to register in the DLP tool. EngineeringCo started with a phased deployment to install the DLP endpoint discovery agent on all corporate systems. In phase 1, the tool was rolled out to 100 systems per week, starting with product development teams. The initial policy allowed those teams access to the sensitive information, but documented what was on their systems. Those reports were later mated to their encryption tool to ensure that no unencrypted laptops hold the sensitive data. Phase 2 expanded deployment to the broader enterprise, initially in alerting mode. After 90 days the product was switched into enforcement mode and any identified content outside of the product development teams was quarantined with an alert sent to the user, who could request an exemption. Initial alert rates were high, but user education reduced levels to only a dozen or so “violations” a week during the 90-day grace period. In the coming year EngineeringCo plans to refine their policy to restrict product development employees from placing registered documents onto portable storage. The network component of their DLP tool already restricts emailing and other file transfers outside of the enterprise. They also plan on adding policies to protect employee healthcare information and customer account information. These are, of course, fictional best practices examples, but they’re drawn from discussions with dozens of DLP clients. The key takeaways are: Start small, with a few simple policies and a limited scanning footprint. Grow deployments as you reduce incidents/violations to keep your incident queue under control and educate employees. Start with monitoring/alerting and employee educations, then move on to enforcement. This is risk reduction, not risk elimination. Use the tool to identify and reduce exposures but don’t expect it to magically solve all your data security problems. When you add new policies, test first with a limited audience before rolling them out to the entire scope, even if you are already covering the entire enterprise with other policies. Share:

This past Monday, I had the privilege of speaking (along with several peers) to the Commission on Cyber Security for the 44th Presidency about issues on identity theft, breach disclosure and personal privacy in general. It was an honor to present with such a great group of folks. There were some great discussions/debates and I look forward to the opportunity to present again as the Commission works to streamline its recommendations. My written testimony is below. A special thanks to the folks at Emergent Chaos and to Rich for their comments, which made this a much better piece. Any errors or logical fallacies are, of course, my own. Thank you for the opportunity to present to you today on the issue of identity theft. Since the advent of CA1386, we have seen 41 other states pass similar legislation mandating to some degree or another that companies must notify customers or the government when they believe they have suffered a loss of personal data. Unfortunately, each and every state has created slightly different criteria for what constitutes personal information, what a loss is, when notification needs be sent and, to whom it must be sent. As a result there are huge disparities among companies on what they do when they discover they’ve suffered a breach. As much as I prefer to not have even more legislation, I believe that the only solution to this dilemma is to have a uniform federal law that covers the loss of personal information. Rather than preempt state laws, this law should set baseline requirements of: a) Notification to all customers in a timely fashion. b) Notification to a central organization. c) The gathered data about companies suffering breaches must be a matter of public record and un-anonymized. d) Include notification of any personal information that is not a matter of public record. e) Not have a “get out of jail free” card. This last point is key. One of the great weaknesses of CA1386 (and several other states’ legislation as well) is that companies don’t have to notify in case the information was encrypted. Unfortunately, the mere use of encryption does not mean the data was actually obfuscated at the time it was stolen, for instance in cases where a laptop is stolen while the user is logged in. Don’t get me wrong- encryption is important. A well-written law will provide a safe harbor for a company that has lost data. If they can establish that it was encrypted following best practices and that key material was not also lost, the company should be protected from litigation as a result of the breach disclosure. Similarly, many state laws allow companies to choose to not disclose if they believe the data has not been misused. Given that the companies lost the data to begin with, should we really trust their assessment of the risk of misuse, especially when many executives believe it is not in their best interest to not disclose? It is worth noting that following a breach, stock prices do not suffer in the long run and customer loss is approximately 2%. On the other side of the coin from breach disclosure, we have the problem that people don’t know what personal information companies have about them. Part of the outrage behind the ChoicePoint debacle of several years ago was that people didn’t know that this data was even being collected about them to begin with, and had no real way to find out what ChoicePoint might or might not have collected. In Europe as well as in Australia and parts of Asia such as Japan, companies have to both tell customers what data they have and allow them the opportunity to correct any errors. Additionally, there are strict restrictions on what collected personal information may be used for. I believe that it is time that similar protections be available to Americans as well. Share:

Chris Pepper, Master Editor, pointed out something I missed. If you memorize an encrypted network, your iPhone won’t connect to an unencrypted one with the same name, or one with a different password. Thus unless the bad guy knows your WPA passphrase (you’re not dumb enough to use WEP, are you?), you can memorize your home network and not worry about accidentally connecting while wandering around, even if it’s still called “tsunami”. Share:

In Part 3 of our series we finished our review of the technical architecture and selection; now we’re going to delve into best practices for deployment. We will focus on setting expectations, prioritization, and defining your internal processes. The main obstacle to successful deployments isn’t a technology weakness, but rather the failure of the enterprise to understand what to protect, decide how to protect it, and recognize what’s reasonable in a real-world environment. Setting Expectations The single most important factor for any successful DLP deployment – content discovery or otherwise – is properly setting expectations at the start of the project. DLP tools are powerful, but far from a magic bullet or black box that makes all data completely secure. When setting expectations you need to pull key stakeholders together in a single room and define what’s achievable with your solution. All discussion at this point assumes you’ve already selected a tool. Some of these practices deliberately overlap steps during the selection process since at this point you’ll have a much clearer understanding of the capabilities of your chosen tool. In this phase, you discuss and define the following: What kinds of content you can protect, based on the content analysis capabilities of your tool. Expected accuracy rates for those different kinds of content; for example, you’ll have a much higher false positive rate with statistical/conceptual techniques than partial document or database matching. Protection options: Can you encrypt? Move files? Change access controls? Performance, based on scanning techniques. How much of the infrastructure you’d like to cover (which servers, endpoints, and other storage repositories). Scanning frequency (days? hours? near continuous?). Reporting and workflow capabilities. It’s extremely important to start defining a phased implementation. It’s completely unrealistic to expect to monitor every nook and cranny of your infrastructure with your initial rollout. Nearly every organization finds they are more successful with a controlled, staged rollout that slowly expands breadth of infrastructure coverage and types of content to protect. Prioritization If you haven’t already prioritized your information during the selection process, you need to pull all major stakeholders together (business units, legal, compliance, security, IT, HR, etc.) and determine which kinds of information are more important, and which to protect first. I recommend you first rank major information types (e.g., customer PII, employee PII, engineering plans, corporate financials), then re-order them based on priority for monitoring/protecting within your DLP content discovery tool. In an ideal world your prioritization should directly align with the order of protection, but while some data might be more important to the organization (engineering plans) other data may need to be protected first due to exposure or regulatory requirements (PII). You’ll also need to tweak the order based on the capabilities of your tool. After your prioritize information types to protect, run through and determine approximate timelines for deploying content policies for each type. Be realistic, and understand that you’ll need to both tune new policies and leave time for the organizational to become comfortable with any required business changes. We’ll look further at how to roll out policies and what to expect in terms of deployment times later in this series. Define Process DLP tools are, by their very nature, intrusive. Not in terms of breaking things, but intrusive in terms of the depth and breadth of what they find. Organizations are strongly advised to define their business processes for dealing with DLP policy creation and violations before turning on the tools. Here’s a sample of a process for defining new policies: Business unit requests policy from DLP team to protect content type. DLP team meets with business unit to determine goals and protection requirements. DLP team engages with legal/compliance to determine any legal or contractual requirements or limitations. DLP team defines draft policy. Draft policy tested in monitoring (alert only) mode without full workflow and tuned to acceptable accuracy. DLP team defines workflow for selected policy. DLP team reviews final policy and workflow with business unit to confirm needs have been met. Appropriate business units notified of new policy and any required changes in business processes. Policy deployed in production environment in monitoring mode, but will full workflow enabled. Protection certified as stable. Protection/enforcement actions enabled. And here’s one for policy violations: Violation detected; appears in incident handling queue. Incident handler confirms incident and severity. If action required, incident handler escalates and opens investigation. Business unit contact for triggered policy notified. Incident evaluated. Protective actions taken. If file moved/protected, notify user and drop placeholder file with contact information. Notify employee manager and HR if corrective actions required. Perform required employee education. Close incident. These are, of course, just rough samples in text form, but they should give you a good idea of where to start. Share:

I was driving around listening to Car Talk on NPR this weekend, and it was an incredibly insightful lesson on risk tolerance and risk perception. I tend to do a lot of errands over the weekend around that time, so I usually catch 20-40 minutes of it every week as I’m in and out of stores. Pretty much every week you’ll hear things like: Caller: My car’s making this grinding noise when I accelerate. CT: How long has this been going on? Caller: About a year or so. CT: And why didn’t you take it in? Caller: I’m worried it will be too expensive to fix. Gee, that sounds familiar. Or these calls: Caller: My engine feels like it’s running slow or something. CT: Is the check engine light on? Caller: Why yes, how did you know? CT: And let me guess, it’s been on for three months? Caller: Okay, who called and told you? CT: No one [Click and Clack laugh]. So why didn’t you check the engine? Caller: I’m scared it will be expensive. Then there are these calls: [long discussion figuring out the problem] Caller: So I just need to take it in and get it fixed? CT: Yep, that’s it. Caller: Will it be expensive? CT: Maybe, about [x dollars], but it will be a lot more expensive later if you don’t. Caller: Oh, that’s a lot. Do you think I’ll be okay if I don’t get it fixed? CT: As long as you don’t need a car, you’ll be fine. Think about all those cavities you could have avoided by going to the dentist on a regular basis, or that big air conditioning repair you could have skipped if you just performed the annual maintenance on time. Then stop complaining that your users “just don’t get it,” or stop whining about the business ignoring you. Share:

Update: See Update To The iPhone Security Tip. Encrypted networks are safe to remember. The other day I was wandering around San Francisco on a work trip, and I freaked out when I noticed the WiFi indicator on my iPhone was showing an active connection to some random network. I never have my phone set to connect to unknown networks, so I quickly jumped into the settings to see what the heck was going on. Turns out I was connected to “tsunami” which is a common default name on Cisco wireless gear. Like the Cisco gear in our community center, which just a week or so before I was playing with. And that got me thinking. Many of you probably connect to wireless networks with common names- like Linksys, 2WIRExx, tsunami, or whatever. In other words, either default networks, or names (like those used at conferences and airports) that are in common use or easy to find. But when you remember those on your iPhone (or computer for that sake), it only remembers the network ID (SSID), not that actual network! Your iPhone doesn’t know the difference between “tsunami” in your community center, “tsunami” in an office building, and “tsunami” running on some bad guy’s laptop to see what naive fools will connect to it. When you trust a network you’re just trusting a name anyone can use, not something really unique to that network. Your iPhone will then connect to any network using that name. Why is that bad? Go read this article I wrote at Dark Reading. An attacker can set up his or her laptop to broadcast that name, then perform a man in the middle attack to anyone who connects. They can sniff and modify any traffic going to your iPhone. Why is this more serious on an iPhone than your laptop? Because you walk around with your phone all the time, often checking things like email in the background. Another problem with the iPhone is that its VPN doesn’t automatically reconnect if the connection drops. Thus, even if you connect via a secure VPN, you might find your connection got dropped and your phone happily continues, sending all your traffic unencrypted. Here are my best practices for iPhone wireless security: Turn on “Ask to join networks”. If you have a home wireless network, use an obscure name with some random numbers in it. This reduces the odds you’ll ever hit another one with the same name unless someone specifically targets you. On your home network, don’t broadcast the SSID (sure, easy to figure out, but we’re just trying to reduce our risks). If you need to connect to a public wireless network, use a VPN to protect your traffic. In the VPN settings, after you configure your connection, turn on the “Send all traffic” option. When you’re done with the network, click on the “Forget this network” button in your WiFi settings. On my phone I only have it set to connect at home (a weird name), and I use AT&T EDGE when I’m out of my house. I have a VPN server set up at home for those rare occasions I connect from a conference network. The good news is that your iPhone doesn’t send out “probes” for known networks. This would be an easy way for a bad guy to know even those obscure SSIDs you use at home. Good move on Apple’s part- now I just want them to make the VPN connections persistent. Share:

Had another one of those real world experiences today that was just begging for a blog post. A couple hours ago I was driving down the highway on my way to my physical therapy appointment when I saw a rollover car accident on the side of the road near an on-ramp. There were a bunch of bystanders, but the first police officer was just pulling up and there was no fire or ambulance in sight. There is some good news and some bad news if you get in an accident by that particular on-ramp. The good news is it’s right down the road from the Mayo clinic. The bad news is a lot of doctors drive on and off that ramp at any given moment. Very few of them work in the emergency department. I first became an EMT in 1990, went on to become a full-time paramedic, and have dabbled in everything from ski patrol to mountain rescue to HAZMAT over the years. I’m still an EMT, although not doing much with it since moving to Phoenix. If I’d knocked someone up when I got certified they’d be getting ready for college right about now. That is, to be honest, a little scary. Since no responders were on scene yet I identified myself and asked if they needed help. The other bystanders, including the first doctor, stepped back (she was calling the patient’s parents). The patient was looking okay, but not great, crying and complaining about neck and head pain. She did not remember the accident. The next bit went like this: DAD (Dumb Ass Doctor): Here, let’s put this under her head [holding rolled-up jacket] Me: Sir, we don’t want to do that. DAD: I’m a doctor. It’s fine, she was walking around [Note, most patients who scramble out of their overturned car through the missing windshield wander around a little bit until someone sits them down.] Me: What kind of doctor? DAD: Anesthesiologist. Trauma anesthesiologist. It’s fine. [Note, that means he puts trauma patients to sleep in an operating room so a surgeon can fix them.] Me: Sir, we have a patient complaining of head and neck pain with a loss of consciousness; you do NOT want to manipulate her head. DAD: I’m a doctor [inserts pillow, as patient cries out from the pain]. Gee [other doc’s name] don’t you remember that emergency training and the chain of command? Me: You’re the doctor, can you gossip with your friends and stand over there now while I make sure she can still move? For the record, I’ve never met an ER doctor in the world that will clear a patient’s c-spine in the field with that mechanism (a rollover) and pain on touch and movement. I would never pretend to be able to anesthetize a patient, but this bozo, like many doctors, thinks he’s fully capable of directing field treatment completely outside his experience. Here’s the thing;as professionals we train hard at becoming experts in a particular domain. This doesn’t make us experts in adjacent domains. For example, I may be a security expert, but despite some broad knowledge I’ve specialized in certain areas, like information-centric security. If, for example, you needed me to read your IDS logs or deploy your UTM I’d send you to someone with practical network security knowledge. When doing risk assessments or practical, on-the-ground security, make sure you engage the right domain experts before you break something. You may have kung-fu, but that doesn’t mean you aren’t a total freaking idiot. Share:

It took a little longer than expected, thanks to me being totally swamped post-surgery until now, but let’s congratulate our winners of a free year of Debix identity theft protection: myemailisvalid, Jay, and Brett. Thanks for participating, and you’ll be hearing from us via email. Share:

I was reading one of Alan’s posts over at StillSecure, based on the Lending Tree debacle. He starts with a bit I totally agree with: This sort of stealing your competitors information has been going on for decades, well before computers and cybercrime were around. However, this is a great example of some things not going out of style. Obtaining your competitors information is a great motive, computers are just the container where the information is kept. This is something I’ve been harping on for a while- the only new thing about cybercrime is the vector; nearly every crime we see has a corollary in the physical world. Why? Because we’ve been screwing each other over since before we were technically humans. We’ve been taking things that don’t belong to us since far before we had any concept of commerce or society. That’s tens of thousands, if not hundreds of thousands, of years of criminal refinement. Nigerian 419 scam? It’s the Spanish Prisoner. DoS? It’s sabotage or a protection racket. You name the cybercrime, and I can name the pre-cyber-crime. Now how does this practically apply to how security professionals do their job? Focus on the crime, not the tech. When you’re piecing together your defenses, monitoring for incidents, or cleaning up a mess, always remember that someone attacked for a reason. If they didn’t steal something, hijack an asset for their own use, trespass for the fun of it, or vandalize/break something, keep looking. Odds are you still haven’t figured out why they are there, and what the real target is, and your day ain’t over yet. A person may change, but people don’t. Share:

I know what’s running through your head right now. “WTF?!? Mogull’s totally lost it. Isn’t he that data/information-centric security dude?” Yes I am (the info-centric guy, not the insane bit), and here’s the thing: The concept that you can run around, analyze, and tag your data throughout the enterprise, then keep it current through changing business contexts and requirements, is totally ridiculous. Sure, we have tools today that can scan our environment and tag files based on policies, but that just applies a static classification in a dynamic environment. I have yet to talk with a customer that really does enterprise-wide data classification successfully except for a few, discrete bits of data (like credit card numbers). The truth is that’s data identification, not data classification. Enterprise content is just too volatile for static tags to really represent its value. Even those of you in defense/intelligence don’t really do granular data classification. You just hit things with a big sledgehammer. “Is it Top Secret? Then we keep it totally isolated. What, this bit isn’t Top Secret but it’s on a Top Secret server? Frack it, we’ll just make it all Top Secret and be done with it. Need to pull it out? Go fill out this form.” This post was inspired by a conversation yesterday where another information-centric wonk criticized the idea that data can be self-describing in any meaningful way, part of my principles of information centric security. While he caught the first point, he missed my meaning in the second point (policies and controls must account for business context) which means that the data self describes in such a way that business context can then be applied to determine value in that situation. I know it sounds like science fiction, but we’re starting to see real-world scenarios, and I’ll be the first to admit this is going to be a big area of advance over the next few years. Now there is one piece of data classification that isn’t dead (I like sensational headlines just like the next person). That’s the business process of prioritizing information. That’s where you sit down with business executives and determine what information is more valuable than other information for your organization. It will drive all the protective strategies and dynamic protections we talk about when applying information-centric security. That’s absolutely vital to successful information security. Thus we prioritize and identify information, but this is different than data classification, which is the concept that after these two steps, we can apply static labels as a way of protecting information. That, my friend, is not only dead, it was never really alive. Share: