Assess the Security Impact of Acquired Software in this the making significant purchases requires a thorough quality assessment. With acquired software, it is almost impossible for an organization to know the full scope of its safety, quality, and security for a number of reasons.
Acquired Software Types
When an organization acquired software, it also acquires the risks inherent in or related to that software. When an organization acquired software, it also acquires the product of the skills and habits of the developers. It receives the management effectiveness, or lack thereof, of the company or community that developed it. It might inherit malware in its envelope.
There are different types of acquired software. Some software is commercial off-the-shelf software. Other software is provided by a vendor. OSS is another type. Even if an organization develops software internally, it often requires libraries and packages developed externally for necessary functionality. Even after an organization assesses the software products that it already uses, the products require updates and patches. These are all sources of acquired software. And if one organization acquires another one, the acquisition may come with all these forms of software. That’s why it’s important to assess acquired software.
Commercial Off-the-Shelf (COTS) Software
Commercial off-the-shelf (COTS) software is software that is ready made and available to the public for sale. It can be purchased outright with a license or leased. It may come with vendor support.
An advantage of COTS is that it can immediately fulfill a business or technical need at a low cost. The downside of COTS is that it can come with vulnerabilities, and some can affect the organization’s information systems once installed and used. Vulnerabilities can exist in COTS because the source code is a black box and the best COTS evaluation options often include using the software in the production environment.
According to the United States Computer Emergency Response Team (US-CERT), security concerns of COTS software include the following:
- COTS software is an attractive attack target because of organizational dependency on them as well as their high profile in the marketplace.
- It is difficult to verify the security of COTS products because they are black boxes to their customers.
- The COTS software vendors have limited liability as designated by the end-user license agreement (EULA) that the user must agree with prior to software use.
- COTS is typically designed without consideration for your specific security control requirements. While this is not universally true, COTS products are usually developed to be standalone products.
Furthermore, the US-CERT, in its article “Security Considerations in Managing COTS Software” (https://www.us-cert.gov/bsi/articles/best-practices/legacy-systems/security-considerations-in-managing-cots-software), offers guidance to consider on how to mitigate the risk of COTS software use. This guidance serves as good reference material for developing a framework for COTS assessment. Some of the suggestions they make in the section “Mitigating Risk” are the following:
- Identify the COTS components.
- Understand what counts in terms of acceptable risk with COTS.
- Get as much security information as you can from the COTS vendor, including results from vendor security scans and CVE information.
- Operate a secure computing infrastructure.
- Control access to the COTS software.
- Engage with the user community and security community.
- Test the software, particularly testing by fault injection.
- Look for ISO- or CMMI-certified vendors.
- Understand how the COTS software operate.
This is not their complete list of suggestions but is instead a set to consider for when you develop your COTS product assessment.
Outsourced Development
Outsourced development is when your organization contracts with an outside vendor to build software for your organization. The organization has very little day-to-day control over the software development practice. Mostly, any control the customer has is based on contracts and a review schedule.
Outsourced development can be done in a foreign country, which is sometimes also referred to as offshoring. On the other hand, outsourced development can also be done in the same country but in an area where the expense of development would be less than at the originating market.
Two significant benefits of outsourcing software development are cost savings on production and decreased need to manage internal technical staff. Each of these outsourcing forms poses interesting challenges, not least of which can be time zone differences and jurisdictional conflicts of interest. The further away you are from the software, the less control you have. Your organization won’t be absolved of all production costs, either. There still may be the expenses of management, design, testing, and deployment.
When your software is developed by entities that you do not have direct supervision over, these are major concerns:
- Embedded malware
- Design or coding flaws exposing software vulnerabilities
- Disclosure of software or sensitive data
- Unauthorized back door mechanisms
- Security verification of outsourcing vendor
- Establishment and compliance with security metrics and service level agreement
Open-Source Software
There are many benefits to OSS. First, OSS is often free or more affordable than commercial software. Depending on the software, it can also offer flexibility to modify the program source code to meet your needs. Open-source is typically supported by an active community of developers. And it’s (arguably) secure.
On the other hand, the downsides of OSS include its complexity, the fact that it often requires technical expertise and a thorough evaluation process, and that it is (potentially) insecure. (There are two sides to the security/insecurity argument, each with its own merits.)
Security risks to OSS come in the following forms and should be key factors in your assessment of the OSS:
- Lack of sufficient evaluation
- Spurious open-source code
- Lack of sponsorship
- Vulnerabilities
The following sections examine these open-source security risks more closely.
Sufficient Evaluation
Because OSS is typically complex software developed by multiple people from around the world of varying skills and its development is usually not managed like commercial software, it is essential to critically evaluate it because it may not have the same level of security management and quality assurance as commercial software.
One of the ways to evaluate the safety and security of open-source code is to look at the project repository. The prerequisite for this activity is to have technical and security experts on hand to conduct this evaluation. Furthermore, it is useful to have a plan.
Many open-source projects are hosted on publicly viewable project sites such as GitHub. GitHub is now to OSS hosting, sharing, and configuration management as Java is to the language of OSS. You can get a lot of information on an open-source project hosted on GitHub from the project page. Among a number of things that you’ll find on a GitHub project page, you’ll find the issues with the project, the source code, and the people who contribute to it.
In a project’s list of issues, you can see the number that are open and closed. You can also view each issue’s narrative and subscribe to any activity on the issue.
You can view and download, or pull, the source code of the project. In GitHub, the project’s modules or subsystems are typically hosted in separate repositories. This organization tells something about the project management and design quality, as modularity is a means for quality in both areas. Within the code itself, GitHub also provides a volumetric breakdown of the languages that the project uses. It’s good to know which languages make up the project. In the code, look for test code. You can see the number of commits to the project and the number of branches. For more detailed assurance, you can even do your own code review.
You can see the project’s contributors. GitHub shows the people who’ve contributed to the project. You can see where they claim to reside. Often the contributors will share their blogs, websites, or other affiliations. You can see other projects to which they contribute. Getting into the details, you can evaluate their activities with various projects, from the perspectives of contributions per day over the past year to the actual code changes they made per contribution.
Ensure Source Code Integrity
Throughout this book, you’ve seen examples of the various means by which information systems and communications can be compromised. OSS code and distribution are subject to many of these vulnerabilities. It isn’t that much of a stretch for even an amateur hacker to embed malware into a modified version of the open-source distribution. Don’t blindly trust the download distribution of OSS.
At a minimum, verify the integrity of the OSS distribution with the supplied MD5 checksum. Better yet, get the open-source distributions from trusted and authenticated sources and then verify its integrity with the MD5 checksum. Make sure you are using an authentic version of the OSS. When using open-source libraries, it is important to maintain a local repository that in-house development projects use for builds. A process for monitoring those libraries for security updates will need to be established to ensure updates are performed and pulled in to projects accordingly.
Ensure Commercial Support and Sponsorship
Popular OSS these days is typically supported by contributions from its community and sponsors from industry. As an example, the Internet Systems Consortium (ISC) is a not- for-profit organization that maintains a number of Internet standards, as well as technologies such as BIND, DHCP, and NNN. ISC is supported by individual and corporate sponsors. The Apache Software Foundation is a self-attested “cornerstone of the open- source software ecosystem.” IBM has sponsored a number of open-source projects. Red Hat pioneered the sponsorship of Linux.
Sponsorship is a benefit to open-source projects because it offers both technical resources and expertise, as well as management and financial support. Sponsorship impacts the safety and security of open-source projects by improving the overall technical quality of the projects, including security maintenance. Furthermore, by selecting trust- worthy, reputable, commercial support vendors to support your open-source journey, you increase the assurance that the software they provide and support will further approach your safety and security needs.
Check for Vulnerabilities
Like any software product, OSS is not without its vulnerabilities. Good stewardship of an open-source program at your organization should involve awareness and management of existing vulnerabilities as well as continuous education of future security impacting information.
OSS vulnerabilities exist for a number of reasons. The software code could be based on bad design. The quality of code could be poor. Secure and defensive coding may not have been a priority in the OSS’s code development. The developers may not have either the knowledge or the interest to write secure code. The OSS’s project management may not know or think to include secure software processes and practices into its SDLC. Project management may effectively not exist. Each of these factors can cause vulnerabilities as OSS is created, packaged, and distributed.
An effective strategy for checking for vulnerabilities recognizes how vulnerabilities get introduced into software. Since vulnerabilities can result from code design, development, and quality management issues, an effective strategy to check for vulnerabilities is to conduct routine code reviews on the open-source code to identify vulnerabilities. The concept of code review has been covered earlier in this chapter. Code review is a great technique for discovering vulnerabilities, but it is very labor and time intensive. This limits its ability to cover the code base. Assessing all of the code vulnerabilities is essential for improving the success of the effort. Automated code scanning techniques are effective for discovering vulnerabilities across volumes of a code base. Common types of automated code coverage are static application security testing (SAST) and dynamic application security testing (DAST). Automated code scanning techniques are covered elsewhere in this chapter.
Staying informed of the vulnerabilities in OSS is important. Industry and vendor guidance and the user community are great sources of open-source vulnerability information. The security documentation of open-source projects is another valuable resource for information on the security vulnerabilities of the open software programs and libraries that your organization uses. For instance, each Apache Software Foundation project has a security page that discusses the state of open and closed vulnerabilities in the releases of its software. The Red Hat Customer Portal provides searchable security advisories and common vulnerabilities for the projects that it manages. It also provides a Security Labs section for its subscribers containing information and tools to help its customers secure their software.
The CVE dictionary of vulnerabilities is a helpful reference for discovering potential vulnerabilities in OSS. Because of the number of evolving vulnerabilities and the rigor with which CVEs process them, these resources do not cover all of the vulnerabilities that exist. Even so, CVE searches can provide a substantial volume of information, so it is best to be as specific as possible in querying them to find the most useful results for your security program needs. The CVE is discussed in more detail in the “Security Weaknesses and Vulnerabilities at the Source-Code Level” section of this chapter. It is a searchable database of common vulnerabilities in software, including OSS. See http://cve.mitre.org and https://www.cvedetails.com to take a closer look at and use the CVE.
As open-source packages, modules, and libraries are produced, any vulnerabilities that exist within them are carried forward into the software that uses them. As open- source projects are composed of many of these constituents, most vulnerabilities exist in the software’s dependencies, including the libraries, packages, and modules that it incorporates into its packaging or workflow to deliver functionality.
Modules, Libraries, and Packages
Modules, libraries, and packages are collections of preassembled software with common functionality. They are made available for general use in other programs and comprise the most common form in which OSS functionality is included for use by programs.
The terms module, library, and package are often used interchangeably to refer to the concept of a piece of included software. However, there are distinctions between them. A module typically describes a grouping of reusable code often associated with the Python programming language. A library in the context of software is a collection of reusable functionality. This reusable functionality can be associated with software programs but also with operating systems. A package similarly has multiple common meanings as well.
In the context of Python programming, it can refer to a collection of modules. On the other hand, a package also refers to the units of software that can be deployed onto some Linux operating systems.
Modules, libraries, and packages are often overlooked in the security evaluation of software. Conventional software security evaluation is thorough and includes a number of different approaches to conducting assessments. SAST evaluates source code. DAST evaluates the code execution. Software testing can be driven interactively. Human experts examine software in code reviews. All of these approaches are thorough and comprehensive. However, there is a gap in the verification that one can trust the safety and security of these artifacts.
Modules, libraries, and packages as binary objects may not be subject to scans. The best a code review can accomplish is to evaluate their external aspects. Libraries and packages could contain malware hidden from testable functionality. How can you trust libraries and packages?
There are several things to consider with libraries and packages:
- Verification of the security software supply chain that produced the software
- Verification of trustworthiness of vendor
- Integrity and authenticity of all libraries and packages
- Black-box security assessment of libraries and packages
- Obtaining original source code for libraries and packages instead of binaries and treating as OSS
- Source security scanning and testing if source code is available
Software Updates and Patches
Software updates and patches could be considered an aspect of the first three categories of commercial off-the-shelf, outsourced development, or OSS; however, they are called out here because they deserve special attention with respect to the particular care required to address their safety and security assessment.
A cornerstone piece of guidance on how to improve software development security is to ensure that you keep your systems and software, from BIOS to applications, up to date and properly patched. Nonetheless, updating and patching do not come without their own concerns and consequences. The downside to updates and patches are that they can be malware infection vectors or could be defective and disrupt your business services or software environment.
In many respects, software updates and patches are the same as modules, libraries, and packages, as often the former come in the form of the latter and fundamentally it’s all essentially unknown code. Thus, the security considerations for software updates and patches are the same as for software modules, libraries, and packages. Consult the previous section for these concerns.
Software with Company Acquisition
When an organization merges with or acquires another organization, software comes with the deal. The acquired company most likely will have a variety of different types of software acquired. In a merger or acquisition transition, it is important to treat all of the software brought in with the situation the same as any other software acquired from a third party. Protecting against potentially dangerous code needs to be part of the transition proceedings.
Another concern when one organization acquired software another is that the new organization comes with its existing array of supply chains, customers, and partners and all of their software. Some (or all) of those parties might not have the same security focus or diligence for their software as your organization does. In such circumstances, business pressures to maintain existing systems, software, and configurations can potentially be problematic. It is important for the security professional to be aware of these factors and to address them with the appropriate parties.
