Security Lessons from Nature – Status monitoring

I weigh between 150 and 155 pounds. What’s interesting is that, under ideal conditions, it is exactly between 150 and 155. I weigh myself regularly, and I have noticed that if my weight ever drops below 150, I get sick within a day. The same applies if it holds steady over 155 for more than a couple of days. Similarly, I have an average temperature range, and any significant variance typically bodes ill(ness).

The human body (really, all mammals) has many such metrics. In addition to weight and temp, there is an average heart rate, normal EKG, bone density and typical levels of vitamins, minerals and hormones. These can be measured in many ways, but they generally fall into two categories. Some things can be measured at a surface level (weight and temp), others require special equipment, a tolerance of invasive procedures and significant amounts of time. Of course, the more time you devote to it, the better the data you get, so these scans are generally only done when a problem is suspected.

The same applies to IT systems. There are certain metrics that are easily determined and if they vary, it can indicate a problem. Just like weight and temperature, some can be easily gathered, gathering others can impact the system, and some require the system to be down before they can be gathered.

Just like we generally don’t send people in for a full body scan on a regular basis, we aren’t in the habit of shutting down servers for a day each week and performing precautionary forensic analysis upon them. Instead, we prefer to check surface-level data: Disk, CPU and RAM usage, network connection statistics. If one of these indicate a problem, then and only then do we begin to dig more deeply and run scans that might impact system performance.

The key, just like my regular monitoring of my weight and temp, is to regularly monitor system performance metrics. Otherwise, you only catch problems after they’ve already impacted the system. Just as it’s easiest to deal with a cold before it really sets in, it’s easier to identify an attack at the beginning of the process.

Mythic Monday – Alternate Worlds

There is an interesting thing about studying Myth.  Looking just at origin stories, there is a basic belief that each culture has but one.  However, this isn’t true.  Most cultures have many stories.  Historically, this may be due to the constant culture clashes of warring tribes, where differing cultures absorbed parts of one another and partially merged in order to avoid utter annihilation.  Politically, it may be because no matter how the rulers divided the maps, the people stayed more or less the same, and gods and goddesses were simply added into hierarchies (until we got to monotheism and saints started to serve this role).  However, sociologically, what’s fascinating is that the stories can conflict and still both be viewed as true.

The human mind, apparently, has a desire to know and believe in the one universal truth, but doesn’t seem to have to deal with the cognitive dissonance around conflicting worlds. This has even been studied:

An initial study involved 50 three- and four-year-olds. Each child sat with two experimenters, a toy bear, a toy doll and a central pile of toy blocks. The first experimenter, located to the right, introduced the child to the doll Mary; together they pretended it was her bath-time and the child used one or more blocks as bath objects, such as soap. Then the second experimenter, located to the left, introduced the child to Bruno the bear. They pretended it was his bedtime and the child used one or more blocks in the game, for example as a pillow.

The crucial part came next, as the first experimenter told the child that Mary had grown tired and needed to sleep, whilst Bruno had woken and wanted to wash. Rather than using the toy block already established to be a pillow in Bruno’s world, the children, regardless of age, nearly always reached for a new block from the pile to use as a pillow for Mary.

In short, kids seem to resolve the conflict by constructing an alternate world for each story.  In their minds, anything can happen within one world, but events in one world cannot cross over to the other.  This keeps things simple and easily understood.  Sure, we play with the idea here and there. We cross genres in the movies, comics and literature.  However, even within these genres, you’ll find that there is a not-insignificant number of people who can easily point out half a dozen logical flaws in each story. It doesn’t matter how careful you are, the flaws seem to inevitably exist and leap right out at anyone who cares to look.

So, it would seem that we’re wired to allow for almost infinite flexibility but only so long as it stays segmented.  So I have to ask, why do we insist on tearing down the walls?

I’ve seen numerous envionments, where for one reason or another, there are a mix of technologies in play.  This makes sense.  There are good reasons to use both Microsoft and Linux operating systems in an environment.  The same goes for firewalls (Cisco/Astaro), endpoint protection (Sophos/Bit9) and  word processing (MS Office/OpenOffice).  Each of these technologies is powerful and can bring definite business advantages.

However, point here is that each should be kept isolated, as much as possible.  From a security perspective, one can use flaws in one product to escalate an attack on another. Operationally, trying to connect diverse systems means that you are making both of them work in non-intended ways, which means that subject matter experts in both tend to point fingers at one another.

That’s not to say that every technology should be kept isolated. Not at all. Technology tends to fall into specific worlds. There are three primary Linux worlds: Ubuntu/Debian, SuSE and Red Hat. Each of these worlds have their own repositories, and are built to be more or less complete. Microsoft Windows tends be a bit less well defined, but it still has it’s set of technologies that are designed to inter-operate with one another and not necessarily with anything else. Yes, you can try to force it… but as the article shows, we don’t naturally think that way, so there may be problems.

Review – Security Power Tools

Security Power Tools is one of those monstrous tomes that people buy and almost no one ever actually reads. It sits on the shelf and mocks you with the knowledge that it contains while simultaneously scaring you with the commitment it would take to actually read it. It’s 822 pages of dense techno babble.

It took me about three weeks to get through it.

In general, it contains the same information that is in SANS 504, but not quite as complete. It is, however, much cheaper than the course.

In the course, you get six days with a top-notch penetration tester and walk through all of the commonly-used tools in a standardized environment. You get lots of practice and a interactive sessions with security practitioners of various levels. In my opinion, it is the best way to learn.

However, it’s not something that everyone can do, either for reasons of budget or time. Failing that, Security Power Tools is a good alternative. It digs into scanning, reconnaissance, penetration techniques and tools, backdoors, rootkits, firewalls, encryption, service tuning, monitoring, forensics, fuzzing and reverse engineering. It’s a fairly complete book.

It is important, though, to read the book correctly. If you want to learn, really learn, how these things work, you have to approach it as self study, not just a reference guide. Before you pick it up, look at your life and decide how much time each week you can devote to the process. Reserve that time in your schedule. As you read the book, consider each section independently and think about how you might use the tool in a real world scenario. Then, build such an environment (use virtualization if it helps). Read the section again and run the tool within the environment.

That way, you actually learn how things work instead of just having a surface-level understanding.

Small Business Defense – Anti-Malware (yes, again)

Microsoft recently released their Security Essentials product. This is a free anti-malware product, and analysts seem to think that it does a pretty good job at what it does.

However, I want to point out one thing that you probably already know: You get what you pay for.

Security Essentials is intended to be a lightweight anti-malware solution that competes against other free AV solutions. It does a decent job at protecting against the average threat and is certainly better than using nothing at all. However, it is a mistake to compare it to a professional anti-malware system. As SANS says, “Think of this as the AV as it used to be in 2000 or so.”

In short, if you are a home user and don’t care enough about your system to spent $50 a year to protect it, go ahead and use Security Essentials. However, if you are in a business environment, you need something that includes firewall, behavioral detection, network access control, data loss prevention and central management (and more). Security Essentials won’t cut it.

Lastly, if you do decide that you want to try it out, be sure you download the right thing. There are search engine optimization attempts going on to make malicious software (fake antivirus) appear on the search results instead of the link you really want. The right link is http://www.microsoft.com/security_essentials/.

Small Business Attack – Malware (yes, again)

I’ve posted about the current run of banking malware before. For a quick review, this is malware that sits on your computer and waits for you to access your online banking site. Once you’re logged in, it watches what you do and then surreptitiously transfers money out of your account to the attacker. I’m posting about it again because of the new wrinkle:

It will now alter what your browser shows to you, so that you don’t see the unauthorized transfers.

Essentially, the malware knows what you expect to see and shows you that, while it is simultaneously lurking under the radar of banks and avoiding their anti-fraud systems. For those that want more details, read this, this, this and this.

For everyone else, try the following:

1) Check your banking statements very carefully. Most home users have at least 30 days to challenge a transfer, but business users only get 2.

2) Work with your bank to implement a call-back mechanism so that you can approve transfers.

3) See if you can use a dedicated system for only doing banking. Leave it unplugged and turned off unless you’re using it or patching it.

4) Keep all of your other systems patched and run a decent anti-malware system.

Security Lessons from Nature – Long Worm

There is a story that we hear as kids about worms.  We’re told that you can cut worms into as many pieces as you like and they’ll each grow into a new worm.  As cool as that sounds, it’s a lie… mostly.

Regular earthworms don’t regenerate, so you can set aside your plans to buy worms on the Internet, cut them up, and sell them at a profit. However, after generations of scientists spent their lives gleefully chopping up worms and recording the results, we know of a few families of worms that do manage to more of less regenerate.

The key seems to be the segments. When you make a cut, the number of segments connected to one another determine the worm’s ability to regenerate. Certain worms can, in fact, grow from both ends and go on to live fairly normal lives… at least, as far as worms go.

This can be applied to business systems as well, though we call the segments different things at different levels. At a programming level, we work with modules and services. A good design would use lose coupling and connect the segments in such a way that some of them could fail and the system would still function. At a system/network level, you can build highly available systems out of nodes and connect them with either a cluster or virtualization system. Again, the goal would be that if any nodes fail, the system itself would survive.

What’s interesting is that the same model works at the business as well. One of the techniques discussed at last month’s BIZ presentation for business acquisition, was to build your business such that you can spin portions off. Business incubators often work the same way.

The thing we often forget about security is that it’s not just about keeping the wrong people out and allowing the right people in. It’s about survival. The reason we care so much about access and is that one of the easiest ways to ensure survivability is to prevent bad people from getting in. However, if the ultimate goal is to survive, you also have to consider ways to thrive in changing environments. Security should be intrinsically tied into the business in the same way that the segments tie into the worm.

The segments do more than just allow the worm to survive should it be dissevered in the name of scientific discovery. They give the worm flexibility and help contain organs. In fact, the longest worms in the world are segmented.

Makes you think, doesn’t it?

Mythic Monday – The Camel Seen For The First Time

Another Aesop fable is The Camel Seen For the First Time. You can read it here, here or here… but since it’s short, I’ll paraphrase it here. (While the actual text is public domain, the translations are, for the most part, not.)

When humans first say the camel, they found it frightening. It was huge, scary and humpy, so everyone fled. However, as time went by, people discovered that the camel was gentle. As they grew more familiar with it, they began to hold it in contempt and eventually allowed their children to lead it.

The intent of the fable is to basically show that familiarity breeds contempt. It is both a message that one should not fear things unnecessarily, and that one should not become so familiar with something that fear goes away entirely.

I think that this applies to technology as well. We often hear about new technology and how it can be paradigm-changing. However, when we first attempt to deploy such technology we are often baffled and confused. New technology can be incredibly complex and difficult to understand. It can take days of trial and error to figure it out, much less determine how to best fit the technology into your existing infrastructure.

Of course, once you’ve managed to get the technology working, it seems old hat and it is often baffling when new employees don’t pick it up right away. As time goes by, though, they learn the technology and eventually take over.

The lesson here, of course, is to learn from other camel trainers. If you just believe those that have gone before you, you can avoid the whole fear response and jump ahead to figuring out how to train the camel. Then you can get the technology quickly deployed and get on to learning about future species.

Review – Apache Security

I’ve had the book Apache Security for a while now, so I thought I’d give it a quick review.

Like most O’Reilly books, it’s well thought out and fairly complete.  Unsurprisingly, it focuses on the standard LAMP stack, giving advice on building and deploying Apache and hooking in PHP and SSL.  Ruby seem to be missing, and Perl is just discussed within a chroot environment.  It discusses performance tuning a bit, in the guise of protection against DOS, and then moves onto issues in a shared hosting environment.

Much of what is in this book is more general than just Apache, so it’s best to consider this as a general security book for people running both Linux and Apache, and ideally using PHP and MySQL.  It would be less useful to people running Apache on Windows and for people using less common languages.  However, it is very good for the basics:

  • Installing Apache
  • Hardening Apache
  • Setting up chroot
  • Hardening PHP
  • Configuring logging and access
  • Understanding web attacks

Where it seems to lack a bit is:

  • It presumes that the reader will install Apache from source, whereas most these days will install from a package.  More advice on hardening Apache in the SuSE, Red Hat and Ubuntu/Debian environments would be useful.
  • There is no mention of AppArmor or SELinux (which, to be fair, were pretty new when this book came out).  A second edition will have to have these, as they are a key way to protect Apache against itself.
  • A few pages on how to use Suhosin to protect PHP applications would be good.
  • A section on protecting Ruby and one on Perl would be good.  While it is certainly true that no book can cover everything, these three languages are the most common in the LAMP world and should probably be addressed, at least in passing.
  • While we’re at it, a section on hardening MySQL wouldn’t be out place, as the book is more of a LAMP book than an Apache book anyway.

I recommend this book for the beginner to moderate admin, be they a web admin or in the security space.  However, experienced people may not find much new in here.  I would, however, love to see a second edition released.

Small Business Attack – Metasploit Defenses

The easiest way to protect against tools like Metasploit is to make sure that there are no exploitable services running. Of course, this isn’t always as easy as it sounds. Services are constantly being explored and new exploits are often found. If you’re lucky, the vendor will release a patch. If you’re even luckier, the patch won’t break anything essential.

However, odds are that you’re not that lucky.

Some systems stop being updated after a period of time (Windows NT and 2000) and some cannot be updated without causing a problem for a linked system (manufacturing systems are often prevented from being updated). It’s also quite likely that a so-called “zero day” exploit will be used against you. Zero day exploits are ones that are used the day that they are announced. Of course, they tend to be announced after the exploit had been found and used… so the “zero” could well be a “negative thirty” (or 60 or 120).

So, if you can’t make sure that your running services aren’t inherently exploitable, you’re pretty much left to two choices. You can either turn the services off (a service that isn’t running can’t be exploited) or you can try to wrap the service in a system that makes it less exploitable.

I recommend that you do both. If you don’t need a service, disable it. If you do need it, consider wrapping technologies like AppArmor, Suhosin, OSSEC, Core Force and Mod Security or using a more generic proxy solution.

Other Sites: Business, Photos/Conservation

Get the feed (RSS):



Josh More - Entropologist
Expert in removing chaos from
I.T. and business systems.