Date   
EdgeX Security WG Meeting (Weekly) - Wed, 01/30/2019 8:00am-9:00am #cal-reminder

EdgeX-TSC-Security@lists.edgexfoundry.org Calendar <EdgeX-TSC-Security@...>
 

Reminder:
EdgeX Security WG Meeting (Weekly)

When:
Wednesday, 30 January 2019
8:00am to 9:00am
(GMT-08:00) America/Los Angeles

Where:
https://zoom.us/j/576218946

Organizer:
EdgeX-TSC-Security@...

Description:
EdgeX Security WG Meeting. Meeting content posted to Security WG Wiki.
Meeting Lead: David Ferriera, Security WG Chair, david.ferriera@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/576218946

Or iPhone one-tap (US Toll): +14086380968,,576218946# or +16465588656,,576218946#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 576 218 946
    International numbers available: https://zoom.us/zoomconference?m=t6UX5OTIE0SFrIk-9MMnBPbFjE3dZ_xx

An RSVP is requested. Click here to RSVP

EdgeX Security WG Meeting (Weekly) - Wed, 02/20/2019 8:00am-9:00am #cal-reminder

EdgeX-TSC-Security@lists.edgexfoundry.org Calendar <EdgeX-TSC-Security@...>
 

Reminder:
EdgeX Security WG Meeting (Weekly)

When:
Wednesday, 20 February 2019
8:00am to 9:00am
(GMT-08:00) America/Los Angeles

Where:
https://zoom.us/j/576218946

Organizer:
EdgeX-TSC-Security@...

Description:
EdgeX Security WG Meeting. Meeting content posted to Security WG Wiki.
Meeting Lead: David Ferriera, Security WG Chair, david.ferriera@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/576218946

Or iPhone one-tap (US Toll): +14086380968,,576218946# or +16465588656,,576218946#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 576 218 946
    International numbers available: https://zoom.us/zoomconference?m=t6UX5OTIE0SFrIk-9MMnBPbFjE3dZ_xx

An RSVP is requested. Click here to RSVP

EdgeX Security WG Meeting (Weekly) - Wed, 03/06/2019 8:00am-9:00am #cal-reminder

EdgeX-TSC-Security@lists.edgexfoundry.org Calendar <EdgeX-TSC-Security@...>
 

Reminder:
EdgeX Security WG Meeting (Weekly)

When:
Wednesday, 6 March 2019
8:00am to 9:00am
(GMT-08:00) America/Los Angeles

Where:
https://zoom.us/j/576218946

Organizer:
EdgeX-TSC-Security@...

Description:
EdgeX Security WG Meeting. Meeting content posted to Security WG Wiki.
Meeting Lead: David Ferriera, Security WG Chair, david.ferriera@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/576218946

Or iPhone one-tap (US Toll): +14086380968,,576218946# or +16465588656,,576218946#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 576 218 946
    International numbers available: https://zoom.us/zoomconference?m=t6UX5OTIE0SFrIk-9MMnBPbFjE3dZ_xx

An RSVP is requested. Click here to RSVP

last minute meeting cancel - with apologies

White2, James
 

All,

Our Security WG meeting for today has been cancelled.  Unfortunately, David F who was going to present his roadmap ideas is in a location where he is unable to connect.  We’ll reschedule David’s talk in the near future.

 

Next week, we’ll be looking at some early designs around storing secrets in Vault.  Again, apologies for the late notice.

Jim

Cancelled Event: EdgeX Security WG Meeting (Weekly) - Wednesday, 20 March 2019 #cal-cancelled

EdgeX-TSC-Security@lists.edgexfoundry.org Calendar <EdgeX-TSC-Security@...>
 

Cancelled: EdgeX Security WG Meeting (Weekly)

This event has been cancelled.

When:
Wednesday, 20 March 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/576218946

Organizer:
EdgeX-TSC-Security@...

Description:
EdgeX Security WG Meeting. Meeting content posted to Security WG Wiki.
Meeting Lead: David Ferriera, Security WG Chair, david.ferriera@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/576218946

Or iPhone one-tap (US Toll): +14086380968,,576218946# or +16465588656,,576218946#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 576 218 946
    International numbers available: https://zoom.us/zoomconference?m=t6UX5OTIE0SFrIk-9MMnBPbFjE3dZ_xx

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

White2, James
 

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

 

 

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

 

 

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" <ian.johnson=canonical.com@...>
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.

Echo!

  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.

Echo!

  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.

Sincerely

Malini

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

 

 

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

White2, James
 

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.

 

From: Bhandaru, Malini (VMware)
Sent: Tuesday, March 26, 2019 5:37 PM
To: ian.johnson@...; White2, James
Cc: EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)

 

Hello Jim! I echo Ian’s comments.

 

From: <EdgeX-TSC-Security@...> on behalf of "Ian Johnson via Lists.Edgexfoundry.Org" <ian.johnson=canonical.com@...>
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.

Echo!

  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.

Echo!

  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.

Sincerely

Malini

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

 

 

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

Malini Bhandaru
 

Thank you Tingyu and Jim for the secrets storage v4 document.

 

A few comments/questions:

  1. Would you please include a sample vault master token file.
  2. What is the auth: null in the json response from a rest API call?
  3. While ACLs are not checked in Edinburgh, would it make sense to have some stub code in there that tests ACLs and returns trivially true to get the flow in place?
  4. How do we anticipate to use the ACL? Might it be which microservice can make what REST call on another microservice?
  5. Is the namespace to microservice mapping one-to-one?
  6. Why do the namespaces need to be secret? 

3. Define the secret namespaces and share the namespace definitions with the individual consuming micro service or init scripts.

       7) Looks like the flow chart figure with steps 1, 2, .. 4.1 .. 5 is duplicated. Why?

       8) What does secret store namespace description look like?

Regards

Malini

 

From: <EdgeX-TSC-Security@...> on behalf of "White2, James via Lists.Edgexfoundry.Org" <James.White2=dell.com@...>
Reply-To: "White, James (EMC)" <James_White2@...>
Date: Tuesday, March 26, 2019 at 7:51 AM
To: "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Cc: "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Subject: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)

 

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

 

 

EdgeX Security WG Meeting (Weekly) - Wed, 03/27/2019 8:00am-9:00am #cal-reminder

EdgeX-TSC-Security@lists.edgexfoundry.org Calendar <EdgeX-TSC-Security@...>
 

Reminder:
EdgeX Security WG Meeting (Weekly)

When:
Wednesday, 27 March 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/576218946

Organizer:
EdgeX-TSC-Security@...

Description:
EdgeX Security WG Meeting. Meeting content posted to Security WG Wiki.
Meeting Lead: David Ferriera, Security WG Chair, david.ferriera@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/576218946

Or iPhone one-tap (US Toll): +14086380968,,576218946# or +16465588656,,576218946#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 576 218 946
    International numbers available: https://zoom.us/zoomconference?m=t6UX5OTIE0SFrIk-9MMnBPbFjE3dZ_xx

An RSVP is requested. Click here to RSVP

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

Zeng, Tingyu
 

Please see my comments inline below.

 

From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of Malini Bhandaru via Lists.Edgexfoundry.Org
Sent: Wednesday, March 27, 2019 3:15 AM
To: White2, James; EdgeX-TSC-Security@...
Cc: EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)

 

[EXTERNAL EMAIL]

Thank you Tingyu and Jim for the secrets storage v4 document.

 

A few comments/questions:

1)      Would you please include a sample vault master token file.

[Tingyu] a sample master token file can be found on github security-api-gateway project here: https://github.com/edgexfoundry/security-api-gateway/blob/california/core/res/resp-init.json

2)      What is the auth: null in the json response from a rest API call?

[Tingyu]  this is the auth method that can be customized to protect the individual resource other on top of the master token. Default it is null as we haven’t defined it yet.

3)      While ACLs are not checked in Edinburgh, would it make sense to have some stub code in there that

tests ACLs and returns trivially true to get the flow in place?

        [Tingyu] the ACL will be implemented in the secret store ( Vault) side, either HCL or policy file. We will include some sample files/configuration later.

 

4)      How do we anticipate to use the ACL? Might it be which microservice can make what REST call on another microservice?

[Tingyu] ACL we are referring here is for retrieving secret from secret store ( Vault). Communication between microservice is still in the road map, we have a couple of options like sidecar etc.

5)      Is the namespace to microservice mapping one-to-one?

[Tingyu] yes it is for this current implementation.

6)      Why do the namespaces need to be secret? 

 

3. Define the secret namespaces and share the namespace definitions with the individual consuming micro service or init scripts.

                [Tingyu] A better description would be “Define the namespace for the credentials and sensitive data for individual microservice”. The namespace itself is not secret, it needs to be published to the consumers.

7)      Looks like the flow chart figure with steps 1, 2, .. 4.1 .. 5 is duplicated. Why?

[Tingyu]  need more details ..

8)      What does secret store namespace description look like?

[Tingyu] If I understand it correctly, the namespace it self-explained, something like this: v1/secret/edgex/devicemodbus

 

Regards

Malini

 

From: <EdgeX-TSC-Security@...> on behalf of "White2, James via Lists.Edgexfoundry.Org" <James.White2=dell.com@...>
Reply-To: "White, James (EMC)" <James_White2@...>
Date: Tuesday, March 26, 2019 at 7:51 AM
To: "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Cc: "EdgeX-TSC-Security@..." <EdgeX-TSC-Security@...>
Subject: [Edgex-tsc-security] Security WG meeting tomorrow after the TSC Call (10am central)

 

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

 

 

Next version of design and process docs available

White2, James
 

All,

Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)

 

The next version of these docs is available on the Wiki and at the link locations below:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.

 

Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.

 

Thanks,

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

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

 

Re: Next version of design and process docs available

Goodell, Leonard
 

Hi Jim,

  Is there any interest in reviving the idea of having the Registry Client do the secret retrieval?

 

It of course would have to first be configured with the appropriate vault token, but then could take care of the namespace and actual retrieval of the secrets into the services configuration struct.

 

My thought is the service’s config structure could have a Secrets section which would get pulled from Vault rather than the registry service (i.e. Consul) as part of the GetConfiguration() implementation.

 

Thanks!

   Lenny

 

From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of White2, James
Sent: Sunday, March 31, 2019 4:00 PM
To: EdgeX-TSC-Security@...
Subject: [Edgex-tsc-security] Next version of design and process docs available

 

All,

Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)

 

The next version of these docs is available on the Wiki and at the link locations below:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.

 

Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.

 

Thanks,

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

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

 

Re: Next version of design and process docs available

White2, James
 

Hi Lenny,

I have always found that to be appealing (registry gets data from non-secret or secret store) but I know there are those in the community that feel these are separate responsibilities.  It is worth chatting about tomorrow and even if it isn’t delivered as part of this release, something we think about for future releases if that the arguments can be effectively made to offer that through the client.

jim

 

From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of Goodell, Leonard
Sent: Tuesday, April 2, 2019 2:01 PM
To: White2, James; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Next version of design and process docs available

 

[EXTERNAL EMAIL]

Hi Jim,

  Is there any interest in reviving the idea of having the Registry Client do the secret retrieval?

 

It of course would have to first be configured with the appropriate vault token, but then could take care of the namespace and actual retrieval of the secrets into the services configuration struct.

 

My thought is the service’s config structure could have a Secrets section which would get pulled from Vault rather than the registry service (i.e. Consul) as part of the GetConfiguration() implementation.

 

Thanks!

   Lenny

 

From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of White2, James
Sent: Sunday, March 31, 2019 4:00 PM
To: EdgeX-TSC-Security@...
Subject: [Edgex-tsc-security] Next version of design and process docs available

 

All,

Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)

 

The next version of these docs is available on the Wiki and at the link locations below:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.

 

Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.

 

Thanks,

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

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

 

EdgeX Security WG Meeting (Weekly) - Wed, 04/03/2019 8:00am-9:00am #cal-reminder

EdgeX-TSC-Security@lists.edgexfoundry.org Calendar <EdgeX-TSC-Security@...>
 

Reminder:
EdgeX Security WG Meeting (Weekly)

When:
Wednesday, 3 April 2019
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/576218946

Organizer:
EdgeX-TSC-Security@...

Description:
EdgeX Security WG Meeting. Meeting content posted to Security WG Wiki.
Meeting Lead: David Ferriera, Security WG Chair, david.ferriera@...
-----
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/576218946

Or iPhone one-tap (US Toll): +14086380968,,576218946# or +16465588656,,576218946#

Or Telephone:
    Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
    +1 855 880 1246 (US Toll Free)
    +1 877 369 0926 (US Toll Free)
    Meeting ID: 576 218 946
    International numbers available: https://zoom.us/zoomconference?m=t6UX5OTIE0SFrIk-9MMnBPbFjE3dZ_xx

An RSVP is requested. Click here to RSVP

From Ike Alisson: Info on evolvement/enhancement of Security with Quantum Computing

Ike Alisson <ike.alisson@...>
 

Hello James et al,
With reference to yesterday's TSC Security meeting, as promissed during the meeting, please see atached (in text below and to the mail) some info that may affect the Security aspects in the coming 12-24 months, and in  case of convenience and/or preference, to be utilised at choice:

1. Link below to a video on Security Encryption comparing the RSA encryption keys with Quantum Computing Encryption keys (based on BB84 and E91 Protocols utilizing the Shor's algorithm and "superposition" and "entanglement" states and related to the latter, "decoherence") that the current RSA Encryption Security will not stand against and have a chance.
P.S. Please note that the technology in the video refers to Google/D-Wave, while IBM and Microsoft has different technology approach (former with Quantum GWs and the latter with quasi-particles, non-abelian anyons).

2. Attach to this mail and in the Link below, info to IBM Q (IBM Quantum Experience Research Lab) providing an access to two (2) Quantum Computing Platforms (one as a simulator and the 2nd for Commercial use with 3-5 Qbits capacity) for developers interested in developing and running Applications on Quantum Computing Technology). Please note that Microsoft has a similar set-up.

3. Attached to this mail, there is a "Developer Guide" (that I need to update, sorry for that..) elaborating on the set-up for Developers for developing applications. 
Hope that this might be of use to you and/or the rest of the colleagues at the TSC Security Edge X Foundry in the coming months.
Sincerely yours, 
Ike 

_______________________________
Ike Alısson
ALICON (ALIsson CONsulting)
GSM :                +46 707 60 99 00
E-mail:               ike.alisson@...
                          ike@...
Webpage:          www.alicon.se
_______________________________
This communication is confidential and intended solely for the addressee(s). Any unauthorized review; use, disclosure, or distribution is prohibited.  If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it.  Thank you.  E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: Next version of design and process docs available

espy
 

On 3/31/19 7:00 PM, White2, James wrote:

All,

Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)

 

The next version of these docs is available on the Wiki and at the link locations below:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

Here are my comments on v6 of the Protecting Secrets document.

/tony

---

 - <p1> 1st sentence: "centralize management" --> "centralized management"

 - <p2> 2nd sentence: "permission need" --> "permission needs"

= inventory of edgex secrets =

 - last bullet, last sentence: "securely store" --> "securely stored"

= secret storage architecture =

 step 1 - the part of the last sentence needs re-wording ("and an ACL that back by Vault...". I'd actually just suggest dropping that part instead.

 step 2

  - Shouldn't this step happen before 1?

  - This should mention that the access token is the master

  - Are there more than one initialization programs (same question for step 3)?

= vault initialization =

 - If the secret store init is written in Go, it's not really a script anymore.  Just sayin...

 - <p2> 2nd sentence:

   - if secrets are passed by command-line, aren't they going to be in source code whereever the command-line is defined? This applies to environment variables too... Why not use a configuration file approach where the init app would read secrets configuration files from a volume and then delete them when initialized?

   - how would someone do this if EdgeX is being deployed via docker-compose? how would someone do this in the snap?

 - <p2> last sentence: What's the use case for being able to generate GUIDs or random strings?

 - <p3> This sentence ("If the credentials need to be updated...") doesn't make sense as written.

= vault master token file protection =

 - I'd suggest a slight re-wording of the first sentence:
    "Today, the Vault master token is stored, without protection, in the file system. In docker deployments this is a shared volume. In snap deployments this this write-able part of the snap."

 - Also note that on a traditional Unix/Linux system this file would be only owner readable via standard MAC, however doing this with docker and shared volumes might be tricky.

 - And a slight re-wording of the second sentence too:
   "In the future, this file needs to be protected with an HSM (e.g. TPM) or similar mechanism."

= org of secrets =

 - <p1> "In general, credentials will be organized under a namespace of v1/secret/edgex/:path"

  - Is the ":" a typo?

  - Is mongodbinit an existing micro service?

  - paths typically start with a "/"

 - <p4> It looks like triggering GUID generation is to just use the value ”xxxxxxxxx-xxxxxxxx-xxxxxxxx”. Does password generation use the same value or is it just a string of 'x' chars? Does the length matter?



https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.

 

Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.

 

Thanks,

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

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

 

Re: Next version of design and process docs available

White2, James
 

Thanks Tony.  Am traveling tonight but will take a look and incorporate tomorrow in the copy for review on Wednesday.

Jim

 

From: EdgeX-TSC-Security@... <EdgeX-TSC-Security@...> On Behalf Of espy
Sent: Monday, April 8, 2019 6:12 PM
To: White2, James; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Next version of design and process docs available

 

[EXTERNAL EMAIL]

On 3/31/19 7:00 PM, White2, James wrote:

All,

Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)

 

The next version of these docs is available on the Wiki and at the link locations below:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

Here are my comments on v6 of the Protecting Secrets document.

/tony

---

 - <p1> 1st sentence: "centralize management" --> "centralized management"

 - <p2> 2nd sentence: "permission need" --> "permission needs"

= inventory of edgex secrets =

 - last bullet, last sentence: "securely store" --> "securely stored"

= secret storage architecture =

 step 1 - the part of the last sentence needs re-wording ("and an ACL that back by Vault...". I'd actually just suggest dropping that part instead.

 step 2

  - Shouldn't this step happen before 1?

  - This should mention that the access token is the master

  - Are there more than one initialization programs (same question for step 3)?

= vault initialization =

 - If the secret store init is written in Go, it's not really a script anymore.  Just sayin...

 - <p2> 2nd sentence:

   - if secrets are passed by command-line, aren't they going to be in source code whereever the command-line is defined? This applies to environment variables too... Why not use a configuration file approach where the init app would read secrets configuration files from a volume and then delete them when initialized?

   - how would someone do this if EdgeX is being deployed via docker-compose? how would someone do this in the snap?

 - <p2> last sentence: What's the use case for being able to generate GUIDs or random strings?

 - <p3> This sentence ("If the credentials need to be updated...") doesn't make sense as written.

= vault master token file protection =

 - I'd suggest a slight re-wording of the first sentence:
    "Today, the Vault master token is stored, without protection, in the file system. In docker deployments this is a shared volume. In snap deployments this this write-able part of the snap."

 - Also note that on a traditional Unix/Linux system this file would be only owner readable via standard MAC, however doing this with docker and shared volumes might be tricky.

 - And a slight re-wording of the second sentence too:
   "In the future, this file needs to be protected with an HSM (e.g. TPM) or similar mechanism."

= org of secrets =

 - <p1> "In general, credentials will be organized under a namespace of v1/secret/edgex/:path"

  - Is the ":" a typo?

  - Is mongodbinit an existing micro service?

  - paths typically start with a "/"

 - <p4> It looks like triggering GUID generation is to just use the value ”xxxxxxxxx-xxxxxxxx-xxxxxxxx”. Does password generation use the same value or is it just a string of 'x' chars? Does the length matter?

 

 

https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.

 

Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.

 

Thanks,

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

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

 

Re: Next version of design and process docs available

Zeng, Tingyu
 

Tony,

Thanks for the comments. I am trying to answer some questions in your previous email 

 - <p2> last sentence: What's the use case for being able to generate GUIDs or random strings?

Answer: the purpose is to create username/password that are hard to guess - once they are created they will be staying in the secret store and the only way to access is through the REST API or command line interface. I will explain more in this weeks security group meeting.

   - if secrets are passed by command-line, aren't they going to be in source code whereever the command-line is defined? This applies to environment variables too... Why not use a configuration file approach where the init app would read secrets configuration files from a volume and then delete them when initialized?

Answer: We are trying to eliminate the cases that keep the password/credential in plain text in the system so that anyone can read it. 


 - <p1> "In general, credentials will be organized under a namespace of v1/secret/edgex/:path"

  - Is the ":" a typo?

Answer: This is not a typo. It means a path that can be decided later based on the individual micro service. Some other options to use here would be something like {:path}. 

  - Is mongodbinit an existing micro service?

Answer: Yes it is, and here is the name of the repo is docker-edgex-mongo. 

 - <p4> It looks like triggering GUID generation is to just use the value ”xxxxxxxxx-xxxxxxxx-xxxxxxxx”. Does password generation use the same value or is it just a string of 'x' chars? Does the length matter?

Answer:  In the example this is GUID that represents a unique resource in the secret store. Using GUID as a password has its disadvantage. We will discuss more in this week's security group meeting about the options. 



Thanks

Tingyu





From: EdgeX-TSC-Security@... [EdgeX-TSC-Security@...] on behalf of espy [espy@...]
Sent: Monday, April 8, 2019 7:12 PM
To: White2, James; EdgeX-TSC-Security@...
Subject: Re: [Edgex-tsc-security] Next version of design and process docs available

[EXTERNAL EMAIL]

On 3/31/19 7:00 PM, White2, James wrote:

All,

Thanks for the input last week on

  • our design for protecting EdgeX secrets for Edinburgh Release and
  • the process for addressing security issues (CVE)

 

The next version of these docs is available on the Wiki and at the link locations below:

https://wiki.edgexfoundry.org/download/attachments/329467/Protecting%20EdgeX%20Secrets-v5.pdf?version=1&modificationDate=1554072568311&api=v2

Here are my comments on v6 of the Protecting Secrets document.

/tony

---

 - <p1> 1st sentence: "centralize management" --> "centralized management"

 - <p2> 2nd sentence: "permission need" --> "permission needs"

= inventory of edgex secrets =

 - last bullet, last sentence: "securely store" --> "securely stored"

= secret storage architecture =

 step 1 - the part of the last sentence needs re-wording ("and an ACL that back by Vault...". I'd actually just suggest dropping that part instead.

 step 2

  - Shouldn't this step happen before 1?

  - This should mention that the access token is the master

  - Are there more than one initialization programs (same question for step 3)?

= vault initialization =

 - If the secret store init is written in Go, it's not really a script anymore.  Just sayin...

 - <p2> 2nd sentence:

   - if secrets are passed by command-line, aren't they going to be in source code whereever the command-line is defined? This applies to environment variables too... Why not use a configuration file approach where the init app would read secrets configuration files from a volume and then delete them when initialized?

   - how would someone do this if EdgeX is being deployed via docker-compose? how would someone do this in the snap?

 - <p2> last sentence: What's the use case for being able to generate GUIDs or random strings?

 - <p3> This sentence ("If the credentials need to be updated...") doesn't make sense as written.

= vault master token file protection =

 - I'd suggest a slight re-wording of the first sentence:
    "Today, the Vault master token is stored, without protection, in the file system. In docker deployments this is a shared volume. In snap deployments this this write-able part of the snap."

 - Also note that on a traditional Unix/Linux system this file would be only owner readable via standard MAC, however doing this with docker and shared volumes might be tricky.

 - And a slight re-wording of the second sentence too:
   "In the future, this file needs to be protected with an HSM (e.g. TPM) or similar mechanism."

= org of secrets =

 - <p1> "In general, credentials will be organized under a namespace of v1/secret/edgex/:path"

  - Is the ":" a typo?

  - Is mongodbinit an existing micro service?

  - paths typically start with a "/"

 - <p4> It looks like triggering GUID generation is to just use the value ”xxxxxxxxx-xxxxxxxx-xxxxxxxx”. Does password generation use the same value or is it just a string of 'x' chars? Does the length matter?



https://wiki.edgexfoundry.org/download/attachments/329467/EdgeX%20Process%20for%20Addressing%20Security%20Issues-v4.pdf?version=1&modificationDate=1554068308940&api=v2

 

We’ll discuss these at this week’s security WG meeting, but we always welcome feedback early.

 

Bryon Nevis and Jim Wang will also present their (Intel) high level planning for Fuji.

 

Thanks,

Jim White

Director, IoT Platform Development Team & Distinguished Engineer

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