[cabf_netsec] Minutes of the NetSec meeting on 2020-03-05

[Neil Dunbar]

All,

With deep apologies for the lateness (one bluescreen of death cost me 
two hours of transcription :-/) , I'm enclosing the minutes of the last 
meeting. It was a particularly detailed discussion, with lots of view 
being expressed, so I would appreciate the membership of the list 
reading through it and correcting any of my misinterpretations of the 
recording.

In particular, if anyone was at the meeting and I've failed to record 
their attendance, please mail me and I'll get it sorted.

Thanks,

Neil


-------------- next part --------------
Network Security Subcommittee Meeting: 2020-03-05

Attendees:

Neil Dunbar (TrustCor) [Chair]
Aaron Poulsen (DigiCert)
Bruce Morton (Entrust Datacard)
Corey Rasmussen (OATI)
David Kluge (Google)
Trevoli Ponds-White (Amazon)
Ben Wilson (IP)
Mariusz Kondratowicz (Opera)
Tobias Josefowitz (Opera)
Dustin Hollenback (Microsoft)
Clint Wilson (Apple)

1. Review Agenda

The agenda was agreed upon.

2. Approve Minutes of Last Meeting

The minutes were approved.

3. Pain Points Subgroup Meeting

David reported that the PP group had met and had discussed the ballot SC20v2
[note: now called SC29] and whether patching should be considered within the
change control process; the conclusion was that it should, although the ballot
should not lay out in detail how the changes should be managed.

There was a review of the ballot on system account management, and the group
now considers that the ballot is ready for wider discussion in the NetSec team.

The ballot on log data retention periods was considered [note: this ballot is
SC28] - the group would like to proceed with this ballot. However, the team
have adjusted the text of the ballot to more consistent, including shortening
the time for issuance related logs. This ballot also needs more discussion
within the team.

The last issue covered was to do with account lockout on failed access attempts.
The team feels this is no longer a good control, since lockout itself carries
risk. However, no replacement mechanism has been suggested.

Trev indicated that she would do away with detailed instructions in this matter,
preferring reference to discrete standards. David agreed with that observation.

4. Threat Modelling Subgroup Meeting

Mariusz said that since the F2F in Bratislava there was no update to give
but that the next meeting would have an update in the Threat Modelling work.

Neil sent his apologies for being unable to attend that call.

5. Document Structuring Subgroup Update

Ben reported that the team had identified the two letter subject matter 
abbreviations which should annotate each section heading. Ben took on the
task of presenting a new draft with the subject matter annotations.

6. Ballot SC20v2 and Patching

Neil said that one of the reasons for reconsideration was that he had not
considered that patching would be excluded. His intention was to put the
scope into the background document.

Trev replied that she would not want to see the text purely in the background
document. Neil answered by suggesting that the rubric would contain the scope
as well.

Some examples of non change controlled modifications were discussed; including
things like clock changes. The conclusion was that all system modifications
were covered by the ballot, and no descoping to 'security impactful changes'
should be permissible.

Neil suggested that he did not want to see the ballot text itself change, since
it was good as it was. David also said that the text should remain unchanged,
and was keen to see this done as soon as possible, since this ballot had been
waiting around for a year.

Neil finished by saying that the ballot would be submitted on Monday
(2020-03-09), assuming the seconders were still comfortable with the new
ballot.

7. System Account Management

Tobi introduced the proposed ballot which would replace the three monthly
review and deactivation of unnecessary accounts with an option to continuously
monitor accounts. Review would be against a known, approved, list of accounts
which were supposed to be operational on a system, and in the event of an
account not on the approved list being found, it must be deactivated within
24 hours.

Trev asked for better punctuation in the text, but was concerned about the
focus on 'accounts'. After observations by Ben and David, the question was
refined to 'Should we be talking about access to systems, rather than the
fixation on the system account phrase'?

Neil also argued for clearer text, since the text as it stands was ambiguous
and could be read in a fashion which the authors did not intend. Tobi agreed
that the text should be improved. David suggested multiple ways in which a
list of approved accounts could be generated, giving as an instance a list of
names from HR.

Trev responded by saying that this implies that system accounts are then the
accounts of people, and not machine processes. This would appear, then, to clash
with clause (l), which specifically deals with removing accounts of people
who have left the company.

David replied by saying that he understood 'system accounts' to be all accounts
which have access to a system, whether human or not-human. Tobi also thought
this was the case, and Ben indicated his agreement with this interpretation.

Trev said that she would prefer a deactivation within 24 hours of non-use 
for any method of access. Neil responded by saying that what should be removed
is any account (human or not, eg. a cron job) which has been deemed to
no longer require access to a given system.

Trev remarked that then 24 hours seems like an emergency response to something
which may not be an emergency; in which case the ballot seems to propose an
overreaction.

Tim commented that he prefers the shift to credentials and access rather than
the expression via system accounts.

Neil asked for the Pain Points team to reconsider the text. Tobi said that
they would.

Neil said that he would want it to move forward, since it would appear that
accounts with high privileges could stay around without need for three months.
David replied that some systems cannot immediately withdraw accounts because
it could break systems.

Trev's response was that the concern is more about the credentialling of
accounts rather than the existence of the accounts themselves. But that
bringing this matter into sharp focus was altogether a positive step.

8. Work on Upcoming Ballot Texts

Neil thought that SC28 was ready to do, but Tim said that there had been a few
changes to the document since then, which should be reviewed. As it turns out
there had been significant change, so the ballot would need to be reviewed
before it can go forward.

Tim introduced the changes, where he said that it seems to make little sense
to retain log information regarding issuance for the full seven years as certificate
lifetimes were reducing to one year. Therefore the changes were to call out
certificate issuance events as only needing to be stored for two years after
the expiration of the certificate.

Trev asked how this impacted validation. Tim answered that it would need to
be held for three years. Trev's response was that valdation time is longer
than certificate life time. Clint agreed that validation lifetime is still
27 months, and no change has been proposed there. He suggested that it could
be possible to have validation recorded for three years to ensure that any
certificate under the validation had expired.

Trev asked what the advantage of the text "two years after the expiration"
adds. Ben replied that auditing was the driver, but that he did not think that the phrase
"retention beyond seven years is not required", since it did not add anything.

Tim asked if that would mean that CA certificate issuance records should
need to be kept for more than (say) 30 years, or should there be some cap put
on the record retention. Ben said that he did not think it unreasonable to
keep event logs for CA certificates for their duration plus two years. Trev
agreed with that interpretation.

Tim said that as things stand, a CA could dispose of CA certificate logs
after 7 years. Clint commented than, on reflection, a CA should retain such
logs for the duration of the CA certificate, and asked for the cap on
retention to be removed.

Tim asked if 'revocation or expiration' could be used. There was general
agreement that this would be a positive change.

Trev commented that she found it interesting that validation retention was
being tied to certificate lifetime, and that it seems to be creating a
complex mapping from validation to certificates which dominates event
retention.

Tim replied that the tieing was somewhat required, since it becomes
hard to audit the issuance of a certificate if the validation information has
been destroyed per a retention policy. Neil said that that seemed a reasonable
concern.

Trev summarised that while firewall and security event logs should be retained
for two years, it would make sense to break up the categories between
CA and Subscriber Certificates, since they have vastly different retention
requirements.

Neil said that this ballot would not go forward as it stood until there
was another chance to address the issues raised in this discussion.

9. Any Other Business

Mariusz said that he would be sending out a new invitation for the NetSec
threat modelling.

10. Adjourn

The meeting was adjourned and will reconvene on 2020-03-19 17:00:00 UTC