Passwords (c) : buying lifetime

Here's my idea- which I shall publish somewhere in a paper, perhaps.

People have trouble seeing the benefit in having a strong password. Why not make the benefit simple and obvious?

So, here's my proposal. Have a graphic next to the password change box which shows two things. Firstly the strength, by maybe bar colour or length. Secondly... the number of days you get to keep your password. The stronger the password, the longer before the system makes you change it. Have this update as you type in your password, in realtime. The strength, and the lifespan you get in return, can be determined by how complex it is, the sensitivity of the system, how careful you have been in the past, who else vouches for you, current threats (do you have a clear and present danger?), and so forth. By picking a stronger password, you buy time for it to live. The system would of course have upper and lower limits for lifetime- a really bad password would just not be accepted at all. 

I'm calling this Positive Passwords. The password is stronger, and so it lives longer. Hence it is happy- positive!

I don't know any system which currently does this yet, but I think it is a very worthwhile and simple thing to do, with significant benefits to security and user awareness. 

Copyright Bridget Kenyon 2015

Get me a sandwich and buy me a car

I find people frequently ask for a set of "standard best-practice security measures/controls", to help them do security. Here is an argument against trying to provide this.

Imagine you are scheduled to meet a colleague (whom you don't know well) for a chat over lunch. They mail you to ask you to pick them up a sandwich. 

Sounds fine, yes? But you get to the sandwich shop and find there are forty types of sandwich. Some are low in fat. Some are gluten free. Some are bacon-filled, and some vegetarian- and a couple are vegan. There is tomato in many, and chilli in some. Red meat and pork also feature. There are even wraps and mini rolls. And I haven't even started on the seafood options. 

You have no idea what your colleague wants. So you can a) pick something you think everyone will like (trust me, there is no such beast), or ask them what they want. 

Being asked for "best practice advice" is very like being in this situation. Unless you know the requirements, preferences and tolerances of your customer, you are going to have problems. And if you pick something you would like for yourself, you have missed a really big point: you are not the one who is going to be eating that sandwich. 

Now let's amp this up a bit. Imagine that, instead of a sandwich, that same colleague emails and says "Buy me a car". OK, that sounds nuts. Why? Because there are even more variables at play. Is this a toy car? A small run-about for town? A people carrier, or a four-by-four? What make? What model? What options? What colour(s)? What age? The list of questions just goes on and on. You don't have the information to answer them unless you know exactly the requirements. And the cost of guessing wrong could be catastrophic. 

Information security controls can be expensive to apply, and getting them wrong can damage the overall image of the team- and the profession. 

If you are close to your colleague - or, back in the infosec world, if you are part of the business - you are in a position to identify suitable risk treatments. 

Of Russian dolls and risk assessment

A risk is like a Russian doll- it appears to be of a particular size, but what's inside? You have to open it to know- but that only takes you one step; there's another doll! Is that doll still large enough to be worrying? If so, open it and take a look inside. At some point, the next doll will be too small to bother about (i.e. the residual risk is tolerable) - or the next doll is charred, i.e. there is enough wrong that it's not worth assessing further.

The main difference is that sometimes the doll magically gets bigger as you open it...

Here's an example based on past risk related discussions:

Q1: Are you handling personal data, and if so, how are you protecting it?
A: We take every care in protecting personal data. We are a member of the Safe Harbour Agreement.

<Open the doll>

Q2: Thanks so much for your answer... Can you tell me more about the protection you are applying? Do you encrypt the data at rest and in motion?
A: We use industry standard encryption to protect the information using SSL.

<Note that there is no mention of what they are doing with data at rest, but let's leave that part for now. Next doll>

Q3: You mention SSL. What version are you using?
A: We are using TLS, and have verified that it is not vulnerable to POODLE.

<Next doll>

Q4: That's great - can you confirm that you are keeping your encryption strength up to date as threats evolve?
A: Oh- I suppose we can if you want. That's the Extended Deluxe Support Package $$$$$$$. We didn't include it in the tender because no-one asks for it.

<Next doll>

Q5: What do you do to prevent fail-back to insecure encryption algorithms?
A: We disable insecure algorithms <Note: this is a Very Rare Good Answer to this question>

<Is the doll small enough yet? No, let's have a look at data storage>

Q4: Many thanks for the information, but you haven't mentioned what you are doing with data at rest (SSL only applies to data in motion). How are you protecting data at rest?
A: We use HostyPlace Company's storage, which is industry standard.

<Oh, the doll just got bigger. Let's open it>

Q7: How are you managing the data in storage? Is it encrypted, and if so, how?
A: We use industry standard encryption to protect the information using SSL.

<Not an answer to the question asked. Next doll>

Q8: Thanks for getting back to me. SSL is for data transmission- what are you doing to encrypt stored data?
A: We are storing the data in a secure hosted facility at HostyPlace (American company): link

 Q9: Do you encrypt the data in storage?
A: The data is physically secure and has access restricted to only three people in our company, with authentication handled by HostyPlace's secure servers. All of our other customers are happy with this, and we have never had an incident.

<I'm taking that as a "no", then. Do I really want to ask about their authentication system, or do I want to find out about whether they are using a Safe Harbour accepted hosting solution? Choices, choices...>

Q10: Is HostyPlace also a Safe Harbour signatory?
A: HostyPlace is a very well respected company, which is used by Big Famous Company 1 and Big Famous Company 2: link to HostyPlace sales page. We have been with them for seventeen hundred years, and never had so much as had a stubbed toe. In fact, I credit them with my aunt's miraculous recovery from the plague.

At this point, we can open even more dolls, but it looks like we are suffering from a classic case of Wrong Doll. The correct doll is the Legal Liability Doll, which we now hand to our colleagues in Legal.

We can also ask about compliance with management system standards. This can massively simplify matters if HostyPlace is ISO 27001 certified, and has a sensible sounding scope, AND a reasonable Statement of Applicability. I've started to ask that one first, these days...

Information and the three-legged stool

I was trying to explain to a colleague how infosec people think about information, and came up with this:

I see information as being like a glass vase you have put on a three legged stool. The stool is standing on uneven ground, in a river of melted chocolate (yes, I'm peckish). If any leg is the wrong length, the vase will fall and be swept away. If the seat is too low, the vase will also be swept away. If the seat is too high, you won't be able to see the vase, and you may break it trying to get at it. Now, you may not be bothered about losing the vase, but then again you may. Depends on the vase.

The three legs of the stool represent the three main attributes of information: Confidentiality, Availability, and Integrity. The uneven ground represents your different tolerances of threats to those three attributes. The chocolate river represents the threats to your information. The length of each leg is the amount/severity of controls which have been applied to protect the information's availability, confidentiality and integrity. The space you decide to put between the bottom of the seat of the stool and the chocolate is your risk tolerance. If the vase is swept away or broken, that's an information security incident. This can be because the seat is uneven, or the seat is too low, or too high- not being able to see it is analogous to having so many security controls that you cannot do your work effectively, and breaking it while trying to get to it is analogous to creating an incident as a consequence of requiring overly strong controls (eg complex passwords which people then write down on Post-Its).

The role of infosec is to work out how uneven the ground is, and to help you get the legs to the right length, also bearing in mind the likely strength of the chocolate river now and in the future. Which means that you're always at risk of an unexpected chocolate tsunami, but hey, that's life...

OK, this isn't a perfect analogy, but hopefully it helps. Or makes you crave chocolate. it does imply that there isn't a "perfectly secure" situation, just one which is suitable to your organisation's needs, attitudes and risks.

Chickens!

Why is it so hard to explain the business justification for managing information risk? I have an idea about how to explain this.

I've heard it said that information security isn't about the shark attack, but instead about being pecked to death by chickens. Let's look at that from a financial standpoint. The risk of a major incident is low enough, in people's minds, that it can be discounted (like a shark attack); the potential financial loss is huge, but it won't happen, so who cares?

The risk of minor information security incidents- hah, they're happening all the time! Everyone and their dog is getting dodgy emails from "their bank", or "the IT department", and a non-zero proportion of the recipients will click on the wrong link out of bad luck, curiosity or fear. Of these, some will type in their login details, or have computers able to be taken over, and there you go. Not a huge impact on the organisation as a whole, by and large, but some hours of someone's day used to sort this out (once they notice...). The user loses time; the IT department loses time; and the organisation loses a little money. Not much. Like a single peck from a chicken- uncomfortable, but you can handle it.

How many chicken pecks before you start to really hurt? If the organisation doesn't have a "central nervous system" to allow the cumulative effect of these incidents to be understood, then they won't react like a human who's being pecked many times - they'll react like a huge number of humans who are each being pecked once. Which is to say, they will be mildly uncomfortable, but not inclined to make major changes.

The irony here is that a good information security management system acts as a central nervous system; but without it, you don't realise that you need one.

So what is the solution?

It's easy and hard - you need to either take advantage of a shark attack (have your wish list ready to go BEFORE the shark appears) or start really small and work on it. You can work on both of these approaches simultaneously.

Hack-a-day events

I have just attended a meeting in which a presentation was given expounding upon the great value of having a "hack-a-day" event, where lots of keen programmers with fresh ideas get together and try to create code in three days (or less) in an intensive and collaborative environment. Great. It has the major advantage of getting new ideas into a workable state in a short period of time.

The thing it doesn't provide is a finished product. This is sometimes not clearly understood by the people sponsoring the event. What you get may operate, but it is "hacked" together, exactly as you might expect of code written hastily by a group. It is best to think of a hacked together application, or app, as an example of what might be created for genuine use - a proof of concept. Like building a house in a week without plans or building regulations approval- it might look great, but how will it look in a year- and will it electrocute you?

A hacked together solution will not work reliably- it will not be documented, and it will not be supportable. It will also not be secure. But if you take it as what it is intended to be - an example of what you could produce- it saves you a lot of time and money by telling you that the goal may well be attainable in the production world, as long as you start from scratch and develop a supportable, documented, suitably secure version of your "hack". Using my analogy above, you need to get planning permission, electrical testing and qualified builders to build a house you would be happy to live in.

Say no to "cyber"

I am strongly opposed to the term "cyber" as I find it makes people think information security is just about IT, undoing all the hard work professionals in my field have been doing to try to bring the topic to board level.

I work in information risk (or security), not IT security.