[cabf_netsec] [EXTERNAL] Rationale for changes in ballot 210 - summary

Kirk Hall Kirk.Hall at entrustdatacard.com
Tue Aug 15 08:35:02 MST 2017


I think those are good explanations, Neil - thanks.  I'd add that according to memory, the original NetSec requirements were based on an internal Symantec security document, supplemented in places from outside standards.  Thus they may in effect be 5-10 years old, and ready for updating as you suggest.

-----Original Message-----
From: Netsec [mailto:netsec-bounces at cabforum.org] On Behalf Of Neil Dunbar via Netsec
Sent: Tuesday, August 15, 2017 8:14 AM
To: CA/Browser Forum Network Security WG List <netsec at cabforum.org>
Subject: [EXTERNAL][cabf_netsec] Rationale for changes in ballot 210 - summary

Chaps,

I’m pushing this out as a discussion point in order to answer Ryan’s (perfectly reasonable) request for the logic underpinning Ballot 210 changes.

I’m certain that I’ve missed many points, or invented others from my fevered imagination - so please do add some suggestions, and I’ll integrate before posting to the main list. Note - I’m NOT trying to speak for the NetSec group as a whole - I’m just trying to ensure that my memory is sufficiently refreshed as not to mislead the forum.

Cheers,

Neil

-------------
Ryan,

I’ll take a stab at at least some of the rationale. Obviously, others will have different observations and priorities - so don’t take this as anything other than my musings on the NetSec discussions.

1a - logical versus physical separation: I think that the view here was that VLAN tagging be orchestrated and enforced from dedicated managed network equipment (which must be accounted for, audited, configuration reviewed, change logged just as before), and not from a host based network stack, since that would necessitate the host being able to span the VLANs - in other words the host performing Certificate System work would - at least logically - exist in a bridging state, which violates the principle of isolation. Why is it being proposed? I suspect because the maturity of software defined networking (whether enforced via VLAN, IPSec, etc) has now reached the point where its isolation properties are deemed sufficiently trustworthy for CA work. However, I can see that others may have a markedly different view of this level of trust.

1b - “equivalent" versus “same”. Some deployments have different vendors (or different versions of equipment from the same vendor) which have different expressions of isolation enforcement (e.g. different routers having equivalent, but non-identical configuration data to enforce separation); the technical security properties desired remain the same, but the means of achieving them may differ. If I recall correctly (and I almost certainly don’t, or at least incompletely) the intention is to try and give some flexibility to CAs to have heterogeneous equipment setups within their environments, while retaining the requirement to establish to an auditor that the isolation properties are of equal value to a homogeneous environment. I’ll readily confess that my memory is less that solid on this point - so other NetSec people, please correct my errors.

1l, 2l, 4c, 4f - Replacing numerals with text. Stylistic change.

2g, 2j, 3e, 4c  - Replacing number of days with months. More to fit in with the scheduling which most IT departments orchestrate regular reviews and activities, i.e., every three months rather than every 90 days.

2m - Multi-party authentication. We had a long discussion on what constituted a “System” as far as issuing certificates was concerned (specifically around Root CA equipment, which is often offline and/or air gapped) - did it include the HSM as well as the computers which interface to it? Assuming that the HSM and computer falls within the boundary of the “System”, the question then arose about multi-factor authentication being difficult in such isolated environments, since often things like OTP/U2F involves synchronising with other online equipment, and some CAs might be very loath to expose their air gapped kit - even for a short while. Thus the suggestion arose that if the multi-party authentication to the HSM could be counted (e.g. by using USB keys, or some other means), then it wouldn’t really matter if the authentication to the computer used to talk to the HSM was single-factor. Now, since all HSM equipment is mandated to be FIPS-140 L3 or higher, a simple password level compromise would not be effective - the attacker would need to compromise the trusted inputs to the HSM too. Or so some of my thinking went.

2o - Removal of requirement to have remote access from a “pre-approved IP address”. Giving CAs the flexibility to perform trusted operations from systems in their direct control using MFA, but which may not have a persistent IP address. The idea being that the security is vested in the control of the device, network and authentication method, and no longer a specific external IP address. Given the prevalence of NAT within isolated networks, it could be argued that a pre-approved IP address yields no tangible benefit (IPv6 networks notwithstanding).

4a - Intrusion Detection. This was to replace the overly prescriptive suggestions of anti-virus software with the notion of “something which detect unauthorised changes to the system”, which is I suspect what the anti-virus statement was intended to achieve all along. 

Definition of Security Support System - making it clear that the functions of the security support systems include HIDS/NIDS, rather than the overly prescriptive “anti-virus”. In fact, anti-virus software could let all manner of unauthorised changes through since the changes don’t fit the definition of malware.

_______________________________________________
Netsec mailing list
Netsec at cabforum.org
http://cabforum.org/mailman/listinfo/netsec


More information about the Netsec mailing list