[Cryptography] What do we mean by Secure?

ianG iang at iang.org
Tue Feb 10 07:33:27 EST 2015


On 10/02/2015 04:41 am, Kevin W. Wall wrote:
> On Sun, Feb 8, 2015 at 6:44 AM, ianG <iang at iang.org> wrote:
>> ...  The issue isn't so much that the result is
>> nebulous, but that security is *individual*.
>
> True, but in general security is not (directly) paid up front by the
> individual, so that the individual doesn't generally get what she / he
> wants except generally at great expense because customizable security
> does not scale well.


Right.  So, there is a huge analogue here with the insurance market. 
Users want to be protected but won't pay for it because it always 
happens to someone else, and it is far in the future.  When it does 
happen, it's too late.  So FUD is used to sell these things, and there 
are scale opportunities such that a nationalised insurance scheme is 
often efficient at least on paper.

However we can't take this too far and say that we should have purchased 
security protection things like insurance or a nationalised PC health 
programme, because this assumes that one or other party knows how to do 
this.

(C.f., oft-mentioned markets in imperfect information, link at bottom.)

>> In the old days, we used to say, WYTM or what's your threat model?  The
>> problem with this was it captured the above fallacy perfectly -- we were all
>> searching for the one threat model to rule all others.
>>
>> E.g., the threat model _du jour_ is for the state to shut down your system
>> and therefore we have to now use the blockchain to secure our socks & undies
>> drawer.  The threat model of the 1990s was that everyone would listen/MITM
>> your traffic on the open net so you have to get some CIA.
>>
>> Security is an individual attribute and is not easily aggregated.  Even with
>> homogonous groupings like "USA middle class white dudes" there is sufficient
>> variation to make any 'security policy' look daft.  E.g, those
>> aforementioned guys care little about their iPhone photo collection, but
>> their girlfriends are paranoid about them.
>
> I hope you are not advocating throwing out threat models as being completely
> useless.

Nope.  Threat models are only completely useless if no business model 
was in place to inform them.

(I'm simplifying here.  You can sell a completely useless security model 
and make people feel good about themselves - placebo.  Or you can sell 
it and cause them to reach compliance, which is good for business.)


> The generally help an organization think about security issues
> clearly and in my experience are a lot better than then single PowerPoint
> block diagram (or a UML diagram if draw by a *real* engineer :) with a
> large, red box labled "security" or "encryptor", etc. I see threat models
> as somewhat analogous to doing requirements analysis, which, with agile
> is also getting a bad rap in software development. Of course, ever since
> the term "analysis paralysis" became a catch phrase of IT management in
> the 1980s or so, deep thinking of any type related to software development
> has gone out of vogue. I do understand time-to-market concepts, but more
> often it seems to only minimize time-to-failure.


Right, so what is happening here is that the organisation understands 
its business.  So the business model part is done, but the org does not 
understand how to take the next step.

And, you the security dude do not understand the business model, but you 
do understand the whole security lifecycle thing.  So there are two 
tasks going on in parallel:  bring the org forward into the threat 
discussion, and push the security dude backwards into the business.

So a common thing here for first task is to thrust a series of threats 
extracted from popular threat models in front of them.  "Are you worried 
about MITM?  Are you worried about your SO seeing your photos?  Are you ..."

Another simple way which gets more at the question of 'what is your 
business model' is to ask them "how did you lose money?"  Collect 
anecdotes.  And then go ask the customers "how did you lose money..." 
because often the business has internalised or dumped the losses of 
their customers.  Think retail shopping or browsers.


>> Something that snapchat made billions on, so they know more about security
>> than us, by some market measure.  Which leads us to some form of aggregation
>> history:  the 'security' products that have made a lot of money are these:
>> SSH, SSL, Skype, Facebook, Snapchat, Bitcoin.  (How, why and repeatability
>> is an interesting MBA-business-case-study exercise.)
>>
>> So I guess we need a different way of approaching the question.  Maybe we
>> need to ask two questions not one:
>>
>>     1. what would make *you* feel secure?
>
> Is that "you" collectively, as in some majority, or "you" as each
> individual?


Individual.


>>     2. how aggregatable is that over a larger population?


What I might be saying here is that you cannot ask the population 
anything in this area because the population only repeats today's memes. 
  If you started asking today about security threats of the population 
you'll get global warming, cyber security, terrorism, bitcoin, etc. 
Completely sodding useless.  You have to go ask people what they are 
scared of, and do it alone so there is no feedback loops, and work with 
that data.


> Exactly. And not only do we need to ensure whether that it will
> scale properly, but also that their are not any inherent conflicts
> or other undesirable issues caused by all the different indivual
> "policies" and the fact that these policies overall would be
> changing dynamically as individual users come and go. Of course,
> suitably restricted, you might be able to give the users very
> limited choices and get by, but the general case likely is not
> easily solvable. (IIRC, even Lampson's access matrix was unable
> to show which transistions to the AM were "safe" when the AM
> was not static. By comparision, this seems a lot harder if we
> allow it to be perfectly general.)


Yeah.  I think security is one of those things in life that pops up 
models that are then self-defeating.


>> I'm assuming here that we can't for example construct a
>> security-for-the-individual process/technique that scales & works.
>
> Yep; I'd bet that's a safe assumption.
>
>> I.e., now we need to take you through the policy wizard, relax,
>> this won't hurt a bit...
>
> :) And even that wouldn't work because some would end up having their
> data breached because of decisions that you didn't allow or consider
> in the policy wizard so you end up with a class action suit or your
> company's reputation goes down the toilet, etc.


Right.  This is the liability dilemma.  If you actually do secure people 
more, and they get robbed through some ommission or other, because they 
were secured more, they are more likely to take it seriously and seek 
damages recovery.

The market for "best efforts for all" security is quite stable, the 
market for "better efforts for you" is not.  E.g., browsers do 
everything they can to provide one security model "and it's secure" and 
fight any attempts by the users to vary that model.

It works, the market for browser security is stable.  The benefits for 
the entire body for lesser security are often in excess of the losses to 
the provider for better security.


>> <...deleted...>
>> I think ... people need to get a lot better at understanding that (1)
>> security is something you have to do yourself, if you care.  If you don't
>> care, then you're back to the firewalls & SSL & best practices approach;
>> but the evidence that you don't care is clear.
>>
>> Which is rather tricky.  As others pointed out in previous threads, if you
>> do care, then we hit limits to scale:  we don't have enough programmers to
>> produce good security code,
>
> Honestly, we don't have enough programs to produce GOOD code period,
> let alone good security code.


Yeah.  The market for programmers is definitely broken, but that's a 
topic way out of scope for this list ;)



iang


Markets in Imperfect Information - Lemons, Limes and Silver Bullets
http://financialcryptography.com/mt/archives/000721.html


More information about the cryptography mailing list