Two dimentional space and other imaginary consrtructs

Remember in geometry class when you were asked to imagine a single point in space with zero width? That's a "point" a zero dimensional object. Then, they asked you to imagine two such impossible constructs and the series of such zero dimensional objects which lie between (how can something be "between" two objects which have no width?) the two and extensions without curve into infinity on either side, this is - geometrically speaking a line, a mythical two dimensional object having only length (typically infinite length) but no width.

Why rant about impossible constructs that we use to define the world around us, build bridges, shoot laser beams at highly reflective Russian moon landers (http://en.wikipedia.org/wiki/Lunokhod_1) and generally differentiate ourselves from really smart chickens? Because I want to make a distinction between useful imaginary constructs like geometric lines and really damaging ones like "secure um, anything."

The word "secure" is by it's nature an absolute term. To back away from that you need to add modifiers like "somewhat" or (and I've heard and/or used this one) suffixes like -ish. Like an actual two dimensional object, secure doesn't actually exist except in theory. Unlike lines, there is really no useful context in which we describe things as secure or not.

Why even have this discussion? Because I encounter people every day, who are supposedly savvy in the ways of protecting electronic assets but use language like "secure infrastructure" and "secure database" when they should be talking about levels of protection. In truth, there's a sliding scale of how protected (how secure - see you can use it with qualifiers...) things are; from my fairly well protected Timex Sinclair in the corner of my office running my lava lamp (no network connection, and I don't type on it - but an EMP could probably corrupt data and ruin the current rendering of the Experience Music Project in lava) to the City of Bellevue 911 system (http://www.schneier.com/essay-002.html) at the other end of the spectrum. All discussions of risk regarding systems and networks should really be done in this context, or lay people (and geometry teachers) will assume that you mean what you say when you use the unqualified word "secure."

While we're at it, there's also no absolute standard for what is "secure enough." Our ultimate goal in most commercial applications of information assurance should be to make things as secure as the organization needs it to be. In other words, to match the level of accepted (or residual) risk to the level of risk that management deems appropriate. I can hear the howling already "What the heck does MANAGEMENT know about appropriate levels of risk? Those guys are complaining about how antivirus is slowing down their $2000 ultra-thin laptops!" To which I say, understanding and accepting all kinds of organizational risk is a large part of their job. In fact, it's what really defines the role of the highest levels of management beyond being just a high level administrative wonk but if your management doesn't understand cyber risk, you haven't done your job.

Mind you, I'm not saying that it was ever really even possible to DO your job, I'm just saying that a HUGE part of the job is explaining risk to the point where the highest levels of management truly understand it and can make good decisions, and apparently that didn't happen. It may be that your management, for whatever reason is incapable of understanding cyber risk (I'll follow with a rant about what is or is not being taught in business schools some other time.) In that case, it may be completely impossible to convey risk and be understood --- but it still means you haven't done that part of your job. I liken this to sending a carpenter to a job site without any hammers. At the end of what would be a very frustrating day trying to build a wall hammering with rocks and other found materials, there's no new dining room wall. Sure, there was no way to build one without a hammer, but in the end the job still isn't done.

So, let's leave the theoretical ideals safely back in geometry class (unless you want to talk about separable completely metrizable topological spaces - which are totally useful in understanding some kinds of data) and talk about the universe we actually interact with where lines have width (on paper), secure doesn't exist, risk is acknowledged to be a relative measure and we don't eliminate parts of our job because they are really hard, or even impossible.

Stop thinking that... whatever it is you are thinking

I'm pretty sure that we don't have the faintest idea what's going through the heads of IT and even IA folks when they make risk decisions. From the fairly common results, I can say that much of the time, it's wrong, but I don't know HOW it's wrong so I'm not sure what needs correcting in the intricate jumble of education, social reinforcement and organizational baggage that's in the head of everyone (including myself) that makes risk decisions that affect the safety of your personal information.

The way we treat security incidents is pretty dysfunctional in many ways, but for today's ramble I'm really just thinking about the fact that when we do root cause analysis (you're doing root cause analysis, right?) we seem to ignore a step in the chain that could have prevented the whole problem in the first place -- a risk management decision that correctly interpreted the risk as well as the likelihood. If that had happened in most cases, steps would have been taken to prevent the mess you find yourself in. Oh, you say that the risk analysis was flawless and folks just failed to act? I've seen that happen too, in which case need to try and understand how management interpreted:

1. Anvil falling from the sky

2. We are standing where it will land in 10 seconds from now (assuming 9.8 meters per second squared acc.)

3. It looks like a heavy anvil and will hurt when it hits us.

...and came up with the strategy "Stay where we are, we've never been hit by an anvil in the past." In all scenarios, someone isn't thinking the right thing, and we need to figure out what that is to even begin to understand how to correct it.

An example of a field where folks have thought about the fact that almost NOBODY instinctively thinks correctly about the topic is probability and statistics. They've thought about it, and come up with a way of figuring out exactly what wrong thinking is going on in some test cases. Here's an example:

Most people get this wrong (from a paper by Linda S. Hirsch and Angela M. O'Donnell in Journal of Statistics Education Volume 9, Number 2 (2001)):

If a fair coin is tossed six times, which of the following ordered sequences of heads (H) and tails (T), if any, is LEAST LIKELY to occur?

1. H T H T H T
2. T T H H T H
3. H H H H T T
4. H T H T H H
5. All sequences are equally likely.

It’s a semi-standardized question to reveal what misconception a person might have about calculating probability. #5 is correct, but a lot of folks will pick #3, as it "doesn’t seem sufficiently random".  The diagnostically useful questions regarding WHY they answer what they did are something like:

Which of the following best describes the reason for your answer to the preceding question?

1.       Since tossing a coin is random, you should not get a long string of head or tails.

2.       Every sequence of six tosses has exactly the same probability of occurring.

3.       There ought to be roughly the same number of tails as heads.

4.       Since tossing a coin is random, the coin should not alternate between heads and tails.

5.       Other _____________________________________

If we wanted to understand how the average (or even average IT person) thinks about risk, it would be helpful to come up with similar tests. 

Password Quality

So, do you administer a system with general user accessing it? Your companies AD, online banking, launch codes? Do you require that passwords be "high quality" - in other words do you require that they be of at least a certain length and further require that they use non-alphanumeric characters in their password, such as numbers braces and the like?

In that case, I expect that most of your users are using 7 or 8 character passwords with the numbers 1 or 2 in them, typically at the beginning (for 1) or in the middle (for 2), if they are REALLY trixy they might be doing 133t letter for number substitution. If I guessed the length wrong, I might be able to figure out the minimum by getting an account and then choosing bad passwords until you tell me the rules. Once I know the rules, human nature helps me narrow down the field of passwords I should try in brute-forcing your accounts from the millions down to the hundred thousand or so that fit your more restrictive scheme.

What? You say your scheme isn't restrictive? It only insists on certain quality measures to insure that folks are using "password" or "qwerty" and they could be using 21 character passwords just as easily as the minimum 7. OK, I'm not interested in the folks using passwords like "afttr2U*sdfvS!&Ennadcczxza)0" If they can remember that, their head is too full of passwords for their account to have anything in it of interest. I'm interested in cracking the vast majority of accounts which will do the minimum required to pass your quality tests and end up with "g00d2g01" and then next rotation will choose g00d3g01. (OK, maybe you are doing comparisons to the last 6 passwords, that would help. You are doing at least 6 revs, right?)

My point is that the best password quality testing would actually just test quality and not announce the rules so much. Sure, a pure brute force will crack a 5 character password reasonably quickly, but who does pure brute force cracking anymore? Do you lock account out after some reasonable number of attempts? How long would it take to crack a 5 character password if you lock me out after every 5 tries and I have to either a) Wait for a timer to expire or b) wait for manual reset ??? Somewhere in the vicinity of a thousand years if the timeout is more than an hour or two, and I would hope that some time in the first decade of trying, you would notice that the account I'm attacking keeps getting locked out.

There are reasonably good safeguards to keep attackers from logging in using brute force cracking, which just leaves stupid password trying like "xyzzy" and "Passw0rd" which ANY good password quality test would reject. They way we're trying for quality right now is worse than annoying, it's counter productive in that if gives attackers more information about the password space that they would be cracking than we should be and encourages predictable passwords.

What's with not solving electronic identity problems?

There are a lot of interesting technical problems involved in figuring out a way to reliably identify people online, but none of the ones I'm aware of are insurmountable. At this point, it's ridiculous that we don't have a good way of saying (online, electronically):

1. I trust identities from entity A, B and Monkey. Anyone they vouch for as being who they say that are I'll (mostly) believe.
2. If you want me to buy into who you tell me you are, you need to go through the hoops of A, B or Monkey. I don't care if you are already identity registered with C, D and Unicorn. I only trust the list I gave you (via a simple registration, not by answering any of your silly questions...)
3. I get to choose what identity authority I trust for what purposes and which items of my identity they get to publish.

For example, I would like the State of Washington to issue me a drivers license / Washington resident identity. They get to use that for traffic stops and maybe border crossings, plus I can at my discretion use that identity to authenticate myself to other places that trust the state of WA.

I also would like the Postal Service to issue me an identity which I will keep for a lifetime (or until I believe it's been compromised) I can use portions of that identity code to tell people how to physically mail stuff to me without telling them where I live. There's no reason someone mailing me a rebate coupon needs to know where I physically reside, and if the USPS was tracking a PKI which internally linked to physical addresses, I could give out a code that only the USPS could use to find me. It also means I could change that physical location without much trouble, and for only myself. In the best of all worlds, it also means that I could produce one-time-use physical mailing addresses and get a LOT less junk mail. Abusive spouses could send child support checks directly to the recipient without danger to the abused...

We're currently defaulting to trusting lots and lots of identity managers (Facebook, Twitter, MySpace etc) who:

• Don't think of themselves as identity managers (with the exception of Google)
• Aren't checking that you really are even a human, much less the human you claim to be
• Aren't interested in providing this service

If you don't think we are trusting these places to identify people, just look at some of the friends lists and tell me that every person individually qualifies each request by some other means. Law enforcement and others (like the press) are using the lack of authentication to gather information as they go to press, or prepare indictments. I'm all for supporting good law enforcement, but these are examples of where the current state of affairs is biting people in the hiney.

It would be great to see:

1. A good cryptographic API that addresses key exchange with multiple PKIs is open source and non proprietary
2. PKI which conforms to #1 (the more the better) and allows for multiple levels of trust and multi-key encryption providing for field level access to identity information based on the key issued as well as quorum based decryption (three of these 7 keys are required for actions A, D and F)
3. Open, free access to multiple services (public and private) which use such a system
4. Integration into online services which use identity in some way

Note that I'm not calling for the death of immunity on the Internet here, just for application of some level of trust for identities that we care about knowing. For those of you that might respond with "Hey, OATH or OpenAuth provides these things" you are partially correct. What's being looked at now is the management of authentication and authorization, rather than identity. It's an important step in the right direction, but essentially does not address the problem that authentication is not identity and identity is a complex object with dozens, possibly hundreds of attributes.