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

Malini Bhandaru

Hello Jim! I echo Ian’s comments.


From: <EdgeX-TSC-Security@...> on behalf of "Ian Johnson via Lists.Edgexfoundry.Org" <>
Reply-To: "ian.johnson@..." <ian.johnson@...>
Date: Tuesday, March 26, 2019 at 2:55 PM
To: "White, James (EMC)" <James_White2@...>
Cc: "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Subject: Re: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)


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.

I agree with Ian here. The recipients of the email will typically be a small subset of people, who will ascertain its validity, rank its criticality, and how soon a fix can be issued. Perhaps even call the team “vulnerability management” or something. My guess is each vendor/partner might want to have a representative here. 

Any public disclosure is only after a fix is “in place” in production systems. Secrecy is key here. With the Specter and Meltdown bugs, an entire community spanning multiple companies worked under wraps to fix the issues over a period of 6 months. The public became aware of the issue only when patches were pushed to the Linux kernel. Note OpenStack followed an alternate review workflow for security patches. With IoT, the attack surface is even larger.

Once addressed, we document each such issue discovered, which releases it affected, how, and the fix/patch. This is public like all CVEs.

OpenStack gave a lot of thought to this, please see if these link help:


  1. 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.

The security vulnerability team will be a rapid response team, but fixes may take longer than a week. It may be more meaningful to say the mail box will be monitored constantly, with coverage during member vacation spells.

  1. 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.


  1. 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.


  1. 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?

Here a patch may require new containers to be posted including a patched OS or application as the case may be. We will need to determine whether it can be a “rolling” install (one that does not interrupt edge services) or one that does and if so how rapidly it can be applied.






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


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




Join to automatically receive all group messages.