Immutable Security

There are four or five responses to risk, depending on who you ask. They are: mitigate, accept, transfer, reduce, and sometimes, ignore. Ignoring a risk is just a lame way of burying your head in the sand and pretending it doesn’t exist. Let’s just say there are four legitimate responses to risk.

What we usually hope for is mitigation and reduction. These responses deal with risk directly, but most importantly, they show the greatest amount of responsibility in dealing with the problem.

Transferring risk can be a legitimate response or it can be a way to essentially ignore it. It can be legitimate when there is a thoughtful decision to transfer to another party, and that party accepts. This can be an insurance policy, for example. It is illegitimate when transferring it to another party is a way of ignoring it, essentially just another way of saying, “it’s not my problem.”

That leaves acceptance. Acceptance means, “I know that this might happen, and if it does, I am prepared to accept the consequences of my decision.” The problem with acceptance is that it is rarely tied to consequences.

I see this problem in the real world all the time. Security professionals present risks to senior management and they simply do not respond. They don’t respond unless there is an incentive to do so, and agreeing to put themselves on the line with little or no positive return doesn’t win many fans. If the senior executive fails to respond and the risk is realized, they can just say, “I never saw the risk analysis,” or worse, “they failed to effectively communicate the risk to me.”

We need two things to make risk acceptance work. One, the risk acceptor can not be in a position of authority over the risk advisor. This creates a situation where the advisor might water down the risk out of fear for his own job. Two, there have to be consequences that tie directly to the risk being realized and for choosing to not mitigate, transfer or reduce it. Essentially, this means that ignoring the risk becomes default acceptance with a particular consequence. In both cases, the consequences of acceptance (either by default or explicitly) need to be commensurate with the risk.

Consequences tend to motivate people. Risk acceptance without consequences is not risk acceptance at all.

In a recent point/counterpoint over at techtarget.com, Marcus Ranum responded to Bruce Schneir on the issue of the risks of hiring hackers. Marcus said one thing in particular that struck me as very insightful. He writes:

We hear a lot about “thinking like a hacker,” but I think that’s largely nonsense — it’s really just a matter of “thinking like an engineer” and performing an in-line failure analysis along with your design analysis.

I think he’s mostly right.

Information security defenses are generally built based on compliance, the current new attack and logical analysis of the threats, in that order. But even when we perform a thoughtful risk analysis, we tend to over-emphasize the rare but sensationalized threats, and under-emphasize the mundane threats. Because information security is seen as a solution to the problem of other people actively attacking systems, we tend to design our countermeasures around those threats.

While it’s true that attacks are happening all the time, the vast majority of those are non-targeted attacks that can be resolved by simple countermeasures such as patching. What we tend to underestimate is loss from areas where information security practitioners have traditionally not had a foothold. We don’t design good countermeasures around forgetting to renew the domain name, a service provider going out of business, or someone hitting the delete key by mistake. But the end result is the same–a loss of confidentiality, integrity or availability.

So where does thinking like a hacker come in? Do we need to think like a hacker to protect against a hacker? I suppose that depends on your definition of what a hacker is. If that definition involves creative thinking, considering how things break, and coming up with solid solutions, then yes, thinking like a hacker is good. But then that is really just good security engineering.

Take this site for example. Before it went live, I played the “what if” game. I started to ponder the many ways this site could break. Along with considering the usual stuff like SQL injection and XSS, I wondered what would happen if my DNS provider suddenly went offline. I assumed that someone would steal the server from the data center, or that a government subpoena might inadvertently include this site along with the site they were targeting. I assumed I would turn off some of the security measures temporarily to see if something started to work again. I then assumed I would forget to turn them back on.

I designed countermeasures for all of these scenarios to a certain extent. At some point it wasn’t worth going any further–it is a blog after all. The point is that I didn’t so much design to be attacked as I designed it to be resilient to failure. Does that mean it is fail-proof? Absolutely not. The site could still be defaced. The server could crash and I might have a problem with restoring the backup. I might get hit by a bus. Despite all this, I am comfortable with the level of security engineering I put into the site.

To sum this up, thinking like a hacker is not that different than thinking like a security engineer. It’s two sides of the same coin. To consider how systems can be resilient to failure (the security engineer), we need to consider how they will break (the hacker).

And sometimes, just sometimes, they break in spectacular ways.

I had the good fortune recently to take a few days off. We decided to travel to a city a few hours away by train, a method of travel that is generally comfortable and relaxing.

Being a security guy, I couldn’t help but notice the lack of security. My ID was checked only once when heading to our destination, but not on the leg back. The guy obviously didn’t even look at it very closely and he didn’t use one of those little ultraviolet lights. My luggage wasn’t inspected at all, nor was my person. There were no metal detectors. All I noticed was a few cameras and a sign telling me to watch out for suspicious stuff.

It would have been trivial to load myself up with automatic weapons or even pack my suitcase with explosives. At a minimum, I could have destroyed the portion of the train I was on and killed everyone on it.

I got to thinking–in the post 9/11 world we live in, how could this be? Didn’t they think to secure the rail system? Wouldn’t an attack on the railway instill fear in America and be an easy target? Of course they must have thought about this. There must be other explanations.

Perhaps the intelligence indicates that the railway really isn’t a target. Perhaps Amtrak doesn’t have enough money to implement something like the airlines have, and since they haven’t been given a mandate or been taken over by the government, they haven’t done anything. Maybe it’s “in the works.” Maybe there aren’t enough resources to go around and this is at the bottom of the list.

Whatever the case, I came to realize that I really, really enjoyed the lack of security. I didn’t feel any less safe by not having my luggage swabbed. I realized that I most likely had a much higher risk of dying in the car on the way to the Amtrak station than I did by a terrorist attack on the actual train.

Would I feel differently if there had been a recent terrorist attack on a train, or if I had survived a terrorist attack anywhere? Possibly. But not having gone through that experience, I realize that fearing an attack on a train is a mostly irrational fear and a risk that may not be worth doing anything about.

Now the lack of on-board wi-fi is another matter entirely…

The new version of Ubuntu includes integration with the 7digital.com music store. No longer do open source users have to rely on proprietary applications like iTunes. They can now purchase good-quality music using only free software.

Like most other online music stores today, 7digital sells non-proprietary, but patent-encumbered MP3 files. This is leaps and bounds better than the DRM-laden files which used to be sold by stores like Amazon and iTunes.

And while there is a bug which discusses some of the issues surrounding relying on a patent-encumbered format, rather than something free like Vorbis, there is one critical issue that free software users are not debating.

Allow me to demonstrate by quoting from the 7digital.com Terms and Conditions:

(i) You are authorized to use the Content only for personal, non-commercial use, and not for redistribution, transfer, assignment or sublicense, to the extent permitted by law.

So, unlike a traditional CD you buy at the store, you are contractually agreeing not to lend it to your friend, donate it to your library, or when you’re tired of it, throw it up on eBay for sale. In short, it makes it a breach of contract to share your music or even to sell it when you’re you have outgrown it or lost your job.

The Terms and Conditions continue:

(ii) You are authorized to use the Content on up to five authorized devices at any time. 7 reserves the right to limit the number of authorized devices further and the number of authorized downloads to comply with the wishes of its licensors.

And there we have the DRM. The difference here is that it is implemented in a contract, not in technology.

And just when you thought it might be over, they throw in this little gem:

(iii) You may not use Content as a musical “ringer” in connection with mobile phone calls.

Take all the fun away, why don’t you.

Ubuntu certainly isn’t the only one guilty of implementing the DRM through a contract rather than technology, but honestly, I hoped for better from a distribution that espouses to be freedom-focused.

If the free software community can accept this, what hope do we have for retaining the rights under U.S. copyright law that we have enjoyed for so long? If we contractually give up those rights on music, video and most importantly, books, what does that say for the future of the independent after-markets, fair use and archival?

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.

Many years ago, after I had been using OSSEC in an enterprise setting for a few months, I noticed an interesting phenomenon. Administrators, many of whom I had forwarded “was this you?” alerts to, were now coming to me to rat on themselves.

I would be working away in my cubicle when someone would come up behind me. It went something like this:

“Hey, Mike. Just wanted to let you know what you’ll be seeing me <insert action here> in the logs. No cause for concern.”

“Thanks for the heads up,” I would reply.

The administrators knew they were being monitored, but didn’t exactly know the full details of the monitoring. They naturally assumed I would see what they were up to. In many cases I wouldn’t have known.

The vast majority of these folks were honest to begin with, but I can’t help think it assisted them in following process and being just a bit more transparent with what they were doing. Maybe it even dissuaded someone who was on the fence from doing something vindictive.

After seeing this in other environments, I think it deserves a term. At the risk of coining a term for something that has already been identified, I hereby declare this the “OSSEC Effect.” The definition (which could use some refinement) is as follows:

OSSEC Effect: The alteration of a computer user’s behavior when they know their actions are being monitored, but do not realize or understand the extent of the monitoring. Users will, without provocation, volunteer information they believe could be seen as questionable, whether the monitoring system would have known about it or not.

Spammers are weasels. They will try to spam every web application they can, and of course this blog is no exception. Usually, it’s something about Viagra or gambling, but lately they have been leaving rather lame and somewhat amusing jokes along with the spam content. Why not take a moment for a chuckle. For you, dear reader, I present the best of moderated comment spam jokes!

• How do you revive a drowning rodent?  Give it mouse-to-mouse resuscitation.
• What do you call cheese that isn’t yours?  Nacho cheese.  <– my personal favorite :)
• How would you clean a tuba?  Try a tuba toothpaste.
• What kind of flowers grow in outer space?  Sunflowers.
• What is the difference between a prizefighter and a man with a cold?  One knows his blows, and the other blows his nose!
• What do sea monsters eat for lunch?  Fish and ships.

Enjoy your day.

I have been fighting the bad guys for the better part of a decade now, and have been in IT for even longer. In all that time I have seen no real progress in security. Systems get hacked, they get rebuilt, and companies supposedly take it seriously. Wash, rinse, repeat.

So I’m done. I’m leaving IT entirely and have decided to pursue my life’s passion, ballet. No more will I be analyzing logs, helping with OSSEC or chasing down the latest worm. Instead, I will be twirling on my tip toes and sliding across Swan Lake.

I imagine there will be some who don’t understand, especially my choice to don a pink tutu in the traditional style. That’s fine. You can continue your futile charge into the black hole that is information security. As for myself, I will enjoy the gentle breeze across my ruffles and the warm embrace of my slippers.

Awhile back I signed up for the CouponMom.com newsletter (hey, who doesn’t like to save a few bucks), using a very unique and distinctive e-mail address used only for this purpose.

Awhile later, I started to get garden variety spam to this e-mail address (Viagra, etc).

There are a few reasons this could happen:

1. I have been compromised and the spammers think it would be clever to use that address.
2. Spammers start spamming that address as a matter of chance or because they think, “hey, this guy likes Coupon Mom, maybe he’ll like some male enhancement!”
3. Coupon Mom is supplementing her income by spamming or selling the data, which makes its way into spammer’s hands.
4. Coupon Mom has been compromised.

Usually, when this happens, it’s number 4.

I got to thinking, “hey, they might want to know there might be a problem. I should tell them.”

I fill out their contact form and wait. More than a week goes by with no response.

I try to post a cautionary word to the forum. More than a week goes by and I don’t pass moderation.

I fill out the form again, indicating that it would be better for them to investigate this and notify their members of a breach, if one happened, than it would be for me to speculate about it.

Finally, I get a response. The response, in part, states:

You must have signed up for a Google advertiser link on the site, since the email signups for my site are not shared with any other party.

I am sorry you have had this experience, but caution you against publicly slandering The Coupon Mom program and our member database as the source of the unsolicited email.

Can I say that the Coupon Mom database has been breached? Categorically, no. But I can say that there are symptoms which, in my opinion, should cause a reasonable person to take a closer look.

What’s the lesson here? When someone tells you of a potential problem with your security, don’t just assume you are impenetrable. That person may serve as an early warning of a serious problem you would want to be on top of.

My three-year old recently tried to social engineer her mother and I. The conversation went something like this:

Daughter: I want some milk.

Mom: You can’t have milk right now, honey. You have a cold. How about some juice?

Daughter: I don’t have a cold any more, I gave it to Grandma.

Nice try, little girl, but your evil plan is foiled!

Little does she realize that giving a cold to someone does not mean that you get rid of it.

Until next time, daughter. Until next time…