[cabf_netsec] As

[Neil Dunbar]

All,

The minutes of last meeting are attached here for consideration and review.

Regards,

Neil

-------------- next part --------------
Minutes for NetSec Meeting - 2020-04-16

Attendees

Neil Dunbar (TrustCor) [Chair]
Corey Rasmussen (OATI)
Mariusz Kondratowicz (Opera)
Joanna Fox (GoDaddy)
Aaron Poulsen (DigiCert)
Ben Wilson (Mozilla)
Wendy Brown (FPKI)
Taconis Lewis (Protiviti)
Tim Crawford (BDO)
Dustin Hollenback (Microsoft)
Bruce Morton (Entrust Datacard)
Janet Hines (SecureTrust)
Trevoli Ponds-White (Amazon)
Clint Wilson (Apple)

1. Review Agenda

The agenda was agreed.

2. Agree Last Two Meetings Minutes

The minutes of the last two meetings were agreed.

3. Pain Points Subgroup update

There was no meeting for the Pain Points group because of vacations, so no update was submitted.

4. Threat Modelling SG update

Mariusz reported that the meeting format had changed, so that the first 20-25 minutes
would be spent discussing risks most prevalent from the main NetSec meeting - thus for
the last call, patch management was the main theme.

This identified 14 distinct risks emanating from patch management against the existing
threat models, which will be forwarded to the main group, once a review of the NSRs has
been completed to establish whether those risks are appropriately covered by the 
requirements.

The meeting will then look at user cases. For offline CAs, these have established 18
pertinent risks, which again will require NSR coverage review.

For the meeting following this one (2020-04-16) the plan is to examine the same user
cases for online CAs, with a view to producing a similar risk list.

Neil asked that, having review some of the threat modelling output, that some risks have
been noted as not being adequately covered by the NSRs; thus would the threat modelling
group wish to prepare ballots to address these gaps.

Mariusz replied that it is still up for discussion, but that the modelling team are still
focused on finding more gaps from their analysis. The options are either to group the
uncovered risks into a smaller number of ballots, or to prioritise the risks as discovered,
forward those findings to the NetSec group, and then decide on any ballots to be written.

Trev opined that the second option (prioritise and discuss) seemed the best one. She
said that sometimes opinions vary as to whether a gap is truly a gap versus differing
interpretations of the existing language.

5. Document Structuring SG update

Ben has produced a draft ballot regarding the elimination of the Zone terminology.

Neil asked if this also touched on the authentication requirements over zone boundaries.
Ben replied that it might be slightly touched, by virtue of moving some of the 2.g section
up into another section.

Ben said that there had been no redlining as such. Neil said that the changes might be
"wide but not deep". Ben thought that might be the case. Ben did also think that a few
CPS might be changed as a result of the ballot. Neil wasn't sure that this was the case.

Ben encouraged everyone to examine the ballot and provide comments.

6. Ballot SC28 update

Tim had rearranged the categories of events which are used for log retention into:

 - CA key and certificate lifecycle events
 - Subscriber certificate lifecycle events
 - Security events

He thought those elements made more sense. Neil asked if that meant that the retention
of logs was essentially "two years after the information stops being meaningful". Tim
agreed, and Neil expressed approval for that structure.

Tim did mention that the Security events section might still cause some angst. There
followed some discussion on whether the notion of "two years after the event stops" is
completely accurate; Tim did say that for security events it would be once the event
takes place, rather than on "expiry" of the event.

Trev asked if the certificate lifecycle retention was inconsistent with security
events, but added that she did not actually think that they should be consistent.

Tim said that security events were events unto themselves, and that they were not
contingent on the lifecycle of some other object.

Neil said that he would prepare a redline for the ballot, if Tim could accept the
changes into a single document.

7. Ballot SC29 update

Neil said that Ballot SC29v3 was out for discussion. He has put out a list comment
asking if the voluntary moratorium on ballots should be lifted, and that it was time
to take the ballot to a vote.

8. System Account Management Ballot

Tobi mentioned that the sentence structure was highly ambiguous so a new draft was
completed to rectify this. The defined list of accounts is now removed from the ballot.
Neil asked if this meant that the CA is now required to maintain its own processes
for defining whether an account is necessary or not. Tobi agreed.

Trev asked why the 24 hour deactivation window was still in place for a three month
review process, since it seems that such a fire drill doesn't follow from a three month
review. She also asked whether it meant that the account deactivation begins at the
24 hour period, or should be complete by 24 hours.

Neil asked if the three month review period could be brought in to a shorter period;
even though that is the period specified for PCI-DSS. Tobi replied that if such a ballot
would succeed, then he would be all for it. Trev indicated that such a ballot would cause
real problems for some CAs.

Trev said that she saw this ballot as essentially imposing a 24 hour deactivation
window over and above what was already there, and that the understanding of the
necessity of accounts should be separated from the deactivation period of the account
if deemed to be unnecessary. After Tim said that some period needs to be established,
and Trev said that such periods should be defined for the different kinds of account.

Neil reminded the group of statements made (by Tim and others) that the concern was
over people who move within a company, and who may still have accounts for historical
reasons, but no longer have a need to use certain systems by virtue of their move.
He then went on to explain that while a central list of accounts might exist within a
company, it was the access to those accounts which needs to be controlled rather than
the existence of the account per se.

Clint reminded the team of an earlier suggestion he made about replacing the term
"account" with "credentialled access to an account" (whether a personal account or a
system account).

Neil gave the example of an enterprise wide LDAP directory where all boxes in the company
could list a large number of users, but only a small fraction of those users had
sufficient credentials to access those accounts. In this case, many of the accounts
would be deemed "deactivated" from the NSR perspective.

Following that, Tobi gave the example of an account existing outside of the designated
list of accounts, which should not be there, and where removal was the only acceptable
option, since the account's existence was anomalous. Trev then asked whether the three
month review was intended to cover the existence of such rogue accounts, and Tobi thought
that it was. Trev replied that such a situation seems more of a security incident than
the sort of thing to be captured during a periodic review.

Tobi replied that he saw the review as a supplementary control on top of the existing
provisions for account provisioning. Neil said that he saw accounts as persistent
identifier and that it was the credentials which was the dominant control. Tobi said
that there still needs to be some ulimate control to remove accounts which have no
business being in place in any capacity, whether the account can be accessed via
credentials or not. He gave the example of an account which has operates a persistent tunnel
allowing remote access into the controlled network, even though the account cannot
be logged into any more.

Trev observed that it seems then that the three month review is the fallback position
to cover such rogue accounts, as well as non-emergency.

Neil asked if then the 24 hour period could just go away, and Tobi said that it was
simply added to make the ballot clearer. Which would mean that the ballot would essentially
just be adding continuous monitoring as an option, with continuous monitoring being
the preferred end state. Tobi added that since configuration management was the intended
state, then a continuous monitoring system on such a configured system would be an
improvement.

Neil then asked if the ballot text could be updated with a new redline, and Tobi agreed
that he would do so.

Tim asked if the text of "remove access" would be preferable to "deactivate". Following
that, Ben asked if we wanted to rework the text to clarify the nature of systems and
account.

Trev gave the example of accounts which had files remaining which were important enough
to not allow deletion of the account, but simply removal of access capabilities. She mentioned
that the word "account" does not appear very often, and that Ben's ballot would remove
even more of them, and thus we should be focussing on the access to accounts.

Neil summarised by saying that the driver should be that each CA should ensure that
all accesses to accounts were strictly in keeping with business need. Tobi disagreed, saying
that what needs to be monitored is that the accounts on a system were as the configuration
management says it should be. Trev said that Neil's point may be what is desired, but
is not what this current ballot does.

Neil stated that perhaps "deactivate" is the only text that does work.

Tobi maintained that it was more about ensuring that the only accounts on a system are the
ones one expects to be there.

Neil offered to begin a discussion on list seeking to clarify his thoughts. Tobi said
this would be fine, because it was clear in discussions that people have vastly different
intepretations of what "system accounts" even means. Trev posted some chat as a starting
point for such a discussion.

9. Any other ballot work

There was no other ballot work to be discussed.

10. Any Other Business

Trev asked if Neil was going to post regarding lifting the ballot moratorium. Neil replied
that he had already done so.

11. Adjourn

The meeting was adjourned until 2020-04-30 09:00:00 PST/12:00:00 EST/17:00:00 BST/18:00:00 CET