Path to Secure Linux Platforms

Linux is being relied upon by an increasing number of programmers due to its versatility, power, and speed. Unlike other development platforms, Linux grants embedded developers untethered access to its most granular building-block components. Programmers can customize everything to suit their preferences or particular usecase. These traits make Linux an especially appealing tool to developers who want to tinker and iterate quickly.

That being said, just because Linux is swift and powerful doesn’t mean it’s without vulnerabilities. Once an embedded device is in use out in the world, undetected security holes and bugs that appear are serious business. When dealing with CVEs (Common Vulnerabilities and Exposures), fresh data is a must, time is of the essence, accuracy is paramount, and understanding context is vital.

According to the Linux Foundation, “It has been estimated that free and open-source software (FOSS) constitutes 70% to 90% of any given piece of modern software solutions.”

Best security practices dictate proactively and regularly monitoring all components for usability, trustworthiness, and vulnerabilities. The most important factor to remember in a responsible security approach is that it’s a never-ending process — you’re always evolving, always improving.

But many companies are falling short. According to the Open SF Foundation, 50% of companies have a security policy, 30% do not, and 17% of respondents didn’t know if they had one or not.

The path to a secure embedded Linux platform follows this vulnerability management lifecycle:

● Assess identity assets, scan them, and report findings

● Gauge exposure and consider threat context to prioritize CVEs

● Execute an action plan that remediates, mitigates, or accepts the identified risk

● Conduct a rescan to reandassess the CVE and validate whether or not your action plan produced the desired outcomes

● Evaluate the metrics you have been using to measure success, evolve your security process, and update your SLA to improve them. Eliminate any underlying issues affecting success.

● Restart this process with your improvements and continue to revise and repeat.

Companies need to be vigilant at every stage in the vulnerability management life cycle and have a CSIRT (computer security incident response team) in place that can understand the impact of a vulnerability and notify customers to explain what the company is doing about it.

To achieve and maintain platform stability you need a solid CI/CD pipeline implemented internally or managed by a partner. This pipeline should incorporate regular smoke tests of a CVE fix, and include ongoing testing. Specific to the coding of the CVE fix, your pipeline needs to integrate the chosen fix into embedded Linux and all your solutions layers, automate the architecture that you’re looking for, automate testing, review tests with partners and peers, then merge those components into whatever repo(s) your organization uses.

Once the development team has integrated a CVE fix into the pipeline, you’ll need to make sure your open source automation server and CIRT can present the relevant information to your organization and to your customers to show that the CVEs have been resolved.

If this sounds like a lot, the good news is that there are partners who can help you manage all of this. We invite you to watch our webinar, Path to Secure Linux Platforms, for a more in-depth discussion of this topic. During this session, we'll walk you through each step in a vulnerability management lifecycle. For further assistance, contact Wind River to see how we can support you.