What the Government Needs vs. How the Government Thinks

The Federal Government is trying to update its approach to security; will it succeed?

At the end of 2010, the then-CIO for the US Government, Vivek Kundra, published a paper outlining 25 points to reform Federal IT Management. I’d heard of it at the time, but not read it. However, with the President having recently signed the sequestration order into law, it’s being passed around again with “where are we now and where are we going with this” notes attached.

There's nothing wrong with the paper, per se. In a nutshell, it says that the government should focus its energies on programs that yield obvious benefits, and on hiring programs that will attract rising IT stars. The problem is that, for the most part, the Federal government has no idea what will attract such people to work for and with it. And the reason for that is that the way that most IT professionals - especially the young geniuses that the government is hoping to snare - think is complete antithesis to how the government works, and vice versa.

Like any generalization, of course, there are exceptions to what I’m talking about. There are certainly a lot of brilliant people whose way of thinking is not antithetical to the way the government works, and many of those people are in fact working for the government, or working for companies that support the government. And there are some people who, regardless of the fact that they don’t have a meeting of minds with the government, will still choose to work for it in some capacity, for various reasons. But it’s very unlikely that the government will be able to attract the sorts of people that Kundra’s paper is talking about, at least in large quantities. The fact that the government representatives who talk about this hiring concept don’t realize how unrealistic they’re being is rather worrying.

There are several reasons why the government won’t, for the most part, attract the best and the brightest young minds in IT. First of all, as I’ve mentioned, there’s the fact that the government way of thinking and doing things is antithetical to your typical hacker. (Note to the reader: if you feel that the term hacker is pejorative, then you are not one.) This isn’t true in all cases, and certainly a number of us feel that it’s worthwhile to try to work from within the government system, but I’d venture to guess that those of us who chafe less in the government are a bit older and more staid than the “cyberninjas” the government is trying to attract (most of whom ridicule that term). The government already has a lot of people in its employ who might be able to fit their idea of “cyberninjas”, but the government is not willing to spend the money to train them.

And this lack of desire to spend money where it would do good leads to the second problem: the government works by spending the least amount of money possible to achieve the best result it can. If a particular company or entity is the lowest bidder on a project while promising the same or a better result, that entity will be awarded the job. Because the citizenry are the ones paying for the project through their taxes, that’s the way it has to be. However, it doesn’t give the government a lot to work with in terms of attracting “cyberninjas”, who can make a lot more in the private sector. In general, a government job is comfortable and secure, but it can’t match the perqs and thrills that come with being a famous name in IT culture. In fact, the government would frown on a lot of those perqs and thrills (which brings us back to the difference in mindsets), and it wouldn’t want to or be able to fund even those it would not frown on (such as extensive traveling to security-related conferences and training).

A third issue is something I touched on in my previous article about Continuous Monitoring. The Federal government is so focused on compliance that it’s seemingly forgotten that there’s a lot more to security. I see a lot of people saying “what is the right thing to do” and other people saying “it says right here that...”. Adherence to policy is necessary and I’m not trying to knock it, but it’s not the be-all and end-all of securing information. The government as an entity may know that - although I’m not taking any bets - but I would estimate that 99.9% of the people who are actually in the trenches doing security don’t have the first clue to proceed, other than finding out what the policy is so they can tell other people how to adhere to it. And that is a problem.

Vivek Kundra’s paper was written only a couple of years ago, and it’s still very germane. However, I’m not sure how realistic it is. Kundra has himself returned to the private sector, but I wonder what he thinks now, especially about methods to attract young and brilliant IT professionals. The government really needs fresh blood, but I’m not sure it will know what to do if it can get what it needs.

Continuous Monitoring: You’re Doing It Wrong

The Federal Government is not really sure what it’s talking about. Are you?

[This article also appears at Great Lakes Computer.]

One of the surprising challenges of being an Information Security professional is keeping up with the current buzzwords and jargon in the industry, and it’s made more difficult by the fact that not everybody uses those terms in the same way. For instance, given the posture of an organization and whether or not it’s sales-based or based on something else (research, defense, etc.), the term Data Loss Prevention (DLP) can mean different things. However, when I went back to work for the US Federal Government, I thought that Continuous Monitoring was one term that was clear as crystal.

It turns out, however, that the government, which of necessity places a huge emphasis on regulatory compliance, is using the term in an entirely different way from the commercial sector. Continuous Monitoring, as used by the private sector,  is actually a relatively new concept, and that’s because it’s only really been in the last few years that we could spin up machines with enough speed and power to do the job in real time.

What Continuous Monitoring should mean is a way to watch what’s happening on your network in real time, integrated with logging so that you can go back and follow patterns, graph anomalies, and so forth. For instance, a good CM setup should tell you when most of your users are using social media, or if there’s a spike in activity to or from a certain address, and so on. The information has always been there, but it’s been hard to find, and now we have the means to automate grabbing those details and presenting them in such a way that network and security admins can form a much better mental picture of what’s going on.

However, NIST and the Federal Government have made this term their own, and they mean something completely different - and far less useful, security-wise - by it. I think that the government’s use of the term completely misses the point and buries CM under a pile of compliance paperwork, and the result is that nobody is really watching the network the way that they should be.

What the government means by Continuous Monitoring is looking at the NIST-defined security controls - policy statements dealing with regulatory compliance - for a given network and deciding if they are applied correctly, given the threats list that the government subscribes to and the vulnerabilities that routine scans discover.

NIST does define CM as “maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions”, which sounds as if it would fit in with the automated approach that I described briefly above, but the problem is that most of the people who are actually responsible for performing this monitoring are using completely manual methods to demonstrate compliance. For instance, I have been told that presenting auditors documented evidence of testing security controls in small batches over time constitutes Continuous Monitoring because it shows “continuously” action promoting the security of the network I’m responsible for. I suppose it doesn’t hurt, but that’s not what CM should be.

Change is slow in the government, but I’m hopeful, as many agencies (including mine) are installing new vulnerability and monitoring solutions that I think will really be an eye-opener on the subject of CM. Compliance is important, but it doesn’t define Information Security; it’s just one part of the whole.

the importance of being anonymous...?

I haven't posted here in a while. I've never been more than kind of intermittent, but currently I have a good reason; I'm writing weekly articles for Crain's Cleveland Business. They're a little non-technical (basic security for businesspeople), so the content is probably not what I'd choose to share here anyway, but with 500-1000 words per week going there, I'm not as motivated to post here.

That said...last night, I went to our local chapter ISSA meeting last night. They weren't charging admission to the meeting, so it was basically free CPEs (and free pizza). I was a little late for the meeting due to mixing it up with another meeting I have next week, so I was a bit flustered as I entered the venue.

As I approached the room where the meeting was being held, I saw a sign on the wall about the meeting saying to text to a certain phone number for a door prize. I had my phone in my hand anyway, so I paused and sent the SMS, then proceeded into the meeting.

Realizing I was late, I quickly sat down. The lecturer, Branson Matheson, was talking about social engineering, which is a subject that's very interesting to me. During the lecture he mentioned the "hack" he'd perpetrated and wondered aloud how many phone numbers he'd captured that way.

Yup, okay, he got me. Turned out, too, that I was the only person in the room who fell for it, although that fact is mitigated to some extent by the fact that not everybody in the room actually saw the sign. But really...did he in fact "get me"? What exactly happened here?

It's no secret, I'm looking for a job. Because of this, I give people my contact details several times a day. I WANT people to have my phone number. In fact, had I arrived at the meeting early, as I'd intended to do, I would have been passing out my virtual business card (via Cardcloud) to anybody who would take it. People very often do, in fact, exchange business cards at such meetings, which will usually include a mobile number among others. So, practically speaking, Mr. Matheson didn't actually gain any knowledge that I wasn't willing for him to have, and in fact, he didn't have a name attached to that number. 

Mr. Matheson's point was that there's nothing stopping a hacker from putting up signs randomly saying "text to [phone number] for free offers" and actually collecting phone numbers that way, and it's a very good point. I was fairly sure, when I sent my text, that I was sending it to an officer of the local board (and he is, in fact, the VP of the local chapter), so while I "fell for" his trick, I'm actually just as happy that he has my phone number. Maybe he'll refer me to a new job. ;)

what my cissp means to me

I've had my CISSP for six and a half years. I would have had it before that, but I couldn't really afford study materials and the test. When the company I was working for in 2005 offered to pay for it, I got it pretty much immediately.

While on the one hand, it's great that my company was willing to pay for it, it was also a bad thing because it signalled a trend. When a certification is necessary to obtain or retain a job, the idea is supposed to be that the people who hold that job are the best and brightest, but what it really means is the opposite, and the certification becomes devalued. When I got my MCP in networking back in 2000, it was the furthest I wanted to go, because Microsoft certification had become a joke. Now the same is happening with the CISSP. A lot of people say it's already happened.

When I took the CISSP exam in April of 2005, I had just finished a week-long bootcamp, also paid for by my company. I don't want to say that the bootcamp didn't teach me anything I didn't already know, but I will say that there was nothing that I didn't know at least something about. For instance, I learned things about encryption that I hadn't known before, but I'd certainly known the base concepts and wasn't "lost" like a lot of the other people in my class. I was pretty sure that I would pass the exam because I had the requisite 10 years experience in Infosec already.

That said, walking out of the exam, I wasn't sure I had passed. I wasn't the first person to leave but I left a lot of other people in there. I was very hopeful, but I honestly had no idea how I had done. I hear this happens a lot. I'd been sitting in an uncomfortable chair all week, and I don't test well (which is part of the reason why I don't have a whole STRING of certs), but I was hopeful.

I was elated to find I had passed. A lot of other people who took the boot camp with me -- including another person from my company -- did not pass at their first sitting. Some of them subsequently went on to get their CISSPs later. Some of them left Infosec. I was glad that part was over, but harder than taking the test was finding a sponsor. It's not that nobody would sponsor me; it's that I took the certification seriously and wanted someone who actually knew my work to endorse my certification. I eventually asked a representative from one of my company's customers, a person with whom I'd worked extensively. Neither of us has ever had cause to regret that decision.

As I say, I take my certification very seriously. As someone who is largely self-taught -- meaning not that other people didn't help to teach or mentor me but that I was not spoon-fed my knowledge, choosing to actively pursue my IT education through nontraditional means -- I am deeply grateful to have that certification and spend a good deal of my time continuing to educate myself. Unfortunately, the more I know, the more I realize I don't know. But that also gives me hope, because I've never believed that there's such a thing as an expert in any field. In fact, if one of my esteemed colleagues -- most of whom are men -- calls himself an "expert", that's a pretty good indication he's not. (It's okay if someone else says it. Just, really...sooo tacky to say it about yourself. Just sayin'.)

I take it seriously, but I've watched it become devalued. For instance, the DoD mandates that IT personnel of a certain level have or obtain a CISSP, including military personnel who are assigned to IT jobs. Well, uh, great, except that I can personally state that some of those personnel have no idea what they're talking about when it comes to IT in general and Infosec in specific. Since they can't exactly be fired (or, not easily) from their jobs for not passing the exam, it follows that the exam must be rendered passable for them, i.e. through extra coaching etc. Basically, in the end, there are a lot of people who have CISSPs who have no real interest or aptitude for Infosec -- never mind the passion that I and a lot of other "older" CISSPs bring to the mix. It's become just another checkbox, like old technology. I see people disparage the cert every day now.

A side effect of all this is that the assumption is often made that if you have a CISSP but a) no other certs or b) someone doesn't personally know your work that you're a newbie and nothing you say is meaningful or relevant. I've been treated this way several times by some of my esteemed colleagues who assume that I'm one of these newly-minted CISSPs who got handed the cert instead of earning it. And really, what can I say? I'm not one of the "old salts" in this business, as some of them are. But at the same time, I'm not one of the newly-minted CISSPs currently rolling off the assembly line. I've been "doing Infosec" since before it became trendy, and I'm certainly passionate about it. I have paid -- and continue to pay -- my dues.

My certification continues, and will continue, to mean a lot to me, regardless of what other people think. I may be the manic pixie dream girl of the Infosec community, but I'm here to stay...and so is my certification.

data loss redux: thinking organically

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.

data loss prevention: a red herring

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.

the most important infosec component

Also posted in my Securiteam blog.

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.