[cabf_netsec] Comments from call

[Tom .]

Hey all, didn't want to monologue on the call, so I thought I would
try and jot down some thoughts in email.

I haven't made a concrete decision about what direction I would want
things to go, but would say I'm generally supportive of reducing
redundancy by outsourcing more or most of the Network Security
Guidelines to other standards where they are indeed redundant. And I
certainly have no objections to doing a short term fix for
non-controversial changes - but the emphasis is on non-controversial,
I think it would be very distracting if we spent more than a month or
so debating what is and isn't controversial and getting that fix out
the door.

But coming from a pentesting background, I am extremely skeptical that
existing auditing requirements would encompass many of the attack
vectors I am concerned about in CA infrastructure.

How to capture those concerns I don't have a strong opinion on at the
moment, but I would like, at the least, to document them in some
capacity (probably with an accompanying story) and have them reviewed
officially by CAs in some capacity, if not having specific actions
required.

I tend to be work backwards from the most valuable assets and operate
from a 'line in the sand' perspective. If the attacker compromises
'above' the line in the sand, there are authz/authn/policy/sanity
checks that prevent 'the bad things from happening' (here issuance).
If they compromise 'below' the line in the sand, they can issue.

So to be explicit, some of the concerns I have are around:
- Administration of systems governing issuance below the line in the
sand. Administration via ssh keys, puppet or similar tools, IPMI, etc.
E.g. Can I compromise Joe's work laptop and login to the issuance box
OR to the puppet host and push a config change to the issuance box.
- The authentication systems that govern control to the above systems,
both the issuance systems and the systems which administer them. E.g.
Can I compromise Joe's work laptop, login to the ldap system, grant a
fake user account permission to login to the puppet box, login to the
puppet box and push a configuration change.

And similar, but I think those are good examples.

-tom