Open Source Security Issues Exist: Deal With Them, Report Urges

Open Source Security Issues Exist: 

Deal With Them, Report Urges

Open Source Software is becoming much more commonplace within organizations, bringing a different set of risks and perceived challenges compared to closed source or proprietary software.

The Information Security Forum (ISF) today released a report to help security professionals recognize the benefits and perceived challenges of using Open Source Software.

"Deploying Open Source Software: Challenges and Rewards," which the IFS calls a briefing document, focuses on setting up a program of protective measures to effectively manage OSS deployment.

One of its goals is to detail the difference between the myths and the realities surrounding open source use. That understanding is critical to securing open source components in mixed code applications, according to ISF.

Open Source Software is emerging as a core part of IT infrastructure and applications. This status is due largely to the growing popularity of agile development methodologies and DevOps practices, according to ISF. With a substantial number of commercial and custom-made applications incorporating OSS, it cannot and should not be ignored.

As OSS becomes the mainstay within application development and infrastructure, security professionals will need to understand OSS and manage the challenges associated with its components. Fixes to these security challenges should be implemented as part of an OSS management program, led by a senior individual appointed to the role of OSS Program Manager, urges the organization.

Integrating all of these measures into a single, overarching program will enable a holistic and coordinated approach to managing the risks of OSS, said Paul Holland, Principal Research Analyst, at ISF. That is an essential need to make sure security remains intact.

"Many organizations are adopting agile and DevOps methodologies, which is driving an increased uptake of OSS and, in turn, the creation of new mixed source applications," said Holland.

Far-Reaching Goals

The ISF guide on deploying open-source software pulls together a quick study for IT workers and other open-source users in enterprise. It provides useful approaches for how organizations can effectively manage the challenges of using OSS, and why they need to do it.

The guide also talks about how to maximize the benefits and reap the rewards of using open-source software. In a way, this how-to guide from ISF is an attempt to close the software barn door before more of the malware horses get in.

Closed source software has been a staple of organizational IT applications and infrastructure. But many well-established and popular software programs are actually open source. So, organizations need to recognize that OSS may already exist within their own environment. It often is used in combination with closed source software, creating what is termed 'mixed source software'.

Mixed source software can be derived from any number of combinations of OSS components. The possibilities include closed source software, purchased code, and internal code. Developers can then integrate these components together to create a customized mixed source software application.

The security risks of using OSS within IT infrastructure and applications bring core challenges that must be minimized, the guide cautions. That task is made more complex if organizations have limited awareness of the OSS components in use. These include complex licensing and intellectual property obligations, a shortage of relevant OSS skills, and the absence of security in DevOps practices.

Balance Needed

A concerted effort to manage the use of OSS appropriately and effectively is needed. The growing prevalence of OSS needs to be balanced, urged Holland. For some organizations, the first step is to realize that the myths surrounding OSS are simply illusions.

For other organizations, the appeal of OSS and mixed source software is already apparent. This allows them to develop new applications securely and increase speed to market for new ideas, he explained.

OSS is often seen as being insecure and unsupported. As these negative connotations continue to taint its reputation, some organizations officially prohibit it, even though they may unknowingly be using OSS.

Others enthusiastically adopt OSS, harnessing its advantages, such as aiding flexible and rapid development. OSS can be a positive influence on software development. But that can only happen if it is used and managed responsibly, according to the ISF's latest guide.

Support Is Essential

The guide recommends supporting the organization's OSS program manager with the necessary funds and resources to develop a viable program and team. While in some instances, existing tools for closed source software can be extended to secure and manage OSS.

Other integration cases require the program team to procure additional tools to further enhance OSS security. The team should also monitor threat intelligence feeds for mentions of OSS components that the organization is using, according to the ISF guide.

"Resisting the move to OSS could limit an organization's ability to progress and evolve. If harnessed effectively, OSS can potentially be an accelerator for the business," said Holland. "Fostering an OSS management program is, therefore, vital to securing and managing OSS, allowing the organization to use it safely."

Preparation Required

Combining open source's dynamics with established practices around the management of closed source software will deliver a coherent, all-encompassing software management program. The result will provide the best opportunity for success, Holland added.

Many traditionally closed source software vendors are adopting OSS principles. That means OSS is here to stay, declared the ISF.

The flexibility of both open and mixed source software could lead to a decline in closed source software. In turn, that could cause a fundamental shift in software management, licensing, and security.

Fix What's Broken

"Deploying Open Source Software: Challenges and Rewards" presents a series of challenges and proposed fixes for a number of typical IT situations. The information cites specific issues that involve the use of open source components.

One challenge presented involves how some organizations use software applications that have open-source code inadvertently included in the IT infrastructure. Or the organization lacks a complete view of all OSS components deployed across their environment.

The situation involves having open-source components implemented in an uncontrolled manner and potentially left in an insecure state with outdated, unpatched, and prone to vulnerability exploits. Without adequate knowledge of where and how OSS is used, the organization risks allowing vulnerabilities into their infrastructure of which the IT staff is unaware and thus cannot proactively address.

The guide notes that this exemplifies what led to the Equifax breach in September 2017. In that case, malicious actors exploited an out-of-date version of Apache Struts, an OSS web application framework for Java applications. IT staff did not know that this OSS platform component existed in the corporate environment. Therefore, it had not been included in the company's patch management processes and schedules.

Fixes in the Making

ISF's guide explains a fix for that broken challenge. It suggests that organizations create and maintain an accurate, up-to-date inventory of all OSS components within their corporate environment. An initial discovery phase may be required if an inventory is not already in place or if the organization contemplates the possibility that OSS is in use without being formally recognized or documented.

The information cataloged should include replicating details about closed source software, source of OSS (e.g. vendor, third-party developer, OSS repository or internal development project), deployed versions of OSS components, software dependencies, support providers, and locations of safe updates available for download.

Compiling such an inventory can be created manually. An alternative option is to deploy an automated discovery tool that scans and monitors the infrastructure to create a database of software and the versions in use.

Absence of Security in DevOps Practices

Another critical challenge in the ISF guide uses the example of agile and DevOps developers who favor rapid application deployment over code security. The suggested fixes set the pace for what should be a best practice for application coding.

The ISF guide suggests that in-house developers should be made aware of, and trained in, secure coding practices related to OSS and some of the challenges that OSS presents in making mixed source applications secure by design. Developers' secure coding responsibilities should be outlined in a secure development lifecycle (SDL) specific to OSS.

That, in turn, should be linked closely to the SDL methodology for closed source software. Timeframes and deadlines for writing code should account for embedding security into the design phase.

How Things Work

If an organization is running open-source software and uses a central IT model, there should be operators, or someone, responsible for IT operations in general. That person is responsible for patch maintenance and ensuring that upgrades are made, according to Wei Lien Dang, co-founder, and chief strategy officer at StackRox.

"This could also be handled by someone on the development or DevOps team. While open-source software is often a cost-conscious choice, that doesn't mean that it is not without overhead. This comes in the form of experience and/or training to ensure that OSS code is patched and secured," he told LinuxInsider.

This is one of the reasons why organizations go with commercial software or a cloud-managed service. In those cases, it is the responsibility of the software or cloud provider to make patches available. You get the added benefit of a level of outsourced support and upkeep, he added.

The average IT worker may not know how to patch the OSS code. But it is not uncommon that the person who made the decision to leverage OSS within an organization is the one responsible for maintaining it, Dang explained.

"But the challenge is that the maintenance of this software becomes tribal knowledge. So, if that person leaves, the other folks on the IT team need to figure out what to do," he suggested.

Varied Duties

The duties of IT workers vary greatly from organization to organization. But a large number of organizations have very few IT resources that are focused on patching, according to Thomas Hatch, CTO and co-founder at SaltStack.

"Modern IT professionals spend much more time managing high-level APIs and UIs. They need to deal with a large group of systems and services and are not as focused on the system and OSS management as they were 10 years ago," he told LinuxInsider.

The continued security of open software components is a problem, agreed Hatch.

"The ability to take massive amounts of free, untested, unvalidated, and not necessarily secured software off the shelf has created a liability deeply embedded in areas that make heavy use of open-source software," he said.

Training for All

If we are talking about central IT staff or someone with an I/O role, then yes, Dang believes. Anyone who is responsible for the part of the environment in which OSS is used should have this knowledge.

If you are using open source, you assume the responsibility of tracking patches and security disclosures. That should be the responsibility of the decision-maker who decided to use OSS, he argues.

"They should assume the responsibility for operating that part of the stack and the environment that the OSS runs in. They should also be responsible for working with their team to implement a process to maintain patches or else they run the risk of losing the critical knowledge should they leave the organization," said Dang.

Is all OSS Use the Culprit?

Benefits come from using open source software, but organizations need to be careful that they understand how to deal with vulnerabilities and licensing issues that could create exposures, cautioned Dang.

Software developers are focused on building and shipping software. There are Software development practices, regardless of the methodology. Those that borrow from open source need to account for product security, urged Dang.

"It is not unique to DevOps. If you overlook the OSS patching process, you can easily put your organization at risk," he said.

There are two core considerations when using OSS in software development. One is that you have the right tooling in place to ensure protection. The other is that you have the right processes in place to manage patches.

You need to have a way of discovering vulnerabilities, license issues, and other risks associated with using OSS. The methodology, Agile, DevOps, or otherwise, should not make a difference.

"If you choose to use OSS, you need to understand the security risks and implications of doing so and be prepared to deal with it appropriately," said Dang.

Availability

"Deploying Open Source Software: Challenges and Rewards" is available as a PDF download here.