CMP 630 UMGC Assess Software Vulnerabilities Paper

Step 1: Assess Software Vulnerabilities

Project 2 outlined the steps involved to produce a final vulnerability and threat assessment, and Project 3 covered risk analysis and mitigation. Those assessments 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 and threat assessment from Project 2 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 and 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.

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.

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.

Submit your results below for feedback.

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.

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 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- to three-page narrative that addresses the following supply chain concerns:

Describe      cybersecurity implications related to the procurement process.

Provide      recommendations that would address these concerns.

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.

Step 10: Consider Alignment Issues

Based on the review and recommendations on the supply chain described in the previous step, consider how well the policies and procedures regarding the acquisition, procurement, and outsourcing of software in your organization are aligned.

Outline a strategic approach to getting all the functions in alignment. There is no submission for this step. The alignment recommendations will be submitted in the next step.

• Step 11: Develop an Acquisition Alignment Report

Keeping the alignment issues in mind from the previous step, prepare a one-page plan to align acquisition, procurement, and outsourcing of software applications for the enterprise. This should be a strategic approach to getting all the functions in alignment. Start with a request for information, proceed through acquisition, testing, and implementation, and finish with ongoing maintenance of the application.

• All the work has been done in the previous steps. This step is designed to “bring it all together” in one easy-to-understand approach. The approach will be used in the final step to complete the supply chain analysis with a mitigation plan as it applies to software acquisition and maintenance.

Submit your one-page plan to align acquisition, procurement, and outsourcing efforts with your organization’s information security goals here for feedback.

• Step 12: Consolidate Your Work

The acquisition plan alignment is complete. For this exercise, collate all the material presented in the previous steps into a cohesive presentation that describes the entire software risk analysis processes and articulates specific supply chain cybersecurity threats and the technologies and policies that can be used to mitigate them.

• You will use your consolidated results in your final project submission in the next step.

Step 13: Write the Risk Analysis/Supply Chain Threats/Mitigation Report

Management is always interested in solutions, and Maria Sosa and the other executives at your company are no exception. In the case of cybersecurity, there are no absolute solutions to an ever-changing environment. However, there are steps to mitigation that might eliminate or minimize the results of certain vulnerabilities. This final step is to describe the mitigation strategies recommended as a result of all previous steps in the project.

The final report for the executive meeting should be five to seven pages, only one to two of which will have to be written in this step. The remainder is from all the previous steps in the project.

Use the Supply Chain Risk Mitigation Final Report Template to submit your specific testing and validation procedures.