The flaw in the Kubernetes orchestration engine uncovered late last year should serve as a reminder of the value and mission-critical nature of open source in the enterprise—and the care you must take to secure upstream open-source projects.
Since its release in 2015, Kubernetes has become by far the most popular container orchestration system in use today, whether companies are implementing it through a platform or directly through the Kubernetes project.
CVE-2018-1002105 is a privilege-escalation issue that makes it possible for users to gain full administrator privileges on compute nodes being run in Kubernetes pods.
As flaws go, this was a big one. Companies that use Kubernetes as part of a commercial platform were protected before they even knew there was a problem. Here's why you should shift your security upstream.
The broader risks with open source
Companies going it on their own with Kubernetes had to do this work themselves—a feat ranging from no problem to challenging to impossible, depending on the organization's resources. But organizations using open-source software provided by a commercial vendor were at reduced risk, since the vendors handle supply chain security and provide continuous security fixes.
The wider use of open source in the enterprise has not fully mitigated the risk that comes from a community-based support model. This is especially true when it comes to the use of upstream projects—or the open-source "source."
Many companies decide to download and use open-source software to save money and time, as opposed to buying or subscribing to commercial software based on an open-source project. They may figure that what they give up in security and accountability they make up for in cost savings and agility.
Key issues to consider
That may be true, but if you do decide to go to the source, so to speak, be prepared. Companies need to ask themselves three questions:
Do we have a method of inventorying the scope of open-source usage in the organization?
Do we have the ability to determine what is and is not at risk when a new, high-impact security vulnerability is discovered?
Do we have the resources in place to quickly find and fix vulnerabilities and quickly update all affected systems to the latest version that includes the fix?
Take patch management, for example. Are there people on your staff who have the time and skills to determine which of the open-source projects you're using need to be patched and when—if at all? You can build or buy a tool for proactive scanning, but there's more to patching than determining that you need one and then applying the patch.
What about the impact on your broader systems? What about your applications? Does the patch break anything? In short, you need not only to have the resources to do the patching, but to also assess the impact for your particular environment.
Oops, they did it again
Gartner says that 99% of the vulnerabilities exploited by the end of 2020 will continue to be ones known by security and IT professionals at the time of the incident.
This tells you that most organizations do not have a proactive patching strategy in place, don't have the skills or resources in house to do the patching, aren't sure which systems are affected by vulnerabilities, are purposely not patching their systems because they're afraid that they will break something—or all of the above.
Then there's the software supply chain. The open-source project you're using may depend on or include other open-source projects, making it challenging to determine whether a fix to a vulnerability is available.
When platform vendors implement open source into their platforms, they vet the code, validating that it has been inspected, thoroughly tested, digitally signed, and securely distributed, as well as that continuous security updates are provided.
Even then, commercial providers may decide that certain code is too risky to implement, and so they provide extensive quality assurance and put the software through stringent security certifications such as Common Criteria and FIPS 140-2.
Balance risk, budget, and engineering resources
There is no question that open source drives innovation and agility, and there are many good reasons to work directly with upstream projects. But your organization needs to go into it with eyes wide open. Decide how to balance your security risk, budget, and internal engineering resources, based on a risk policy that has been agreed upon by all stakeholders in the organization.
When it comes to open source, there will always be times when upstream projects make sense, just as there will always be times when the organization requires the security and management support—and peace of mind that comes with reduced risk.
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
