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, focus on all areas of application software. 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

 

Software Vulnerability Assessment Template

Application Software that Could Present Vulnerabilities

Note: You can add more rows to the bottom of the table 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

Procurement Policy List Template

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

Procurement Policy List

Note: You can add more rows to the bottom of the table if needed.

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

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 Policy List	Test Script Procedures for Software Acceptance

Note: You can add more rows to the bottom of the table if needed.

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 

Test Script Procedures Template

Copy your list from Step 3 into the first column.

Procurement Policy Concern	Specific Testing Recommendation to Address Each Policy Concern

Note: You can add more rows to the bottom of the table if needed.

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:

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.

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

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.

Supply Chain Risk Mitigation Final Report Template

In this report, use applicable systems, tools, and concepts to minimize risks to an organization’s cyberspace and prevent cybersecurity incidents.

Maria and the other executives at your organization will be looking for a final report that applies security principles, methods, and tools to the software development life cycle. They are also seeking your ideas and recommendations concerning any potential cybersecurity implications related to procurement and supply chain risk management.

Supply Chain Risk Mitigation Final Report (five to seven pages using this template)

The report should include the following components:

The headings for the report are:

• Title Page
  • Include:
    • for whom you are preparing the document, the title, the date prepared, and your name as the preparer of the document
• Table of Contents
  • with all sections
• Overview
  • Include:
    • introduction and purpose of the report
• Software Vulnerability Assessment (one-column table from Step 1)
  • comprehensive list of application software that could present vulnerability concerns
• Procurement Policy List and Acceptance Procedures (two-column table from Step 3)
  • Policies of concern and specific procedures to test them
• Testing and Validation Procedures (from Step 6)
  • Include specific testing and validation recommendations
• Supply Chain Cyber Security Risk (two- to three-page report, Step 9)
  • Include:
    • identified cybersecurity risks in the procurement process of the supply chain concerns and security recommendations.
• Acquisition Alignment (one-page report: Step 10)
  • Include:
    • recommendations for alignment of the supply chain processes from start to ongoing maintenance
• Software Risk Mitigation Recommendations (two- to three-page report, Step 12)
  • Include:
    • proposed software risk mitigation recommendations