Date   

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

Zeng, Tingyu <tingyu.zeng@...>
 

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

 

 


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)

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

 

 


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
 

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)

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

 

 


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

 

 


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


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


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


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, 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


Abstract Registry proposal presentation

Goodell, Leonard <leonard.goodell@...>
 

 

All,

  Attached is the Abstract Registry proposal I presented in last week’s Core WG meeting.  

 

A few of us met on Monday to discuss Vault and how retrieving secrets could be included in this abstraction. Here are my notes from that meeting. We will continue this discuss in this week Core WG meeting.

 

Thanks!

   Lenny Goodell - Intel

 

-----------------------

Notes:

 

  • Vault
    • 3rd party app also from HashiCorp
    • Tightly coupled to Consul
    • Uses Consul features
      • Fail over
      • Clustering
    • We can’t insert an abstraction layer between 3rd party apps (Vault) and Consul.

 

  • What about abstracting use of Vault for getting values that are stored as secrets so micro services don’t have to be aware/care where the values come from.
    • How do we know which values are in Vault vs which values are in the Registry?
      • One approach is to have the value in the Registry indicate that it is actually a secret in Vault. Then go to Vault for the value.
      • Add a “secrets” path to the configuration like how we are looking at separating out “writeable”
        • Use of Vault vs Registry is determined by the configuration path.
          • If Vault is not enable, defaults to getting “secrets” in plain text from Registry’s …/secrets path
        • FYI, thought of this as I was typing up these notes… 😉
      • What about storing all values in Vault, if enabled?
        • Abstraction must know if Vault is enable.
        • No watcher capability in Vault
          • There might be a way to implement watcher capability via plug-in for Vault’s secrets engine
          • Could keep “writable” section in Registry so still have watcher capability. Assume these never need to be true secrets
            • Use of Vault vs Registry is determined by the configuration path.
    • Recap of Options:
      • Mixed data between Vault & Registry. Some unique value indicates stored as secret in Vault
        • Separate out secrets into “secrets” section/path so they come from Vault when it is enabled.
      • All values store as secrets Vault. No watch capability, implement plug-in for secret engine?
      • All non-writeable stored as secrets in Vault. Writable stored in Registry so they can be watched.

  • Other opens to discuss further
    • How are secrets “put” into Vault?
      • Pre-populated in some other manner?
      • Part of Seed service?
        • Add this capability to Abstraction?
    • Are we expecting a Registry UI to be exposed in production that allows config value changes?
      • Security concerns??
    • What is the approach for implementing this Registry Abstraction and Vault for Edinburgh?
      • Abstraction first so it can be used in the one service targeted for Vault
        • Abstraction must then have support for Vault
      • Separate efforts, Crawl Phase?
        • Abstraction doesn’t initially have support for Vault
        • Vault usage in target micro service is implemented directly against Vault for values that are known to be secrets.
        • Walk phase could a support for Vault to the Abstraction, but not required for Edinburgh.

 


Notes from Today's Registry Abstraction and Vault discussion

Goodell, Leonard <leonard.goodell@...>
 

All,
  Below are my notes from today’s discussion. Please add anything I may have missed. I added another option (highlighted below) that I thought of after our discussion.
 
Trevor, please add me to next Core WG meeting agenda to review this and talk about having a combined Core/Security WG meeting early January to try to close on this.
 
Thanks!
   Lenny
 
-----------------------
Notes:
 
  • Vault
  • 3rd party app also from HashiCorp
  • Tightly coupled to Consul
  • Uses Consul features
  • Fail over
  • Clustering
  • We can’t insert an abstraction layer between 3rd party apps (Vault) and Consul.
 
  • What about abstracting use of Vault for getting values that are stored as secrets so micro services don’t have to be aware/care where the values come from.
  • How do we know which values are in Vault vs which values are in the Registry?
  • One approach is to have the value in the Registry indicate that it is actually a secret in Vault. Then go to Vault for the value.
  • Add a “secrets” path to the configuration like how we are looking at separating out “writeable”
  • Use of Vault vs Registry is determined by the configuration path.
  • If Vault is not enable, defaults to getting “secrets” in plain text from Registry’s …/secrets path
  • FYI, thought of this as I was typing up these notes… 😉
  • What about storing all values in Vault, if enabled?
  • Abstraction must know if Vault is enable.
  • No watcher capability in Vault
  • There might be a way to implement watcher capability via plug-in for Vault’s secrets engine
  • Could keep “writable” section in Registry so still have watcher capability. Assume these never need to be true secrets
  • Use of Vault vs Registry is determined by the configuration path.
  • Recap of Options:
  • Mixed data between Vault & Registry. Some unique value indicates stored as secret in Vault
  • Separate out secrets into “secrets” section/path so they come from Vault when it is enabled.
  • All values store as secrets Vault. No watch capability, implement plug-in for secret engine?
  • All non-writeable stored as secrets in Vault. Writable stored in Registry so they can be watched.
  • Other opens to discuss further
  • How are secrets “put” into Vault?
  • Pre-populated in some other manner?
  • Part of Seed service?
  • Add this capability to Abstraction?
  • Are we expecting a Registry UI to be exposed in production that allows config value changes?
  • Security concerns??
  • What is the approach for implementing this Registry Abstraction and Vault for Edinburgh?
  • Abstraction first so it can be used in the one service targeted for Vault
  • Abstraction must then have support for Vault
  • Separate efforts, Crawl Phase?
  • Abstraction doesn’t initially have support for Vault
  • Vault usage in target micro service is implemented directly against Vault for values that are known to be secrets.
  • Walk phase could a support for Vault to the Abstraction, but not required for Edinburgh.


Hardware-based Secure Storage Design Document - Draft

David Ferriera
 

Hi All,

    I have uploaded the design document we have been discussing in the past two Security WG meetings.  It is in our google drive collaboration folder here.

    If you do not have access to the folder, submit the request when you are denied access and we will approve.

   I have also posted a PDF version of the document to the Security WG Wiki page (at the bottom in the Documents section).

Thanks,
-David

David Ferriera | Forgerock
Senior Director, Cloud Technology | Office of the CTO
m +1 408.454.8189 | w forgerock.com


Container Security

Gregg, James R
 
Edited

Per my conversation with David @ the Edinburgh F2F, here’s a tool we have begun to look at as part of our CI/CD pipeline. There’s a recent PR that now adresses the gap around filtering the scan to a specific container. We also only focus on the relevants checks related to the Docker container but can also look at the underlying host for black box testing. 
https://github.com/docker/docker-bench-security

Thank You, 
James Gregg 
Intel Corporation / IOTG RSD


Re: Potential security issues with EdgeX

Alexandre Courouble <acourouble@...>
 

Thank you for your response David. We are looking for ways to get involved with EdgeX, so this might be a good starting point.

 

Malini will be in Edinburgh for the F2F next week. I’m sure you two meetup.

 

Thanks,

--

Alex Courouble

Member of Technical Staff – Open Source Engineer

VMware Open Source Technology Center

 

From: David Ferriera <david.ferriera@...>
Date: Thursday, October 18, 2018 at 1:32 PM
To: Alexandre Courouble <acourouble@...>, "edgex-tsc-security@..." <edgex-tsc-security@...>
Cc: Malini Bhandaru <mbhandaru@...>
Subject: Re: Potential security issues with EdgeX

 

Hi Alex,

 

    Thank you for the effort.  We welcome contributions.  We are always shorthanded in the security group.

 

   Code analysis has been on our list since the beginning.  If you have the resources to help us fix these and others, that would be great.  We would like to have this function be a part of our ongoing release process.

 

   Will you or any of your team be at the Edinburgh F2F next week?  If not, I will put this topic on one of our weekly meetings and invite you to discuss.

 

Thanks,

-David

 

David Ferriera | Forgerock

Senior Director, Cloud Technology | Office of the CTO

m +1 408.454.8189 | w forgerock.com

 

On October 16, 2018 at 4:17:11 PM, Alexandre Courouble (acourouble@...) wrote:

Hello,

 

Gosec (https://github.com/securego/gosec)  is a tool that parses the source code and looks for security anti-patterns.

 

We ran gosec against the EdgeX-go source code and uncovered a series of potential vulnerabilities including but not limited to:

 

  • Blacklisted import crypto/sha1: weak cryptographic primitive
  • Potential file inclusion via variable
  • Expect file permissions to be 0600 or less

 

I’ve attached the gosec output to this email.

 

Do these vulnerabilities seem critical to you? If so, we would love to contribute fixes.

 

We would like to know how we should proceed further?

 

Potentially we could integrate gosec into the build pipeline.

 

Best regards,

-- 

Alex Courouble

Member of Technical Staff – Open Source Engineer

VMware Open Source Technology Center


Re: Potential security issues with EdgeX

Beau Frusetta
 

We can potentially help out in regards to code analysis. Let’s chat more next week in Edinburgh…

 

From: EdgeX-TSC-Security@... [mailto:EdgeX-TSC-Security@...] On Behalf Of David Ferriera
Sent: Thursday, October 18, 2018 13:32
To: Alexandre Courouble <acourouble@...>; edgex-tsc-security@...
Cc: Malini Bhandaru <mbhandaru@...>
Subject: Re: [Edgex-tsc-security] Potential security issues with EdgeX

 

Hi Alex,

 

    Thank you for the effort.  We welcome contributions.  We are always shorthanded in the security group.

 

   Code analysis has been on our list since the beginning.  If you have the resources to help us fix these and others, that would be great.  We would like to have this function be a part of our ongoing release process.

 

   Will you or any of your team be at the Edinburgh F2F next week?  If not, I will put this topic on one of our weekly meetings and invite you to discuss.

 

Thanks,

-David

 

David Ferriera | Forgerock

Senior Director, Cloud Technology | Office of the CTO

m +1 408.454.8189 | w forgerock.com

 

On October 16, 2018 at 4:17:11 PM, Alexandre Courouble (acourouble@...) wrote:

Hello,

 

Gosec (https://github.com/securego/gosec)  is a tool that parses the source code and looks for security anti-patterns.

 

We ran gosec against the EdgeX-go source code and uncovered a series of potential vulnerabilities including but not limited to:

 

  • Blacklisted import crypto/sha1: weak cryptographic primitive
  • Potential file inclusion via variable
  • Expect file permissions to be 0600 or less

 

I’ve attached the gosec output to this email.

 

Do these vulnerabilities seem critical to you? If so, we would love to contribute fixes.

 

We would like to know how we should proceed further?

 

Potentially we could integrate gosec into the build pipeline.

 

Best regards,

-- 

Alex Courouble

Member of Technical Staff – Open Source Engineer

VMware Open Source Technology Center


Re: Potential security issues with EdgeX

David Ferriera
 

Hi Alex,

    Thank you for the effort.  We welcome contributions.  We are always shorthanded in the security group.

   Code analysis has been on our list since the beginning.  If you have the resources to help us fix these and others, that would be great.  We would like to have this function be a part of our ongoing release process.

   Will you or any of your team be at the Edinburgh F2F next week?  If not, I will put this topic on one of our weekly meetings and invite you to discuss.

Thanks,
-David

David Ferriera | Forgerock
Senior Director, Cloud Technology | Office of the CTO
m +1 408.454.8189 | w forgerock.com

On October 16, 2018 at 4:17:11 PM, Alexandre Courouble (acourouble@...) wrote:

Hello,

 

Gosec (https://github.com/securego/gosec)  is a tool that parses the source code and looks for security anti-patterns.

 

We ran gosec against the EdgeX-go source code and uncovered a series of potential vulnerabilities including but not limited to:

 

  • Blacklisted import crypto/sha1: weak cryptographic primitive
  • Potential file inclusion via variable
  • Expect file permissions to be 0600 or less

 

I’ve attached the gosec output to this email.

 

Do these vulnerabilities seem critical to you? If so, we would love to contribute fixes.

 

We would like to know how we should proceed further?

 

Potentially we could integrate gosec into the build pipeline.

 

Best regards,

-- 

Alex Courouble

Member of Technical Staff – Open Source Engineer

VMware Open Source Technology Center


Re: Potential security issues with EdgeX

Malini Bhandaru
 

Agree Benjamin. We were under the impression the security mailing list was more restricted.

Does EdgeX have such a limited mailing list for security issues? If not we need to create one.

 

Regards

Malini

 

From: <EdgeX-TSC-Security@...> on behalf of Benjamin Cabé <benjamin.cabe@...>
Date: Wednesday, October 17, 2018 at 2:31 AM
To: "edgex-tsc-security@..." <edgex-tsc-security@...>
Subject: Re: [Edgex-tsc-security] Potential security issues with EdgeX

 

FWIW reporting security vulnerabilities on a *public* mailing list certainly sounds like a security anti-pattern as well…

 

On 17 Oct 2018, at 01:17, Alexandre Courouble <acourouble@...> wrote:

 

Hello,

 

Gosec (https://github.com/securego/gosec)  is a tool that parses the source code and looks for security anti-patterns.

 

We ran gosec against the EdgeX-go source code and uncovered a series of potential vulnerabilities including but not limited to:

 

  • Blacklisted import crypto/sha1: weak cryptographic primitive
  • Potential file inclusion via variable
  • Expect file permissions to be 0600 or less

 

I’ve attached the gosec output to this email.

 

Do these vulnerabilities seem critical to you? If so, we would love to contribute fixes.

 

We would like to know how we should proceed further?

 

Potentially we could integrate gosec into the build pipeline.

 

Best regards,

-- 

Alex Courouble

Member of Technical Staff – Open Source Engineer

VMware Open Source Technology Center

<results.json>