[cabf_netsec] Minutes of NetSec meeting onm 2020-05-14

[Neil Dunbar]

All,

Please find attached the minutes of the last meeting. Any comments, 
please get them to me and I'll adjust the minutes accordingly.

Cheers,

Neil

-------------- next part --------------
Minutes for NetSec Meeting 2020-05-14

Attendees

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

1. Review Agenda

The agenda was agreed but modified. Bruce asked for a discussion on the remote access provisions of the NCSSRs,
and Ben asked for a discussion on OCSP availability.

2. Agree Minutes

The minutes for the meeting on 2020-04-30 were approved.

3. Pain Points Subgroup Update

David summarised the comments on the Pain Point meeting on 2020-05-11, focussing on a new discussion on the lockout controls in
section 2.k of the NSRs. The general feeling from the group is that this is not a particularly effective control because there
are sufficiently many exceptions so as to make the lockout enforcement almost optional; and even then it is unclear that a 5
attempt lockout is even an effective control in the first place. However, David was concerned that there has been opposition
to modifying such language in the past, and was unsure if a ballot was likely to succeed.

Specifically, it is unclear that all architectures require a password lockout mechanism and without a better understanding
of how CAs perform authentication (whether password based or not) specifying concrete ballot text would be tricky.

Ben said that he would conduct some research to measure the state of the art of authentication methods. Trev asked if we could
just point to something else, but Ben said that he was unsure of what that reference would be. Trev commented back that we
all agree that 2.k is out of date and makes little sense for a great many CA deployments. However she said that if we simply
replicate the current state of the art into the NSRs, it places an obligation to continually review and replace as the state
of the art advances; and this may be too prescriptive a burden for CAs to bear.

She preferred a mechanism which would refer to best practices as defined by some other body, and a requirement to follow
best practices would then be embedded into the NSRs.

Neil commented that if the problem is to resist attempts to penetrate CA systems by an attacker who would eventually get lucky,
then what emerges is a requirement to monitor, review and alert on failed access attempts and not to rely on a 5 strike lockout
which he described as a worthless specification. Trev liked that mode of expression. Neil continued to say that a ballot which
imposes a clear duty on the CA to be aware of and mitigate damage from failed access attempts seemed a more fruitful approach.

4. Threat Modelling SG Update

Mariusz said that the authentication proposals just discussed dovetail nicely into the subject matter which the Threat
Modelling Group will be considering anyway.

He then introduced the proposals on Shared Credentials [which are notionally prohibited from CA use except where no other
solution exists]. A possible ballot to replace 2.f is emerging - to split 2.f into two separate requirements: one to strongly
push for unique credentials (even if accessing a shared account name), and then a logging requirement to identify the principal
doing the authentication as well as the IP address of the authenticating host (where applicable).

The key point is that as long as there is a log chain which leads from a person to an authentication event, the existence
of a shared account is not necessarily a bad thing.

Mariusz also pointed out an awkward piece of text in BR 5.4.1(2) which required a log entry to include the identity of "the person"
making the journal entry; we need to accept that persons and services cause log entry events and that the text should
expand to be "person or service". Mariusz then asked for feedback on the approach taken.

Neil said that we should certainly attack the issue of shared accounts; he pointed out that many HSMs have fixed account
identies embedded into them, but that some have the ability to link particular SSH keys to that account, so there is still
a link back to an individual assuming an account identity. What should not happen is that a general shared password is
passed around the company which then loses accountability. Neil added that for general computer systems it seems much harder
to defend a shared account name and/or credentials - he did not think there were *no* reasons for it happening, but he
would be interested in knowing what they could be.

Tim asked about the "root" account. Neil replied that in general, people should not be logging in as root, and that a mechanism
like "sudo" preserved the link between the unique (personal) identity and the new account identity (root). Aaron agreed that
that sudo preserves attribution.

Trev mentioned that we should take care not to break legacy systems, so proposed a minor modification: that if there is a
gating layer (with unique credentialling) around the shared account bearing system, that should be permitted. Neil asked then
if the notion was that even if the logging system did not allow the unique identity to be expressed, but inferred from
surrounding log data, was that the permitted model? The group agreed that was the point being expressed.

Bruce asked if a secure room/rack authentication into where some equipment (without unique credentialling) would count as
a sufficient gating layer. Neil said that was a really good example, because there might well be a case where a rack has
a simple combination lock or padlock, but that the data centre itself would have detailed logs which identified which person
was allowed into the room/rack at that time.

Mariusz then said that there was a corner case: where two persons in the room at the same time who both know the shared
password to a device - there is no chain of inference there, since either person could have authenticated. Neil said that if
any change was made (which required this authentication) then a change order would need to exist which specified the
identity of the person making the changes; if that person was in the secure space at the time that the change was made
then that person would be deemed to have made the change; whether someone else actually did it or not.

Tobi asked about the situation where someone isn't following the rules. Neil said that would be a case of having an
insufficient change control process. Tobi continued, asking about the case where staff are simply ignoring the rules
regarding change controls. Neil said that in such a case, the CA would risk failing audit, since a CA is required to
demonstrate continuous compliance, rather than an auditor searching for incidents of non-compliance. The discussion went
back and forth a few times - Tobi pointed out that such violations could happen; Neil agreed that they could, but in the
end, the lack of evidence of compliance with a solid change control process would be reason enough for a qualification on the
audit; which for a CA is highly undesirable. Tobi replied that an audit is fine, but the problem simply goes away if
shared accounts are not allowed to exist.

Neil replied in turn that we have established that there are systems and equipment in the CA sector which simply do not
allow all accounts to be uniquely specified; therefore the approach would either be to prohibit such deployments, or to control
usage of such equipment.

Tobi suggested that for those pieces of equipment, it would be possible to design systems where only one person was allowed
access at a time, or that a person would be monitored by someone who did not know the password.

Trev brought up the point of multi-person access; that was there to ensure that individuals could not perform wide
ranging tasks unsupervised or unmonitored; and that a requirement to exclude all but one person seemed like going backwards.
Neil agreed with this. Tobi continued, saying that perhaps there could be a requirement that the multiple persons granted
access would need to know of one another's presence in the data centre.

Trev was concerned that the scope of different computers, HSMs, dedicated equipment et al meant that there might be a need
to split the requirements into more specific zones of concern. Neil agreed with this view.

Mariusz asked what would an auditor really want to know in a scenario like this (a person using a credential to get into
a secure room then using a shared password to access a system, but where the log also show that a second person was in
the secure room at the same time). If there was nothing from an auditor perspective which they found troubling, perhaps
we are worrying overmuch. Specifically, do we need to know with 100% accuracy which one out of two people made a change?

Trev then asked whether a trusted witness would be the necessary attestation that the auditor would use. Tim said that
while unique credentials are massively preferred. But that trusted attestation would be acceptable.

Neil asked if the Threat Modelling team would take this matter forward - and that time was limited; Mariusz said that they
would.

5. Document Structuring SG Update

Ben has sent out an email regarding the zones ballot.

There was a new redlined section for the NSRs regarding offline CAs which needs discussion. Work is still
ongoing on this matter.

The zones ballot takes priority, and Ben asked for endorsers. Neil offered to endorse. Trev said that she was
happy to endorse. David also added that he would endorse. Neil asked if Ben would be proposing the ballot, and
Ben replied that he would.

6. F2F 50 presentation discussion

This topic was skipped owing to lack of time and the change to the agenda.

7. Ballot SC28 - final prep

It was agreed that Ballot SC28 was ready to be put to the main SCWG. Neil asked if the seconders were still
fine with the text. Trev and Dustin said that they still were, so the submission will be made in the next
few days.

Tim summarised the changes such that the main categories have been overhauled, and now the seven year retention
period is replaced by two years after the end of the event.

8. System Account Management ballot

Trev mentioned that the only new thing would be the six months review if the account monitoring is being
performed via continuous monitoring (ie, accounts supplied by a system configuration manager).

Neil asked if Tobi would make a new redline and then be prepared to put it forward as a ballot.

Trev also suggested renaming the ballot "Account Management" rather than "System Account Management".

Neil offered to endorse, and Trev also said that she would endorse the ballot.

9. Any Other Business

Bruce opened up with a question about remote administration or access (where a secure network connection
is needed). He asked if this meant _all_ access, or just access for administrative purposes. He thought
that the text was confusing.

Ben replied that he had worked on that text as originally written, and he said that the intent was purely
to restrict administrative access, not (for instance) customer access. So there was no intent to constrain
access as a whole. He suggested to just replace the text with "remote administrative access". Bruce thought
such text would clean up such confusion. Trev thought that was a sensible idea, because the text as it
stands is not what was intended. Neil suggested a short cleanup ballot to amend the text to the intended one.

Ben then brought up the OCSP IdenTrust outage which was discussed on m.d.s.p; and whether this should be
an incident response matter. He mentioned that many CAs offload pregenerated responses to a CDN, to maximise
availability, but not all do. The BRs require 24x7 performance of OCSP services - did this mean a 100%
availability promise?

Neil said that in his opinion it did not mean 100% uptime of service, because that is exceptionally
difficult to engineer; but even in the CDN case, it still is no guarantee of 100%. For a start OCSP is
very poorly tailored to a traditional CDN style solution. If a requestor puts a nonce in the OCSP request
then this guarantees a cache miss, and therefore will result in a round trip to origin for the
pregenerated response; thus the uptime of the service is conditioned by the uptime of the origin servers.
Similarly, a POST (rather than GET) OCSP request is highly likely to result in a cache miss.

Ben also pointed out that CDNs can have other problems, like blocking in some parts of the world. He
mentioned that Ryan Hurst had written an OCSP monitoring tool which might be good to resurrect as a
service quality metric.

Neil thought this would be a good idea and could be improved by having it tail CT logs and selecting
random certificates for OCSP tests, because then a CA would not be able to ensure that specific test
OCSP requests were always successful but would need to ensure that the service worked for all serial
numbers equally.

Trev thought it was a nice idea but was unclear on how that could be expressed as a requirement. She
then referred to BR 4.10.2, which referred to a 10 second response time - perhaps uptime should be
considered along the same basis. She said that it was not that CAs wanted wiggle room, but rather could
CAs be constrained to state their OCSP service quality provision and then prove that they operate
within their stated parameters. She presumed that auditors would not expect to see incident reports if
there was an OCSP outage but that outage was within the allowed OCSP operations policy.

Trev gave the example of a policy of notifying customers of OCSP outages and therefore the auditors
would want to see evidence of that notification should there actually have been an outage. Incident
responses would be reserved for violations of a stated policy.

David mentioned that there are profound challenges to a 24x7 OCSP - uptime, correctness, freshness of
response and so on. He was in favour of the Service Level Objective proposal, and that CAs should be
obliged to publish their SLOs in Section 4.10.2 of their CPS. That then gives a clear space on what
metrics should be gathered to support the CAs claim of service provision. This met with general
approval.

Ben then said that he would like to see some language drawn up which would provide normative language
on what would be required of CAs to publish in their CPSes. Neil suggested that the mailing list
continues this discussion.

Tim asked if any CAs are considering virtual presence requirements for multi-person controlled activity,
given the COVID-19 pandemic. Tim felt that such adjustments probably don't work for CA audit requirements, but
wanted to ask whether such things were becoming commonplace. Aaron said that while he was unaware of
any such changes in practice, it was still something which could be considered some more. Trev agreed
that it was worth looking at, although she did not think that it was generally possible. Tim replied
that the general auditor view was not a favourable one, but was raising the question to a wider audience.

10. Adjourn

The meeting was adjourned and will reconvene on 2020-05-28 at 0900 PST/1200 EST/1700 BST/1800 CEST.