[cabf_netsec] [EXTERNAL] Comments from call

[Tom Ritter]

Yes, Ritter - Sorry I think I fixed my display name.

Can you elaborate on what you mean by "send out your idea"?  As I
mentioned I'd like to see guidelines that take in account what I think
of as the lesser-considered attack vectors (administration vectors,
login dependencies, deployment/what's now considered 'devops', etc).




If I was going to try and attempt a text change, it might take the
form of a definition of 'administrator access':

Administrator/Administration Access is defined to encompass the
entirety of mechanisms by which one may deploy changes to a system
that can be used to effect a meaningful change in certificate
issuance. This includes but is not limited to IPMI, automated system
configuration tools, credential vaults, and authentication backends.

Wordsmithing needing. In particular:

'meaningful change' was chosen to allow CAs to argue that some things
should be out of scope. For example: "Yes, this user account which has
single-factor authentication and whose password isn't rotated can
indeed change the network switch speed from 1 gigabit to 10 megabit,
or even turn it off entirely, but this is not a meaningful change in
the operation of certificate issuance."



Let's imagine an architecture where you have:

[HSM] --- [Issuing Machine] ---- [Job Queue] --- [Web Frontend]

- The HSM has an online intermediate that signs certs
- The Issuing Machine has the HSM credentials and performs validation
- The Job Queue and Web Frontend are less important.
- Administrators can directly login to the Issuing Machine if they are
granted access in an LDAP group. They use a hardware SSH key.


My intended effect of this would be:

1 i. Grant administration access to Certificate Systems only to
persons acting in Trusted Roles and require their accountability for
the Certificate System’s security;

1 k. Change authentication keys and passwords for any privileged
account or service account on a Certificate System whenever a person’s
authorization to administratively access that account on the
Certificate System is changed or revoked; and

2 d. Ensure that an individual in a Trusted Role acts only within the
scope of such role when performing administrative tasks assigned to
that role;

2 i. Configure workstations with inactivity time-outs that log the
user off or lock the workstation after a set time of inactivity
without input from the user  (the CA or Delegated Third Party MAY
allow a workstation to remain active and unattended if the workstation
is otherwise secured and running administrative tasks that would be
interrupted by an inactivity time-out or system lock);

2 m. Enforce multi-factor authentication for administrator access to
Issuing Systems and Certificate Management Systems;

2 o. Restrict remote administration or access to an Issuing System,
Certificate Management System, or Security Support System except
when...

These should apply to accounts that control (examples, not limited to,
would depend on individual network and administration architecture of
course):
- Services (e.g. Puppet) that can push config changes to the Issuing Machine
- Credential Vaults (e.g. Hashicorp's Vault) that contain HSM
Credentials and push those credentials to new Issuing Machines
- The login accounts needed to login and control the LDAP server,
since this account could add an attacker into the necessary groups to
login to the Issuing Machine and push a new SSH key (which is probably
not hardware backed)

I'd probably also want to try and stick something into the later
sections of Logging (3) and Vuln Detection (4) about these systems as
well.


-tom

On 5 July 2017 at 13:22, Kirk Hall <Kirk.Hall at entrustdatacard.com> wrote:
> Tom (Ritter, I assume) - your message below is helpful.  Can you send out your ideas before our next call on July 13?  Kirk
>
> -----Original Message-----
> From: Netsec [mailto:netsec-bounces at cabforum.org] On Behalf Of Tom . via Netsec
> Sent: Thursday, June 29, 2017 10:47 PM
> To: netsec at cabforum.org
> Subject: [EXTERNAL][cabf_netsec] Comments from call
>
> 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
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec