Re: Security WG meeting tomorrow after the TSC Call (10am central)


Ian Johnson
 

Hi Jim,

Thanks for starting on this. I have a few general comments on document #2 (the CVE/security process document).

  1. I strongly think that all messages sent to the security@... email address for disclosing security issues should not be forwarded to the security TSC email list - this defeats the purpose of having the email address because we want that email address to be subscribed to by a few select folks who are responsible and can coordinate fixing security issues before the issue is publicly disclosed. I do think that after the issue has been resolved or decided it's not an issue a summary could be sent to the security TSC list, but it should not be automatic for that to happen.
  2. The one week response time is arbitrary. I don't think that all security issues can be resolved in that time, and for critical security issues we will want to respond and act sooner. I think this document shouldn't lay out time restrictions or expectations for responses to security issues disclosed on the email list.
  3. There needs to be a process to handle the response to security issue in a private/non-public way. Having public meetings with the working group to discuss the issue is not a solution as then the issue will be disclosed before we will have had a chance to fix it in private before disclosing. I think a fair way to handle this is to allow nomination of individuals who get subscribed to the security issue email address, and these individuals are then like a "mini-working group" who are responsible for responding to a security issue, but have the benefit of being able to coordinate privately before public disclosure.
  4. We should not be automatically posting details about security issues in a public manner until a decision has been made about their resolution (or lack thereof). Some security bugs are purely hypothetical or low priority and so it's okay to publicly disclose these before resolution but others may be very critical and need to stay private until fixed.
  5. Absent from your document is any discussion of how we handle CVE's or security issues discovered (and possibly fixed) in our dependencies. For example, if a critical security bug is discovered and fixed inside vault (and then disclosed publicly), how do we go about handling that?
Thanks,
Ian


On Tue, Mar 26, 2019 at 9:51 AM White2, James <James.White2@...> wrote:

All,

Apologies in that it has taken me sometime to get organized as the temporary chair of this working group.  However, we have been working in the background to try to organize the necessary work for the Edinburgh release.  Additionally, we have been talking to members of Intel and David Ferriera about roadmap items (importantly what has to be explored for Fuji).  In tomorrow’s meeting, I’d like to share with you some of this work and get your reaction.

 

Specifically, the agenda for tomorrow includes:

  1. Edinburgh Release Securing EdgeX Secrets (securing the Vault Master token and database username/password at a minimum)
  2. Providing a means to report/react to security issues (per recent CVE discussions)
  3. Planning/working roadmap and Fuji release – getting out front of that release starting now (Intel helping to drive)

 

Please see and review the attached documents in advance of tomorrow’s meeting to discuss items #1 and #2

 

Look forward to the call and chatting with you all.

 

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

 

Join EdgeX-TSC-Security@lists.edgexfoundry.org to automatically receive all group messages.