A change in dealing with security vulnerabilities in external communication
You cannot communicate that your Software Application has a vulnerability – OR - Your Software must be 100% Secure… these or similar statements were quite normal to hear ten years ago internally in Software (SW) businesses. Especially Sales or Marketing departments had believed, that openly informing about SW vulnerabilities would be a bad idea in terms of SW vendor`s reputation.
About a decade ago, we have seen that this mindset was changing towards a more open and pro-active communication of the SW vendor to the outside in case of known vulnerabilities. This was driven by Operating System (OS) vendors and Open Source Software (OSS) vendors and was followed by Application SW vendors. What contributed to this trend was, that SW Application vendor products typically included, and continue to include, SW components from 3rd party SW partners and, even more significantly, from OSS communities. This actually is a positive trend, because SW Application vendors can concentrate on creating valuable business logic SW, while leveraging existing base components from the OSS communities.
I had a real “light-bulb” moment years ago, when a large Customer told us, that while he loved using our Communications and Collaboration products, he could no longer believe that we never had any vulnerabilities. Remark: We of course have always had our SW development process in place with Major, Minor, Fix and Hotfix Releases, but that time we did not yet publish our Security Vulnerability Advisories. In other words, where some company departments in the past feared that pro-active publication of Security Vulnerability Advisories was a bad idea, things had turned around by 180 degrees and lack of disclosure created lack of trust.
Security Vulnerability Management Process & SW Fixes
The requirement for Vulnerability Management for a SW vendor is about setting up and organizing an appropriate process. Referring to the different possible sources of SW components mentioned above (OSS, OS Software, Partner SW) and considering that Software Applications might contain quite a large number of them, the Application SW vendor has to establish a vulnerability monitoring system, monitoring vulnerability alerts received for those 3rd party SW components in use (there are providers offering services for that). After analyzing, the SW Application vendor needs to decide what such a “component specific” alert means for its overall Application SW product. If relevant, then it is of course about a SW fix to be implemented and to be rolled out to the customer in a timely manner based on criticality.
About Publishing Security Advisories additionally
Based on nature and significance of the vulnerability, a Security Vulnerability Advisory (= Notification) should pro-actively be sent out to the customers, informing them about the Vulnerability. This in addition and often before the SW Fix is even being rolled out. A SW vendor should focus on publishing Advisories that are really important for the customer, including notes for the customer how to mitigate and information about next steps. Often enough SW Updates are not even necessary, because - depending on the vulnerability type - a configuration change hinted in the Security Vulnerability Advisory being sent out can be quite sufficient.
Summary & Outlook
Customers today are well aware, that Software cannot be made “100% secure”, at least not economically with the technology we have at our disposal. The technology shift over the last couple of decades, from proprietary HW and proprietary OS SW to general purpose compute HW and general purpose SW Operating Systems have actually vastly improved the quality of the code, yet still increased the potential attack surface because of the Internet and the productivity gains expanded the functional richness. Spectre and Meltdown have also made us well aware both of the increasing sophistication of attack vectors and that a clear-cut distinction between hardware and software vulnerabilities does not exist. A SW vendor needs to do everything to reduce the Security risk for the customer such as following Secure Coding principles, applying Security by Design and recommending appropriate hardening measures for the SW installation and operation stakeholders.
In future, new technologies in HW and SW Architectures may further reduce the security attack surface. Examples might be around special and dedicated chipset capabilities such as hardware support for Control Flow Integrity as well as around reductions of the OS stacks to only those modules that are really needed for the given Applications (rather than deploying a full Linux stack on a tiny IoT Device). Furthermore, thanks to Data Analytics, Machine Learning and Artificial Intelligence, new generations of Security Monitoring Systems will become able to detect anomalies in a network or Application in real-time by learning anomaly behavior to help eradicating threats before they occur.
Back to pro-active Publication of Security Vulnerability Advisories, as a building block of a SW vendor`s Vulnerability Process and as an approach to create Trust, I am happy that we have introduced our Vulnerability Intelligence Process already many years ago. Our published Security Advisories address critical security issues in components used by our Unify Atos Collaboration Solutions and how to mitigate and solve them. In most cases of previous Advisories it was about issues at the general purpose OS level, with information being provided on how to fix.
Find more information in our Vulnerability Intelligence Process. For subscribing to receive Security Advisories via e-mail notifications and for access to published Advisories, you may want to send an e-mail to our Unify Product Security team to firstname.lastname@example.org or directly to its head email@example.com.