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 accidently connecting while wandering around, even if it’s still called “tsunami”.

In our last post we talked about the preparatory work before you begin your DLP content discovery deployment, including expectation setting, prioritizing information for protection, and defining your workflow. By this point you should know what policies you’d like to deploy, where you want to start protecting the content, how you’d like to grow that protection after initial deployment, and the workflow for when you detect policy violations.

Today we’re going to move beyond planning into deployment.

1. Integrate with your infrastructure: DLP content discovery tools require either a local agent or file share access to scan content in a repository. In this stage you define the initial repositories to scan and either install agents or load credentials into the DLP system. For endpoints, you should scan C$ or D$ (administrative access to all files) remotely, but a local agent is your best option for managed systems. If you haven’t already, you also need to integrate with your enterprise directory servers so the DLP tool understands users and roles/groups.
2. Build initial policies: For your first deployment, you should start with a small subset of policies, or even a single policy, in alert or content classification mode (where the tool reports on sensitive data, but doesn’t generate policy violations).
3. Baseline, then expand deployment: Deploy your initial policies on a limited number of storage repositories (or endpoints). Once you have a good feel for the effectiveness of the policies, performance, and enterprise integration you can expand into a wider deployment, covering more of the enterprise. After the first few times you’ll have a good understanding of how quickly, and how widely, you can roll out new policies.
4. Tune policies: Even stable policies may require tuning over time. In some cases it’s to improve effectiveness, in others to reduce false positives, and in still other cases to adapt to evolving business needs. You’ll want to initially tune policies during baselining, but you’ll continue to tune them as the deployment expands. Most DLP clients report that they don’t spend much time tuning policies after baselining, but it’s always a good idea to keep your policies current with enterprise needs.
5. Add enforcement/protection: By this point you should understand the effectiveness of your policies, and have educated users where you’ve found policy violations. You can now start switching to enforcement or protective actions, such as moving, encrypting, or changing access controls on files. Any time you make a file inaccessible, you should leave a plain-text contact note (or send the user an email) so they know why the file is missing and how to ask for an exception. If you’re making a major change to established business process, consider scaling out enforcement options on a business unit by business unit basis (e.g., restricting access to a common content type to meet a new compliance need).

Deploying DLP content discovery isn’t really very difficult; the most common mistake enterprises make is applying policies too widely, too quickly.

It’s also important to keep in mind that there are four general types of discovery deployments. With a monitoring/alerting deployment you roll out and generate alerts in the DLP system which are then followed up on by incident handlers. These deployments are often for sensitive data types where you don’t want immediate protection, but do want to prompt corrective actions or user education. The second type of deployment is where you add content protection actions, like encryption. It’s typically for very sensitive data types, and as we’ve outlined above often follows an alerting-only deployment. In a compliance deployment we scan for selective data related to regulatory compliance, like credit card numbers- both to ensure sensitive data is remaining within allowed containers, and also to generate compliance reports to show auditors that content is being handled appropriately.

The last deployment is a completely different model- content classification. In this case you are scanning with a very wide scope, often using general policies, to identify and classify systems based on the content they hold. Or, in some cases, you may tag the content as part of a broader classification initiative. Content classification deployments aren’t concerned with alerts or enforcement actions, but rather use these tools to help classify systems and content.

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:

1. What kinds of content you can protect, based on the content analysis capabilities of your tool.
2. 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.
3. Protection options: Can you encrypt? Move files? Change access controls?
4. Performance, based on scanning techniques.
5. How much of the infrastructure you’d like to cover (which servers, endpoints, and other storage repositories).
6. Scanning frequency (days? hours? near continuous?).
7. 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:

1. Business unit requests policy from DLP team to protect content type.
2. DLP team meets with business unit to determine goals and protection requirements.
3. DLP team engages with legal/compliance to determine any legal or contractual requirements or limitations.
4. DLP team defines draft policy.
5. Draft policy tested in monitoring (alert only) mode without full workflow and tuned to acceptable accuracy.
6. DLP team defines workflow for selected policy.
7. DLP team reviews final policy and workflow with business unit to confirm needs have been met.
8. Appropriate business units notified of new policy and any required changes in business processes.
9. Policy deployed in production environment in monitoring mode, but will full workflow enabled.
10. Protection certified as stable.
11. Protection/enforcement actions enabled.

And here’s one for policy violations:

1. Violation detected; appears in incident handling queue.
2. Incident handler confirms incident and severity.
3. If action required, incident handler escalates and opens investigation.
4. Business unit contact for triggered policy notified.
5. Incident evaluated.
6. Protective actions taken.
7. If file moved/protected, notify user and drop placeholder file with contact information.
8. Notify employee manager and HR if corrective actions required.
9. Perform required employee education.
10. Close incident.

These are, of course, just rough samples in text form, but they should give you a good idea of where to start.

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.

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:

1. Turn on “Ask to join networks”.
2. 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.
3. On your home network, don’t broadcast the SSID (sure, easy to figure out, but we’re just trying to reduce our risks).
4. 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.
5. 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.

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.

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.

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.

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.

Thanks in large part to the Attrition.org data loss database, there’s recently been some great work on analyzing breaches. I’ve used it myself to produce some slick looking presentation graphs and call attention to the ever-growing data breach epidemic.

But there’s one problem. Not a little problem, but a big honking leviathan lurking in the deep with a malevolent gleam in its black eyes.

Breach notification statistics don’t tell us anything, at all, about fraud or the real state of data breaches.

The statistics we’re all using are culled from breach notifications- the public declarations made by organizations (or the press) after an incident occurs. All a notification says is that information was lost, stolen, or simply misplaced. Notifications are a tool to warn individuals that their information was exposed, and perhaps they should take some extra precautions to protect themselves. At least that’s what the regulations say, but the truth is they are mostly a tool to shame companies into following better security practices, while giving exposed customers an excuse to sue them.

But notifications don’t tell us a damn thing about how much fraud is out there, and which exposures result in losses.

(Okay- the one exception is that any notification results in losses for a business that goes through the process).

In other words, we don’t know which of the myriad of exposures we read about daily in the press result in damages to those whose records were lost. They are also self reported; and I know for a fact there are incidents where companies did not disclose because they didn’t think they’d get caught.

For example, based on the statistics nearly a third of all breach notifications are the result of lost laptops, computers, and portable media (around 85 million records, out of around 316 million total lost records). About 51 million of those records were the result of two incidents (the VA in the US, and HMRC in the UK). The resulting fraud?

Unknown. No idea. Zip. Nada. In all those cases, I don’t know of a single one where we can tie the fraud to the lost data.

In some cases we really can track back the fraud. TJX is a great example, and the losses may be in the many tens of millions of dollars. ChoicePoint is another example, with 800 cases of identity theft resulting from 163,000 violated records (a number that’s probably really around 500,000, but ChoicePoint limited the scope of their investigation).

What we need are fraud statistics, not self-reported breach notification statistics. We do the best with what we have, but according to the notification stats we should all be encrypting laptops before we secure our web applications, yet the few fraud statistics available support the contrary conclusion.

In other words, we do not have the metrics we need to make informed risk management decisions.

This also creates a self-fulfilling negative feedback loop. Notifications result in measurable losses to businesses, driving security spending to prevent incidents that cause notifications, which may not represent prioritized security/loss risks.

When you read these things, especially on the slides shoved down your throat by desperate vendors (it’s usually slide 2 or 3), ask yourself if each one is an exposure, or actual fraud.