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

[Tim Hollebeek]

Just one comment.  Allowing arbitrary compensating controls in PCI was a
huge mistake, and is regularly abused to do all sorts of bad things.  The
approach should not be adopted by any other group.

Having clear control objectives, and evaluating whether the controls meet
the control objective, is much better.

-Tim

 

From: Netsec <netsec-bounces at cabforum.org> On Behalf Of Ben Wilson via
Netsec
Sent: Sunday, March 31, 2019 5:44 PM
To: netsec at cabforum.org
Subject: [cabf_netsec] Draft Minutes of Telephone Call Held 21-March-2019

 

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/20190417/95fd2b21/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20190417/95fd2b21/attachment-0001.p7s>