Blog

Low Hanging Fruit: Security Management

By Mike Rothman

To wrap up my low hanging fruit series (I believe Rich and Adrian will be doing their own takes), let’s talk about security management. Yes, there were lots of components of each in the previous LHF posts (network security & endpoint security) that had “management” components, but now let’s talk about the discipline of management, not necessarily the tools.

Think and Be Program

Some folks would rather think and be rich, but if you do security for a living, you need to be thinking about a security program. To be clear, establishing a security program is the single hardest thing any security professional has to do. Period. Nothing else comes close in heartburn, futility, angst, or importance. The folks residing in a hamster wheel of pain (a great term coined by Andy Jaquith, I think) tend to spend most of their time in fire-fighting mode. OK, being honest, they spend all their time fire-fighting.

That also means a program is not really low hanging fruit (it’s more like skyscraper hanging fruit), but I don’t think you’ll make much headway with any kind of security management without having the structure of a program in place. Thus, this is really about context and the importance of that context as you look to other security management techniques.

So why is it so hard to get a program off the ground? Per usual, it gets back to shiny objects and your to-do list. It’s just easier to do something else. Senior management doesn’t have to agree to fixing a firewall rule, re-imaging a machine, or patching a bunch of devices. But they do have to buy into a program. Your peers have to agree to think about security before they do things. Since they don’t like to do that, getting consensus is hard. So most folks just don’t do it – and that’s a big mistake.

Without the program in place, your likelihood of success is small. Best of all, you don’t have to implement a full program to greatly increase your chance of success.

Yet, all is not lost. You can start slowly with the program and do a few things (kind of low hanging) to get you going:

  • Define success: Without a clear and agreed-upon definition of security success, you may as well give up now. So this really has to be the first step in the process.

  • Communication: How often do you get face time with senior management? It’s probably not enough. Make sure you get an audience as often as you need. In the initial stages probably once a month (if not more often), later on maybe not as much. But if you don’t have something set in stone, scheduled on the calendar, it won’t happen.

  • Accountability: In most organizations, the security team is not well liked. In order to have any chance to implement a security program, you need to change that perception. That’s done one step at a time. Tell them what you are going to do and then do it. Yes, it seems pretty easy. But if it was really easy, everyone would be doing it, right?

Just to throw in a shameless plug, I discussed how to implement a security program in The Pragmatic CSO. It goes into a lot of detail on how to structure the program and get acceptance with your business leaders.

Incident Response

No matter what time it is, it’s time to revisit your incident response plan. Hopefully you haven’t had to use it lately, but don’t get lulled into a false sense of security. Before long you’ll be compromised, and whether you live to fight another day has everything to do with how you respond to the incident.

The worst time to learn your IR plan sucks is when you are in the middle of an attack. First make sure senior management understands roles and responsibilities. Who runs point for what? When do the CEO and board need to be notified? When does law enforcement get involved? All of this needs to be documented and agreed upon.

Next run simulations and practice. Lots of my practitioner friends practice using live ammo, but if you aren’t under constant attack, then you’ll need to schedule time to practice. Yes, shiny objects and fires to fight make it hard to carve out the time to practice the IR process, but don’t neglect your preparation.

Monitor Everything

If there is anything the recent APT (advanced persistent threat) hysteria has shown, it’s that we have little chance against a well-funded and patient attacker. The only chance we have is to figure out they are in the house as soon as possible. I call this Reacting Faster, which of course Rich has to improve by reminding us all to React Faster, and Better.

The point remains that we don’t know where the attacks are coming from (0-day, by definition, means you don’t know about it, so it’s pretty laughable when an IPS vendor says they can protect against a 0-day attack), so we’d better get better at detecting funky behavior.

Anomaly detection is your friend. You need to monitor everything you can, baseline the “normal” course of events, and look for something that is not normal. That gives you something to investigate, as opposed to the literally infinite places where you could be looking for an attack.

  • Logging: Your regulations say you need to log stuff, so you probably have some rudimentary logging capability in place. Or you are looking at one. That’s a good idea because all security management starts with data, and a good portion of your data is in log files. So having an automated mechanism to gather and parse logs is a critical first step.

  • Change detection: Malware tends to leave a trail. Well, most malware anyway. To change behavior usually requires some kind of operating system file change. So seeing those changes will usually give you an indication that something is wrong. Look at key network devices and servers, since those are the interesting targets.

  • Network behavioral analysis: Network flow analysis yields some very interesting perspective on what folks are doing with your corporate IT assets. It’s also very hard to hide an attack (especially exfiltrating data) from the network. So monitoring network activity can provide another treasure trove of information useful for detecting attacks.

There are plenty of commercial tools for logging, change detection, and NBA. There are also open source options as well. What’s important is not how you solve the problem or how much money you spend, but rather that you are thinking about monitoring now, given the reality that you will get pwned, it’s just a matter of when.

Notice I didn’t mention SIEM or correlation in any of these posts. There is nothing low-hanging at all about SIEM, which requires a lot of time and money to get right. If you make the investment, correlating a lot of disparate sources does help. But be clear that it is an investment, and in most cases a rather large one.

Full Packet Capture

You’ll hear a lot about full packet capture over the next few months. This capability involves capturing every packet that traverses your network. A few vendors will try to make the case that full packet capture would have alerted organizations to the APT (and pretty much every other attack) sooner. Maybe that’s true, maybe it isn’t. But that isn’t the point, which is to remember that data is your friend.

Data is essential to incident response, which you’ll learn the first time you “lose” data as the forensics folks are trying to figure out what happened. Since a large part of my security philosophy is based on reacting faster, you need data – lots of it. Thus I’m a fan of full packet capture, where possible. Certainly on sensitive network segments (like those housing CC data) at a minimum.

Yes, it’s a lot of data, but through the wonders of Moore’s Law and some smart math folks, it’s actually possible today. Not necessarily cheap, but definitely possible.

Prioritize Effectively

The last of the low hanging fruit I’ll leave you with involves prioritizing your daily activities. Your to-do list isn’t going to be getting any smaller. You aren’t going to be getting more resources, and odds are your budget will remain tight. Which means you have to work smarter, not harder. More efficiently, as opposed to throwing money and resources at things.

That’s why I’m such an advocate for a strong security program, which defines your top priorities and (if done correctly) makes it easy to determine what you need to be working on at any given time. Without that kind of roadmap (agreed upon by the key influencers), all of your activity and decisions are open to interpretation. OK, you’ll be second guessed no matter what you do, but if you have told folks what your priorities are ahead of time, you’ll be able to point back to that.

No Related Posts
Comments

Adrian,
You bring up a good point relative to the need to prioritize monitoring on the most critical assets. And one of the things I sometimes forget to explicitly call out is *common sense,* which says you don’t spend a zillion dollars capturing packets on a network with nothing important on it. But every company has a set of assets where if a compromise happens, it’s really bad. For those assets, I think it’s reasonable to monitor *everything* including the application logs and the change detection and also the network traffic. Once you either roll over that data or don’t collect it at all, it’s gone. Goodbye. Never to return.

Also keep in mind the fact that this data is used predominately for forensics purposes. Try to reduce and correlate on full packet capture isn’t realistic - no matter what the vendors tell you. So drowning in data is a good thing when doing a deep forensic investigation.

So to net it out, everyone needs to use their heads. All other things being equal capturing more data is better than less data and that’s all I have to say about that.

By Mike Rothman


OK, Mike, I’ll bite. I did not think we did ‘Firestarter’ posts on Wednesday. 

—- 

I think monitoring everything is a bad idea. This sounds like SIEM vendor speak to me. Why the hell would I waste that much in terms of storage and processing resources to do it?  Yeah, I get it that you don’t know what exploits or how someone may breach your defenses, but application logging and change detection may be enough. In fact, you may even want to filter a lot of the information coming in from logging, auditing or monitoring software. The downside is you _might_ miss some data, but you have a far greater likelihood someone might actually read the log files. I’ll log this one under ‘prioritize effectively’, because if I am logging everything and capturing all packets, I am certainly not prioritizing and probably going to be ineffective. I’d also be paranoid and drowning in data, but dealing with mental psychosis is not security ‘low hanging fruit’, but ‘dealing with the fruit’ in security.

-Adrian

By Adrian Lane


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.