Regardless of the number of ways to acquire software, at a high level, the software acquisition process applies to all and consists of four stages, which are planning, contracting or procurement, implementation and acceptance, and follow-on. As a security practitioner, you should be aware of the steps in the software acquisition process and what security challenges each step poses. You should also be familiar with industry standards that pertain to the process and how each standard solves the security challenges for different situations related to the process, such as the impact it has in public versus private organizations, open-source versus commercial software, and any specific situations that your organization may face.
Planning
The planning process is indispensable because it clarifies and directs the real needs, options, solutions, risks, and vetting criteria into forms that translate into action. The planning phase consists of the following:
- Determining the need for the software or service to be acquired
- Identifying alternative solutions to acquiring software
- Identifying risks associated with acquiring software
- Developing clear requirements for the software or service
- Defining an acquisition strategy
- Defining evaluation and acceptance criteria
- Defining an evaluation and acceptance plan
- Identifying alternative options or vendors based on requirements, criteria, and plans
Contracting or Procurement
The contracting or procurement phase of the acquisition process is essentially a selection process. Depending upon the type of acquisition, it can follow one of two branches: contracting or procurement. Contracting is used if the software acquisition is to be an outsourced development project. Procurement is used if the software acquisition process is either COTS or OSS. Some people wonder why something that is freely downloadable needs to be procured, which is an understandable question. OSS is procured because it must be carefully selected, preferably from a trusted source.
The security practitioner should understand that the procurement process can vary by organization or type of organization. Public organizations such as governmental organizations often have a formal open evaluation process that works to remove preferential bias from product or service selection and determine their selection based on established nondiscriminatory and needs-based constraints. Private-sector company procurement processes are generally driven more by time pressures and specific quality outcomes more so than public organizations. The procurement process varies around the world, influenced by laws and regulations of the governing bodies that cover the participating parties.
Contracting
Contracting applies to outsourced development. The steps involved in the contracting phase generally follow:
- Evaluating and selecting a set of vendors from those that were identified in the planning phase
- Creating and issuing a request for proposal or solicitation to the vendors, which includes but is not limited to the following:
- Statement of work
- Technical requirements
- Terms and conditions
- Timeline
- Points of contact
- Budget
- Evaluation and acceptance criteria, acceptably modified for vendor’s eyes
- Evaluating vendors’ responses to requests for proposals (RFPs) or solicitation
- Selecting vendor(s) and finalizing contract negotiation with selected vendor(s)
- Awarding the contract
- Ensuring that the vendor is willing to make changes when required
All risks identified in the planning phase, as well as any discovered in the contracting phase, should be addressed with plans for their mitigation stated in a binding contract with the selected vendor along with the awarded contract.
Procurement
Procurement applies to COTS, OSS, libraries and packages, and updates and patches. The steps involved in the procurement phase generally follow:
- Evaluating and selecting:
- For COTS or OSS, a set of solutions from those that were identified in the planning phase
- For libraries and packages or updates and patches, the specific version of software that meets your needs
- Selecting and verifying a trusted source from which to obtain the software. For libraries and packages or updates and patches, this may already be established.
- Verifying the means of certification of authenticity and integrity of the solution from a trusted source:
- For OSS, this may be a process of obtaining a source code download from a trusted and approved source and verifying it against a checksum.
- For COTS software, this is purchasing a shrink-wrapped distribution that comes with a certification of authenticity from a trusted and approved vendor.
- Obtaining the solution distribution from a trusted source and verifying authenticity and integrity.
All risks identified in the planning phase, as well as any discovered in the procurement phase, should be addressed with plans for their mitigation stated in the acceptance and evaluation criteria and plans.
Implementation and Acceptance
When implementing software, packages, and updates, there are several things an organization can do to improve the security impact. Gathering and evaluating security information can help identify which software best meets the security needs of the organization before acquiring it. Establishing and validating a support contract with a trusted vendor ensures better support and open lines of communication for updates and patches. Developing and executing a test plan based on acceptance and evaluation criteria, including safety and security risks, can produce measurable results for evaluation.
Ongoing monitoring of security and performance can reveal problems that might otherwise go undetected.
When dealing with outsourced development, the organization has less direct control of some of these factors. In these situations, the organization can establish a baseline structure to the relationship with the vendor that includes an agreed upon schedule for deliverables, communication channels, and regular progress reports. This facilitates routine deliverables reviews, including security and testing reviews. Ongoing monitoring of security and performance also plays a role here, and in many organizations it is still possible to varying degrees to develop and execute test plans that include safety and security risks.
For each type of software, establish an isolated testing environment for testing purposes. This measure is to contain any negative effects of examining the software from being exposed to other environments.
Follow-On
For the software product under evaluation, follow-on activities are just as important as the initial planning, procuring, implementation, and acceptance. Ongoing maintenance, risk management, and configuration management all need to be performed regularly. Continuous monitoring of security and performance must be maintained. It is also important to routinely update information on security and status. And if any issues arise, it is necessary to request intervention from the vendor.
