[Ach] 30C3 talk "The Internet (Doesn't) need another security guide"

[ianG]

On 14/01/14 23:36 PM, arne renkema-padmos wrote:
> On 14/01/14 11:06, Andreas Mirbach wrote:
>>> 2. Threat modelling: Eva mentioned that most guides first focus on a threat 
>>> model. We don't really do that so much in ours.
>>> Are we missing something here?
>>
>> I Don't think that we need a Threat model because it shrinks the focus onto this 
>> model. Everything else is left out.
>> I Think we should provide an overall preventive security configuration and not 
>> how to defend specific threats. (Maybe there can be smaller document with 
>> different threats that can be referenced)
> 
> From what I understood the problem wasn't so much that they do / don't
> include a threat model, but that they don't include the concept of
> threat modelling, and determining what advice is and is not relevant in
> the readers context. AFAIK, these guides start off with a specific
> threat model, and don't discuss the concept of threat modelling.


This is a general problem that strikes the security industry in the
heart.  To put it in context, it is the separation of toolkit from business.

A business has threats.  A toolkit does not.  If you imagine SSL, it is
a secure connection, and as a piece of isolated technical wizadry, it
doesn't really consider any particular business ideas [0].

But a business is threatened by specific issues.  Take the example
below:  persecuted groups are looking to communicate their persecution
stories outside, and coordinate their activities safely:


> There was also some talk about how persecuted groups generally tend to
> have a good model of the threats that they are up against.


So they need protection from eavesdroppers, and as they are persecuted,
we can safely assume that they also need protection from active attacks,
aka MITMs.  So they need something that ties the identity tightly.
These things are all quite specific and quite demandable.

Then take another business:  the stock market and traders.  These people
are trying share trading information amongst peers, and might also be
concerned with eavesdropping because advance tips means someone can get
ahead of their trades.  But they are also threatened by insider trading,
so the ability to exfiltrate stock tips must be controlled.  So,
typically all market discussion is recorded by law, so there is escrow
and so forth.

You see the contradiction?  We have a need that is diametrically opposed
in two separate businesses.  One wants protection from the MITM and from
eavesdropping, the other wants to MITM and escrow all traffic!

Yet, the same toolkit is used in both to achieve their individual and
opposing purposes.


> How this maps
> to security technology is another matter, and what's missing from any
> guides.


Toolkits resolve this dilemma by creating for themselves a 'perfect
threat model' and a 'perfect security model' that they anticipate fills
the needs of the majority of users.  For example, SSL envisages a
'perfectly secure tcp connection' in many and various ways.

But, the threat model is plastic or made up.  It isn't and cannot be a
real threat model because .. it isn't and cannot be a real business.

This discordance or dissonance will be faced by all approaches with are
bottom-up.  And the guide is essentially that;  Here, we imagine we know
what is best for all sysadms.  We do that on the basis of good and
combined experience;  so it's a good guess, but at the end of the day,
it's a guess.


> I guess administrators must also have quite some experience with
> different kinds of threats, which is what a threat modelling section
> could build on.


For these reasons, it might be plausible to enunciate our threat model
thinking (maybe, I'd say not).  But it is not possible to do it properly
or accurately because we don't know the business of each sysadm who's
reading the document.

>From that pov, it is far better to leave the entirety of that discussion
out, if only because we cannot do it correctly, and we can annoy a lot
of people for its lack.  What we could say is wte:

"We imagine a stylised or perfect threat model from our combined and
deep experiences as sysadms;  but you should always be aware that your
business is different.  Where you know those differences, you should be
aware of the need to modify."

etc.


> Cheers,
> arne



iang



[0] OK, that's not completely true.  SSL was created by Netscape to
protect credit cards.  But, the team that built it did not really
consider credit cards per se, they drifted quickly to their perfect
security model of a secure connection, without much consideration of
credit cards.  For those who are enjoying the thread about MITMs, you
might enjoy this old rant that explored the threat model of SSL as it
was originally cast:

http://iang.org/ssl/wytm.html