[Ach] 30C3 talk "The Internet (Doesn't) need another security guide"
Joe St Sauver
joe at oregon.uoregon.edu
Tue Jan 14 01:15:06 CET 2014
<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
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
-- 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
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.
More information about the Ach