[cabfpub] Ballot 210: Misc. Changes to the Network and Certificate System Security Requirements

Tue Aug 15 08:56:01 MST 2017

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. The dominant notion was that the document which was the source of NetSec was an old one (from Symantec, I think?), and that the movement in technology meant that some of its stipulations had somewhat been obsoleted.

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.

Hope this helps more than it confuses,

Neil

> On 14 Aug 2017, at 13:52, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> Hi Ben,
> 
> It's good you have a full ballot ready to go. It'd be useful to
> understand further context behind these proposals, beyond just
> "Network Security Working Group recommends"
> 
> For example, ideally it'd be useful to understand the overarching
> motivation, and the motivation for each and every specific change. For
> example, are these changes related to solving the same problem, or are
> they solving different, independent problems?
> 
> If there are threads from the (public, correct?) NSWG mailing list
> that can be referenced, that'd be great as well.
> 
> For example, the changes to 1.a represent a substantial change in the
> security and risk profile here - we move from physical separation into
> VLAN tagging. While VLAN tagging can be implemented by managed devices
> (e.g. switches), it can also be implemented at the host end, which
> means that a compromised host could, conceptually, 'uplift' itself
> from an untrusted zone to a trusted zone if it were to be compromised.
> Understanding if this was a goal (as it may very well be, given
> concerns raised about 1.a in the past) is useful to help members
> understand if the security risk is worth it.
> 
> 1.b introduces an element from objective judgement ("same") to
> subjective ("equivalent"), which relies on the CA's competency and the
> auditor's familiarity with evaluating these controls as equivalent. As
> we saw from the "any equivalent method" clause with validating
> domains, we've note that there are subtle gaps in both assumptions
> that can result in direct security risk to the ecosystem. At the same
> time, it's understandable that some CAs may desire this flexibility.
> 
> Similarly, 1.m introduces a risk that rather than having to compromise
> multi-factor authentication, one could just compromise two account
> passwords ("multi-party"), which would significantly undermine the
> security profile for such software.
> 
> This is where helping understand the motivations and goals (via a
> 'problem statement' for each change) can help evaluate whether or not
> the proposals from the NSWG meet those goals, whether alternatives
> exist (that may have been considered and ruled out by the NSWG, or may
> not have been considered at all), and whether the risks are
> significant enough to warrant voting against rather than in favor.
> 
> I don't want this to appear ungrateful for the work, and appreciate
> the progress being made, and hopefully with greater context provided
> we can evaluate what was considered - and what was not - and either
> make suggestions for modifications or vote appropriately relative to
> the risk of these changes and the benefits they may (or may not)
> provide.
> 
> On Sat, Aug 12, 2017 at 11:30 PM, Ben Wilson via Public
> <public at cabforum.org> wrote:
>> The discussion period for this ballot is 12 days to give everyone ample time
>> to review it.  Voting will start at 2200 UTC on Thursday, August 24, 2017.
>> 
>> The Network Security Working Group recommends that the Forum make the
>> following minor revisions to the Network and Certificate System Security
>> Requirements.   (Other changes are being considered by the Working Group and
>> will be presented in due course.)
>> 
>> The following ballot is proposed by Dimitris Zacharopoulos of HARICA and
>> endorsed by Ben Wilson of DigiCert and Neil Dunbar of TrustCor.
>> 
>> --Motion Begins--
>> 
>> In the Network and Certificate System Security Requirements:
>> 
>> ADD ETSI EN 319 411-1 to first sentence of the Scope and Applicability
>> section so that it reads "These Network and Certificate System Security
>> Requirements (Requirements) apply to all publicly trusted Certification
>> Authorities (CAs) and are adopted with the intent that all such CAs and
>> Delegated Third Parties be audited for conformity with these Requirements as
>> soon as they have been incorporated as mandatory requirements (if not
>> already mandatory requirements) in the root embedding program for any major
>> Internet browsing client and that they be incorporated into the WebTrust
>> Service Principles and Criteria for Certification Authorities, ETSI TS 101
>> 456, ETSI TS 102 042 and ETSI EN 319 411-1 including revisions and
>> implementations thereof, including any audit scheme that purports to
>> determine conformity therewith."
>> 
>> REPLACE section 1.a. with "a. Segment Certificate Systems into networks
>> based on their functional or logical relationship, for example separate
>> physical networks or VLANs;"
>> 
>> REPLACE section 1.b. with "b. Apply equivalent security controls to all
>> systems co-located in the same network with a Certificate System;"
>> 
>> REPLACE "90 days" with "three (3) months" in section 2.g.ii. and 2.j so that
>> they read "ii. For accounts that are accessible from outside a Secure Zone
>> or High Security Zone, require that passwords have at least eight (8)
>> characters, be changed at least every three (3) months, use a combination of
>> at least numeric and alphabetic characters, that are not a dictionary word
>> or on a list of previously disclosed human-generated passwords, and not be
>> one of the user's previous four (4) passwords; and implement account lockout
>> for failed access attempts in accordance with subsection k; OR"
>> 
>> AND
>> 
>> "j. Review all system accounts at least every three (3) months and
>> deactivate any accounts that are no longer necessary for operations;"
>> 
>> REPLACE section 2.m. with "m. Enforce multi-factor OR multi-party
>> authentication for administrator access to Issuing Systems and Certificate
>> Management Systems;"
>> 
>> REPLACE section 2.o. with "o. Restrict remote administration or access to an
>> Issuing System, Certificate Management System, or Security Support System
>> except when: (i) the remote connection originates from a device owned or
>> controlled by the CA or Delegated Third Party, (ii) the remote connection is
>> through a temporary, non-persistent encrypted channel that is supported by
>> multi-factor authentication, and (iii) the remote connection is made to a
>> designated intermediary device (a) located within the CA’s network, (b)
>> secured in accordance with these Requirements, and (c) that mediates the
>> remote connection to the Issuing System."
>> 
>> REPLACE "every 30 days and" with "once a month to" in section 3.e. so that
>> it reads "e. Conduct a human review of application and system logs at least
>> once a month to validate the integrity of logging processes and ensure that
>> monitoring, logging, alerting, and log-integrity-verification functions are
>> operating properly (the CA or Delegated Third Party MAY use an in-house or
>> third-party audit log reduction and analysis tool); and"
>> 
>> REPLACE 4.a. with "a. Implement intrusion detection and prevention controls
>> under the control of CA or Delegated Third Party Trusted Roles to protect
>> Certificate Systems against common network and system threats;"
>> 
>> REPLACE 4.C. with "c. Undergo or perform a Vulnerability Scan (i) within one
>> (1) week of receiving a request from the CA/Browser Forum, (ii) after any
>> system or network changes that the CA determines are significant, and (iii)
>> at least every three (3) months, on public and private IP addresses
>> identified by the CA or Delegated Third Party as the CA’s or Delegated Third
>> Party’s Certificate Systems;"
>> 
>> REPLACE the definition of Security Support System in the Definitions with
>> "Security Support System: A system used to provide security support
>> functions, which MAY include authentication, network boundary control, audit
>> logging, audit log reduction and analysis, vulnerability scanning, and
>> intrusion detection (Host-based intrusion detection, Network-based intrusion
>> detection)."
>> 
>> Make other editorial changes as indicated at
>> https://github.com/cabforum/documents/pull/64/files and in the attached PDF.
>> 
>> --Motion Ends—
>> 
>> The procedure for approval of this Final Maintenance Guideline ballot is as
>> follows:
>> 
>> BALLOT 210 - Final Maintenance Guideline
>> 
>> Relevant Start times and End Times are 22:00 UTC
>> 
>> Discussion (7 to 14 days) Start: August 17, 2017     End: August 24, 2017
>> 
>> Vote for approval (7 days) Start: August 24, 2017    End:  August 31, 2017
>> 
>> If a vote of the Forum approves this ballot, the Chair will initiate a
>> 30-day IPR Review Period by sending out an IPR Review Notice.
>> 
>> After 30 days of announcing the IPR Review period by the Chair:
>> 
>> (a) If Exclusion Notice(s) are filed, this ballot approval is rescinded and
>> a PAG will be created; or (b) If no Exclusion Notices are filed, this ballot
>> becomes effective at end of the IPR Review Period.
>> 
>> From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
>> Maintenance Guideline, such ballot will include a redline or comparison
>> showing the set of changes from the Final Guideline section(s) intended to
>> become a Final Maintenance Guideline, and need not include a copy of the
>> full set of guidelines. Such redline or comparison shall be made against the
>> Final Guideline section(s) as they exist at the time a ballot is proposed,
>> and need not take into consideration other ballots that may be proposed
>> subsequently, except as provided in Bylaw Section 2.3(j).
>> 
>> Votes must be cast by posting an on-list reply to this thread on the Public
>> list. A vote in favor of the motion must indicate a clear 'yes' in the
>> response. A vote against must indicate a clear 'no' in the response. A vote
>> to abstain must indicate a clear 'abstain' in the response. Unclear
>> responses will not be counted. The latest vote received from any
>> representative of a voting member before the close of the voting period will
>> be counted. Voting members are listed here: https://cabforum.org/members/
>> 
>> In order for the motion to be adopted, two thirds or more of the votes cast
>> by members in the CA category and greater than 50% of the votes cast by
>> members in the browser category must be in favor. Quorum is half of the
>> number of currently active Members, which is the average number of Member
>> organizations that have participated in the previous three Forum-wide
>> meetings (both teleconferences and face-to-face meetings). Under Bylaw
>> 2.2(g), at least the required quorum number must participate in the ballot
>> for the ballot to be valid, either by voting in favor, voting against, or
>> abstaining.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public