Thursday, 19 November 2015

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

Thursday, 25 June 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. 

Monday, 9 February 2015

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...