Immutable Security

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…

OSSEC is one of those tools that continues to surprise me with its ability to perform low-level and important security tasks. In fine Unix tradition, individual parts of OSSEC can often be persuaded to do your bidding in ways not previously conceived. Put another way, it’s nice to hack. :)

Today, I’m going to show you how to use OSSEC to detect sensitive info within flat files. This example will demonstrate American social security numbers, but the same logic could be used to detect clear-text credit card numbers (a violation of the PCI DSS standard), or other personally identifiable information which should not be in clear-text.

We’re going to rely on the rootcheck functionality of OSSEC. Rootcheck does all kinds of nifty things, one of which is to scan within files for patterns. Normally, you would expect to look for things like insecure system configuration settings. We’re going to use it to find possible social security numbers.

First, create a test file containing a properly formatted SSN in a location that OSSEC is monitoring:

echo 123-45-6789 > /var/www/html/example.com/www/customer_data

Next, add the following to /var/ossec/etc/shared/system_audit_rcl.txt:

# Detect possible SSNs
[Possible Unencrypted Social Security Number Detected] [any] []
d:$web_dirs -> r:^\. -> r:\d\d\d-\d\d-\d\d\d\d;

Now, let’s create an alert so we get a heads up on what OSSEC finds (change the rule ID as needed):

<rule id=”100024″ level=”12″>
<if_sid>516</if_sid>
<match>Unencrypted Social Security Number</match>
<description>Possible Unencrypted Social Security Number Detected</description>
</rule>

Restart OSSEC:

/var/ossec/bin/ossec-control restart

Finally, we’ll initiate a scan on the local system:

/var/ossec/bin/agent_control -r -u 000

And here is what the resulting alert looks like:

OSSEC HIDS Notification.

2010 Jan 12 18:25:43
Received From: hostname->rootcheck
Rule: 100024 fired (level 12) -> “Possible Unencrypted Social Security Number Detected”
Portion of the log(s):

System Audit: Possible Unencrypted Social Security Number Detected. File: /var/www/html/example.com/www/customer_data.

–END OF NOTIFICATION

One of the nice things about the alert above is that it doesn’t actually include the contents of the file, so you don’t have to worry about clear-text data traversing your mail server.

There are also a few caveats to keep in mind.

First, it is slightly prone to false-positives. Since the OSSEC regex library is designed for speed, rather than full regex support, it’s not possible to use something like \b to define a word boundary. This means that while the regex will match SSNs like 123-45-6789, it would also match something like 00123-45-678911. It also wouldn’t match a delimiter other than the dash. You might be able to mitigate some of these risks if you’re sure how the data would be formatted (but then again, if you’re sure you have clear-text data on the server why do you need this :) ?)

Second, it won’t find data in databases, which is probably where it is likely to be stored. It’s really only useful against flat-files.

Finally, there’s currently no facility to save this change when upgrading, such as you can already do with local_rules.xml. Make sure you have a backup of system_audit_rcl.txt handy that you can restore.

Despite these shortcomings, if you are already using OSSEC then this can be an excellent way to quickly add some rudimentary data checking to the OSSEC scans. It shouldn’t be relied on exclusively and the absense of an alert doesn’t necessarily mean you’re safe, but for a 5-minute change and in the absence of a budget for a more robust tool, this might lead to quite a surprise!

Thanks to Daniel Cid for help in getting this working, and of course for the excellent tool that OSSEC is.

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.