[cabf_netsec] Draft Minutes of Telephone Call Held 21-March-2019

[Ben Wilson]

Draft Minutes of NetSec Subcommittee Teleconference of 21-March-2019

Present:  Dustin Hollenback, Tim Crawford, Ken Myers, David Kluge, Robin Alden, Ben Wilson, and Corey Rasmussen

Ben read the Antitrust Statement

Ben reviewed the list of participants on the wiki page for this subgroup and the list of subgroups in Google Docs.

We discussed whether past draft minutes should need to be formally approved during our meetings or whether it would be satisfactory to just leave the draft minutes as informal notes of what was discussed. If anyone had corrections, they could communicate them, and we could re-post the minutes as corrected.  Ben and David did not feel strongly about whether additional formality was needed and felt that the record could be left as is, as it is noted in the emails that are sent as draft minutes, and there were no objections to this approach.

Ben quickly reviewed the F2F discussion minutes.  During the F2F we discussed relying on principles-based approaches of the PCI-DSS, WebTrust and other similar standards.  Logging had been raised as an issue by Trev and also discussed by Tim Crawford as part of the WebTrust task force feedback.  David said that was an area that he was interested in too, as part of the pain points subgroup discussions. The issue of across-the-board 7-year retentions was raised again at the F2F.  (Audit logs are typically not archived for such a long time.)

The Pain Points subgroup is meeting regularly on every Monday @ Monday 2pm UTC.  (Other subgroups still need to set a regular meeting time.)  A list of 11 Pain Points from WebTrust is being worked on by the P2 subgroup.  However, two of those 11 are flagged as needing work by the Authentication and Access Control subgroup, so they have an immediate list of tasks to work on.  Those two items are: (1) Testability of access controls in Section 2(k),  and (2) Prescriptiveness of authentication and account lockout requirements.

The above subcommittee meeting adjourned after 20 minutes, and anyone wanting to leave the meeting could.  The remainder of the hour was used to discuss the PCI-DSS, v. 3.2.1.

We reviewed the Scope statement in the PCI DSS.  Our Scope statement could be similarly expanded and elaborated on.  Mentioned were network segmentation, best practices, guidance for assessors, and compensating controls, which is one of the things that we want to incorporate into our Network Security Requirements.

Ben read page 16 of the PCI DSS, Compensating Controls, "On an annual basis, any compensating controls must be documented, reviewed and validated by the assessor and included with the Report on Compliance submission, per Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet. For each and every compensating control, the Compensating Controls Worksheet (Appendix C)must be completed. Additionally, compensating control results should be documented in the ROC in the corresponding PCI DSS requirement section. See the above-mentioned Appendices B and C for more details on 'compensating controls.'"

David noted that if a company has complicated systems with lots of controls, then this concept of compensating controls makes sense because the NCSSR requirements might not fit very well, and the PCI DSS allow for more stringent or superior controls.

There is also a Guidance column in the PCI DSS.  The PCI DSS says, "This column describes the intent or security objective behind each of the PCI DSS requirements. This column contains guidance only, and is intended to assist understanding of the intent of each requirement. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures."

The subgroup reviewed the structure of Requirement 1 and its sub-requirements.  Then we also reviewed a table in the quick reference guide (https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf) that also outlined some high-level principles:

Goals

PCI DSS Requirements

Build and Maintain a Secure Network and Systems

1.     Install and maintain a firewall configuration to protect cardholder data

2.     Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3.     Protect stored cardholder data

4.     Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

5.     Protect all systems against malware and regularly update anti- virus software or programs

6.     Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7.     Restrict access to cardholder data by business need to know

8.     Identify and authenticate access to system components

9.     Restrict physical access to cardholder data

Regularly Monitor and Test Networks

10.    Track and monitor all access to network resources and cardholder data

11.    Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security for all personnel



It was noted that the CA/B Forum would have its own statement of goals, but that much of the PCI DSS may prove helpful in revamping the NCSSRs.  And we wouldn't be adopting the same text either, but coming up with our own statements of security requirements, etc., so we would make sure that we're not running into IPR problems with PCI.

With regard to assessments, we would be relying on the existing audit standards as they are updated by WebTrust and ETSI, so we wouldn't have an assessment program like PCI DSS.

Ken asked about whether we would be looking at other information security frameworks and things like cryptographic requirements.  Ben said that the primary goal of the effort isn't to create a full-fledged information security program but to improve what we have now, but that an outcome of the threat-risk subgroup might be identification of additional security requirements that we would need to add.  Part of the analysis should require that we adopt a set of high-level principles and then if a new suggestion is made for a requirement, it can be measured against the applicable high-level principle.  If someone proposed a new high-level principle, then it should receive even more scrutiny (because we should stick to our original list).  However, there is the chance that in going through the PCI-DSS, we might discover something that we really feel we need to have as part of the NCSSRs, and then we would adopt something similar-fitting it best to the needs of the PKI industry.  Ken said that one of the reasons he raised the issue is that if there are multiple sets of baseline requirements, then it would be best to have one set of NCSSRs that each subset in the PKI industry could reference it. Ben agreed and said that one of our challenges will be to figure out how to integrate compensating controls into the document.

The subgroup reviewed Appendix B and Appendix C of the PCI DSS.  Tim C. compared and contrasted the PCI DSS approach with WebTrust.  WebTrust relies more on statements about the control objectives, e.g., "controls are in place to provide reasonable assurance that logical access is limited to approved individuals ...".  A CA might have ten controls to address that objective, so that if a CA has a failure in one, the other nine might be sufficient to serve as compensating controls to address the identified risk (as opposed to very prescriptive controls, which in PCI are then evaluated according to Appendices B and C).  Ben asked whether the PCI-DSS compensating-controls methodology was too prescriptive and whether we could come up with something a little more reasonable. Tim said that having prescriptive objectives rather than prescriptive controls makes it more flexible for the CA. Ben wondered whether it would be a good idea to turn some requirements into illustrative controls and then have a requirement that there be "reasonable assurance" that the combination of controls meets the security objective.

Meeting of the subgroup adjourned.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190331/4c03ae16/attachment-0001.html>