Supply Chain Risk

Description: Step 9: Document Supply Chain Risks After review, its time to document supply chain risks. This portion of the overall report requires a two page narrative that addresses the following supply chain concerns: 1) Describe cybersecurity implications related to the procurement process. 2) Provide recommendations that would address these concerns. 3) Include appropriate supply chain risk management practices. Where appropriate, cite references to support the assertions in the recommendations and conclusion. Submit your report on supply chain concerns here for feedback Then, move to the next step, in which you will consider how the procedures of acquisition, procurement, and outsourcing line up in the organization. REVIEW ATTACHMENT FROM STEP 7 TO STEP 9 FOR MORE ON THIS PROJECT.

System Development or Application Assurance
Step 1: Assess Software Vulnerabilities
Project 1 outlined the steps involved to produce a final vulnerability assessment and
Project 2 covered risk analysis & mitigation. Those assessment were across the entire enterprise and included numerous elements outside the realm of systems and technology. However, they did uncover opportunities for improvement in the application software processes.
For this step, return to the vulnerability assessment from Project 1 and focus on all areas of application software that were itemized. Give additional thought to uncover software that perhaps did not make the list or were assumed to be secure and simply overlooked.
The assignment is to create a more comprehensive list of application software that could place the enterprise at risk of a breach, loss of data, loss of production, and/or loss of brand confidence.
The assessment should include the application of secure principles, development models such as the maturity model or integrated product and process development (IPPD), software development methods, libraries & toolsets used in the software development life cycle or systems development life cycle.
Use the Software Vulnerability Assessment Template to submit your results for feedback. In the next step, you will review your organization’s software procurement policy.

Risk Analysis and Mitigation
Risk analysis and mitigation is an important component of computer security in which you analyze risks to determine if there are any threats or vulnerabilities that could impact the integrity or security of networks or data.
Risks might include unpatched vulnerabilities, human behaviors, or emerging threats. Once a threat is identified, the next step is to develop mitigations to thwart or minimize the impact of the threat. Corrective actions include modifying or hardening security elements, changing security procedures, or limiting system access.
Testing and verification provides the opportunity to assess system security and affirm that system security is performing acceptably. An example is penetration (pen) testing, which is used to validate the system’s security, identify weaknesses that could put the system at risk, and recommend mitigations to address the vulnerabilities.
Pen testing can
• provide an assessment of the defenses in use
• assess the response capabilities of the personnel in the organization charged with protecting and defending the network
• evaluate the organization’s crisis response and any associated plans
• provide justification for the allocation of additional resources (people and/ortechnologies) for network security
• result in recommendations to address any vulnerabilities identified

Software Vulnerability Assessment Template

Application Software that Could Present Vulnerabilities

Add rows if needed.

Step 2: Review Software Procurement Policy
Upon completion of the software specific vulnerability assessment, conduct a review of the organization’s software procurement policies for software development methods.
Note that there is no submitted assignment for this step. Your review will be used in the submission for the following steps.
When the review is complete, move to the next step, where you will create a table or spreadsheet that lists recommended policies for software procurement that address certain questions or concerns.

Step 3: Create a Software Procurement Policy List
You’ve reviewed the organization’s policies for software development methods. Now it’s time to create a policy list for software procurement. The following are some sample questions to be included in a software procurement policy:
• Does the vendor provide any cybersecurity certifications with the product?
• Does the vendor provide access to the source code for the product? Are there other security issues in source code to be addressed?
• What is the guaranteed frequency of security updates to be provided for the product?
• What is the implementation process for software updates/upgrades?
What are additional questions or concerns that should be included in the procurement process? Create a table or spreadsheet that lists recommended policies to properly address these questions or concerns.
Use the Procurement Policy Template to list the cybersecurity implications related to procurement and supply chain risk management and submit your results for feedback. In the next step, you will generate assurances or controls to address each of the policy issues identified here.

Security Issues in Source Code
The security issues of source code depend on a number of factors, including the integrity of the processes used to develop the source code from a perspective of human practices as well as the development environment itself.
Source code is susceptible to many of the same threats that exist for networks and operating systems, including the use of malware to corrupt and/or exploit the source code. There are controls that can be used to minimize threats to source code security. Such controls include having sufficient backup procedures so that prior versions of code are retained, and separating environments to protect the source code by isolating its development.
Security controls that can be used for source code development include process isolation and memory protection, which segregate processes and storage for enhanced protection. Password protection techniques can be used to reduce the potential for the exploitation of passwords. Such techniques can include the requirements for the frequency of password changes, password length and composition, and layers of access with appropriate password controls.
Sandboxing, or isolating source code development to a stand-alone environment, protects both the development of the source code itself as well as the involvement of other network assets in any security issues. Ultimately, there are a number of adequate security controls for source code.

Procurement Policy List Template
List appropriate procurement policies to address concerns in the process of software evaluation and acquisition.
Procurement Policy List

Add rows

Step 4: Document Relevant Software Acceptance Policies
Now that the procurement policies have been identified in the previous step, what assurances or controls should be established as policy that would evaluate the security implications during the software acceptance process? The objective is to provide a one-page overview of security testing that would be included in the acceptance of a vendor’s application.
The next step in this project will document the actual testing and validation. This step is simply to verify the congruence between the procurement process and acceptance process. In other words, do the procurement policies establish the correct cyber security framework for software purchase and do the acceptance policies match?
In considering the security implications of the in the software acceptance phase of the development cycle, use the Software Acceptance Policy Template to document recommended tests and assurances for the procurement policies identified in the previous steps.
Software Acceptance Policy Template
Test Script Procedures for Software Acceptance
Copy the policy list from the previous step into the column on the right. In the column on the left, document your recommendations for specific testing steps to address each of the policy concerns.
Procurement Policies
Test Script Procedures for Software Acceptance

Add rows.

Step 5: Research Software Testing and Validation Procedures
Based on the software acceptance policies created in the previous step, consider what testing and validation procedures could be used to assure compliance.
Note that there is no submitted assignment for this step. You will submit the final list of recommended testing and validation procedures in the next step.

Step 6: Document Software Testing and Validation Procedures
You’ve completed the research, and it is now time to create testing and validation procedures that follow a specific process to assure compliance. The key to the success of this step is to document exact procedures to be followed by a testing team prior to installation.
At a minimum, the procedures should address the following questions:
• What are potential vulnerabilities inherent in the application platform?
• How well does the vendor document preventive measures built into the application?
• Are there alternative solutions provided by the vendor or in the application in case of a breach?
• What additional safeguards can be added to ensure the security of the software environment?
The testing and validation procedures should address each of these concerns.
The executive team will want to see specific steps for the testing team to follow as the team members complete the tests and assurances you recommended in the previous step.
Document your specific testing and validation recommendations from a cybersecurity policy standpoint in the Test Script Procedures Template and submit for feedback. In the next step, you will consider procedures for upgrading software.

The Software Environment
The software environment includes processes, languages, security features, and development models that together deliver security, flexibility, and functionality. Security is paramount in software environments, as it can assure the integrity of the software, ensure that the software performs as designed, and can audit and log software modifications.
Object-oriented components, processes and systems are geared toward objects and data. “Object-oriented (OO) technology has emerged in recent years as the clear choice for developers of large, dynamic applications. OO technology allows developers to encapsulate data and operations in units called objects. Each object is independent of others, and groups of objects cooperate to solve specific problems” (Cobb & Shaw, 2000). Examples include object-oriented security, object-oriented security and object-oriented programming.
Software development environments include open source and off-the-shelf. An open-source environment involves software development conducted collaboratively by multiple independent entities. While the rights to the resultant software may be owned by a single entity, the source code continues to be made available for editing through licenses. The benefits of open source include the potential for enhanced and more diverse creativity. Security is a concern with open source; however, proponents of open source argue that with a diverse set of contributors, the likelihood of finding malicious code is increased in the open source environment. Still, there is a strong open-source community comprised of experts and volunteers who advocate for open development and collaboration.
In contrast, off-the-shelf software is generally proprietary software that is developed, owned, and controlled by one entity, which also solely develops new features and tests for security. While configuration control is generally not at issue, cost, requirements, and security remain areas that must be carefully considered. Additionally, owners/developers of proprietary software are generally limited in the resources available to address bugs or security issues, potentially delaying the development of patches and increasing the potential for vulnerabilities to be exploited.

Test Script Procedures Template
Copy your list from Step 2 into the first column.
Procurement Policy Concern
Specific Testing Recommendation to Address Each Policy Concern

ADD ROWS
Step 7: Review Software Upgrade Procedures
In the last step, you documented testing and validation requirements. In this step, it’s important to review software upgrades. Installation of a software upgrade has similar, yet unique requirements from the previous steps. In most enterprise environments, software updates and upgrades follow a specific change management routine. However, complete reliance on this procedure can lead to unintended oversight of cybersecurity issues. The change management process is generally focused on detecting errors and the auditing and logging of changes in the operational environment after the upgrade has been performed.
From the cyber perspective, this is not enough. As demonstrated in previous steps, significant effort is required to ensure a secure environment, not just an operational one. The question to be answered is “when” should the upgrade be performed during an application or system change. Should it be performed multiple times during the update?
Think through this issue thoroughly and make notes on your thought process. It is important that the risk analysis associated with an application or system change is conducted at the optimal time.
Note that there is no submitted assignment for this step. However, the research and corresponding notes related to to this step will be applicable to the final report for Maria and the other executives. When this is complete, move to the next step, where supply chain risks will be considered.
Step 8: Review Supply Chain Risks
Following the previous steps relative to the supply chain and previous projects, it is time to thoroughly review risk within the supply chain.
Like many companies, your organization is dependent on a supply chain, so the software development process must include a supply chain risk management (SCRM) plan to minimize the impact of supply chain-related risks on business operations and the security of the infrastructures and data.
Note that there is no submitted assignment for this step. The identified supply chain risks will be reported in the next step.
Step 9: Document Supply Chain Risks
After review, it’s time to document supply chain risks. This portion of the overall report requires a two page narrative that addresses the following supply chain concerns:
1) Describe cybersecurity implications related to the procurement process.
2) Provide recommendations that would address these concerns.
3) Include appropriate supply chain risk management practices.
Where appropriate, cite references to support the assertions in the recommendations and conclusion.

Submit your report on supply chain concerns here for feedback. Then, move to the next step, in which you will consider how the procedures of acquisition, procurement, and outsourcing line up in the organization.