Critical Fortinet and Kubernetes Vulnerabilities; NIST refurbishing NVD

This has not been a good week for Fortinet. A PoC for this vulnerability is expected in the next few days. You must patch now! Vulnerability research firm Horizon3 released PoC for some vulnerabilities in Fortinet's wireless management product. These vulnerabilities have not been patched yet.

The flaw affects FortiClient EMS versions 7.0 (7.0.1 through 7.0.10) and 7.2 (7.2.0 through 7.2.2), so you’re going to want to apply the updates, ideally this week.

The NVD database is crucial for many commercial and open source vulnerability management tools. I believe part of the problem is growing pains as the number of published vulnerabilities has skyrocketed. The NVD database should be compared to a public service like GPS that enabled many valuable services and has taken on a critical safety role. I hope they are able to resolve the issues quickly and continue processing vulnerabilities. If anything, one of NVDs problems has been the time it takes to publish the enriched data.

Some research find that less than 50% of vulnerabilities are analyzed, which means they’re not benefitting from context and value add to aid businesses in evaluating them; some don’t have root cause or CWE information. Regardless of shortfalls, the NVD is still the best game in town and addressing the issues will help us determine the relevance and priority of noted CVEs.

For automotive “vulnerabilities” (recalls) that have to be fixed, vehicle manufacturers are required to notify the National Highway Traffic Safety Administration who has maintained an easy to use database. Those manufacturers also have to pay for the vehicles to be fixed! The NHTSA had a 40 years head start over NIST/NVD but it really is time for legislation to treat software more like we treat vehicles.

This initiative may give consumers a choice. Let’s hope they use it to buy more secure devices. I may have been doing this for a bit too long to have much hope. Please prove me wrong. I do like that this includes a "life expectancy" to inform consumers for how long this device will receive updates. And yes, some kid will glue fake QR codes on boxes. Ignore them. QR codes are used all the time to direct users to manuals and other additional information.

This reminds me of various web “trust” seal programs: since search engines never favored sites with those trust seals, really not much impact on web site security levels. But when browsers started making it harder to get to sites not using SSL, rapid increase in security. It would be very good to see AI shopping tools have rules favoring higher levels of security in products.

This is targeting home IoT devices, baby monitors, home security cameras, internet connected appliances, fitness trackers, garage door openers, and voice-activated devices. CISA and folks at the department of justice have been tasked with setting standards and enforcement actions. The logo is being equated to the Energy Star label. This could really help consumers make good buying decisions provided the standards and claims are consistent and trustworthy.

Having an informed buyer is always a good thing. That said, having buyers use a QR code to get security information is an extra step that most will not take. In the meantime, creating a set of enforceable industry standards on device support (SW updates, Patches, Firmware, etc.) would be more beneficial.

Good start. I would like to see labeling about safe and appropriate use, for example, whether it is intended for connection to public networks or needs to be fire-walled.

The form mandates signing by a software contractor’s CEO when being filed to the U.S. government. An outside software assessor is also allowed to demonstrate the security features of the software offering, assuming it’s a qualified Third Party Assessor Organization certified by Federal Risk and Authorization Management Program (FedRAMP). while the current form doesn’t support SBOM or memory safe coding, it’s still a big step in the right direction, and those should be incorporated over time.

Three items of interest in the form: 1) Open source and software developed for the federal government is excluded; 2) Signature by CEO or designee that binds the company; and 3) doesn’t reflect the reality that is today’s distributed software development practice. It’s also unclear that completion of the form results in software that is trustworthy. Perhaps that will come with the next update to the form.

One small step in the direction of necessary software quality. Software needs to be held to the same standard of merchantability as other products. We cannot continue to build our infrastructure on this porous foundation.