\n\n\n
A few months ago I wrote “Why We CVE”, wherein I covered the general intention of the CVE program, and more specifically the reasons why F5 publishes CVEs. After publishing that article the rusty, creaky mental wheels started turning, remembering the old “Who, What, Where, When, Why, and How”. I thought I might answer those as well. I’ll be leaving ‘How’ as a possible future article. I have been giving that some thought, and what it might entail – maybe how F5 runs out processes internally, or perhaps a general look at how the CVE system works with CVE Services 2.1, CVE JSON 5.0, CNAs, Root CNAs, etc. But that’s a story for another time.
\n
Today I intend to attempt to answer the Who, What, Where, and When questions.
\n\n
I touched on this briefly last time. As I said then, F5 officially joined the CVE program as a CNA in late 2016. Joining the program doesn’t magically publish CVEs though. Someone, or some group, must ultimately do the work that goes into being a CNA and publishing CVEs. While my primary responsibility as an F5 SIRT Principal Security Engineer is coordinating our vulnerability efforts, and acting as F5’s primary external contact with CVE.org, VINCE, etc., I’m just one member of the team – and this very much is a team effort.
Within F5 the effort to diagnose, document, track, and publish security issues is the responsibility of the F5 SIRT. Ownership of different security issues is distributed amongst the core team, and each Security Engineer shepherds their issues through our processes from initial discovery all the way to readying the Security Advisory for publication. Everyone who has published under the ‘F5 SIRT’ tag here on DevCentral plays a role, and I’m glad to be part of such a great team.
\n
Of course, other teams within F5 are also involved – Product Engineering creates the fixes, Digital Services works with us to author the Security Advisories, many groups review those before publication, etc. – but ownership and responsibility resides with the F5 SIRT.
\n\n
There are a couple of ways to interpret ‘what’ – so first, what do we CVE?
\n
As mentioned last time, each CNA has a ‘Scope’ statement, which defines what the CNA is responsible for within the CVE program. This is F5’s statement:
\n
All F5 products and services, commercial and open source, which have not yet reached End of Technical Support (EoTS). All legacy acquisition products and brands including, but not limited to, NGINX, Shape Security, Volterra, and Threat Stack. F5 does not issue CVEs for products which are no longer supported.
\n
So that establishes the overall scope for which products and services we’re responsible for when it comes to issuing CVEs. That’s a broad area, but this is further refined by K4602: Overview of the F5 security vulnerability response policy.
\n
F5 assigns Common Vulnerability and Exposures (CVEs) and publishes security advisories for all vulnerability categories, from Low to Critical.
\n
Additionally, F5 publishes security advisories for security exposures, which do not affect the confidentiality, integrity, and availability (CIA) of the F5 product, but may impact the CIA of one of the following:
\n
\n- Services or network traffic processed by the F5 product
\n- Confidentiality of data cached on the F5 product
\n
\n
Security exposures are generally dependent on configuration and use of the F5 device. Therefore, F5 cannot produce an accurate CVSS score or severity for security exposures. F5 recommends customers treat security exposures as a high priority and evaluate the specific severity of these issues in their own environment.
\n
An important item to call out from that policy is that F5 publishes Security Advisories for both CVEs and what we call Security Exposures. The way we distinguish these is via the CIA Triad. For those not familiar with infosec terminology, the ‘CIA’ refers to Confidentiality, Integrity, and Availability. The very high-level overview is that a Confidentiality impact means information is seen by those who should not be able to see it, an Integrity impact means someone is able to change information they should not be able to change, and an Availability impact means a degradation, or complete loss, of a service to legitimate users. Yes, that’s extremely simplified, feel free to leave a comment – but it will suffice for our needs here.
\n
How does F5 distinguish between a CVE and a Security Exposure? We look at where the CIA impact resides. If the CIA of the F5 product or service itself is impacted, then we consider that a vulnerability in need of a CVE. Leaking private keys, modifying the configuration, denial of services attacks, etc. We know the full scope of the issue and can provide an accurate CVSS score and vector, available mitigations, etc. These are relatively straight-forward.
\n
We use Security Exposures when a defect in the F5 product or service causes a CIA impact that is not against the F5 product or service itself, but rather somewhere else in the network. An example of this would be a defect in the WAF engine that causes traffic that is rightfully expected to be blocked to be allowed through. The backend systems are now being exposed to malicious traffic. The CIA impact is against those backend systems, but the flaw allowing this is in F5’s product. As every network is different, there are many unknowns and the CVSS score and vector would vary.
\n
We publish these issues because, as I like to say, “Our customers can’t make informed decisions about their networks if we don’t inform them.” We are advocates for the customer, and making good security decisions requires knowing all relevant information. Part of our role, and duty, is providing that information.
\n
The other way to interpret ‘what’ is – what do we say when we CVE?
\n
This is covered in more detail by our Vulnerability Disclosure Policy within K4602:
\n
F5 is committed to responsibly disclosing information that contains sufficient detail about the vulnerability in question, such as the CVSS score and vector. This information is intended to help customers understand the impact, severity, potential mitigations, and software fixes related to the vulnerability when such information is available.
\n
F5 does not provide the following information:
\n
\n- Example exploit code or reproduction information
\n- The number of customers or sites affected
\n- Any information F5 regards as confidential
\n
\n
We strive to provide enough information to be useful to our customers, and the broader infosec community, while not providing information that might aid those with malicious intent. That is a fine line to walk, and we tend to err on the side of caution, but we do try to provide the information necessary to evaluate the issue and determine if a given system is impacted and needs to be remediated.
\n
We have refined our approach to Security Advisories over the years and will continue to do so. Over time we introduced CVSS and CWE. We’ve updated the document structure, standardized language, and made many other changes based on the feedback received. We are always open to feedback, and there is a field for that at the bottom of every Security Advisory. Yes, that feedback is read.
\n\n
This may be the simplest question to answer; you can find all F5 Security Advisories on MyF5. More specifically, you can see all new Security Advisories. Note that includes F5’s first-party issues as well as any third-party CVE’s we’ve responded to, and it covers both CVEs and Security Exposures. If you wish to be notified of new security announcements, we have two mailing lists – F5 Security Announcements and NGINX Security Announcements. We do strongly encourage everyone to subscribe to the appropriate list(s) to receive security notifications.
\n
We normally have an RSS feed option as well, documented at K9957: Creating a custom RSS feed to view new and updated documents – but that is currently K9957: RSS feed service interruption as the RSS functionally was lost in a recent platform change for MyF5. RSS functionality will be returning to MyF5, but we don’t have a date for restoration that I can share. I recommend checking K000092546: What's new and planned for MyF5 for updates.
\n
Of course, as participants in the CVE program, all CVEs published by F5 can also be found through CVE.org, as well as downstream providers such as NVD, etc. You can find our CVEs wherever fine CVEs are distributed. Do note that this will only be CVEs; Security Exposures are only distributed directly by F5.
\n\n
Actually, this is the simplest question to answer - K12201527: Overview of Quarterly Security Notifications. Done.
\n
OK, more seriously, we do four scheduled disclosures a year – the aptly named Quarterly Security Notifications (QSN). Each QSN ‘rolls up’ all fixes released since the last QSN. At the time I’m writing this our next QSN is May 3, 2023. With each QSN the next day is also published, and we’re currently on a February, May, August, October cycle. (October? Wouldn’t the cadence be November? Yes, but based on customer feedback we do the fourth quarter QSN a little earlier, primarily to avoid holiday IT change freezes. And now you know.)
\n
While we always try to announce security issues via a QSN, that is not always possible. Typically, this is due to an issue being reported to F5 by an external researcher with a disclosure deadline we must meet, and we’re unable to hold disclosure until the next QSN. When this occurs we perform an Out-Of-Band Security Notification (OOBSN), which is akin to a ‘surprise QSN’. We follow the same processes and procedures, but the date isn’t scheduled or announced in advance.
\n
Other reasons this might happen would include an issue being disclosed publicly in some way such as a zero day from a 3rd party, F5 discovering active exploitation against our customers, discovery in an open-source repository where it would be visible (mainly this involves NGINX products), etc. The short version is that various external forces may periodically require F5 to disclose issues outside of the scheduled QSN process.
\n\n
Hopefully I’ve sufficiently addressed Who, What, Where, and When, but feel free to leave a comment if you have any lingering questions. After two CVE-related articles in a row, we’ll see what I get into next time; I think I’ll save the How for a later date and tackle something else for a change of pace. If you enjoyed this article or found it useful, or even if you didn’t, I encourage you to check out the articles from my F5 SIRT colleagues, including the This Week In Security newsletter.
\n
Thank you for your time and attention. The F5 SIRT will continue advocating for better security. Stay safe out there.
\n
\n
CVE: Who, What, Where, and When
\n
Background
\n
A few months ago I wrote “Why We CVE”, wherein I covered the general intention of the CVE program, and more specifically the reasons why F5 publishes CVEs. After publishing that article the rusty, creaky mental wheels started turning, remembering the old “Who, What, Where, When, Why, and How”. I thought I might answer those as well. I’ll be leaving ‘How’ as a possible future article. I have been giving that some thought, and what it might entail – maybe how F5 runs out processes internally, or perhaps a general look at how the CVE system works with CVE Services 2.1, CVE JSON 5.0, CNAs, Root CNAs, etc. But that’s a story for another time.
\n
Today I intend to attempt to answer the Who, What, Where, and When questions.
\n
Who
\n
I touched on this briefly last time. As I said then, F5 officially joined the CVE program as a CNA in late 2016. Joining the program doesn’t magically publish CVEs though. Someone, or some group, must ultimately do the work that goes into being a CNA and publishing CVEs. While my primary responsibility as an F5 SIRT Principal Security Engineer is coordinating our vulnerability efforts, and acting as F5’s primary external contact with CVE.org, VINCE, etc., I’m just one member of the team – and this very much is a team effort.
Within F5 the effort to diagnose, document, track, and publish security issues is the responsibility of the F5 SIRT. Ownership of different security issues is distributed amongst the core team, and each Security Engineer shepherds their issues through our processes from initial discovery all the way to readying the Security Advisory for publication. Everyone who has published under the ‘F5 SIRT’ tag here on DevCentral plays a role, and I’m glad to be part of such a great team.
\n
Of course, other teams within F5 are also involved – Product Engineering creates the fixes, Digital Services works with us to author the Security Advisories, many groups review those before publication, etc. – but ownership and responsibility resides with the F5 SIRT.
\n
What
\n
There are a couple of ways to interpret ‘what’ – so first, what do we CVE?
\n
As mentioned last time, each CNA has a ‘Scope’ statement, which defines what the CNA is responsible for within the CVE program. This is F5’s statement:
\n
All F5 products and services, commercial and open source, which have not yet reached End of Technical Support (EoTS). All legacy acquisition products and brands including, but not limited to, NGINX, Shape Security, Volterra, and Threat Stack. F5 does not issue CVEs for products which are no longer supported.
\n
So that establishes the overall scope for which products and services we’re responsible for when it comes to issuing CVEs. That’s a broad area, but this is further refined by K4602: Overview of the F5 security vulnerability response policy.
\n
F5 assigns Common Vulnerability and Exposures (CVEs) and publishes security advisories for all vulnerability categories, from Low to Critical.
\n
Additionally, F5 publishes security advisories for security exposures, which do not affect the confidentiality, integrity, and availability (CIA) of the F5 product, but may impact the CIA of one of the following:
\n
\n- Services or network traffic processed by the F5 product
\n- Confidentiality of data cached on the F5 product
\n
\n
Security exposures are generally dependent on configuration and use of the F5 device. Therefore, F5 cannot produce an accurate CVSS score or severity for security exposures. F5 recommends customers treat security exposures as a high priority and evaluate the specific severity of these issues in their own environment.
\n
An important item to call out from that policy is that F5 publishes Security Advisories for both CVEs and what we call Security Exposures. The way we distinguish these is via the CIA Triad. For those not familiar with infosec terminology, the ‘CIA’ refers to Confidentiality, Integrity, and Availability. The very high-level overview is that a Confidentiality impact means information is seen by those who should not be able to see it, an Integrity impact means someone is able to change information they should not be able to change, and an Availability impact means a degradation, or complete loss, of a service to legitimate users. Yes, that’s extremely simplified, feel free to leave a comment – but it will suffice for our needs here.
\n
How does F5 distinguish between a CVE and a Security Exposure? We look at where the CIA impact resides. If the CIA of the F5 product or service itself is impacted, then we consider that a vulnerability in need of a CVE. Leaking private keys, modifying the configuration, denial of services attacks, etc. We know the full scope of the issue and can provide an accurate CVSS score and vector, available mitigations, etc. These are relatively straight-forward.
\n
We use Security Exposures when a defect in the F5 product or service causes a CIA impact that is not against the F5 product or service itself, but rather somewhere else in the network. An example of this would be a defect in the WAF engine that causes traffic that is rightfully expected to be blocked to be allowed through. The backend systems are now being exposed to malicious traffic. The CIA impact is against those backend systems, but the flaw allowing this is in F5’s product. As every network is different, there are many unknowns and the CVSS score and vector would vary.
\n
We publish these issues because, as I like to say, “Our customers can’t make informed decisions about their networks if we don’t inform them.” We are advocates for the customer, and making good security decisions requires knowing all relevant information. Part of our role, and duty, is providing that information.
\n
The other way to interpret ‘what’ is – what do we say when we CVE?
\n
This is covered in more detail by our Vulnerability Disclosure Policy within K4602:
\n
F5 is committed to responsibly disclosing information that contains sufficient detail about the vulnerability in question, such as the CVSS score and vector. This information is intended to help customers understand the impact, severity, potential mitigations, and software fixes related to the vulnerability when such information is available.
\n
F5 does not provide the following information:
\n
\n- Example exploit code or reproduction information
\n- The number of customers or sites affected
\n- Any information F5 regards as confidential
\n
\n
We strive to provide enough information to be useful to our customers, and the broader infosec community, while not providing information that might aid those with malicious intent. That is a fine line to walk, and we tend to err on the side of caution, but we do try to provide the information necessary to evaluate the issue and determine if a given system is impacted and needs to be remediated.
\n
We have refined our approach to Security Advisories over the years and will continue to do so. Over time we introduced CVSS and CWE. We’ve updated the document structure, standardized language, and made many other changes based on the feedback received. We are always open to feedback, and there is a field for that at the bottom of every Security Advisory. Yes, that feedback is read.
\n
Where
\n
This may be the simplest question to answer; you can find all F5 Security Advisories on MyF5. More specifically, you can see all new Security Advisories. Note that includes F5’s first-party issues as well as any third-party CVE’s we’ve responded to, and it covers both CVEs and Security Exposures. If you wish to be notified of new security announcements, we have two mailing lists – F5 Security Announcements and NGINX Security Announcements. We do strongly encourage everyone to subscribe to the appropriate list(s) to receive security notifications.
\n
We normally have an RSS feed option as well, documented at K9957: Creating a custom RSS feed to view new and updated documents – but that is currently K9957: RSS feed service interruption as the RSS functionally was lost in a recent platform change for MyF5. RSS functionality will be returning to MyF5, but we don’t have a date for restoration that I can share. I recommend checking K000092546: What's new and planned for MyF5 for updates.
\n
Of course, as participants in the CVE program, all CVEs published by F5 can also be found through CVE.org, as well as downstream providers such as NVD, etc. You can find our CVEs wherever fine CVEs are distributed. Do note that this will only be CVEs; Security Exposures are only distributed directly by F5.
\n
When
\n
Actually, this is the simplest question to answer - K12201527: Overview of Quarterly Security Notifications. Done.
\n
OK, more seriously, we do four scheduled disclosures a year – the aptly named Quarterly Security Notifications (QSN). Each QSN ‘rolls up’ all fixes released since the last QSN. At the time I’m writing this our next QSN is May 3, 2023. With each QSN the next day is also published, and we’re currently on a February, May, August, October cycle. (October? Wouldn’t the cadence be November? Yes, but based on customer feedback we do the fourth quarter QSN a little earlier, primarily to avoid holiday IT change freezes. And now you know.)
\n
While we always try to announce security issues via a QSN, that is not always possible. Typically, this is due to an issue being reported to F5 by an external researcher with a disclosure deadline we must meet, and we’re unable to hold disclosure until the next QSN. When this occurs we perform an Out-Of-Band Security Notification (OOBSN), which is akin to a ‘surprise QSN’. We follow the same processes and procedures, but the date isn’t scheduled or announced in advance.
\n
Other reasons this might happen would include an issue being disclosed publicly in some way such as a zero day from a 3rd party, F5 discovering active exploitation against our customers, discovery in an open-source repository where it would be visible (mainly this involves NGINX products), etc. The short version is that various external forces may periodically require F5 to disclose issues outside of the scheduled QSN process.
\n
Wrapping Up
\n
Hopefully I’ve sufficiently addressed Who, What, Where, and When, but feel free to leave a comment if you have any lingering questions. After two CVE-related articles in a row, we’ll see what I get into next time; I think I’ll save the How for a later date and tackle something else for a change of pace. If you enjoyed this article or found it useful, or even if you didn’t, I encourage you to check out the articles from my F5 SIRT colleagues, including the This Week In Security newsletter.
\n
Thank you for your time and attention. The F5 SIRT will continue advocating for better security. Stay safe out there.
\n
Employee
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
