Mythic Monday – The Sphinx
- At April 06, 2009
- By Josh More
- In Mythology
- 0
“Which creature in the morning goes on four legs, at mid-day on two, and in the evening upon three, and the more legs it has, the weaker it be?”
That was the riddle asked by the Sphinx, a creature sent to Thebes to by Hera (or Ares). When the riddle was answered incorrectly, the Sphinx would strangle and devour the challenger. This went on for a while until Oedipus, who answered “man” and explained that the “time of day” was a metaphor for “time of life” and that the question refers to the stages of life: baby crawling, man walking, old man with a cane. After this, the Sphinx (being unable to come up with another clever riddle) promptly killed herself.
Today’s myth is fairly transparently about password security. The Sphinx made three basic errors that we can learn from:
Question/Answer Pairs
We’ve all seen the “security question” prompts. They often ask about pets or parental surnames. Sometimes they ask about special anniversaries. In any event, if you are moderately findable online, a quick search of genealogy databases or photo-sharing sites can turn up answers to such questions. To combat this, you can either hide all information relating to you, search it out online and remove it, visit public libraries and burn all the public records and brain-wipe all your friends… or you can answer the question nonsensically. Just because the field says “mother’s maiden name”, doesn’t mean that you have to put that in there. Maybe put in your favorite fruit instead.
Suppose the answer to the Sphinx’s riddle wasn’t “Man”, but was “Kiwi”? Sure, the myth wouldn’t make much sense, and Oedipus would have become dinner rather than king, but the riddle would have much less guessable.
Short Answer
You know how irritating it is to have to have a password that is “at least 8 characters”? Well, the reason is that there are people that can try all sorts of different words until they get in. It’s as if someone in power (like, say, Oedipus) were sending numerous peasants to the Sphinx with random answers. It would have gone something like this:
- Sphinx: “Which creature in the morning goes on four legs, at mid-day on two, and in the evening upon three, and the more legs it has, the weaker it be?”
- Peasant 1: Umm, (checks list) an apple!
- Sphinx: Nope. (strangle) (eat)
- Peasant 2: How about an eagle?
- Sphinx: Nope. (strangle) (eat)
- Peasant 3: (looks about warilly) man?
- Sphinx: Close, but we just changed the answer in the previous section. (strangle) (OM NOM NOM NOM)
- Peasant 4: (reads the previous section). Kiwi!
- Sphinx: Drat! (strangles self and throws body over cliff)
- Peasant 4: Yay! I win.
- Oedipus: (strangles peasant 4) (looks around warilly) Yay! I win.
So, the Sphinx manages to survive a bit longer, but is still undone because the answer is short and guessable. Let’s protect against that by changing the answer from “Kiwi” to “My favorite of all the fruits is the kiwi… the fruit that needs a shave!” That’d be a lot harder to guess. Hard enough the Oedipus might even run out of peasants before he gets to it.
Only One Question
Ah, but what if you have an exceptionally smart guesser. Suppose they know something about the person choosing the password. Even incredibly long passphrases have to be remembered, so odds are that a little bit of social engineering can be of use. If we fully embrace anachronisms and have a Sphinx that is a Star Wars fan, odds are that the pass phrase would appear on the list of 30 Most Memorable ‘Star Wars’ Quotes. Similarly, if the Sphinx were known to enjoy Shakespeare, 200+ Famous Bardisms might be a good place to start. The point here is to pre-load the disposable peasants with likely answers, so that Oedipus can hit upon it while there is still a peasant to kill and claim the credit.
A clever Sphinx can protect herself by coming up with multiple riddles. In the security field, we’d call this multi-factor authentication, which we shorten to “know/have/are”. To extend our horribly-mistreated metaphor, the Sphinx would be highly secure if she:
- Something you know:
- Q: “Which creature in the morning goes on four legs, at mid-day on two, and in the evening upon three, and the more legs it has, the weaker it be?”
- A: “My favorite of all the fruits is the kiwi… the fruit that needs a shave!”
- Something you have:
- Q: “Do you have the key that unlocks this super special box that I borrowed from Pandora?
- A: (peasant offers a herring that has been painted plaid)
- Remember, the answer should be nonsensical and nontrivial. A plaid herring covers both requirements in most instances. Besides, it’s generally best to leave Pandora’s box closed.
- Something you are:
- Q: “How do I know that you are truly you?”
- A: (peasant shows the Sphinx that birthmark that Oedipus painted on his arm)
- It’s very difficult to forge the “something you are” check, but it can be done if the verification technology is flawed, be it a fingerprint scanner that doesn’t check body temperature or a stupid Sphinx.
Thus, the only person that could get past the Sphinx would be someone that managed to prove their identity three different ways, which makes it extremely likely that the person allowed is the one authorized… or someone that has privileged information as to which questions will be asked and which answers are expected. So, make sure that your questions and answers are reasonably secure, but also make sure that you don’t let anyone else know that they are. Secrets are only good so long as they are kept secret.
That’s why the Sphinx had to kill herself, you know.
Mythic Monday – Medusa and Immutability
- At March 23, 2009
- By Josh More
- In Mythology
- 6
Most people these days know at least part of the tale of Medusa. You know that she had snakes for hair and that everything she looked at turned to stone. Well, unless you’re big into gender theory, you can ignore the rest (at least for the purposes of this post), because today we’re going to talk about stone.
Throughout myth, stone is often viewed as unchangable. Even in this modern day, we have phrases like “etched in stone” and stories of the weeping angels. Despite the obvious fact that it’s not true, we tend to think of stone as permanent. After all, making it otherwise requires special tools and/or special skill. In everyday experience, something that is made of stone is going to stay that way forever.
If only there were a way to apply the same concept to business security.
Granted, in many cases, you wouldn’t want this. Security should be reactive and responsive. As stable as stone may be, very few people would call it highly responsive. (Amusingly, as I write this, reports of the eruptions of Redoubt and Tonga are just coming in.) However, it would be nice if you could effectively lock certain changes into stone, rendering them immutable.
Well, you can. Most systems have access rights that can be tuned. If you configure them correctly, only the right people will be able to write to those files. In effect, it’s like the computer has a special Medusa inside it that can turn files into stone for most people. This is a basic aspect of system hardening. If an attacker cannot write to a file, they can’t make changes, and you’re better off.
Ah, but what if you’re one of those Greek heros for whom the computer’s Medusa doesn’t work? Shouldn’t you have the ability to ask Medusa to lock your files so that even you can’t change them?
Well, once again, you can do this. Most Linux systems have what are called extended file permissions that, strangely enough, are generally only used by attackers. In addition to the basic read/write/execute (in this case, “execute” means “run”, not “stalk with mirrored shield, cut off head and cause the birthing of the pegasus”), you get special magic powers such as:
- Make immutable
- Make undeletable
- Make appendable-only
Thus, you can create a configuration that is readable and works just fine, but is completely unchangable unless you are the admin of the server and you know the extra level of protection. Now, it’s not a panacea by any means, but one more layer of protection keeps out one more class of attacks. . . and that’s a win.
For more information:
Mythic Monday – Cúchulainn and the Morrigan
- At March 16, 2009
- By Josh More
- In Mythology
- 0
In Celtic myth, Cúchulainn was a classic hero. The Morrigan, however, was a goddess of battle and fertility (interesting how those two often go together). Near the end of his life, the Morrigan appeared to Cúchulainn in the guise of a young woman and offered him her help in battle. Cúchulainn, of course, refused her help and did so in such a way as to cause offense.
Admire the classic heroes as much as you like, but you have to admit that they had a fair amount of arrogance to them.
The Morrigan, upset at Cúchulainn’s attitude cursed him and left. Later, so the story goes, Cúchulainn entered into battle with another warrior and the Morrigan did her level best to bring about his defeat. Being a classic hero, of course, he prevailed and later met her again in the guise of an old woman. Again, he didn’t recognize her.
At a later point, the Morrigan appears as the Washer at the Ford (aka bean nighe, a type of bean sídhe (not this one)) and then, after he ignores this warning, as three old crones (it’s a goddess plurality thing, just go with it). The three crones trick him into eating dog flesh, which he was sworn to never do. Cúchulainn is then weakened and loses his next battle.
So, ignoring the obvious lesson here (which is, of course, don’t anger a goddess), what business-applicable lesson might we learn from this story?
I think that the important thing here is that Cúchulainn has numerous chances to treat the Morrigan with respect, and never does. He is too caught up in his own legend to recognize the power of another. The classic read on this myth is that he doesn’t recognize feminine power, but I think that business-point works well as a gender-neutral. As such, he makes an enemy for life and she eventually brings about his downfall.
In business, we often see the same people over and over again. Some of my old coworkers are now working for competitors, some are potential clients, some have started their own businesses. Odds are that the same applies to you. If you work in this industry for any length of time, you may well see the same people rise and fall. You may find yourself sitting across the negotiating table from your worst enemy or your best friend. You never know what the future may hold.
Thus, it would be wise to pay attention to all people. Treat them with respect and help them when they ask. After all, the nice, but inexperienced coworker may not be a goddess in disguise, but it’s quite likely that they may become your boss in the future.
Mythic Monday – Cupid, Psyche and Detection
- At March 09, 2009
- By Josh More
- In Mythology
- 0
So I was relaxing last night reading a bit of Lucius Apuleius, and got to the story of Cupid and Psyche. Like many myths that have grown over the ages, this one is terribly long and complex, but I think we only have to look at the first part to learn the important lesson.
Leaving out all the important mythological bits about Venus being jealous and controlling love and Cupid’s arrows having a similar, but subtly different power, let’s get right to the point where Cupid and Psyche are living together. Cupid and Psyche love one another (mostly due to certain arrow errors early in their acquaintance), but Cupid doesn’t want Psyche to know who he is, or it’ll upset his mom (Venus). Therefore, the rule is “Cupid gets to sleep with Psyche every night, but she’s not allowed to know who he is”. The second rule is “Cupid gets to abandon Psyche during daytime.” Though I may not personally agree with the rule, the point is that a security rule was in place.
Of course, this being a mythological tale, I’m sure that it shall surprise no one to learn that Psyche decides to spy on Cupid as he sleeps. She wanted to know that he wasn’t a snake (hey, who wouldn’t?), and lights a lamp (or candle, variations differ). Then, as would be expected, a drop of oil (or wax) falls on Cupid who wakes up and flies off, leaving her bereft. The reason being that “love cannot exist with suspicion”.
So, what we have here is a story where a rule was in place, the rule was violated and consequences occurred. By now, we as an industry are pretty good at making security rules. We’re harden systems, put up firewalls and write policy. We have all sorts of rules. Examples:
- No personal email at work
- Only administrators may access production systems
- No wireless connections allowed, this includes 802.11*, cellular devices and FM radio
- All passwords must be a 48 characters long, contain a mix of upper case and lower case characters, numbers, punctuation and ǝpoɔıun
But, how good are we at checking that the rules are being followed? How often do you check firewall logs? Do you regularly review which users have which permissions? Do you scan for rogue wireless access points? Do you run regular password audits?
Despite how stupid we may think Cupid’s rule may have been, he had a detection system in place, and was alerted to the spying. Thus, he was able to take action. Though I personally would have used a light-triggered system instead of waiting for my flesh to be burned, his system worked for him and he was able to enforce policy.
Can you?
Mythic Monday – The Song of Roland
- At February 23, 2009
- By Josh More
- In Mythology
- 0
The Song or Roland tells the tale of King Charlemagne and his knight Roland. The tale is long and complex (and nicely summarized here), but the important thing is near the end.
Roland and his knights are ambushed. There’s possibility of success, but they keep fighting on. Roland has but one option remaining, and that is to sound his horn and summon reinforcements. However, to require help would not honorable, and Roland would rather die than be dishonored. Things get so bad that Roland’s friend implores him to blow on his horn three times, and Roland in his pride, chooses not to.
Then, at the end, when all is truly lost, Roland finally sounds his horn and dies with the effort. The king hears and comes to the battlefield and avenges the dead.
So, what can we learn from this?
I think that the most important lesson is pretty obvious: blow the horn before everyone dies. Or, in modern vernacular, swallow your pride and ask for help.
It’s no news to anyone that a lot of businesses are struggling right now. The economy is in a state of turmoil, and while a lot people say that you can make money whether the stock market moves up, down or sideways, the simple fact is that things are hard when the future is even less predictable than usual. Existing vendors may change your credit terms, clients may demand a higher value from you for what they’re paying. Competitors may choose to compete in ways that may not be ethical or fair.
What can you do about this? There’s one simple option: ask for help.
There is a lot of talk about business being cut-throat and numerous stories about business partners that took advantage of one another. However, at least in the small business market, the opposite is also true. People help each other out.
Sure, there are high-priced consultants who will come in and give you advice. There are also well-intentioned friends who might help you out for free. But don’t forget about the tons of mid-range business people that are willing to lend a hand for modest fees and/or the trading of services. Odds are that there is a relatively workable solution to your business problem and a cheaper or more efficient way to do things. However, if you never ask for help, you may never find them.
There is also no point of waiting until everyone around is dead or dying (or laid off) before you call for help. If you wait too long, your business just serves as a tale of warning to others (much like The Song of Roland, actually).
Remember, we may be competitors, clients or vendors, but we actually are all in this together. It does no one any good to stand by and idly watch as small businesses fall like dominoes. We can help each other out… so long as we know who to help.
Mythic Monday – Immortality
- At February 09, 2009
- By Josh More
- In Mythology
- 1
Stories about immortality and the quest for it abound in literature. You have kings trying to live on through their sons. You have gods that must ritually die and be reborn so that the cycle of nature can continue. And you have, in a few stories, the few humans that succeed in their quests.
Consider, for example, the Cumaean Sibyl who bartered her virginity to Apollo in exchange for everlasting life (not technically, but despite appearances, this isn’t a mythology blog). However, she made a bit of an error when she forgot to also ask for everlasting youth, so she kept getting older and older until she eventually faded to nothing but a voice kept in a jar.
This is very similar to the story of Tithonos, who was granted immortality by Eos (via Zeus) but she also forgot to ask for everlasing youth, so he aged past senility and was locked away where he babbled to himself in an empty room.
(Stories from Metamorphoses 14 and the Homeric Hymn to Aphrodite).
What lesson is there here? Clearly, there’s something for us all to learn about operating system virtualization.
Yeah, you heard me right. Ovid and Homer* were clearly writing about the modern practice of virtualization. Specifically, they were concerned about aging operating systems.
* Whether Homer actually wrote the Homeric Hymn to Aphrodite is debatable.
See, virtualization is wonderful, and it’s all the rage right now for some excellent reasons. It allows you to fully leverage your hardware to capacity. You can aggregate virtual machines on top of real machines and have them create a robust infrastructure. If any hardware fails, all the little VMs can even skitter around like cockroaches as they find a working environment in which to live. In short, we as IT admins have the power to make these machines live forever. We are truly blessed.
But, as ancient mythology has informed us, with great power comes great responsibility (OK, so that bit is modern mythology). We have the power to grant immortality to these systems, but we have to consider how we use that power.
After all, what purpose does death serve? It allows new life to take hold. It allows unfit life to go away. From a technical perspective, this means that we have to let systems die to make room for new and more efficient systems to be built. Also, and a bigger concern, we have to let the ancient systems die before they start to make problems for us.
Imagine for a second, a network that has a mix of Windows 2003, Windows 2000, Windows NT, Windows 98, RedHat Enterprise 3, IRIX, AIX and DOS. Now, I’m sure you’re thinking “this is ridiculous, such a network doesn’t exist, no one would let that happen”. Well, this describes the network I was working on a few months ago. I’ve worked on live production networks in 2008 that used operating systems that were five to ten years old. I’ve heard tales of systems that were running Windows 3.1, as production machines, into 2009.
Now stop for a minute and think ahead twenty years. Can you imagine still supporting Windows 2000 in 2029? What about 2049? We have the ability to grant these systems immortality, people. It’s going to happen.
Sometime in 2020, you’re going to be working on the GoogleSoftwahoo TeleBlazinger running on Linux kernel 2.6.3492-23 and wondering why your network hypercloud is slow. After launching numerous tools that allow you to trace network traffic in all four dimensions (five if you can afford the enterprise license), you’ll track the problem to an infected botnet of Windows 2000 systems running a ponzi scheme involving stolen credit card numbers. You’ll try to refresh them from backup, to discover that they’ve been compromised for the last 19 years, and your backups only go back 15. And, worst of all, there’s a legacy billing system that requires these machines, so you have to keep them running… forever.
You’ll stop, scratch your head, and think that virtualizing at the operating system level was the stupidest thing that we ever did. And you know, you’d be right.
What it comes down to is how your organization is structured. If you’re building a virtual infrastructure, making brand new systems and setting hard deprecation dates for these systems, you’ll probably be OK. However, if you are like many companies, and take the perspective of “just move the physical machines to virtualization and we’ll straighten it all out later”, I’m sorry to break it to you, but later is never going to get here. There will always be another fire and another resource restriction.
We have think through new technology before we deploy it. There is a tendency to only look at the benefits and costs in terms of dollars, not in terms of time. A small gain in the present can be completely reversed and magnified by the flow of time. Just as inefficiencies add up throughout the weeks and months, security problems tend to grow over time. The longer you keep legacy systems around, the greater your risk grows.
If you grant immortality to these systems, they will just continue to age, until they will eventually be just another set of voices, hidden somewhere in the back of your network, babbling at your IDS systems pleading to be allowed to die.
Mythic Monday – Orpheus
- At February 02, 2009
- By Josh More
- In Mythology
- 0
So, you all know the story of Orpheus, right?
Short form:
Orpheus was the greatest musician in the world. He had a wife named Eurydice who died. He went to the underworld, played for and charmed the Lord and Lady of Death (Hades and Persephone) into letting him bring his wife back from death. The one condition was that he not look back on his journey back to the lands of the living. Being a Greek tragedy, he looked back and saw his wife following. She then faded away, and was gone forever.
Longer (and better) versions can be found here and here. I mostly want to look at one main theme.
Trust
While, most people seem to have a general idea of what the word “trust” means, there has been considerable debate in the computer security field as to how to build it into systems. They raise questions about levels of trust, webs of trust, calculating trust, and how to handle the fact the trusted relationships can change over time. These questions can be very fine grained and particular, but you’re probably not interested in the academic nature of these discussions. Instead, let’s look at a couple examples.
Scenario 1: You partner with a large company.
Suppose you enter into a business partnership with a company that is much larger than yours. Odds are that you have to fill out a contract and commit to specific items (usually based on revenue). You are then granted access to specific resources at the large company. In IT, this is usually in the form of internal-use licenses.
In this model, you trust the company to provide you with software that doesn’t steal your data and the company trusts you not to resell your licenses to others or otherwise negatively impact their revenue. So, what happens if the trust model is violated?
Well, there are really two variants. If you break the trust relationship, you will likely be faced with, at minimum, the severing of partnership and, at maximum, legal action. However, if it turns out that the large company is not to be trusted, what can be done? Legal action may not be much of an option, and if you terminate the partnership, how much would it hurt you versus the large company?
Is the partnership fair?
Scenario 2: Trusted people within a business.
In security discussions, the second hardest discussion is trying to convince a client that inside attacks are a real and present danger. Of course, the hardest discussion is after the trusted insider is discovered to have been embezzling money or selling private data, so it’s often worth the time to have the first discussion.
Simply put, businesses don’t function well without trusted internal people. If there are too many rules, work can’t get done. However, the more lax an organization is, the more risk it faces. In time of economic difficulty, this risk increases.
Why? When people don’t get bonuses and raises, they often take it personally. They may be in a position where valuable data (or even just money) passes through every day. They may stop and think “gee, with all this money around, who is going to miss a little tiny bit” then they’ll have the big thought of “besides, they owe me”. Sometimes, they wind up in personal difficulty, and it starts as a little “borrowing” that gets out of control.
This happens all the time: police sergeants, booster club presidents, priests, vice presidents, and more.
Yeah yeah, I know, you’re different, your people can be trusted.
Maybe, maybe not. . . probably not.
Do you have any systems or procedures in place to catch this type of activity?
Conclusion
In the story, Hades and Orpheus had an agreement. Sure, it was an agreement with an odd condition, but that’s not exactly unusual in partnerships. In this case, who was trustworthy and who was not? Also, how were the individuals impacted?
Hades: Got to hear some lovely music.
Orpheus: Lost the love if his live TWICE.
The cost of being untrustworthy is awfully high, isn’t it?
So, what could Orpheus have done differently? Might the agreement have benefited from some additional clarity, so that his nervousness could have been alleviated? Could there have been some procedure or technology used to make it more difficult for him to violate the agreement?
Look at the trust relationships at work within your business. Consider what happens if you wind up being untrustworthy. Consider what happens if your partner isn’t trustworthy.
Is there anything in place to validate and maintain the trust?
Should there be?