Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
On 9/15/23 2:59 AM, Marta Rybczynska wrote: On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle wrote: * Visibility of the security work of the YP There is much work on security in the YP, but it lacks visibility. Is there a common nexus for this work? eg. do most of the folks who are doing security work tend to congregate on the security sublist? Security means different things to different people. I.e. 1) Secure design - Is the system designed to have security services, if so are the defaults setup to both be appropriate and also functional? 2) Additional security software - i.e. meta-security, what additional software can be available to enhance security design/implementation of the system 3) Security (bug) response - This is where I see a lack of common nexus for work. We don't have a good place to discuss CVE specific information. Now the question really is, should we have a separate space. CVEs are just bugs. Bugs are usually worked on via the main mailing list. So that argument says no, we shouldn't have a special list. BUT the perception is CVEs are "special", so maybe a list specifically to discuss the ramifications of a CVE, fix/mitigation strategy or similar would make sense -- keeping actual bug fixes to the main mailing list? It might e interesting to have opinion on people who are submitting CVE fixes... Would keeping that discussion in a separate place be helpful? Ya, a security mailing list can be interesting for those types of discussions, but ultimately the code needs to go to the regular pull list -- which depending on the project (and level of discussions) it may make sense just to have those discussions on the regular list. It's tricky, and I'm not sure what the right answer is here. * SRTool We might decide to use it again. It allows one to do much but requires constant commitment. I think I passed over the wiki pages and presentations for SRTool once, a while ago. But I didn't pay much attention at the time because it wasn't clear *what it did*. After reviewing it again, I think it might be the kind of tooling I've been searching for to help my team coordinate our CVE response work. I'll test it out and see if it is something I can use/contribute towards. SR Tool requires constant feeding and maintenance from staff, at a minimum to do initial triage work. This means we need a small group of individuals who can take the new items (and changes to existing) and comment on a regular (daily) basis. This is the part we've not been terribly successful in the past. People are great at delivering patches, but trying to do the proactive (before cve-checker) evaluation of CVEs is an activity that often feels like busy work, so it's easy to get behind on and never catch up. I would love to see the project use SR Tool to manage CVE information, (bugzilla is where the bugs need to be managed and processed), as well as cve-checker to be able to continue to feed information or what we believe the current state of things are. This combination would give us per-emptive notification of new items (SR-Tool), and late validation of items (cve-checker) on the perceived state of things. SRTools code base (https://git.yoctoproject.org/srtool) has seen no changes for 4 years. If we decide to use, we'll also need to maintain the tool. Is Windriver going to update the fork? David (adding in copy), do you have any information? Otherwise we would need to maintain our version, and update to the code to take into account how the world have changed. For example, with the CVE v5 JSON, using the CVE database directly for the feed of new CVE list makes more sense than using NVD, for example. For the reason of performance and delay. When SRTool was developed, that data wasn't available. Last time I used it was almost exactly 4 years ago. The tool itself is pretty simple, it's the data import/export that is the complex bit(s). Maybe the lesson here isn't to use SR Tool, but take some of the concepts from it and maybe implement something ourselves (in the future). The key things are: 1) Automatic import from external CVE/Security sources (not all security items are CVEs) 2) A way to triage the information, and do LOCAL edits of the information - Way for the user to query what's new? - Way for the user to query what's changed since last time? - Way for the user to query other things... - Local edit could be YP 'status' - Local edit could add public OR private information about a given item - Local edits should be able to link a problem with a bug and release - Local edits should be able to TRACK progress of a bug - Local edits to CREATE security items not otherwise known (either YP specific, or based on bug reports, etc) - A way to temporarily set things as 'restricted', only for specific people to view until it's public information. 3) Way to generate reports for users. - General report - CVE Specific report 3)
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle wrote: > >> * Visibility of the security work of the YP > >> > >> There is much work on security in the YP, but it lacks visibility. > > > > Is there a common nexus for this work? eg. do most of the folks who are > > doing security work tend to congregate on the security sublist? > > Security means different things to different people. I.e. > > 1) Secure design > - Is the system designed to have security services, if so are the defaults > setup to both be appropriate and also functional? > > 2) Additional security software > - i.e. meta-security, what additional software can be available to enhance > security design/implementation of the system > > 3) Security (bug) response > - This is where I see a lack of common nexus for work. We don't have a > good > place to discuss CVE specific information. Now the question really is, should > we have a separate space. CVEs are just bugs. Bugs are usually worked on via > the main mailing list. So that argument says no, we shouldn't have a special > list. BUT the perception is CVEs are "special", so maybe a list specifically > to > discuss the ramifications of a CVE, fix/mitigation strategy or similar would > make sense -- keeping actual bug fixes to the main mailing list? > It might e interesting to have opinion on people who are submitting CVE fixes... Would keeping that discussion in a separate place be helpful? > >> > >> * SRTool > >> > >> We might decide to use it again. It allows one to do much but requires > >> constant commitment. > > > > I think I passed over the wiki pages and presentations for SRTool once, > > a while ago. But I didn't pay much attention at the time because it > > wasn't clear *what it did*. > > > > After reviewing it again, I think it might be the kind of tooling I've > > been searching for to help my team coordinate our CVE response work. > > I'll test it out and see if it is something I can use/contribute towards. > > SR Tool requires constant feeding and maintenance from staff, at a minimum to > do > initial triage work. This means we need a small group of individuals who can > take the new items (and changes to existing) and comment on a regular (daily) > basis. This is the part we've not been terribly successful in the past. > People > are great at delivering patches, but trying to do the proactive (before > cve-checker) evaluation of CVEs is an activity that often feels like busy > work, > so it's easy to get behind on and never catch up. > > I would love to see the project use SR Tool to manage CVE information, > (bugzilla > is where the bugs need to be managed and processed), as well as cve-checker to > be able to continue to feed information or what we believe the current state > of > things are. This combination would give us per-emptive notification of new > items (SR-Tool), and late validation of items (cve-checker) on the perceived > state of things. SRTools code base (https://git.yoctoproject.org/srtool) has seen no changes for 4 years. If we decide to use, we'll also need to maintain the tool. Is Windriver going to update the fork? David (adding in copy), do you have any information? Otherwise we would need to maintain our version, and update to the code to take into account how the world have changed. For example, with the CVE v5 JSON, using the CVE database directly for the feed of new CVE list makes more sense than using NVD, for example. For the reason of performance and delay. When SRTool was developed, that data wasn't available. Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187660): https://lists.openembedded.org/g/openembedded-core/message/187660 Mute This Topic: https://lists.openembedded.org/mt/101340097/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 6:00 PM Alex Stewart wrote: > > Thanks for driving this Marta. Internally and externally, it feels like > we're just on the cusp of everyone *suddenly caring* about our security > response strategy. So it's good to see that we're making moves in that > direction. > Thank you Alex! > > More responses inline. > > On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: > > * CVEs: Visibility if YP is vulnerable or not > > > > People want to be able to check/look up a specific CVE; it might be a > > CVE unrelated to YP > > (eg. package not included, Windows issue). The cve-checker result is a > > part of the solution, but people also want to know which CVEs do not > > apply. > > I'm not sure I understand this usecase. Is there a reason those people > can't/won't just lookup the CVE on the NIST site? > Mark's answer is clarifying that. I'll add that this is a requirement I have heard from multiple sources. People might look up CVE/NIST, but that takes time if you are required to look up all CVEs. If we have common data, we avoid duplicate work. > > * CVEs: synchronization of the work on fixes > > > > Currently, there is no synchronization; multiple parties might be > > working on the same fix while nobody is working on another. There > > might be duplication of work. > > Ross has https://wiki.yoctoproject.org/wiki/CVE_Status > > Has there been any discussion of adopting the OpenVEX document standard > that the Chainguard guys are putting together? [1] It seems like the VEX > use-cases align well with our needs around tracking and coordinating CVE > response between YP member and individual developers. > We might decide to use it. However, openVEX a way to output the data we have/will have (the conclusion), not a way to sync up the work. > > > * Triaging of security issues > > > > Related to CVE fixes and includes issues reported directly to the YP. > > Some issues are more likely to be serious for embedded products > > (attack by network), so not all has the same priority. > > I'll note here that some of us are sinners and do actually support > network-attached (and internet-attached) embedded devices. :) > > But the greater point of OS vendors being able to triage and assign > vendor-specific severities to incoming issues is absolutely important to > my use-cases. > This is an important point. YP is generic and YP assesment of severity might be different than the one from a vendor. It means that our process should be flexible enough that a vendor can take the data and assign their own severity. > > > > * Visibility of the security work of the YP > > > > There is much work on security in the YP, but it lacks visibility. > > Is there a common nexus for this work? eg. do most of the folks who are > doing security work tend to congregate on the security sublist? I'd like to know :) This thread is a big cross-post (and sorry for that, but I need to reach the whole audience), for further discussions I'd like to invite all to a dedicate list. > > > * Additional tooling > > > > We could add additional tooling: a template on how to add cve-check to > > the CI (possibly > > a different one than the autobuilder), analyze the result, and extend > > our tooling to their layers... > > It is also related to the "Architecture" topic below. > > Can you expand on what you mean here? Is this usecase about extending > the existing tooling into the generic CI processes that YP members are > using, or about expanding the tooling in the YP's indigenous CI? This is a requirement assembling multiple ones. Many people mentioned that additional tooling would be needed and/or helpful. A CI template is an example here. I'm interested in your list of tooling that would be important or useful to have. Preferably related to processes that are currently done in-house and that we can make more generic and share the work. > > > * Presence on pre-notification lists and receiving information before > > the vulnerability gets public > > > > YP currently depends on public data. Principal distributions receive > > the information before > > a vulnerability becomes public. It requires (in short) private > > reporting, a security team, and a track > > of excellent security record. > > > > * Becoming a CNA (be able to assign CVEs) > > > > Needed if we want to assign CVEs to the software of the YP, like > > autobuilder, Toaster etc. > > I'm also interested in this, as the maintainer of our opkg fork. So far, > I haven't had to respond to a CVE against the project, but that won't > last forever. CVEs against a fork, this is an interesting use-case... Noted :) Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187654): https://lists.openembedded.org/g/openembedded-core/message/187654 Mute This Topic: https://lists.openembedded.org/mt/101340097/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe:
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 2:33 PM Mikko Rapeli wrote: > > Hi, > > On Wed, Sep 13, 2023 at 01:52:19PM +0200, Marta Rybczynska wrote: > > Hello, > > I've been working recently on collecting what works and what doesn't > > in YP security processes. The goal is to go forward and define an > > actionable strategy! > > > > Today, I'd like to share with you the summary of what I have heard as > > needs from several people (those in Cc:). > > > > I want the community to comment and tell us what you find important > > and what you'd like to see added or changed from this list. > > Since most users take poky reference distro and combine it with a number > of open source and closed source BSP and other meta layers and build > systems to produce SW for products, they also need documentation and tooling > so that they can replicate the Yocto Project security processes and use the > available tools. Do you also mean that we should make sure Poky follows security best practices? Noted the point on documenting the way process works/will work so other teams can extend it to their layer. > > I think most of the documentation around the tools and processes is in place > already. > Having maintained and shipped from a non-maintained poky branch, I can just > say > thank you to all who participated in the upstream work to get security > vulnerability > detection and fixing possible! > Out of curiosity, what have you backported? cve-check? LTS work? > That being said, extending the CVE scanning and status tracking work to > include more > open source layers would be nice both for the maintainers and for the users > of those > layers. Using some random old branch of meta-foo may not be so safe. Maybe add > this data to layer-index? > We have Yocto Project Compatible already. Do we need something else? Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187653): https://lists.openembedded.org/g/openembedded-core/message/187653 Mute This Topic: https://lists.openembedded.org/mt/101335537/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
On 9/13/23 11:00 AM, Alex Stewart wrote: Thanks for driving this Marta. Internally and externally, it feels like we're just on the cusp of everyone *suddenly caring* about our security response strategy. So it's good to see that we're making moves in that direction. In general, this list looks complete to me. I'm primarily interested in the response coordination, triage, and tracking usecases. Those are the biggest pain points for my team, at the moment. And that is primarily driven by a lack of tooling. More responses inline. On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: [You don't often get email from rybczynska=gmail@lists.openembedded.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hello, I've been working recently on collecting what works and what doesn't in YP security processes. The goal is to go forward and define an actionable strategy! Today, I'd like to share with you the summary of what I have heard as needs from several people (those in Cc:). I want the community to comment and tell us what you find important and what you'd like to see added or changed from this list. * CVEs: Visibility if YP is vulnerable or not People want to be able to check/look up a specific CVE; it might be a CVE unrelated to YP (eg. package not included, Windows issue). The cve-checker result is a part of the solution, but people also want to know which CVEs do not apply. I'm not sure I understand this usecase. Is there a reason those people can't/won't just lookup the CVE on the NIST site? Management goes to an engineer and says "Customer XYZ says we need a statement if CVE-2024-12345 affects us. Can you please comment?" Engineer goes to the Yocto Project "list", and looks the number up and doesn't find it. Does this mean we're affects? We're not affected? We were affected, but it's been fixed (if so when?), etc? So then they have to go to NIST, look at the CVE, find the information and do the evaluation if Yocto Project is affected. Instead what (I have observed) is that people who like to go to a single list (for Yocto Project) information, look up a CVE and get a clear statement of: This affects us, this does not affect us, we did not evaluate it or it was fixed by commit XYZ in branch Then if the item is "not evaluated", they can THEN got to NIST for their own evaluation. This saves a huge amount of time for people who are regularly requested to respond to these messages. * CVEs: synchronization of the work on fixes Currently, there is no synchronization; multiple parties might be working on the same fix while nobody is working on another. There might be duplication of work. Ross has https://wiki.yoctoproject.org/wiki/CVE_Status Has there been any discussion of adopting the OpenVEX document standard that the Chainguard guys are putting together? [1] It seems like the VEX use-cases align well with our needs around tracking and coordinating CVE response between YP member and individual developers. I've been considering it for my internal use for a while. And also considering replacing the existing cve_check output JSON with OpenVEX, once it has stabilized. [1] https://github.com/openvex/spec * Triaging of security issues Related to CVE fixes and includes issues reported directly to the YP. Some issues are more likely to be serious for embedded products (attack by network), so not all has the same priority. I'll note here that some of us are sinners and do actually support network-attached (and internet-attached) embedded devices. :) But the greater point of OS vendors being able to triage and assign vendor-specific severities to incoming issues is absolutely important to my use-cases. * Private security communication A way to send a notification of a non-public security issue. For researchers, other projects etc. The security alias exists, but only some people know about its existence. * Visibility of the security work of the YP There is much work on security in the YP, but it lacks visibility. Is there a common nexus for this work? eg. do most of the folks who are doing security work tend to congregate on the security sublist? Security means different things to different people. I.e. 1) Secure design - Is the system designed to have security services, if so are the defaults setup to both be appropriate and also functional? 2) Additional security software - i.e. meta-security, what additional software can be available to enhance security design/implementation of the system 3) Security (bug) response - This is where I see a lack of common nexus for work. We don't have a good place to discuss CVE specific information. Now the question really is, should we have a separate space. CVEs are just bugs. Bugs are usually worked on via the main mailing list. So that argument says no, we shouldn't have a special list. BUT the perception is CVEs are "special", so maybe a
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
Thanks for driving this Marta. Internally and externally, it feels like we're just on the cusp of everyone *suddenly caring* about our security response strategy. So it's good to see that we're making moves in that direction. In general, this list looks complete to me. I'm primarily interested in the response coordination, triage, and tracking usecases. Those are the biggest pain points for my team, at the moment. And that is primarily driven by a lack of tooling. More responses inline. On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: [You don't often get email from rybczynska=gmail@lists.openembedded.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hello, I've been working recently on collecting what works and what doesn't in YP security processes. The goal is to go forward and define an actionable strategy! Today, I'd like to share with you the summary of what I have heard as needs from several people (those in Cc:). I want the community to comment and tell us what you find important and what you'd like to see added or changed from this list. * CVEs: Visibility if YP is vulnerable or not People want to be able to check/look up a specific CVE; it might be a CVE unrelated to YP (eg. package not included, Windows issue). The cve-checker result is a part of the solution, but people also want to know which CVEs do not apply. I'm not sure I understand this usecase. Is there a reason those people can't/won't just lookup the CVE on the NIST site? * CVEs: synchronization of the work on fixes Currently, there is no synchronization; multiple parties might be working on the same fix while nobody is working on another. There might be duplication of work. Ross has https://wiki.yoctoproject.org/wiki/CVE_Status Has there been any discussion of adopting the OpenVEX document standard that the Chainguard guys are putting together? [1] It seems like the VEX use-cases align well with our needs around tracking and coordinating CVE response between YP member and individual developers. I've been considering it for my internal use for a while. And also considering replacing the existing cve_check output JSON with OpenVEX, once it has stabilized. [1] https://github.com/openvex/spec * Triaging of security issues Related to CVE fixes and includes issues reported directly to the YP. Some issues are more likely to be serious for embedded products (attack by network), so not all has the same priority. I'll note here that some of us are sinners and do actually support network-attached (and internet-attached) embedded devices. :) But the greater point of OS vendors being able to triage and assign vendor-specific severities to incoming issues is absolutely important to my use-cases. * Private security communication A way to send a notification of a non-public security issue. For researchers, other projects etc. The security alias exists, but only some people know about its existence. * Visibility of the security work of the YP There is much work on security in the YP, but it lacks visibility. Is there a common nexus for this work? eg. do most of the folks who are doing security work tend to congregate on the security sublist? * Documentation Related to visibility. We need easy-to-find documentation of subjects like submitting a CVE fix, reporting a private issue, and how our processes work... This documentation should address people who are not regular contributors. Very important. * Additional tooling We could add additional tooling: a template on how to add cve-check to the CI (possibly a different one than the autobuilder), analyze the result, and extend our tooling to their layers... It is also related to the "Architecture" topic below. Can you expand on what you mean here? Is this usecase about extending the existing tooling into the generic CI processes that YP members are using, or about expanding the tooling in the YP's indigenous CI? * Architecture work Security if more than CVE fixes. We also have what is happening in meta-security: hardening, compiler option, secure package configuration, use of code coverage tools, and so on * SRTool We might decide to use it again. It allows one to do much but requires constant commitment. I think I passed over the wiki pages and presentations for SRTool once, a while ago. But I didn't pay much attention at the time because it wasn't clear *what it did*. After reviewing it again, I think it might be the kind of tooling I've been searching for to help my team coordinate our CVE response work. I'll test it out and see if it is something I can use/contribute towards. * Presence on pre-notification lists and receiving information before the vulnerability gets public YP currently depends on public data. Principal distributions receive the information before a vulnerability becomes public. It requires (in short) private reporting, a security team, and a
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
Hi, On Wed, Sep 13, 2023 at 01:52:19PM +0200, Marta Rybczynska wrote: > Hello, > I've been working recently on collecting what works and what doesn't > in YP security processes. The goal is to go forward and define an > actionable strategy! > > Today, I'd like to share with you the summary of what I have heard as > needs from several people (those in Cc:). > > I want the community to comment and tell us what you find important > and what you'd like to see added or changed from this list. Since most users take poky reference distro and combine it with a number of open source and closed source BSP and other meta layers and build systems to produce SW for products, they also need documentation and tooling so that they can replicate the Yocto Project security processes and use the available tools. In the best case downstream users are on poky master branch or one of the maintained LTS branches, but they can also be stuck on a non-LTS branch due to BSP or other technical, contractual or even purely political reasons. Having a description of the processes and tools and best practices helps, and if needed they can for example backport the needed tooling changes to their version to help or kick off in the maintenance effort, just like how upstream LTS branches are managed. I think most of the documentation around the tools and processes is in place already. Having maintained and shipped from a non-maintained poky branch, I can just say thank you to all who participated in the upstream work to get security vulnerability detection and fixing possible! poky seems well maintained and serves as an example to everyone wether open source or not. That being said, extending the CVE scanning and status tracking work to include more open source layers would be nice both for the maintainers and for the users of those layers. Using some random old branch of meta-foo may not be so safe. Maybe add this data to layer-index? Cheers, -Mikko > * CVEs: Visibility if YP is vulnerable or not > > People want to be able to check/look up a specific CVE; it might be a > CVE unrelated to YP > (eg. package not included, Windows issue). The cve-checker result is a > part of the solution, but people also want to know which CVEs do not > apply. > > * CVEs: synchronization of the work on fixes > > Currently, there is no synchronization; multiple parties might be > working on the same fix while nobody is working on another. There > might be duplication of work. > Ross has https://wiki.yoctoproject.org/wiki/CVE_Status > > * Triaging of security issues > > Related to CVE fixes and includes issues reported directly to the YP. > Some issues are more likely to be serious for embedded products > (attack by network), so not all has the same priority. > > * Private security communication > > A way to send a notification of a non-public security issue. For > researchers, other projects etc. > The security alias exists, but only some people know about its existence. > > * Visibility of the security work of the YP > > There is much work on security in the YP, but it lacks visibility. > > * Documentation > > Related to visibility. We need easy-to-find documentation of subjects > like submitting a CVE fix, > reporting a private issue, and how our processes work... This > documentation should address people who are not regular contributors. > > * Additional tooling > > We could add additional tooling: a template on how to add cve-check to > the CI (possibly > a different one than the autobuilder), analyze the result, and extend > our tooling to their layers... > It is also related to the "Architecture" topic below. > > * Architecture work > > Security if more than CVE fixes. We also have what is happening in > meta-security: hardening, compiler option, > secure package configuration, use of code coverage tools, and so on > > * SRTool > > We might decide to use it again. It allows one to do much but requires > constant commitment. > > * Presence on pre-notification lists and receiving information before > the vulnerability gets public > > YP currently depends on public data. Principal distributions receive > the information before > a vulnerability becomes public. It requires (in short) private > reporting, a security team, and a track > of excellent security record. > > * Becoming a CNA (be able to assign CVEs) > > Needed if we want to assign CVEs to the software of the YP, like > autobuilder, Toaster etc. > > Kind regards, > Marta > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187588): https://lists.openembedded.org/g/openembedded-core/message/187588 Mute This Topic: https://lists.openembedded.org/mt/101335537/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
