Open source Linux software has gained favor among IoT system developers for a variety of reasons. Mostly, it is readily available through binary versions prepackaged with embedded hardware and an ever-growing set of community-driven frameworks that are built for Linux. It also offers some practical benefits for IoT applications, notably support for the interoperability that IoT devices often require. Moreover, the cloud systems that run IoT solutions are increasingly built on open source, Linux-based operating systems.
In today’s interconnected world, securing Linux-based systems and devices has become one of the most pressing challenges facing developers and device manufacturers. Gone are the days of “fire and forget” device deployment.
Every IoT device running Linux needs that same level of ongoing protection. The question is how to accomplish it in a systematic, scalable, and cost-effective manner.
The Advantage of Open Source
Using open source software actually presents advantages from a security perspective. Ongoing threat mitigation requires the ability to update the software on a device as soon as a vulnerability is identified. Because of the large open source community, information about vulnerabilities surface quickly through legions of researchers, government agencies such as US-CERT, and dedicated mailing lists. As a result, users of open source in deployed devices can take fast action to lower a potential risk.
Still, the community will always address the fix in the latest iteration of the affected components and move on, focusing on innovation, while old versions of those components (e.g. kernel, libraries, etc.) will remain exposed.
Specific measures can be taken to make things extremely difficult for hackers and considerably reduce the odds of breaches via these four steps:
1. Monitoring
Think of monitoring as the “surveillance camera” in your security strategy. Assuming two houses have strong locks, the one that also has the surveillance camera is going to be better prepared against an intrusion. In this case, the cameras are operated by organizations that issue vulnerability alerts and advisories, such as US-CERT, the National Institute of Standards and Technology (NIST), the CVE database, various security vendors, private mailing lists, and communities focused on finding Linux vulnerabilities.
The challenge here is that, with dozens of organizations issuing advisories, there is bound to be a certain level of confusion about what vulnerabilities may affect which kinds of deployments. This makes it critical to know which organizations can be relied upon for relevant, accurate, and actionable information.
2. Assessment
Once an advisory or security report is issued, the system operator or its software partners need to make a determination as to whether its devices are vulnerable, and to what extent. A vulnerability is scored using the Common Vulnerability Scoring System (CVSS) based on its severity, difficulty of attack, and likelihood of avoidance.
Assessment requires knowing exactly which packages and which versions are vulnerable, and also the exact configurations of your systems (i.e., software bill of materials). Knowing this, of course, depends on how well your development team has documented its work. For vulnerable products, the clock for finding a patch starts the minute the vulnerability is exposed.
3. Notification
Once a vulnerability has been assessed, affected users must be notified promptly of the issue, the relative probability of vulnerability based on the nature of the device, and the action plan for remediation. This step requires the right tools and methodologies, so that notifications are sent to all affected parties in a timely and efficient manner. Timely notification depends on and reinforces a trusted relationship between software vendor and device deployer.
4. Remediation
The timing and method of remediation is usually based on priority. Vulnerabilities deemed to be of high severity may require an immediate “hot fix,” while others of lower severity may be covered in periodic software updates. The challenge is having the ability to quickly deliver effective patches and distribute them to end users via a secure channel. No matter what the severity of the vulnerability, addressing it in a timely manner will likely impact the focus of your business.
The Price of Protection
If this four-step process sounds like a lot of work, it is. There’s no denying that it requires a substantial commitment of people, time, and effort. There are no shortcuts. Speed of response is of the essence. The ideal solution is a dedicated security response team to address every potential vulnerability. If you try to do it all in-house, your team will need to change focus from development to remediation every time a vulnerability threatens.
What would it cost to assemble a dedicated in-house security team? Based on 8,000 to 10,000 CVEs uncovered each year, an organization would require a team of four or five highly skilled engineers to investigate and address each one. At an average annual salary of $120,000 for the appropriate experience and skill set, the organization would need to budget as much as $500,000 a year just for staff.
Most device manufacturers and operators of IoT systems consider such specialized expertise outside of their core competency and beyond their budget. The more cost-effective alternative is to assign this responsibility to an experienced commercial Linux vendor with a dedicated security response team—a proven strategy for providing timely protection within hours of vulnerability publication, often weeks or months ahead of the upstream patching.
The right software partner would have the necessary connections within the Linux community and among advisory organizations— combined with its own monitoring and investigative capabilities—to stay on top of vulnerabilities as they are discovered. Also because this provider would be able to scale its security response services across multiple customers, outsourcing this critical responsibility costs far less than trying to manage it in-house.
Managing vulnerabilities and mitigating related threats are essential steps for the protection of end users, but such action requires a level of engagement that is beyond the scope of most IoT solution developers, device manufacturers, and system operators.
Fortunately, the open source community is extremely vigilant in finding vulnerabilities that affect Linux software. By working with a software partner that is a leading contributor in key communities, with a proven process for monitoring and assessing threats, notifying customers, and fixing vulnerabilities, manufacturers and developers can help protect their customers against cyber-threats over the life of deployed IoT systems.