Mythic Monday – The Creation of the Aztec People

According to Aztec myth, after the previous inhabitants of the Earth had been turned into fish, the gods wanted to make more people. Now, one would rationally expect that if the gods liked people so much, they wouldn’t have flooded the Earth in the first place and turned all the previous people into fish, but the Mesoamerican myths don’t seem to be much for rationality and forethought.

Anyway, to create the people, the gods need the magical bones where were guarded by the Lord of Death. After a fairly typical quest followed by a challenge and the reneging by the Lord of Death on the deal, the hero carrying the bag of bones fell to the bottom of a pit and the bones were broken. That, of course, is why the people come in a variety of shapes and sizes.

Of course, we are quite lucky that the Aztec hero was such a klutz. The numerous variations in humanity have rendered us resistant to various plagues. (Technically, this is only partly true as there is evidence that humans are more genetically identical than most animals (except for cheetahs), but we’re ignoring that here.) The more variation there is in a genome, the greater the resistance to threats. Though similar concern has been raised about the ongoing homogenization of our food supply and how it renders us vulnerable to threats. this blog is about I.T. and business security.

For quite some time, I have been arguing against homogenization within certain businesses. The current practice of having all systems identical makes things very easy to manage. It makes it easy for auditors to verify that proper security standards are in place. It also can tie into automatic patching plans and keep everything up to date. However, it means that every person in the organization has adapt themselves to the same software and that if an attacker manages to get into one system, they can march right into every other one.

Like all things, using system images is a tradeoff. It seems that many organizations implement imaging just because it’s best practice. Sure it solves some problems, but any change also creates others. Often, an imaging project identifies numerous applications to drop out of the environment. This is great for general security, as it reduces attack surface, but often many of these are there because they make the business more effective.

Given that the whole point of “the computer revolution” was that we are now able to adapt technology to our lives are very small levels. It seems like questionable logic to take devices that are capable of enhancing individual abilities and compensating for individual flaws and turn them all into identical machines and then force people to match them. Richard Bejtlich gets into this in more depth over in his post Let a Hundred Flowers Blossom.

My point isn’t that imaging is bad. In some environments, it’s a necessity. (Mostly regulated environments or those lacking a technically-skilled workforce who can select the appropriate applications to enhance their productivity.) It just shouldn’t be a goal without consideration of the total business impact.

After all, people are all different. If the technology is all the same, it obviously won’t work as well for some people than it will for others. The question to ask is whether the benefit of uniformity outweighs the cost of productivity.

Security in the Harry Potter World

I recently picked up Harry Potter 6 on Blu-ray. While I’ve read all the books, I’ve generally not been much for the movies. (I prefer the pictures in my head.) However, there is a photographic beauty to these movies that is worth both the time and the money (especially when the box set of 1-5 was on 70% off recently)… so I’m watching them and remembering the stories.

As with most works of art, the easy path to drama is to create a security failure. It makes sense, after all. As a creator, you may have a need to push your characters at time, and the easy (lazy) ways to push a character are to create a situation for them to react to. Thus, viewing the worlds as if they are real is a bit unfair… but on the other hand, nitpicking is fun.

In the world of Harry Potter, there are several security situations. The world of magic has to be kept a secret from all the muggles, the evil people have to be kept out of Hogwarts, and what is kept in Gringotts must stay in Gringotts. In fact, we know that there is some sort of magical muggle spy network, as Dumbledore knows to investigate Tom Riddle prior to his acceptance into Hogwarts. Why this same network can’t detect the attack upon Harry by the dementors in book/movie 5 is unclear. Clearly, they need to invest in redundancy for the system.

Similarly, Hogwarts seems to have a surprisingly difficult problem keeping students where they belong. It took until book/movie 6 before they put up a firewall around the school, and even then, attackers manage to encapsulate an attack within a legitimate source (Katie Bell) and also fail to Draco’s VPN bypass (terminated by vanishing cabinet). It seems that magic should be able to do better.

In contrast, Voldemort clearly knows a lot about security. He makes backup copies of his soul, just in case something happens (like a backfiring killing curse). Granted, the restoration process leaves a bit to be desired. If he really cared about operational availability, he would have tested the process and avoided that whole 12 year delay issue. (And here I thought 24 hours to deliver backup tapes from the offsite repository was a long time.)

Similarly, given that it’s been established that there is a thing called “a trace” that can detect when someone casts a spell. You’d think that they could use the same practice during quidditch matches to prevent the audience from interfering with the play… but they don’t. As a result, there are all sorts of amusing and dramatically-appropriate hijinks.

Lastly, in an environment where a bunch of students are awash in teenage hormones AND are constantly playing with potions AND know that love potions exist, you’d think that there would be an emergency bezoar in each dormitory. But there’s not.

It would be interesting to see what the world would be like if there were more audit-focused monitoring points, reactive responses points and preventative spells. However, just as in the real world, these sorts of technologies are tempered by the economics of the situation, in the fictional world, there is a trade-off with dramatic tension. Sure, there are a lot of things that Dumbledore could have done to increase the relative safety of his charges, but to do so would have drastically reduced the possibilities for dramatic tension.

This would have reduced the number of books from 7 to likely 1 or 2. In our universe, Dumbledore lives for six whole books. If he had been a more protective head of Hogwarts, Voldemort may have been defeated much more quickly and the series would have been reduced. So, like most people, Dumbledore made a self-interested decision that had ramifications outside of himself. He got to live longer and be in an incredibly popular series of books and as a result, many of his students were placed in some wonderfully dramatic jeopardy. That’s something to consider, I suppose, when there are security decisions that you have to make.

Bias Thursday – Pseudocertainty Effect

While I am not a psychologist, it’s becoming increasingly obvious that a good understanding of psychological issues is an important facet of a full security practice. These themed posts are likely to be incomplete, as I am just exploring some ideas and how they might apply to security.

In running through the List of Cognitive Biases on Wikipedia, I ran across the Pseudocertainty Effect. Simply put, this is the tendency of people to emphasize the positive over the negative when faced with a choice. The classic scenarios can be read at the Wikipedia link above and here.

Basically, this means that by phrasing a choice differently, you can guide people into making the choice you want them to. I’ve seen this used on the sales side of things, but I have to wonder whether it’s an intentional abuse of this tendency.

As I see it, this effect is useful to note in both offensive and defensive capacity. On the offensive side, if you’re needing someone to make a choice and you want them to take a risk, you emphasize the negative consequences, but if you want them to take a guaranteed path that may be incomplete, you emphasize the positive. For example, suppose you are pitching an idea to management. The idea has a 80% chance of success, but has a $10k cost. If you want them to accept your idea, you need to understand that the natural tendency would be to make the choice that preserves the certainty of saving $10k, rather than risking the 20% chance of failure. Thus, to be accepted, the proposal would need to either eliminate certainty altogether (perhaps tie the cost to averted loss offsets and phrase it as “between zero and $10k, depending on success”) or focus on the certainties of the results. Thus, if the 80% projected success rate can be broken down into one set of guaranteed successes and some that are maybe 40% likely, the proposal can focus on $10k for a guaranteed success with a bonus opportunity for further improvements.

On the defensive side, you should be aware that it is natural to think this way and that others will try to exploit your tendencies along these lines. Whenever you are presented with a choice (well, one that matters anyway) you should ask yourself whether it is phrased positively or negatively. Then, knowing that you have a tendency to preserve positive outcomes but take risks to avoid negatives ones, flip the phrasing around and see if the other choice makes sense. If you find that your choice flips with the phrasing, then this bias is in play and you need to think things through more carefully.

Security Sprint – Internet Passwords

We’re all busy people. A security sprint should take no more than two hours… which while long for a real sprint, it a mere blink of an eye when compared to the multi-year commitment that is proper security practice.

You’ve probably heard about some of the recent attacks against various websites. The problem here is that if one of the sites you use gets attacked AND they’re not encrypting your password AND you’re using the same password on other sites, then that one breach on one site can put all your other sites at risk. Of course, if you want to be on the Internet, you have to accept some risk… but it’s hard to accept the risk when you don’t know it’s there. So let’s figure it out.

1) Take twenty minutes and make a list of all of your Internet sites in a spreadsheet. Try to remember all of them, not just the common ones. There’s a list below to get you started:

2) Go to the login page of each site and click on the “forgot your password?” link. Yes, this will reset your password, but that’s the point.

3) Once the new password arrives in your email, look at it. Does it sound like something you’d pick for yourself? If so, there’s a good chance that they’re not encrypting their passwords properly. Create a “secure” column in your spreadsheet and mark them as “no”.

4) If the password arrives and looks random, then they reset your password for you… which probably means that they can’t access your password directly. This means that it’s probably encrypted in the database. Mark these as “yes” in the “secure” column.

5) There is a drawback to this plan, and that’s that all of your passwords will change. Most of the sites that you marked as secure will force you to change your password when you log back in. If they don’t, change their “yes” to “no”.

6) Now you have a list of all of your sites and know which ones are the more trustworthy. The last step to this sprint is to reset your passwords to something more secure. There are lots of articles and tools out there, and I see no need to add to the pile. All I’ll say is that you should pick ones that you can remember and that aren’t the same for all sites. If you want to use really complex systems, look into password wallet software.

7) Once all your passwords are changed, and you have an idea of how risky your sites are, you can proceed with your Internet life in relative security.

Sites to consider:

Email: Gmail, Yahoo Mail, Hotmail
Social: MySpace, Facebook, Livejournal, Twitter
Professional: LinkedIn, Plaxo, Namez, Zoominfo, Notchup
Images: Flickr, Photobucket, Smugmug
Documents: Scribd, Docstoc, Instructables, SlideShare
Shopping: Amazon, Zappos
Bookmarking: Delicious
Video: YouTube, Vimeo

Security Lessons from Nature – Glow Worm Cave

Those of you that have seen the series Planet Earth are probably aware of the glow worm cave. (Those of you that have not have some TV watching to do.) This is a cave full of cute little glow worms that make a light pattern on the ceiling of the cave that is reminiscent of the night stars. It’s a beautiful sight to stare up at those little glittering pinpoints of lights.

Of course, that’s the tourist spiel. In actuality, the “glow worms” are larval gnats that produce mucus and spin out long threads to entrap moths. When a moth becomes deluded by the mights and becomes trapped in the sticky threads, the larvae pull up the moth and liquefy and suck out their internal organs. After secreting mucus and dining upon moths for up to a year, they transform into gnats whereupon they mate and die… which seems like a lot of work to me, but then, I tend not to be consulted in matters such of this.

However, the lesson here is a good one. Namely, it’s probably not worth travelling all the way to New Zealand to visit the the phosphorescent snot worm cave. However, a deeper lesson is that light attracts bugs. (Sure, I could have blogged about the moth and the candle, but then I’d not be able to talk about glow worms.) If you want to know something about the insects that inhabit a cave, just put out a light and see what comes visiting.

We do that in I.T. security to help identify the attackers that are on the Internet. We call them honeypots, which is likely a reference to Winnie the Pooh (I hope), but since I am not (yet) linking children’s literature to security, we’ll ignore that bit for now. Instead, we’ll take a quick look at the value of Lepidopterisy. Just as a scientist can look at the types of moths ensnared in sticky mucusy silk and learn a lot about the ecology cage, a security researcher can examine the malware and attacks found within a honey pot and learn a lot about the sorts of attacks that they may be subjected to.

By creating your own honey pot, you get a chance to deal with attacks before (hopefully) they impact your production systems. However, just like fungus gnats larvae don’t ignore the moths that stumble into their “webs” (strings, really), in order for this to be effective, you can’t ignore what gets caught in the honey pot either.

Mythic Monday – The Lion, the Mouse, and the Fox

In case you haven’t figured it out, I fall back to blogging about an Aesop fable when I’m stuck for other things. In this case, I am stuck underneath a cat and all of my mythological references are about half a meter out of reach. Luckily, many of Aesop’s fables are available online. Like, for example, this one.

In this story, a sleeping lion is startled awake when a mouse runs across his nose. Looking all around for whatever woke him up, he checks all over his cave and finds nothing. A fox observes this behavior and, knowing that he can outrun a sleepy lion, makes fun of him for being afraid of a mouse. Attempting to safe face, the lion claims not to have been afraid, but more affronted by the bad manners.

As usual, Aesop completely missed the point of his story. Instead of being a droll observation of class structure of ancient Greece, it’s obviously a better lesson for dealing with initial network probes. Probes are a fact of life on the Internet. All sorts of attackers on the Internet want to take over your systems. The first step is to send out a small probe and uncover various things about the potential targets. This is part of what firewalls are supposed to prevent.

A lion needs a few things as it sleeps. Air, probably being the most important. However, if it wishes to stay asleep, it helps to have a way to keep the mice out of the lion cave.

As an aside, I personally question how common it was for lions to sleep in caves. Modern lions don’t seem to do this… though perhaps that has less to do with lion slumber preferences and more to do with a general lack of caves in subSaharan Africa.

So, if you have a lion that wish to keep vermin-free, it would help to put up some sort of chicken wire fence over the “cave”, thereby allowing in air and preventing mice (and rats… it’s a twofer!). In much the same way a firewall keeps out known malicious traffic so your servers can crunch their numbers in piece. Admittedly, our firewalls block worms. Worms are smaller and trickier than mice, which is why the firewalls are more complex and expensive than chicken wire.

Running without a firewall would be like trying to coax a lion into sleeping while they are being trampled flat by a veritable cascade of members of the family Muridae.

Small Business Defense – Patch Management

There are three ways to approach this problem. The most common method is to ignore it, and apply patches as time permits. The logic here is that since applying patches can often require a maintenance window, it’s hard to balance the business’s needs against the risk of an attack by an unknown party. Since an increasing number of attacks are subtle, it’s quite easy to convince yourself that it’s not a big deal, and inadvertently accept more risk than you’d like. I don’t really recommend this method.

The second method is to fully embrace the situation and fork out the cash for a full patch management system. These solutions aren’t cheap, but it does allow you to view your entire environment from a single console. This way, you basically outsource the tedious job of keeping on top of everything and use the tool to make sure that all machines on the network are kept fully updated. Now, this solutions doesn’t eliminate the need to schedule downtime to get the patches applied, but it does simplify matters significantly… at least when you are only running software that is monitored by tool.

The third method is something of a middle solution. In situations where you either lack the budget for a patch management solution or are still investigating the varied options, you can simplify the process by doing a quick audit of each of your systems and uninstalling anything that isn’t needed. The key here is system classification:

Development systems should not directly face the Internet.
Production systems should not have development software on them.
Production servers should not have workstation software on them (Office, Adobe reader/flash, Web Browsers)

By eliminating all unnecessary software, you can massively reduce your attack surface. Simply put, if software isn’t there, it cannot be exploited. Now, this doesn’t eliminate the necessity to keep the software that is there up to date, but in the process of removing what’s not needed, you can get a good idea as to what is there and monitor the patch releases for those few projects. It’s not pleasant, but it is doable.

Small Business Attack – Patch Tuesday (and others)

Every month, on the second Tuesday, Microsoft releases a set of patches to their software. They’re ranked in various ways, based on what they correct and how critical they may be. Then, two things happen:

First of all, various security groups review them and start posting their opinions (I prefer the Internet Storm Center synopsis). After that, those of us with more internally-focused positions start reviewing the various summaries by both the security groups and Microsoft and work up an internal plan to test and deploy the patches appropriately. When, after everything looks right, we start deploying the patches to make sure that everything is nice and secure.

Secondly, the various more selfish security groups also review them… but in a tad different way. They investigate what the patches correct and start trying to come up with malicious code that exploits the problem. Then, at the same time that we’re reviewing the patches for our environment, they’re running tests against various other systems. If we’re lucky, at the time that we’re deploying the patches on our systems, they’re deploying the new malware against our systems. If we’re not lucky, they beat us to the punch.

Of course, this is a somewhat simplified scenario. There are a great many more vendors than Microsoft, so this cycle doesn’t really take place on a monthly basis. Some vendors release updates on a quarterly basis, some are yearly and some are pretty much whenever they feel like it. So really, each day is a steady flood of vulnerability information and, if we’re lucky, patches to go along with them.

If you can stay on top of the flood, you can keep your systems somewhat protected. Off course, if you miss something, you leave a hole that an attacker can easily find.

So what do you do about it?

Security Lessons from Nature – Poison Dart Frogs

Poison dart frogs are, not surprisingly, covered with poison. I could go off at length about how different species have different levels of poison, and how not all of them were used to poison darts and how many of them are going extinct due to a nasty fungus that’s only vulnerable to an eyewash solution… but that would be a bit too rambling even for me.

Instead, I’m going to talk about ants. I’m not going to go off about how they are communal, have some interesting chemical signals or even how they are vulnerable to some very interesting fungi that take over their brains (despite how unbelievably cool that is). No, the important thing is that the frogs eat the ants.

Boring, I know.

See, the poison dart frogs don’t generate the poison themselves. Instead, they eat ants and push the poison from the ants out through their skins. Not only is that an awesome example of how a predator can turn a prey’s defense into a defense for the predator while simultaneously rendering it useless for the prey (smart little froggies!), but it’s also an example of the importance of operations.

See, an interesting side effect of this method of defense, is that if the ants go away, then so does the defense. Domesticated poison dart frogs aren’t poisonous (which would make them dart frogs (which, since they neither throw darts nor are tailors, is a horrible name for them)). In order to keep the defense, they have to keep on acquiring ants.

Which gets me into mergers and acquisitions… which is where I wanted to go the whole time. When you conduct an acquisition, as the acquirer, it is often tempting to go for economies of scale and try to get the acquiree to do things your way. This just makes sense. After all, that’s why you bought them, right?

Well, kinda.

Unless you bought them to kill them as competitors, they probably bring another value to the table as well. If you buy a poison dart company and then tell them “Now that you’re part of GlobalConglomeratedWidgetCoInternational, you have do things our way… and we eat our own dogfood!” you’ll definitely merge them into your organization… but if they’re eating dogfood, they’re not eating ants and you just have a dart company.

When merging operations, pay close attention to the operations of the other company and try to understand why they do things the way they do. There’s generally a good one. Then the question would be whether the loss they face by doing things your way is outweighed by the operational efficiencies, and whether it’s all that important that the darts be poisoned.

Mythic Monday – The Aging Lion and the Fox

Another one of Aesop’s fables that isn’t that well known is that of the aging lion and the fox. You can click the link and read it, but for those of you that are linkaphobic, here’s a short version:

A lion was getting old and having trouble hunting. He decided, instead, to pretend to be sick and went back to his cave, moaning all the way. Over time, as each of his neighbors stopped by to check on him, he ate them.

Then, one day a fox came by and asked how the lion was doing. The lion moaned and asked the fox to come closer. The fox then observed that the footprints all led into the cave, and none came out.

Clearly, the fox is the fable animal to be. He’s smart. He’s observant. He’s… umm… red and furry? (Are Greek foxes red? . . . Yes, after googling a bit, it seems that the red fox is global, and the grey fox is only native to the Americas… which has nothing whatsoever to do with this blog entry.)

No, the point of this blog entry is that of evidence. If the lion had been wise, he would have either wiped the tracks after each meal or (more preposterously) fabricated tracks going back out. The fact that he didn’t, is what allowed the fox to escape and presumably tell the other animals what the lion had been up to (and Aesop, since he wrote it down). So, not only was the lion caught, but he lost his lovely little racket and probably starved to death shortly thereafter.

Most attackers are aware of this story (sorta), and do take some effort to reduce evidence. A burglar usually wears gloves, a bank robber usually wears a mask, and a hacker usually clears system logs. So, if we want to make it hard for the lion to wipe away the footprints, we have a few options. The first is to replace the dirt outside his den with fast-setting concrete… which would prove somewhat troublesome if you analyze this ridiculous analogy too far. The second is to set up a camera trap and record everyone who enters the cave. (For those purists who would point out that there were no cameras in ancient Greece, let’s just say that Hephaestus is there cranking out a vase for each animal. (Happy now, picky people?))

In the modern world, we actually use both of these techniques. Instead of fast-setting concrete, we have a hard drive technology called WORM, or Write Once Read Many. With this drive, you can store the logs in such a way that they cannot be altered. They are, however, quite expensive and can be difficult to set up properly. Instead, we generally prefer to use the camera/vase trap system. For this, we use one of many remote-logging technologies. The simplest is probably the venerable syslog server.

This solution simply involves setting up a dedicated server and installing one of the many syslog systems on it. Then you do a bit of configuration on each of the other servers you have and basically tell them to go log over there. Whenever there is an event, it goes over the network and is stored off the server. That way, if an attacker gets in, even if they wipe their own traces, there is a backup elsewhere that is (in theory) a lot harder to alter.

Of course, you still have to actually be the fox and look at the logs now and then, but at least you’ll be safe from a smart lion.