Immutable Security

I recently blogged about security practices in a hospital environment that I was witness to. It was interesting to see how security worked (or perhaps didn’t work), rather than post about another standard, tool or best-practice.

Today, I bring you the story of Grandpa. Grandpa had a little information security incident and, well, it didn’t go so well. In fact, it went something like this:

Scene opens with me exiting out of the bedroom after a good night’s sleep…

“Grandpa thinks he has a virus,” my wife dutifully said.

“Coffee,” was the best reply I could muster.

You see, I knew that viruses were really no big deal. I’ve battled many a virus and have always been victorious.  I certainly knew that it could wait until after a cup o’ joe, so I relegated to call him a bit later.

I forgot.

While I was forgetting, Grandpa was in a mini-panic. Malware was telling him he was infected with all kinds of other malware, using a fake scan window of course, and that the only resource was to pay $49.95 for the program.

He bought it. Of course, that didn’t fix his problem.

Your first reaction might be something along the lines of, “what a dummy.” Maybe you’re thinking, “doesn’t he know not to click on links?” Perhaps you think he got what he deserved. While all of those responses may be justified, and maybe even correct given a certain perspective, let’s take another look at this.

Grandpa can’t hear. He is almost completely deaf. Since he grew up hearing, he doesn’t know sign language. He finds family functions to be extremely saddening and frustrating. When the little ones try to tell him something, he doesn’t know what to say because he didn’t hear a word they said.

Being a retiree, he also doesn’t have much income. In fact, there’s really nothing extra. Spending that $50 meant that he had to take $50 from another, probably essential, area. It wasn’t planned; it was more along the lines of, “I need to do this now!”

So, why did he pay this money when I would have helped him for free? Why did he fall victim to the scam? Why did he make an impulsive decision and not think it through?

The answer has nothing to do with how he has or hasn’t been educated about not clicking on untrusted links or installing untrustworthy software. He became a victim because, in that moment, he felt as if he had no other choice. His fight-or-flight response kicked in. He emotionally made a decision because he felt as if he was losing control over something very important. If the computer were no longer his, how would he communicate? What would he do with this time? How would he take his mind off of the multiple health problems that fills his thoughts?

I was able to fix his computer and even helped to get the charge reversed, but the point of this story is that security problems usually aren’t technical in nature. Obviously, trying to teach people to become security experts just to be able to have some fun or do their job effectively isn’t working. The approaches have to change.

We need to understand people better. The age of the security geek is passing. If we are to truly make progress on issues like this, the solutions will be less technical and more people-focused. If Grandpa had felt secure in knowing that I would help him no matter what, perhaps he would have made a different choice. If he had known that his computer would not be relinquished to this scammer unless he paid money, he might have taken awhile to watch a movie until I had called him back.

Security is about people. Let’s make that a mantra for 2010.

On October 29, I gave a presentation at the Rochester Security Summit entitled “OSSEC in the Enterprise.” After a brief delay as a courtesy to the summit organizers, I’m pleased to be able to share the presentation with everyone else.

Daniel Cid over at ossec.net has graciously offered to provide hosting for the presentation. It can be accessed directly here, or for a list that includes other great OSSEC presentations, go here.

It’s a bit long at well over 100 slides, but it goes fast. I hope you enjoy it and would welcome any feedback you might have.

Tools like AIDE and the original Tripwire have long been used in the Unix world for so-called intrusion detection. They let you know when a file has changed by presenting you with an old and new checksum, but usually don’t provide much more info than that.

While knowing that a file changed is useful, how much inherent value is there in simple file hash reports and alerts? In my opinion, very little.

These old tools don’t provide any context about the change. They don’t tell you who changed it, what happened just before and after the change, and what in the file actually changed. At best, you’re left with a bewildered goose-chase trying to figure out what happened.

To make matters worse, a well administered systems is supposed to change. If critical system files aren’t changing, you’re probably not patching. And if you are patching, you’re getting these alerts all the time and will eventually ignore them. The more systems you have, the worse the problem is.

Does that mean there is no value at all in integrity checks? Of course not. The value lies in two things:

1. Getting alerts for rare but important events. Knowing about a file added to the init.d directory or the Windows run key in the registry might be valuable.
2. Having the checksums available on a secured system for forensics.

Security is always a balancing act. Getting flooded with information about low value events is just as bad, if not worse, than not getting any alerts. Alerts should be meaningful and should, at the very least, cause you to stand up and take notice of something that isn’t normal.

Addendum: Complete IDS systems are also sometimes lacking in context. It probably took three or four tries just to post this due to content in the post that the IDS thought was a web attack. :)

I have spent the last several days responding to a 0-day worm outbreak. We didn’t have signatures when the you-know-what hit the fan. Fortunately, some tooling we already had in place allowed us to contain the initial spread while we waited for emergency signatures from our AV vendor.

The last stage of any incident response is the lessons learned phase. This is where you examine the response and analyze all the things that went well and all of the things you could have done better.  There are always ways to improve the response.

I got to thinking that simulating a worm outbreak would be an excellent way to test a response, along with the detection tools you currently have in place. Although it wouldn’t cover all scenarios, and maybe not even most of them, creating an EICAR worm seems like an excellent way to set this up.

For the uninitiated, an EICAR signature is a string identified by AV vendors as a “test virus.” It is meant to show that AV is working.

So why not take this one step further and create a custom worm from the EICAR string? It would be simple: simply create a batch file with the EICAR string and attempt to loop through a list of network shares using a privileged account.

There are risks, of course. First and foremost, there would have to be absolutely no way for this to “infect” a system not under your management. That would simply be inexcusable. Second, there may need to be a way to throttle and control the spread. Some kind of “dead man’s switch.” Finally, there needs to be a way to pull-the-plug should things go really awry.

While this may sound like a crazy idea at first, which is better: to have finely tuned responses based on well-practiced and controlled scenarios, or to struggle through the next worm incident?