[cabf_netsec] Draft Meeting Minutes - September 28, 2021

Mon Oct 11 04:42:37 UTC 2021

Apologies for the delay! Below are the draft meeting minutes from the NetSec meeting on September 28, 2021.

Best,

Brittany Randall

Meeting Minutes – NetSec – September 28, 2021

Attendees:
Ben Wilson, Brittany Randall, Clint Wilson, Corey Bonnell, Daniel Jeffrey, David Kluge, Dustin Hollenback, Jose Guzman, Kati Davids, Marcelo Silva, Miguel Sanchez, Prachi Jan, Quan Nham, Tim Crawford, Tobias Josefowitz, Trevoli Ponds-White

Welcome

  *   Thanks for joining us
  *   Recording is going
  *   Will start with anti-trust statement and assign a minute taker

Meeting Minute Volunteers

  *   <Awkward silence>
  *   Brittany volunteered to take minutes
  *   Clint mentions that in validation working group, there is a rotation of minute takers. Do we want to do something similar?
  *   Ben mentioned that we could just do the list of members we could follow that. Ben mentions he would be on the rotation, but doesn’t want to be alone.
  *   Clint may add something on the wiki that we can use as a starting point.

Anti-trust Statement

  *   Clint read the anti-trust statement

Minute Approval

  *   Draft meeting minutes sent out by Prachi to the list
  *   Clint asks if there are any questions or corrections for minutes sent out?
  *   No comments or questions. Meeting minutes are considered approved

NetSec GitHub Project

  *   Clint introduces as a carryover topic from two meetings ago and notes that Ben created a project within Github. Notes that the project consists of mostly smaller/individual tasks – more like clean up rather than epics. Wanted to talk through some of the high-level objectives that we have a subcommittee and what we want to accomplish. Examples – bring into scope other working groups and shift NSRs to a forum level activity. This would be good thing to align to – get larger objectives out there to start working on. Clint asks if there are other objectives that others want to make sure we are making progress toward with regard to the NSRs? Example – want to figure out how to get the NSRs to support cloud services for hosting part of CA systems.
  *   Daniel mentioned that related to cloud, we’ve talked about completing a risk assessment and submitting that to the server cert working group, which he has been working on that and should be sharing something this week.
  *   Clint notes that we require CAs to complete a risk assessment and we were talking about doing our own risk assessment. Noted that we don’t have a shared definition of what that means. Either for scope and for what CAs are already expected to do. Larger work of performing a risk assessment around the NSRs is a big objective.
  *   Daniel mentioned that a lot of things have been started on the risk assessment. And that this work makes sense to call out to add as an item that we’re working on and something we’ll want feedback on.
  *   Clint asks about goal of the risk assessment. Is the goal is to create a shared understanding of “what risks the network security requirements are intended to address and require mitigation of by CAs – is that accurate?”
  *   Daniel responds that that is reasonable assertion, but also notes that we are looking at the risk assessment in terms of it covering PKI specific (PKI, Web PKI, CA, etc) risks and threats and provides some analysis. Risk and threat analysis may be more useful to start and then can move toward a discussion on mitigation in the future.
  *   Clint notes mitigation may be more a long term. Maybe as part of this, specifying the ways that are a appropriate for CAs to mitigate.
  *   Daniel mentions that we can achieve that as a risk analysis which considers the threat, vectors, etc and handle the NSR as currently written where those are the mitigations. Mitigations get into things very specific to the environments. Didn’t want to rabbit hole but wanted to make sure we captured this as a large piece of work that the group is working on.
  *   Brittany adds after the risk assessment, we could consider consuming that and understand what areas we should monitor in related industry. Example would be changes in FIPs security. Align or have an objective to investigate that stuff to keep the requirements aligned as well.
  *   Daniel mentions that similar things have been called out before and that the risk assessment can be a good foundational piece. Essentially, right now it feels like we don’t have a foundation to stand on so hoping the risk assessment will help with that.
  *   Clint notes that sequencing will be important.
  *   Marcelo mentions that within the risk assessment, having a starting point of good definitions. What is expected from CAs and browsers perspective. We should align with how would be the risk assessment and going through the context of assets – to identify threats and vulnerabilities. Probably, impact, and probably scoring. Without going further on remediation, how should the risk be treated. What would eb the mitigation point. High level instruction we would put in there.
  *   Marcelo added a comment to the PCI DSS risk assessment guidelines which may be helpful.
  *   Daniel thanks Marcelo for putting that in and shares the approach to risk assessment that he has been using. Currently using NIST, but will take a look to synthesize. Agree with the points on how we approach it. Settling on a methodology which is what hoping to send out shortly.
  *   Clint notes that risk assessment is clearly a priority. Any others that we are missing. Ben has been working on some objectives. Things like updating understanding of the meaningful or practical expectations around physical security and the zones ballot.
  *   Ben mentions yes we just need to capture it. We were wanting to see how it evolved. Will get something out there.
  *   Clint confirms that this is an objective that we want to continue to work toward. Various levels of security that are expected in a CAs infrastructure. Are there other objectives that we already have in mind that we want to accomplish? We will start with this set of objectives. Between risk assessment moving it to a forum level group that sounds like quite a bit. Other little things we can make progress on along the way as well.

Other Standards to Align or Incorporate

  *   Talked a month ago about other standards that could be used along side the NSRs or incorporated into the NSRs by reference which would allow us to focus on the PKI specific aspects of networking security while leveraging an ideally better or modern, comprehensive set of security requirements that address all of the non-PKI specific aspects of security. Believe that the conversation left off on a lot of research that David has been doing. Any update on the topic or any other investigation in this topic?
  *   David mentions that he is not aware of any. Just takes some time to do the work and overlay between the overlay and of standards and the NSR. Mentions that Daniel has been doing some work on this and may be able to give an update on this. Of the standards that were mentioned were PCI. Have not specifically named in the previous calls.
  *   Daniel chimes in that he has looked at what has been done and has seen a lot of useful work. This work is on the back burner behind the risk assessment. The ordering will b helpful to get the risk assessment in and agreed upon on a larger scale then we can come back and define out what the CAB forum wants to control and what we can integrate.
  *   David agrees the approach makes sense as well. Clint does too. Getting the risk assessment will be a good foundation to build on.

Cloud Services

  *   Clint provided an update on the cloud services group. Some of what has already been covered on risk assessment. Anything further you wanted to mention David?
  *   David did not have anything additional beyond the topics already discussed.

Risk Assessment

  *   Clint asked if Daniel wanted to share risk assessment progress, updates, etc.
  *   Daniel mentions that at this point he has been going through lots of prior work spread across different documents (black Tulip).Working through the risk assessment paradigms from Nist, ETSI and PCI DSS and pull together if we want to take on approach. At this point doing the reading and preparatory work to put this together. Hoping to send something out this week which shares approach and to get feedback. Daniel believes we can use a lot of the work that was already done and could be pulled into a single finished piece that could then be discussed. Welcomed any comments on the direction.
  *   Clint mentions that it sounds like a good direction. Mentions that if you do want to collaborate, would be happy to jump on a call.
  *   Daniel mentions that he thinks better out loud so may take Clint up on the offer. Also mentioned that Trev has reached out as well.
  *   Trev is happy to be a rubber duck.
  *   Ben mentions Kermit the frog.
  *   Clint thinks it will be important to make sure that when we share we have something that carries the context. You’re doing all this background work, etc so having something that carries that context would be extraordinarily helpful.
  *   Daniel agrees in the background context. Shares example of some of the work and recommendations being made. How it might be digested by others without some additional context.

Ballot Discussion/Updates

Ballot SC34 – No update

Ballot SCXX Audit Log and Archive retention

  *   Clint mentions that he’s gotten this to a place where he is comfortable with it, but noted that he received a some comments.  Clint mentioned that he dropped a note from the draft which had further statement that these were the minimum but CAs could choose greater as appropriate. It was originally a warning that says this is a minimum, but ended up dropping because it wasn’t really adding all that much. Question for the group – should we add it back?
  *   Trev mentions that as long as you can set it for longer than the additional information isn’t needed, but Trev is opened to other opinions. Trev asked if removing that makes CAs less likely to store information for security purposes? Would guess no.
  *   Clint would hope no.
  *   Clint will double check to make sure it is clear.
  *   Trev mentions that it says at least two years.
  *   Clint will give another look from that perspective.
  *   Another comment. In an earlier version of the ballot, had included illustrative controls. Clint mentioned that he dropped that section from the ballot because no where else are there illustrative controls in the BRs. Was a little worried that introducing this as normative in BRs would distract conversation around the ballot. Beyond that, didn’t have a comprehensive set of examples. Question for the group – should that be added back in? Would it be helpful for CAs? Especially brand new CAs?
  *   Brittany asks if we have considered a supplementary document rather than within the actual requirements? For example, here’s the NSRs mapped to some illustrative controls. For those familiar with PCI, it’s the additional guidance.
  *   David shares that this has come up many times. But we have never had the time to sit down and write something like that.
  *   Clint feels there are a lot of value in having and poses the question would it be better to do piecemeal and add into ballots where it makes sense? Or would it be better to introduce with a whole set all at once? We’ve talked about the second approach, but that’s a lot of work and not nescessarily with a ton of value to any particular person doing that work. Clint wonders if adding here and there more iteratively would change the approach.
  *   Daniel comments that when it comes to doing the audit, we get examples in the IRL, the auditors, and even from CPA Canada. Having Illustrative controls is not a bad thing – could be a really good thing and help guide the WebTrust auditors. David notes that they are a target audience. Believes the auditors would welcome the guidance and possibly have to change some of their interpretation. May go into the larger discussion on what should be meticulously defining and maintaining. Daniel thinks its stuff we should do, but limit to what we actually want to control.
  *   Brittany asks if we can delegate this to the WebTrust task force.
  *   Tim mentions that from the network security standpoint, the requirements are so specific, they almost read as controls themselves. Other parts of the BRs may benefit more from illustrative controls.
  *   Trev agrees that the NSRs feels more like controls which could cause gaps since they don’t talk as much about the objective. Where someone might implement something specifically as written.
  *   Ben believes that they were written that way to keep us away from doing illustrative controls, rather, wanted to have more black and white controls. Wanted to say, no, this is what you have to do. Background that this was in response to things like DigiNotar and to create something that was binding. Agree that it may feel haphazard. Original thought was to provide something narrative to explain the intent behind. Ben mentions that maybe, similar to what was mentioned earlier on the call, maybe it’s a separate document or supplement that goes into this. Maybe that is the approach rather than doing illustrative controls in the sense that Clint suggested within the NSRs.
  *   Tim mentioned that WebTrust did take a stab at illustrative controls to give an example in the long form report (across all the guidelines). He noted that it was very much a preliminary stab and would need a deep dive.
  *   Clint asks if Tim could share or reshare.
  *   Tim mentions it was shared at one of the CAB meetings, but will recirculate for the group.
  *   Clint’s takeaway is to hold off on adding illustrative controls to this ballot, but continue to consider it for both future supplemental or as a topic for us to discuss.
  *   Brittany had a question and mentions that she may be scope creeping this ballot discussion. Shares that she had the opportunity to publish some incidents recently and asks the group if we ever take a look at those from an NSR perspective? Thinking it could help us focus where we could provide guidance. For example, seeing certain criteria are missed or even other incidents which could be an area of opportunity.
  *   Ben mentioned that in the past had discussed having an information security or info sharing group. People were really sensitive about that. In terms of reviewing incident from a security perspective. Was it more security incidents.
  *   Brittany was thinking more the items that are publicly reported we could start there. Provides example of someone reporting a password issue. Mentions that it could give us some trending of potential focus areas or areas where we can help people.
  *   Trev mentions OCSP or test certificate webpages. The browser alignment ballot added in. There are probably other things that should be added to.
  *   Clint mentions he has a branch for SLA for OCSP that is actually achievable.
  *   Daniel was reminded of the problem in UI development. It makes sense to me because I wrote it and then people do something different. That’s why we try and look at and see where. Improve the process. Where are struggle happen. Incident reports are one place. Some of the forum communications of questions. This is a pretty valuable idea. There is some time consumption and dedicating effort, etc. Where are we seeing hotspots. I think it’s a cool idea – implementation would require us to put something on it.
  *   Brittany likes to be the idea guy. Notice how she didn’t volunteer for it 😊
  *   Clint mentions that one potential approach is when CAs or effected parties notice these gaps that we are logging them in the GitHub issues. If it’s written down somewhere it would be easier to look at. As opposed to having to filter through all the things.
  *   Daniel mentions that another option would be to have a periodic meeting where we review stuff. We have a few of us volunteer for the meeting and we all grab a month, etc and these are things I notice and discuss it. Similar to things we expect CAs to do.
  *   Brittany notes that why she mentioned incidents, curious if we could grab information automatically. For example, if there was an NSR flag, could be raised as a potential alert. Loves idea of the periodic review and understand where there are areas of consternation in the community.
  *   Trev asks Ben if he is going to do a Mozilla bug review.
  *   Ben mentions that at some point yes, he will review the Mozilla bugs.
  *   Trev mentions that If there is an opportunity when you’re reviewing and Ben mentions that he will keep an eye open for the NetSec type of incidents.
  *   To summarize the discussion, Clint notes that he will leave the ballot as is and send through.

Any other conversation on zones or air-gapped

  *   David mentioned that he has some follow up on the list and promised to draft something and share. Hoping to have something later this week.