data loss redux: thinking organically

Originally posted to Black Cats and Smoke and Mirrors

A little while ago I wrote about DLP, or Data Loss Prevention, and how the term is something of a red herring because, in reality, everything we do is about preventing data loss; ergo, the concept can’t be neatly productized. I still feel that way.

However, a few days after I posted it, I was contacted by a fellow named Pablo Osinaga, who has co-founded a startup called Kormox. He wanted me to see his company’s DLP solution, profiled by SC Magazine.

After reading SC’s blurb on the subject, I was quite intrigued, and arranged a web/phone meeting with Mr. Osinaga. For a little over an hour, we discussed Kormox and the concept of DLP.

As I said, DLP is a very difficult concept to productize. Everyone needs to prevent the loss or leakage of data, but everyone — every enterprise, every business, every organization, even every person — has different data and different types of data that they need to protect. Some organizations are concerned with mobile data; some are concerned with file shares; some are concerned with PII; and so on. No one vendor — no one product — has a fully comprehensive DLP solution because what DLP means is so dependent on each organization’s mission and needs, which not only differs among organizations but can be subject to change within an organization over time.

One of the first things that Mr. Osinaga mentioned, in presenting his company’s solution, was that enterprises have become more organic and less structured. I could not agree more. I have worked for many different security solutions vendors, and I hear over and over about the “special snowflake syndrome”, how every organization thinks they are “different” in some way, but they are really all the same. The trend, with every security vendor I’ve worked with, is to pigeonhole potential and existing customers, to basically tell them that they can’t have what they say they want, to fit them to the solution that the vendor has, in their infinite wisdom, envisioned and created. Yet as time goes on, and as Mr. Osinaga noted, enterprise structure is becoming more fluid, less definable, and less able to be pigeonholed.

Kormox’s solution starts with data classification. It’s so simple, and so logical. Of course you have to classify your data. But it’s not enough to say “I have to protect medical records” or “I have to protect credit card numbers”. In the DLP-productization game, vendors talk about what kind of data you want to protect, and then they talk about how they’re going to protect it, but they don’t really cover the territory of what, exactly, your data means to the people who are using it. That’s your problem.

And that’s how Kormox differentiates itself from the crowd: data classification is a major step, and it involves finding out not only what the data is (as opposed to merely what kind of data), but the flow of the data: where it is, who is using it, how they use it, where it’s going, where it’s been, and so on. All this is part of the classification, and it brings DLP back to the true “asset management” model of Information Security, where the asset is the data itself, not the (often fungible) hardware on which it rests.

After the data has been classified, the product allows the asset owners to implement controls in a similarly organic fashion. In essence, it takes the organization from the situation of “I know I need to protect our data” to “I know where and what all our data is, how it’s used, and what controls are on it” — something that no other DLP solution does.

I’m not laboring under an illusion that this product is perfect; no product could be. But I do think that Kormox is going in a necessary direction with their concept of data flow as a part of classification. At the moment it’s a bit clunky looking, but from what I saw in our meeting, it is definitely worth a look.

I’d like to note that I am in no way compensated for writing about Kormox; I’m writing about it because Mr. Osinaga contacted me as a result of my last DLP article, and so I thought it was only fair to talk about what I found out in our meeting.

Share

data loss prevention: a red herring

Originally posted to Black Cats and Smoke and Mirrors.

A few years ago, the acronym DLP, which stands for Data Loss (or Leakage) Prevention, hit the security market. Every enterprise was crazy for it, every vendor touted it, and everybody had a different idea of what, exactly, it was.

Half a decade has passed and we still don’t know. The problem is that DLP is a misleading term, because preventing data loss is the key reason for information security in the first place. If you think about it, every component of your enterprise’s security solution, from policy to compliance reports, is in place to prevent your data from being lost or leaked.

There is no panacea for the problem of potential data loss, no matter what your vendor of choice might tell you. The smartest vendors don’t even try to claim such a thing. Because nobody can agree on what, exactly, DLP is, nobody has a complete solution. However, the industry in general does agree on a few key concepts:

- A product that can recognize credit card / SSN / other identifying data both at rest and in motion and (better) control the transmission of such data is a necessary part of your security solution, if you deal with such data

- A product that can tag certain types of files and control the transmission (in whole or in part, encrypted or not) of those files is key

- A product that can recognize certain types of removable storage device being attached and/or written to and IMMEDIATELY control this activity is important

- If your business employs “mobile warriors” and you do not implement some sort of whole disk and file encryption, your data is at risk

- If your employees use mobile phones for business purposes then you should have some control over what type of data they can access on those devices

These are just a few of the concepts behind DLP, and those concepts keep changing as new risks are discovered. Adding to the complexity is the fact that some issues are going to apply to some enterprises, whereas other issues will be unimportant. For instance, the DoD never, ever transmits SSNs in the clear. However, many private sector businesses transmit SSNs in the clear as a matter of course (although they shouldn’t). Ergo, when the DoD talks about data leakage, they are most often concerned with SSNs and other types of personally identifying information (referred to as PII), but protecting credit card information is not so much a concern. The private sector, on the other hand, is much more occupied with protecting credit card information but not so much (say) SSNs, driver license numbers, and other types of PII. Ergo, the part of the DLP solution that identifies certain types of data at rest and in motion needs to be flexible and customizable to be useful for the environment it’s being used in.

Whole disk and file encryption is probably the easiest piece of the DLP pie to choose and to implement. In fact, you can get your whole disk encryption from one source and your file encryption from another, and as long as they don’t fight with each other you’re fine (as long as you remember that nothing is 100% foolproof, that is). But after that, it gets more complex, and vendors only make it worse when they try to convince you that their solution does everything you need for DLP. Well, no, it doesn’t.

A smart executive will realize that DLP is not a single concept, and certainly not a single product; rather, it’s a method. The first thing to do is to revisit your security policy. If you do not have a section detailing the specific types of data that you need to protect from loss/leakage and some (probably non-vendor-specific) methods for doing so, then it is time for a rewrite. [Note: you should be revisiting and perhaps editing your security policy on at least a quarterly basis anyway.] Sit down with your fellow executives and brainstorm your data pitfalls, and then do the courtship dance with vendors who claim to have solutions to these pitfalls. Again, do not fall into the trap of the One True Solution. It doesn’t exist.

As you work on your DLP method, you will see that many of your current solutions and/or their vendors already work towards securing your data…of course, because that, as I said, is the entire point of infosec. For instance, your vulnerability scanner already scans for removable storage devices (both currently inserted and having been inserted at any time). That’s great, but it’s asynchronous. Does the vendor have a real-time solution (agent or sniffer based) that does the same thing? You already have auditing in place to determine if a file’s been touched. How about if it’s been excerpted and transmitted without being edited? And so on. If your current vendors have addons that can fit your newly-perceived needs, then that can perhaps save you money and implementation time.

One big problem with potential data leakage is that many businesses, to save money, don’t issue their employees mobile phones but rather reimburse the employee if his or her existing phone is used for business purposes. However, in many cases, “business purposes” doesn’t mean just calls; if an employee is using a smartphone, he or she is probably also downloading and responding to email and possibly also VPN’ing into the network and accessing corporate resources. If you’re not virus scanning and otherwise protecting his phone in the event of theft and other compromise, then all the time and expense that you’ve gone to in implementing disk and file encryption on his laptop is pretty much useless.

All of this is a lot to think about. The good news, especially if you are a smaller business, is that you don’t have to think about it and implement it all at once. This is why you should be always spiralling back to your security policy in order to revist your business’s current needs. Each time, you can tighten up your data security a little more.

Share

the most important infosec component

Also posted in Black Cats and Smoke and Mirrors.

When I first started working in Information Security, the big “thing” was firewalls. It’s probably hard to believe now, but back then, it wasn’t simply a question of which firewall to install but rather whether to install one at all. I spoke to a lot of former sysadmins who had been repurposed, willy-nilly, as security engineers. They didn’t know much about network security, but they did know that they probably needed to keep “bad stuff” out: hence, the firewall.

These days, if you are in charge of security for an enterprise, you don’t ask yourself if you should install a firewall; instead you’re trying to figure out what types and how many different kinds of intrustion prevention you can get away with on your budget, along with asset and vulnerability scanners, SIEMs, and on and on. Information security has been productized to the point where it’s easy to forget the single most important infosec component in any business, and by that I mean the people who work for and with it.

Smart CEOs these days will say that their most important assets are their employees. That’s very warm and fuzzy, but anybody who has been let go from a company for any reason that isn’t related directly to job performance will tell you that upper level management cares much more about the bottom line than about the inner workings of their employees’ minds. I’m not crazy: a business has to make money, because that is the reason it exists. But businesses also have to realize that employees are, in fact, both assets and liabilties when it comes to that bottom line.

Consider this: every single one of your employees has a life outside his or her job. Mary is a devout Catholic who sings in her church’s award-winning choir. Bill plays in a poker league on Thursday nights and weekends. George and his wife Tess, who both work for different departments, sell Amway together. Jeannette saves up her paid time off to travel all over the world. And Jack? That kind of gothy looking guy with the tattoos that you have working in the infosec department, the one who begs you to send him to SANS and Black Hat every year? Well, when you don’t, he splits the difference and goes to LayerOne and SchmooCon and DefCon.

You can’t control what your employees do in their spare time, nor should you. But if you think that they are not thinking about what they do in their spare time while they are at work, you are wrong, and that is what so many executives don’t take into account when they are thinking about their company’s security posture. The “rank and file” care about the company’s bottom line insofar as it provides them with a paycheck, and most of the time, that is where their caring stops. They do not realize, because it is not part of their job to do so, that what they are thinking or doing at any given point could affect your business. You don’t realize it either, and that’s a problem, because it IS part of your job to know that.

If your business is subject to government or industry regulation(s), you very likely have a security policy. This policy defines physical and network assets, who has access to them, and some kind of vulnerability management and compliance schedule, at a minimum. You probably think that the “access” part takes care of intentional or unintentional abuse of your non-human assets by your human assets: they can’t use the red stapler; they can’t access the HR file server; they can’t post to Facebook from the company network. Even if you can’t stop them, they know from reading the policy that if they are caught doing any of those things, they could be punished, including losing their jobs.

Your employees are smart and innovative: that is why you hired them. They can, or think they can, outwit your automated security components to do what they want to do, and as long as they are also getting their jobs done, no harm no foul, right? Wrong: every minute a human asset spends doing something at work that is against your security policy is a minute of their salary, and, should it end up causing problems that need to be corrected, the salaries of other human assets. This leads in turn to the company’s bottom line being adversely affected over time.

You might think that the obvious solution to this problem is to employ tighter controls and install more automated security components in order to get your human assets to adhere to your security policy. However, I am going to go out on a limb and say that your first step, when faced with employee non-adherence, is to revisit the security policy and determine how it can be brought in line, while still remaining in compliance with governement and industry regulations, with the reality of what is going on with your employees’ lives.

Your employees fail to comply with your security policy, for the most part, not because they don’t care but because they don’t understand how it affects them. Given how smart they are (right?), if they don’t understand this, it is because they’ve never had it explained to them in a way that they can relate to. As an executive of the company, this is your responsibility: to show your employees how they directly affect the amount of money in their paychecks, and to work with them to make the company, and they themselves, earn more rather than stealing from the bottom line.

Alice likes to post to Facebook on company time? Create a company Facebook page and put Alice and her posty friends in charge of it. Mary is spending too much time on choir-related activities at work? See if you can work her choir or a subset thereof into company events, to everybody’s benefit. You’re worried about Jack’s possible hackerish activities? Send him as an official company rep to the conferences he already attends, plus the ones he wants to attend, and encourage him to share his own ideas for strengthening the security posture of your enterprise. All these things will cost money up front, but you will find that when your employees feel that they are being listened to and valued for who they are, those upfront costs will bring in more revenue for the company. Ask Google.

There is absolutely no way to completely automate security, because you can’t control what is going on in the heads of your employees. But when you truly treat your employees as the assets you say they are, your security posture WILL improve.

Share