[cabf_netsec] NetSec meeting minutes from 2020-09-03

[Neil Dunbar]

All,

Please find the minutes of the last meeting attached.

Cheers,

Neil

-------------- next part --------------
Network Security Subcommittee Minutes
2020-09-03

Attendees

Neil Dunbar (TrustCor) [Chair]
Corey Rasmussen (OATI)
Dustin Hollenback (Microsoft)
Tim Crawford (BDO)
Bruce Morton (Entrust Datacard)
Mariusz Kondratowicz (Opera)
Ben Wilson (Mozilla)
Tomofumi Okubo (Digicert)
Tobias Josefowitz (Opera)
Janet Hines (SecureTrust)
Trevoli Ponds-White (Amazon)
Clint Wilson (Apple)
Aaron Poulsen (Digicert)
David Kluge (Google)

1. Review Agenda

The agenda was approved

2. Agree Minutes

The minutes from both previous meetings were approved.

3. Pain Points Subgroup Update

David reported on the last Pain Points call. Most of it was spent discussing
the feedback on the Account Management ballot. The team felt that the lengthening
of the configuration checking of automated systems was worth talking about
should it be set at 3 months rather than 6.

Some of the other feedback left the subteam wondering if the commentators
had not fully understood the intentions and requirements of the ballot proposers.
In particular, it seemed to be asking for language which was already required
from other sections of the NSRs. After discussing the comments for a while, the
team agreed that as a first step that section 2 should be re-ordered such that
they are presented in a more logical arrangement and therefore the Account
Management review process would appear at the bottom of the section, making it
clear that its provisions were in addition to all of the other requirements.

Tobi took it as an action to update the redline. He reported that this was done 
on Github.

4. Threat Modelling Update

There was no update, but a large scale TM meeting was due to take place after
the NetSec meeting.

5. Document Structuring SG Update

Ben reported that the DSG continued the offline vs airgapped discussion. On the
most recent meeting, Ben recapped that the team were toying with the structure
of the NSRs themselves - this goes to the heart of the desire (or not) to move
to RFC 3647 formatting for the NSRs.

This spoke to Bruce (Morton)'s point regarding altering the Baseline Requirements
themselves to incorporate the Trusted Roles part of the NSRs. The alternative
was simply to push the Offline CA ballot as is, and then worry about restructuring.

Bruce replied that he was happy to go with the Offline CAs ballot first. He was
concerned that we could end up with language in the NSRs which doesn't belong there,
specifically how to manage trusted users for particular roles. Bruce points out
that this overlap has been around since the NSRs were first established.

Ben answered that there was no particular order of actions imposed. He was fine
with another ballot to modify the BRs first, or not. But he wanted to guage the
general feeling of the team before he committed to a course of action.

Ben summarised that the Zones ballot still needs more work.

Neil mentioned that the Threat Modelling meeting was due to consider the Zones
ballot in greated detail - following this NetSec call.

6. Account Management Ballot

Neil commented that the redline on Github had been commented on by Ryan and Wayne.
In his opinion some of the feedback went further than the scope of the ballot. Tobi
agreed, saying that some of the feedback seemed actionable, and others not.

Neil commented that the desire in the comments desired "transparency" as an end goal
for CAs, but it was unclear how such a ballot can express actionable items to
achieve that goal. He added that the deployment of automated systems to perform
system checks does not absolve the person performing the deployment for the actions
of the automated scanner.

Tobi added that this seems a natural extension of the language in the ballot. He did
say that there were actionable items in the text. Specifically, if we made it more
explicit in the ballot of the scope of what monitoring needs to cover, that might
help win more hearts and minds of members.

Neil reported that Wayne's comment was that the scope was vague, but he (Neil) said
that the existing language in the NSRs is vague too, so Tobi's ballot does not
make anything worse; however, if Tobi thinks it can be tightened, it's a discussion
worth having. Neil added that he didn't think that "continuous monitoring" was
that confusing a term - it means something which is monitoring a system and at no
point during the systems operation is it not being monitored - as opposed to a 
system which executes regularly scheduled periodic checks on behaviour.

7. Authentication (Lockout) Ballot

David reported that there was no real time to discuss this ballot, but if the
reordering of Section 2 was performed, it would help make the scope of the ballot
clearer (since this ballot touches Section 2 as well). It might even be a possibility
to include the lockout ballot into the account management ballot; but the first
step had to be the Section 2 reorder.

Neil thought that this makes sense in light of a reorder. 2.k might no longer be
2.k after reordering, making the ballot somewhat meaningless.

8. Cloud CA continuing discussion

Neil spoke to some of the comments made by Trev on the discussion document;
he accepted that the cloud providers provide very good systems to spool log data 
from source systems. However, knowing that those logs are complete and free
from tampering is not quite so easy to accomplish, and this quality seems like
something an auditor would want to see demonstrated.

Trev replied that this is something which is already in audit scope. She 
brought up the example of FedRamp, which has an audit criterion of "knowing all
of the things which happened, all of the time". A similar demand comes from
the Australian IRAP standard. To some extent PCI has this requirement.

Trev continued to say that there are different levels of log "completeness" to
be assessed; namely who can disable or enable log output; how is that change
effected; is there a least privileged control in place.

Neil gave the example of having a host producing lots of logging information.
Is it the case that the responsibility lies with the host operator to ensure
that log information has been committed to the log, or can the cloud provider be
relied upon to ensure that the log data is not lost. A CT log comes with
inherent mathematical proofs which demonstrate that a log is both complete and
accurate; can the same thing be gathered from a cloud providers logging system.

Trev said that to some extent it depends on the software running on the box.
She explained that, under the Shared Responsibility Model, the operator of the
(virtual) host is responsible for the loggingg of any data; the cloud provider
is responsible for ensuring that the underlying system is kept running. So,
the detailed permissions management on the virtual OS would not be in the
responsibility of the cloud provider, but the software which ensures that the
system is managed at a coarse level, to particular service level agreements
is within their sphere of responsibility.

Neil continued that the question which emerges then is: which of the many
services (that a cloud provider sells) can be rendered suitable for a CA type
operation. At a base level, having a bare metal box run by a cloud provider is
probably an easy system to audit. Can a virtual host on a shared tenancy
model have its borders so easily policed?

Neil said that the document still needs to be broken down further to explore
these issues.

Trev said that non-CA compliance issues like above have been seen many times,
meaning that some of the issues are not specific to CAs at all. Thus, such challenges
as have been laid out in the document have already been answered from other
customers in regulatory compliance arenas.

The challenges which are CA specific will be that the BRs demand a particular
type of audit; or highly specific controls (the example were Code Signing EV 
certificates).

Neil said that he would drill down into the document to attempt to tease out
the CA specific elements.

David considered that it may be that either an update to the NSRs, or even
a second requirements document might be needed for cloud customers. David
added that we are missing a risk assessment, or a requirements list for CAs.
He thought that a more concrete formulation of properties is an essential
step. CAs in particular need to have strong controls over the signing of
objects via HSMs. We need to develop a clearer understanding of what it takes
to achieve that in a cloud environment. The NSRs don't really spell out what
controls need to obtain over HSM signatures.

Neil commented that transparency of operations is also a requirement. He
brought up the idea of marrying the HSM logs from all signing requests issued
to HSMs, in order to demonstrate that the HSMs have not signed anything
which the CA has not explicitly requested has been signed. It's not so much
an integrity thing (e.g. like showing that logs have not been altered) but
rather transparency so that relying parties can know better that the CA can
be trusted.

Trev asked if it would be helpful to take low hanging fruit which isn't unique
to CAs, but at least to illustrate how a cloud deployment can achieve the
properties.

Neil thought that this was useful. He brought up the example of logging as 
something which is fundamental to a CA's operation - it might be useful to
explore what the BRs require and demonstrate how those can be done in a cloud
type environment. There might be many cases of CA operations which actually
get easier by cloud environments, given that they have been architected differently
to on premises hardware deployments.

David said that a useful idea might be to take the notion of certificate
Transparency and extend it to a transaction level of operations within a cloud
enviroment; thus having transparency on all operations. It would generate a large
amount of data, but cloud environments are designed to handle this. David
added that this is a paradigm shift, because transparency is a detective
control, rather than preventive.

Trev thought it was a bit of both. David agreed, but he added that transparency
feeds into prevention, owing to cloud providers having large teams in situ 
to examine anomalous situations.

Neil commented that most cloud providers need to have those large scale data
mining and report generation schemes because they have customers who will argue
their bills if the provider cannot demonstrate that the services billed were
indeed the services used. However, an on-premises deployment neither requires nor 
would find useful that level of logging granularity.

Trev said that there was nothing better than relying on self-serving mechanisms
to ensure correct operations. Neil agreed - and added that this transparency of
operations should be able to be leveraged to provide trustworthy CA operations.

Trev said that she found two things in the BRs and NSRs which would make life
very hard in moving to a cloud CA environment, because they are written so
specifically. Isolation requirements (airgaps, offline, etc) are one; and firewall
event logs would be another. A cloud providers firewall logs would be utterly
non-meaningful.

Trusted Roles are another one. While conceptually, a documented process could
say that "we trust this provider to assign roles because we trust this other audit
which the provider has passed", such a documented process of role assignment would
be unlikely to pass muster.

Neil said that he would examine the logging section in the document, and tease out
those functions which are BR and NSR mandated, and examine what is CA specific and
what is not.

Trev felt that because the NSRs focus so much on physical hosts and their operations,
many large on-premises deployments might be in conflict with the NSRs as they stand.
David agreed, saying that the unit of computation being the physical machine in the 
NSRs, puts them at odds with how computing deployments work in the modern world.

David added that the isolation requirements, trusted roles and firewall logs have
their equivalents in the cloud CA world, but in different forms. He added that
they might even be more comprehensive than traditional deployments.

David went on to say that the ISACA requirements actually do have sections which
deal with Azure and AWS hosted environments. There is a specific network 
isolation component which looks for the logical separation of communication
between virtual hosts, rather than an explicit firewall appliance to manage
network isolation. He added that logical isolation is easier in the CA world
because of the ease of deploying and destroying instances.

Trev added that the Zones ballot might help clarify some of these issues.

9. Any Other Business

Ben asked about Jos Purvis's suggestion that different documents belong to
different working groups - how would this work with the NSRs?

Neil replied that since NetSec is an SCWG Subcommittee, it would be up to that
working group to determine ownership of the NSRs. However, he thought that
ultimately, there would need to be some sort of pan-working group Network
Security consideration, but that would need to come before the Forum.

David asked why NetSec is a Subcommittee of SCWG and not a working group of
its own. Neil replied it was because pre-working group architecture, NetSec
was a subteam within the CA/B Forum as a whole, and that it migrated with
the formation of the SCWG. Neil added that it doesn't mean that it's supposed
to be that way - it just is.

Neil said that he would email the CA/B Forum asking if there was an
appetite for a pan-working group NetSec team.

10. Adjourn

The meeting was adjourned and will reconvene on 2020-09-17.