toggle quoted messageShow quoted text
Really appreciate the great input and feedback Ian and Malini. Many of the items in this document were simple placeholders just to start the conversation and await debate and input from the work group (like the one week response time).
So as always, your comments are very much appreciated and will help set the tone for some conversations tomorrow.
Bhandaru, Malini (VMware)
Tuesday, March 26, 2019 5:37 PM
ian.johnson@...; White2, James
Re: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)
Hello Jim! I echo Ian’s comments.
Thanks for starting on this. I have a few general comments on document #2 (the CVE/security process document).
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:
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.
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.
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.
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.
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:
Edinburgh Release Securing EdgeX Secrets (securing the Vault Master token and database username/password at a minimum)
Providing a means to report/react to security issues (per recent CVE discussions)
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.
Distinguished Engineer, IoT Platform Development Team Lead
EdgeX Foundry Technical Steering Committee Vice Chairman
| IoT Solutions Division
+1 512-723-6139, mobile/text