Immutable Security

Awhile back, I posted about how certain versions of Windows always have the capability to lose logs. I encourage you to read the full post to understand the issues involved, then come back here and continue reading.

The basic problem is that Windows loads the full log into a shared memory space, and if it’s too big, then logs will be silently dropped. That’s why it is very important to have a centralized logging solution with logs sent in real-time or pretty close to it.

So how does centralized logging affect the local retention settings? To know that, you have to make certain assumptions about log size, average number of events generated per day, and so-on. Let’s start with this quote from Microsoft’s Threats and Countermeasures Guide:

Although there is no simple equation to determine the best log size for a particular server, you can calculate a reasonable size. The average event takes up about 500 bytes within each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the average number of events that are generated each day for each type of log in your organization, you can determine a good size for each type of log file.

For example, if your file server generates 5,000 events per day in its Security log and you want to ensure that you have at least 4 weeks of data available at all times, then you would want to configure the size of that log to about 70 MB. (500 bytes * 5000 events/day * 28 days = 70,000,000 bytes.)

70MB doesn’t sound so bad. It’s probably well within the architectural limits of this memory-mapped I/O thing, but even that may be too big.

A better way of calculating what the local log size should be is to consider the recovery time objective and recovery point objective of the centralized log server. That is, consider how long it might take you to get your log server back online in the event of a disaster, then base your local Windows logging settings on that.

For example, if your recovery point objective is three days, you want to make sure that the local Windows logs will collect for at least three days, but not much more than that. Ideally, you also want to make sure that the solution you’re using can forward the logs collected during the downtime, or have a high-availability solution as part of the plan.

Remember, the goal is to get the local log sizes as small as possible, not as large as possible. You want to make sure you’re not losing any logs, and the two best ways to achieve that are to use centralized logging and try to avoid maxing out the services.exe process. This is counter-intuitive, but when you think it through, you’ll realize that it makes sense.

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.

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?

From the “What can we do to stop terrorism, without actually addressing terrorism” department, comes the news that scientists are researching how to sniff out scared people at checkpoints.

In the research, scientists discovered that they could literally detect the pheromones produced when someone is afraid. That’s not so surprising, but what is mind-boggling is that one of the proposed implications of the research is to be able to identify “scared” terrorists.

I’m not even sure where to begin with this one, but let’s give it a try. Here are just some of the potential vulnerabilities in this stupid idea:

• Many terrorists seem to be so brainwashed into believing that they are about to get 72 virgins that they’re probably more likely to be a bit “happy,” rather than scared if you know what I mean.
• Sociopaths won’t be scared.
• When we recently took my three year old daughter through an airport checkpoint she probably would have been tagged. It would have been because they took her Cabbage Patch doll to scan for hidden bombs.
• We better hope there are no nearby spiders and arachnaphobes.

Do I really need to continue?

Fighting terrorism with stupid ideas like this only serves to take the focus off those areas where we need to pay attention. With limited resources, we can’t afford to divert our attention from those techniques law enforcement has been using for years and which are proven to detect and stop criminals.

This idea smells stupid because it is.

A few of my posts have involved debating the ethics of public web app testing by security professionals. When the good guys poke and prod public web apps it raises a bunch of ethical questions, besides being legally questionable. Rather than recap my thoughts again, I invite you to read the article which I wrote for this month’s “ISSA Journal.” If you like the article and like some of the articles in the Journal archive, please consider supporting ISSA by joining. I have found it to be pretty valuable.

As always, I welcome your feedback. Feel free to challenge my assertions. All constructive comments will be let through moderation.

Don Norman is my hero for today.

Rarely do I read something and come away thinking, “this hits the nail right on the head. I can’t possibly think of a more eloquent way to say what is being said.” But Don manages to do just this in his essay about usability in security.

Don understands that security measures have diminishing points of return. He intuitively knows that asking more and more of users doesn’t necessarily make them more secure. He sees the underlying reasons why security is failing. He gets it.

I could go on and on, but I’m just going to ask you to take a few minutes out of your day and read his essay. Read it slowly and carefully, then print out copies and hand them to your colleagues.

Finally, think about some of the ways you may be unwittingly making security problems worse. Consider if your approach could use some fine tuning. Simplify, re-examine and take chances.

One of the big problems in information security is how to effectively teach small businesses safe data handling. They’re too small to have dedicated security budgets and they can’t be expected to publish volumes of security policies; yet, they have needs to handle information safely above and beyond what a normal consumer has to deal with.

NIST attempts to fill this gap with the Small Business Information Security: The Fundamentals guide. In the guide they detail what a small business should minimally be concerned with, along with some extra measures they may want to take.

While it has a little ways to go (it is a draft, after all), it’s a great start to filling this much needed void. Check it out and see if they manage to walk the fine line by making security simple, yet effective enough for small business.

PhysOrg.com and many others are reporting a new attack against WPA encryption, which is used in wireless networks. While WEP encryption has been proven to be all but worthless, attacks against WPA have mostly been limited to acedemic and brute-force attacks.

The two Japanese scientists apparently have found a method to crack WPA when combined with the TKIP algorithm, however the attack does not apply to WPA2, a more recent version of the standard, when combined with AES.

This might be a good time to verify the settings on your home wireless network. If the option to use AES and WPA2 is present, it makes sense to use it. But I wouldn’t rush home in a panic.

While you’re in there, make sure your admin interface requires a strong passphrase and your WPA2 keys are equally protected. At least for the keys, use a strong, randomly generated password since you generally only have to key them in once per device. Here’s an online generator you can use from grc.com.

I have observed a trend recently that has me internally debating the ethics of the practice. Security professionals are probing public web sites for vulnerabilities, then going through a “responsible” disclosure process with the owners of the site. Then they blog about their exploits and how responsive the owner was to being notified.

How is this different than traditional hacking by the bad guys? Does the disclosure process make it any better? Does the fact they do security for a living and write for security journals make it more ethical? And what of the applications that are vulnerable to routine exploits? What does one do with a successful SQL injection query that just gave you a table full of social security numbers?

On the surface, it seems unethical to me. Attempting to break access controls, even if they are weak, is unethical and maybe illegal. Doing something untoward against another computing resource for which you do not have authorization is treading on thin ice.

But there’s another side to the story here. Applications are moving more towards the software-as-a-service, or SaaS model. Whereas once you would have been able to download the software and legally and ethically reverse-engineer it, now the application is only hosted on another computer. This changes things in a big way, since you’re working on someone elses computer now.

The argument could be made that since the application is public, then there is an expectation that it wil be poked and prodded, so it might as well be the good guys who do it. The bad guys aren’t going to go through a responsible disclosure process, so by the good guys testing the application and making the flaws known to the application owner, everyone benefits (as long as they actually fix it). It can also be said that for security to continually improve, we have to continually test it. If the world is moving towards a web-centric model, we have to move with it.

Honestly, I can see both sides; yet, I am still left with the feeling that, in many cases, it’s nothing more than the security guy trying to have some fun and make a name for himself. If that’s the case, he should carefully consider what that name may be.

I’d like to start by apologizing to all who I have forced to create complex passwords. They made me do it. I know it’s cruel. You’re a human being, and I failed to see that.

Information security, despite being centered around computers, is not a discipline practiced by computers. It is practiced by people. Human beings design the software and hardware, they write the processes and procedures and they are the attackers. Information security is a human problem.

Why then, do we design security solutions that address the machines? That would make sense in a world of androids, but we’re dynamic, emotional and flexible. Designing security solutions that match these characteristics makes sense.

Passwords are a perfect example of a security measure that doesn’t match our human needs. We require people to conform to archaic rules: they must be a minimum of eight characters, complex, not a dictionary word, upper and lower case, and not guessable. Don’t use a birthday, anniversary date, spouse or child name, or your favorite sports team. Don’t write them down. Don’t share them. In other words, submit to our technologically-advanced torture device.

We ask social beings to not be socially-engineered. We ask grandmothers to patch their computers. We tell everyone not to click on links and open attachments, except for those that point to company policies. We tell them that e-mail can be spoofed and let them figure out the cruel joke.

When people forward warnings about the latest threat, we call shenanigans and usually point out that it’s a hoax. When they try to backup their data, we tell them that it’s not encrypted. When Google entices them with “the cloud,” we warn of thunderstorms in the cloud.

I’m fully expecting an uprising of unassuming office workers everywhere, rounding us information security geeks up and making us watch Punky Brewster reruns.

If information security is to progress, if it is to provide new solutions to age-old problems, if it is to innovate, we need to take the focus from machines and place it where it belongs: with people. Developers need simple and fun tools, where writing secure programs is more akin to gaming. User interfaces need to anticipate and conform to the behavior of the end-user and get out of the way. Executives need such a strong financial incentive to endorse an effective security program that to not do so could be seen as irrational.

When information security can be seen as a close cousin to the hospitality industry, we will have made some significant headway.

As for me, I have an SSL certificate warning to click OK on.