Take a Smart Approach to Open Source Security Training and Policies

As more channel partners and MSSPs help business customers begin or expand open source deployments and services, IT leaders must be sure to integrate related security training and policies for open source use to keep systems, developers and critical data safe and secure.

For many IT security tasks, the work is the same for both proprietary and open source applications and development environments, but with some tasks, open source security adds new responsibilities and procedures for training and policies that must be identified and supplemented from the start.

IDC’s Jim Mercer

One thing to remember, said Jim Mercer, a DevOps analyst with IDC, is that different open source projects can offer businesses varied amounts of diligence when it comes to security, depending on the project.

“For example, a project that has an active community and is updated frequently will generally be more proactive about security vulnerabilities and may have code that is actually more secure than your own code,” Mercer told Channel Futures. “However, projects with less activity or that have become stale may fall behind in security due diligence.”

To best protect businesses, development teams must be schooled on what the attributes of a secure open source project look like and must ensure proper code and policy examination before introducing new open source code into an application, he said.

“At the end of the day, when it is being using by your application, the security problem belongs to you.,” said Mercer. “Keeping track of all the OSS, builds, releases, vulnerabilities and fixes can get complex really fast.”

In training developers regarding security and open source use, it’s important to remember that not all developers will become security experts, added Mercer. “Organizations can mitigate this by keeping some security experts on staff who can help create the necessary procedures and checks and balances for using and maintaining security with open source. These experts can form a Center of Excellence on how open source library security is managed. They also may have a wider vantage point since they are providing a common service to multiple teams.”

Open Source Policy Additions

The Linux Foundation’s Mike Dolan

With security policies for proprietary and open source development and use, the usual suspects such as general policies around acceptable use and access control as well as plans for disaster recovery and incident response should be included, said Mike Dolan, vice president of strategic programs for the nonprofit open source advocacy group, The Linux Foundation.

But when it comes to open source development and use, policies that should specifically be included are things like the establishment of guidelines for secure coding best practices, the utilization of peer reviews to check code before it is shared or implemented and rules that mandate incremental code updates with ongoing testing at every step, said Dolan.

“It is important that all policies be clearly communicated to employees at all levels — not only to IT staff — as anyone within an organization can potentially cause a security breach,” he said.  “Staff should receive training on what the policies are, and how best to stay secure. Technical staff may benefit from further formal training around building secure software.”

Other topics that should be included in the open source policies are evaluation of all software to include security reviews, testing to ensure deployment will not negatively impact an organization’s security, access control policies and acceptable use policies, said Dolan.

Clyde Seepersad, the general manager for training and certification for The Linux Foundation, added that it is also critical to think of the training aspect of security as a process rather than an event.

“Companies should make the effort to develop rolling training agendas which ensure both a buildup of skills over time and an ongoing refresh as practices are constantly improving,” said Seepersad. “Keeping track of the human talent around security should be handled with the same structure and follow through as keeping track of code in use.”

Extra Diligence Needed

Red Hat’s Vincent Danen

At open source vendor Red Hat, Vincent Danen, the director of product security, said that using open source inside a company’s development environment requires a little more diligence and awareness, compared to similar practices for proprietary software.

“Given how easy it is to come by a random piece of open source software, see that it meets your needs and then to start using it without any validation whatsoever probably isn’t a great idea,” said Danen. “Also, recognizing that things you pull from GitHub or other repositories means you need to keep tabs on it. Unlike proprietary software that you’d receive updates for via an update service or mechanism, with much open source pulled from various sources you need to manually be aware of updates and manually pull those changes in. You likely want policies around watching and monitoring the upstream sites of the software you use.”

At the same time, “the real training that users and developers need to undergo is a reinforcement of general organizational risk and IT security practices,” added Danen. “Are you able to download whatever applications or code that you think you might need? Should you? What is the protocol for using unverified code from a public repository? What systems can it be run on, and so on. These are the questions that should be asked, regardless of whether the software is open source or not.”

A critical concept for security teams to instill when using open source is the idea of instilling “security hygiene” across their organizations, said Danen. “This means adhering to common, accepted security standards, like changing default passwords, not using unverified software whether open source or not, and not falling for socially-engineered malicious schemes, such as spear-phishing.”

Working with an enterprise open source vendor can help with these tasks, he added. “By leveraging the expertise of an enterprise vendor, a significant part of the cost of proactive security is covered in licensing or subscription costs.”

To help with open source use policy creation, Danen said he’d also suggest that CISOs, CSOs and other security leaders have a good understanding of what their company’s acceptable risk profile might include. “Are they comfortable with developers running software in R&D environments, regardless of provenance?” he asked. “What about end users? If not, what kind of restrictions do they want to put in place? It’s these questions that should be asked first and foremost when it comes to software. Open source is incredibly important to business success but security is universal.”

SUSE’s Gerald Pfeifer

Gerald Pfeifer, the vice president of products and technology programs for open source vendor SUSE, said it’s important to remember that while open source security and training can bring different challenges to business users, they are not unique challenges.

“Like a human body, every complex bit of hardware or software will have vulnerabilities,” he said. “And like a healthy body, a healthy ecosystem or vendor will be able to address those vulnerabilities. Just note that proprietary systems are not inherently more secure, or we would not be having all those Meltdown and Spectre disclosures this past year when microprocessors are about the most proprietary pieces of technology one can imagine.”