[cabf_netsec] Draft Minutes of Meeting July 9, 2020

[Ben Wilson]

Here are the draft minutes of our last call for your review

*Meeting of Thursday, 09-July-2020*

*Antitrust Statement* read by Ben

*Roll Call*:  Ben W., Bruce M., Tim C., Aaron P., Clint W., Corey R., David
K., Janet H., Mariusz K., Tobias J., and Wendy B.

*Minutes*:  Minutes of May 28, 2020 were approved

*Review of Pain Points Subgroup*

There were no calls since the last meeting because of public holidays, but
there are items on the agenda: SC28 feedback, which is being worked on; and
the account management ballot is in the pipeline.

*Review of Document Restructuring Subgroup*

Ballot 32, is in discussion and needs to be worked on. Ben read through
Neil’s recent comments to Ballot 32. Ben is going to re-draft the Ballot
based on comments.  Also, there is the Offline CAs ballot, and Tim C. is
mapping the prior requirements to the new ones listed for physical and
logical offline CA security, otherwise the draft is ready for comment.

*Review of Threat Modeling Subgroup*

We usually spend about half of our time following this meeting to discuss
the main topic of this recent NetSec meeting, and we identify additional
risks. There is a new document,
https://docs.google.com/document/d/1GLQtFKhvzFMD__TUbZVlg6KHid9Ju1tDj4oEom8PmvA/edit#
<https://docs.google.com/document/d/1GLQtFKhvzFMD__TUbZVlg6KHid9Ju1tDj4oEom8PmvA/edit>,
there are seven topics currently on the list. More can be added. Recently
we did a CA equipment threat modeling.  See
https://docs.google.com/document/d/1nHpYpTFhYlSJoweOu3xH1XuJG9h5OpxdApnYWuhd8RY/edit#heading=h.2dvh0smg32m7
.  At some point, we will create a summary before the next F2F that will
present what we’ve done this year.

*Open Discussion*

*SC28* -- The group reviewed and discussed Neil’s email and Ballot SC28v3.
Everyone should look at the email and see if they have any comments. (There
was an issue with reading the numbering, but that looks as though it only
occurred with web-based email—the drafts in Github and elsewhere do not
have the numbering problem.)

*SCXX – System Account Management Ballot* was reviewed.  We are primarily
changing from “accounts” to “access”, which should be mentioned in the
summary. Tobias has a draft of the ballot and summary language in GitHub,
which he copied over to the Google Docs version. We need additional
endorsers—did Neil and Trev volunteer previously? They are not on today’s
call.

“Credentialled” was in parentheses because it isn’t in the text of the
ballot. We don’t want  to put “credentialled access” in the ballot, because
that would mean that non-credentialled access isn’t monitored, and that is
not what we want. We revised the explanation to simply say, “system
accounts” and “access”.

Ben said that the proposal should state the problem that we’re trying to
solve.  David said that the problem is that the current NCSSRs suggest that
a human review of accounts is always required. However, in a large CA
environment, with numerous systems and numerous accounts, that is not
practical to do. It is better to continuously monitor user accounts and
permissions. So, one purpose of the ballot is to clarify that it is one
thing that CAs are allowed to do. And then this ballot is just one in a
series of ballots where we have promoted the idea of continuous monitoring
to identify misconfigurations and issues earlier than every 30 or 90 days.
If we promote continuous monitoring on security-relevant configurations,
then it would be inconsistent to say you have to find out about security
issues immediately, but it is OK to wait several months to find out you
have an orphaned user account. Toby agreed that this issue we're trying to
resolve wasn’t in the document we received from the auditors, but that we
were working on it in order to be consistent with configuration
requirements as well.  There is no reason why we shouldn’t follow the same
trail of thought as the rest of our work.  Tim said that it should be
monitored as part of an automated process in conjunction with HR systems,
but he hasn’t seen that implemented effectively by CAs yet. David said that
maybe it could be implemented.



Ben asked whether we should send this back to the Pain Points subgroup to
refine the explanatory part of the ballot and whether it should be written
to talk about integration with configuration management and HR systems.
Toby said that we shouldn’t take it back to the subgroup and change it.  We
want to keep the changes simple. Ben said that we don’t need to amend the
text of the ballot, but that we need to improve the background explanatory
parts to help with any subsequent interpretation challenges.  Toby said
that the subgroup could take on that challenge.  We need to check for
endorsers – Neil and Trev.



*Ballot SC32 Discussion*

Tobias said that the issue in the NCSSRs is confusing and that is why we’re
trying to work on it. We are coming to the ballot from a confusing
perspective and making changes to it. We need to take into account that we
need to make it less problematic on another level, in addition. We need to
be even more clear. It’s not convincing at first sight. We should
re-evaluate what the document wants to achieve, and express it in a clearer
way.

David – “Tobias, when you look at the document, there are physical zones,
logical zones, or both.  Which is more contentious.

Tobias – It’s both. I am skeptical. It’s difficult.  I don’t think there is
logical separation that is reasonable. You need to go for logical first and
re-examine it really well. If you make logical the backbone for security
controls, if you want logical separation to provide good security. If you
make it more detailed about a VLAN, logging into a switch, etc., it gets
really complicated actually.  You don’t want to give the impression that
doing the logical separation makes it all good.

David – I think you’re mentioning something very important. I think I agree
with you that it’s not good to just replace the concept of secure physical
zones or logical zones and just replace them with nothing. If we replace
them, we need to replace them with something that is equally secure, but
we’d have to improve with something that is even better. And maybe we don’t
have clarity yet on what that would be.  But on the other hand, saying that
as long as there is some separation or zoning, however that looks, that is
problematic too.  That is the problem we have now without a definition of
physical security.  There are problems with the high security zone being
the place where sensitive assets are located, and it’s assumed that the CA
has physical security, but the requirements don’t state what they are.  This
is the dilemma. I’ve talked with several people, and it’s not a trivial
discussion. It would be a pity if we just decide to leave it as is. We
should end with a better definition and concrete controls.

Tobias – Have we looked at how the current edition creates some level of
security?  Right, because it is problematic.  And then we look at the
current model and what we do just make sure that current security level is
left intact, and develop something that does it in a more obvious way.

Meeting adjourned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20200712/2cbf38b1/attachment.html>