Shifting security fixes back towards the development process isn't easy, but is necessary in today's world where even seemingly simple devices like presentation tools are both surprisingly complex, and also networked into everything else.
A version of this article appeared in DevOps.com. It has been updated for syndication here, and includes interactive links to vulnerability challenges.
I think we can all recall a time in recent memory where, in a meeting or at a conference, someone has had issues with presentation technology. It happens so often that there is almost an expectation of a clunky experience, at least initially. It stands as no surprise, then, that ClickShare's seamless app was immediately popular with end-users. For them, there is nothing easier than using a ClickShare application to push a presentation from their laptop, tablet or smartphone over to a big screen or conference room projector. Belgian-based digital projection and imaging technology supplier Barco designed their automation platform to work that way, and big business embraced the concept. FutureSource Consulting puts Barco's market share in conference technology at 29%, with integration into 40% of all Fortune 1,000 companies.
When researchers from F-Secure revealed in December that the seemingly innocuous automation platform was riddled with security vulnerabilities, it sent shockwaves through the business community. The uncovered security flaws are critical in nature, and could potentially enable any number of malicious activities.
Researchers demonstrated how the vulnerabilities could allow remote users to snoop active presentations, create backdoors into secure networks or even configure a spyware distribution server that would infect every user connecting to a Barco device. Suddenly, companies were faced with the prospect of having serious security problems installed directly inside conference rooms and offices throughout their organization. And because of the nature of the vulnerabilities, a single compromised device could support a network-wide breach.
"An attacker who successfully compromised one unit gains the ability to decrypt as well as produce valid encrypted images for any unit, whether within one family or across families," wrote F-Secure officials in their report. "Further, such an attacker may gain access to sensitive data at rest such as the configured Wi-Fi PSK and certificates."
To its credit, Barco has been extremely proactive in issuing patches and fixes to the vulnerabilities found within its products. Security vendor Tenable recently released a report showing 15 vulnerabilities across eight presentation tools, including Barco. As of February, only Barco has been active in deploying fixes.
Although some of the Barco vulnerabilities require hardware changes (and these will be a nightmare to deploy, if a firm acts to this degree to secure them at all), many of them can be corrected with software patches. This gives most enterprise users a seemingly good plan to fix their immediate problems, but they are hardly in the clear now. The problems with Barco are just the tip of the iceberg when it comes to dealing with vulnerabilities in well-known hardware and software products.
Now that the immediate issues have been resolved, we need to ask how devices with serious security flaws ended up sitting in thousands of conference rooms worldwide, or why they were so poorly designed and programmed in the first place. It's not like the F-Secure team was uncovering zero-day or previously unknown vulnerabilities. Ten of the flaws discovered in the Barco products were associated with well-known, common vulnerabilities like code injection attacks. Most already had Common Vulnerabilities and Exposures (CVE) identifications.
So how did decades-old CVEs get coded, or even hardwired, into modern presentation tools? The only possible answer is that developers either didn't know about them, or that security was not made a priority as the Barco devices were being designed. Sadly, this is a common situation, and certainly not exclusive to the Barco teams.
The best time to fix a vulnerability is while an application is being developed, long before it gets sent out to users. The worst (and most expensive) time is after a product has been deployed, or after it's been exploited by attackers. This can be a hard lesson, and one that Barco will surely learn as its once-impenetrable market share takes a hit following this security fiasco.
Shifting security fixes back towards the development process isn't easy, but is necessary in today's world where even seemingly simple devices like presentation tools are both surprisingly complex, and also networked into everything else. In this environment, security must become an organizational best practice. It doesn't matter if a company is programming apps for social media or manufacturing smart toasters, security must be considered in every facet of an organization.
Prioritizing security best practice and making it a shared responsibility is the goal of the DevSecOps movement, where development, security, and operations teams work together to code and deploy secure software and products. It requires as much of a change in culture as anything else. The new mindset needs to be that deploying a working product with security vulnerabilities is just as much a failure as creating one that can't perform its primary function.
In a healthy DevSecOps environment, anyone touching software should be security-aware, with developers receiving relevant and frequent training to avoid introducing disastrous bugs into their work. If the teams working for Barco had looked at security as a shared responsibility, there is no way that such a large collection of vulnerabilities, including decades-old CVEs, would have made it into their presentation tools.
Nobody wants to be the next Barco, having to explain why well-known security flaws were deployed through their devices to thousands of enterprise networks around the world. To avoid that fate, companies developing software or smart hardware should immediately prioritize security as both a shared responsibility and an organizational best practice. Creating a healthy DevSecOps program will take time and likely also require a shift in culture, but the results will be more than worth the effort. Robust DevSecOps can crush vulnerabilities long before they cause trouble.
For companies buying products and software, it's in their best interest to support firms that have embraced DevSecOps. Doing so will go a long way to making sure that the devices and software obtained from them aren't ticking time bombs waiting to be exploited by increasingly skilled attackers.
Check out the Secure Code Warrior blog pages for more insight about DevSecOps, and how to protect your organization and your customers from the ravages of security flaws and vulnerabilities.
Play these gamified challenges on: