Don't Forget the Forest

I'm frustrated. But it may not be why you think.

I haven't made too many posts on the blog over the last few months, mainly because I've shifted out of the Identity Management space and slid more into a security investigator role. I have always wanted to be a security investigator, and while I'm starting out with a focus on privacy disclosures, I do hope to someday parlay this opportunity into something larger.

As a result of this new set of responsibilites, I'm currently at SANS Baltimore attending Ed Skoudis' SEC-504 -- Hacker Techniques, Exploits, and Incident Handling. (The course is being taught by John Strand, who is an amazing instructor doing a bang-up job). This new opportunity is not why I am frustrated. Quite the contrary; I'm ecstatic at the chance to prove I have the chops for this type of work. However, there's a...vibe, perhaps, that I am first noticing now after almost seven years in Information Security. It's really highlighted in this conference by people at every level - the instructors, the presenters and vendors, and the students themselves.

This vibe is, essentially: we (security professionals) are losing the battle versus cyber-criminals. Staying ahead of black-hat hackers is a deeply-technical game of cat and mouse that requires constant vigiliance to stay ahead of, and you are never really ahead, because once update an antivirus signature, the virus is mutated. Once you patch a piece of software, there's another vulnerability found (or worse-yet, a vulnerability in the patch). It's a daunting, no-win scenario that each security professional has to come to terms with. We, as a community, seem to have accepted the fact that we will not win; that we are just "treading water" as one presenter put it. Collectively, perhaps we just feel that someone has to do this job: it's fun and it pays well, so why not?

So sitting in class today, I had an epiphany. I think we are taking the wrong approach to Information Security. I think instead of focusing so strongly on defensive measures and vulnerability management, we should focus on standards (laws) and enforcement of those laws. Let me illustrate with an analogy since my writing kung-fu is not as strong as I would like:

Let's say that we all live in California. California has a problem with earthquakes. When there's an earthquake, buildings fall down, bridges collapse, chaos ensues. Well, let's say the quality of the building construction is pretty weak: there are no shortages of shoddy builders and no standards in construction to make buildings more earthquake-resistant. Instead, we have small, disjointed teams of people who go from building to building and try to reinforce buildings in key areas to make them more earthquake-resistant. Our goal is to try to keep the buildings standing without loss of life and property during the earthquake.

How could we do this more effectively?

1. We could develop strong standards for building structures in California -- i.e. buildings need to be built with ductility; use base isolation devices to detatch the building from the ground so that shaking from the quake does not shake the building, etc.

2. We can also try to prevent the quakes from happening at all.

So let me reel this analogy back in. Think of a hacker as a California earthquake. We go around defending (patching buildings) but when the earthquake comes, the buildings still fall to it. The only way we are going to get ahead of the earthquakes are to make our buildings resistant to failure, --or-- to try to avoid the earthquake (hack) altogether by eliminating the cause. I am saying we need to spend more time and energy focusing on arresting and prosecuting cyber-criminals.

Now, you may read that and chuckle; "but they're all in Russia and China!", you may think. That's not the only places they are. The information being stolen from companies around the globe is funding organized crime and international terrorism. Doesn't stopping organized crime and international terrorism sound like virtuous goals? There are a few things to consider when you start to let the scope of that sink in:

1. we can't do it alone. We, as security professionals, are like the first responders to the collapsed buildings after an earthquake. We stop the bleeding, rescue the folks that are trapped and sometimes we even locate and help remove those that didn't survive the quake. But it's hard for us to influence policy to protect people from earthquakes. It's our job to bring this problem up to our congresspeople, our senators and our appointed civil leaders.
2. Our standards bodies (ICANN, WC3, etc) need to take a more aggressive focus toward information security, through the representative organizations that make up those groups.
3. We need stronger anti-hacking laws that will allow prosecution across international borders...an international agency, perhaps, similar to INTERPOL, that is recognized by an international body (say, the United Nations) to identify, locate, and apprehend cyber criminals. We put the fear into these criminals that they will be caught for these crimes. Deterrance. If you pull a skilled cyber criminal off of the "streets" you remove that talent from being misused.

There are other initiatives you can throw in there (like education of hacker hotbeds, creating legitimate wealth opportunities for that talent, etc), but we won't go into that. Right now, let's focus on the bigger picture: Stronger architectural/technical standards, tougher laws, and a much larger hacker deterrance program (again through apprehension and prosecution) is going to be the beginning of the only way we'll ever get in front of the curve. It's the only way we'll ever see the forest instead of focusing on the trees.

Security Models

I had an interesting conversation this week with an architect at the organization I work at. We were discussing the security model of an existing app that his group was looking at modifying. He was having a difficult time understanding why our organization uses an RBAC (Role Based Access Control) model.

The architect came from a military background before starting at our organization. In the military, information is secured by the level of privacy it requires: data can be unclassified, restricted, confidential, secret, and top-secret.

As our conversation progressed, it became clear to me the architect was trying to apply this classification model to how our organization conceptually separated data. Since we work at a large insurance company, anything with private health information could be one category, and anything with sensitive data (like a date of birth or social security number) could be another classification, and then people could be "cleared" for both classifications, right?

One of the significant differences that he hadn't yet realized was that, unlike a military outfit, our organization paid insurance claims. So, we adopted a role model to help enforce a separation of duty between the claim-creators and the claim-payers, because if you can create a claim and then pay it, you have all ingredients you need to bake a fraud-filled cake. While we do use a military-esque data classification model for certain types of business (for example, employee health data is sequestered away from the general population, as is data related to federal/government employees), the role model we use is where it really shines.

Using conceptual roles, we assign different types of employees different categories: claim processors (the folks that pay claims) are all placed in one conceptual role that gives them all of the access they need on the various applications they use that only permit paying of claims. Our underwriters are given a separate, conceptual role that only permits them to submit claims. Since there is a hard rule that associates can only have one role at a time, a separation between submitting and paying claims exists.

This implementation of Role-Based Access Control (RBAC) has several benefits, especially on a larger organization such as ours; separation of duty is simply one of them. I will get a bit more detailed into how it works in upcoming posts. For today, I just wanted to briefly share these two differing perspectives.

How does your organization classify data?

References:
Military data classifications
RBAC