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

[Joe St Sauver]

Hi,

<kaplan at cert.at> commented:

#1. Eva mentioned that bettercrypto.org could use a section on how to
#convince your boss that the company needs hardened Crypto settings and
#that the sysadmins should invest time into that. 

I'm reminded of Robert M. Lee's recent "SCADA and Me: A Book for Children 
and Management," an illustrated cartoon guide to why supervisory control 
and data acquisition is an important (if obscure by normal management 
standards) topic. :-) It's just unfortunate that some executives may
take afront to the book's title, much as some dislike the yellow and 
black "Dummies" series (I've always figured that they were perfect for me
:-)). 

#Do you agree with that point of view? Should we add such a section?

Yes, I think this is a very good point, and in fact I've got a proposal in
to an upcoming higher ed meeting that will (if accepted) urge universities
to formalize and standardize their approach to crypto issues rather than 
leaving it to whatever "ships as default for a given package," or
whatever the whims of each local sysadmin or network engineer may be 
(good, bad, or indifferent). 

Before I'm put in the stocks for even suggesting that formal policies,
procedures, standards and governance processes might rightly have a 
role for crypto, recognize that w/o them, many system administrators and 
network engineers won't be empowered to roll out systematic changes -- 
at least if those changes rise to the level of being noticed and 
potentially impact business processes or other things "above their 
paygrade." (You can only "fly under the radar" so long...)

And as you mentioned, without management buy-in/crypto governance, 
sysadmins and engineers might also not be able to get the resources 
they need to do the work that may be required (at least when it 
involves more than just quick fixes and free software).

Maybe a preface or introduction written by "one of their own" (e.g., 
a well-recognized executive peer) who already "gets it" and has
credibility delivering the message that hey, this is important, and
something you should be doing?

#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 also like this suggestion. I suspect it was omitted in part because of
the timing of the project, and the fact that the nation state threat was
front and center in everyone's mind.

That's certainly not the ONLY potential threat, however. 

-- Classic monetarily-motivated crime remains a risk, for example, as
   does the risk that customers won't buy if your site doesn't SEEM
   to be secure to them (whatever the reality of the matter may be).

-- There are also compliance-based drivers for things like PII protection 
   (here in the US in higher ed, FERPA is a major considerations,
   while health care organizations may worry about HIPAA here in the
   states, etc.)

-- Some organizations may be increasingly worried about the so-called 
   insider threat, and how crypto can help (or potentially hurt) their 
   efforts to mitigate that threat.

-- There may also be matters of personal privacy involved -- if you 
   have an undisclosed terminal illness, for example, and want to 
   research that condition in privacy as a personal choice w/o
   other family members or fellow employees learning of it, the
   risk is different but still quite personally serious, etc.

-- We also need to recognize that there are risks to USING crypto, just 
   as there are risks to NOT using crypto.

   For example, encrypted email may not be centrally virus scanned, and 
   if key escrow's not in place, accidental death or serious incapacitation 
   of the crypto user may make the contents of encrypted files unavailable.
   I'm fine with having my crypto die with me, but others may not be so
   sanguine.

   True example of this: an acquaintance's spouse worked as a certified
   public accountant, a sole proprietorship. He was careful to use full
   disk encryption to protect his client's files. Unfortunately, this
   fall he suffered a stroke, including paralysis and aphashia... there 
   were real worries that a colleague wouldn't be able to access his
   customer's critical business records (fortunately the CPA recovered 
   to the point where he could share the required credentials, and help
   his clients move to a new accountant).

   Similarly, if you "get too far ahead of the curve," and adopt obscure
   cryptographic settings, you may be terrifically secure, but you may 
   have interoperability issues that prevent your intended customers from
   accessing your resources.

   In other cases, the threat may be increased fragility: for example,
   every time I see someone's zone fall off the wire because they let 
   their DNSSEC keys expire, etc., I groan, because I know that sort of
   fragility scares away others from cryptographically securing their 
   DNS infrastructure against cache poisoning.

I think it would be very good to discuss which (if any) of those threats,
over and above the nation state pervasive monitoring-related risks (which
I assume is a given) are in scope, if only as an appendix.

Regards

Joe