[BreachExchange] Making the Vulnerability Disclosure ‘Nice’ List: Cisco

[Destry Winant]

https://www.riskbasedsecurity.com/2019/12/23/making-the-vulnerability-disclosure-nice-list-cisco/

Risk Based Security has always made it a point to praise organizations
that operate in good faith and Cisco’s PSIRT team definitely knocked
it out of the park this month. It is vital that vulnerability
databases are treated as living entities, where policies are
continually reviewed and entries are updated for clarity, quality, and
new information. This operating concept is vital, and demonstrated
succinctly in a recent dealing with Cisco where we found conflicting
information within their formal advisories and their Cisco Support
Community (CSC) bug reports. While our VulnDB team had a standing
policy on processing information from Cisco, we used it as a chance to
review that policy as well as gain clarity on the accuracy of their
resources.

In most situations, organizations, including RBS, rely on Cisco’s
formal advisories as the single source of truth for official
vulnerability information in Cisco products. Our research team had
noticed some confusing and seemingly unnecessary information disclosed
via CSCs, which could result in users performing unneeded work in
attempts to remediate a vulnerability that doesn’t impact them.

The prompt response and generous discussion by Cisco’s PSIRT team both
confirmed this and, although we will maintain our current policy, this
exchange led to a small change in version coverage within VulnDB. Our
communications with Cisco, and the resulting information, are provided
below.

On the Value and Accuracy of Cisco’s Advisories vs CSCs

On May 5th, 2019, Cisco published an advisory for a vulnerability in
Cisco Adaptive Security Appliance (ASA) and Cisco Firepower Threat
Defense (FTD) software. Toward the bottom of the advisory, a chart
lists the affected ASA release tree, recommended release for this
vulnerability as a fixing version, and the recommended release for all
vulnerabilities in the advisory. (In this advisory, please note that
the 9.7 train is listed as vulnerable with the fix being an upgrade to
version 9.8.4.)

The corresponding CSC (CSCvj33780) provides a longer list of fixing
versions in the “Known Fixed Releases” section, including 9.7(1.26):

This shows a clear discrepancy between the formal advisory and the
associated CSC. The advisory strongly implies that all versions of the
9.7 train are affected, while the CSC suggests there is a specific
fixing version in that train. On the surface, the CSC bug report may
seem as a better source of information given that it has more
information, but in reality, this is not the case. After reaching out
to Cisco PSIRT, they confirmed that 9.7(1.26) should not be considered
a fixing version. How could that be?

Cisco PSIRT went on to clarify that the CSCs include information from
the development teams that do not reflect what software is actually
released to customers. In this case, they indicated that 9.7.(1.26)
was used to check-in the fix to the 9.7 train, but it was done to
ensure that subsequent trains received the fix. This is how a CSC may
list a number of builds listed in the defect that show a fixing
version, but in reality were never available to customers and cannot
be considered a fixing version.

Another concern in this CSC is that among the fixing versions listed
are ones in the 96, 98, 99, 100, 101, and 201 trains. The Cisco ASA
roadmap clearly shows that no such trains officially exist. We
questioned Cisco about these trains and they elaborated on their
automation tasks on the developer side, saying that these may
represent future releases that are internal builds in  early
development, but have not been made public in any fashion. If an
organization took this information and attempted to remediate, the
absence of explanation would be likely to create unnecessary
confusion.

Another issue we see in Cisco Security Advisories is that occasionally
they do not list all specific vulnerable versions, rather just an
affected train (e.g. 9.8) and the first fixed version next to it (e.g.
98.3(0.6)). In cases where a vendor does not expressly list vulnerable
versions or a range (or just states “all prior versions” without
actually having verified it), it is RBS policy for the VulnDB team to
only include the fixed version and latest vulnerable version. Only
versions known to be affected are included to ensure accurate VulnDB
entries, although customers are generally encouraged to consider prior
versions as likely affected.

Other sources like NVD and BID often include prior versions without
actually knowing if these are vulnerable, and in some of these cases,
RBS has confirmed that some of the listed versions are actually not
vulnerable. This may happen when a new feature is introduced in e.g.
version 5.0, but they list all prior versions including 1.x, 2.x, 3.x,
and 4.x, despite not having the vulnerable functionality.

As a result, RBS has historically not added the whole train as
affected but initially just the train itself and later also the latest
vulnerable version. However, Cisco PSIRT has clarified that if nothing
else is stated, it is safe to conclude that all versions in a train
are vulnerable, saying that if a vulnerability “were introduced within
a build this would be noted in the advisory.” This is a great case
where not all vendor advisories can be treated equal and emphasizes
the value of a vulnerability database team reaching out to vendors and
enjoying a collaborative effort.

Catch-22

The Cisco PSIRT team really went out of their way on this one and Risk
Based Security wants to recognize that, and thank them for taking the
time that they did. In today’s environment, organizations tend to
unintentionally marginalize their PSIRT and security teams by basing
their primary metrics on “how many tickets did you answer” or “what is
the future RoI”. However, as we all know, it’s not just about the
tickets or vulnerabilities fielded; it can be just as much about
adding clarity to disclosure processes that greatly assist mutual
customers.

In some organizations PSIRT and security teams fall into a security
‘catch-22’ where a successful job means no breaches. Unfortunately,
having no breaches may create the perception that there is less need
for the security team.  Then, if a breach occurs, the knee-jerk
reaction of “Breach? Hire more security!” starts the cycle once again.

Thanks again to the team at Cisco. We look forward to future
collaborative efforts. Happy holidays!