USA: +1(669)289-8683 
Sign in
Project 4:
System Development or Application Assurance
Start HerePrint Project
It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an organization’s cyberspace and prevent cybersecurity incidents. In this project, you will demonstrate your understanding of how to apply security principles, methods, and tools within the
software development life cycle
. You will also apply your knowledge of the cybersecurity implications related to procurement and supply chain risk management.
This is the fourth and final project for this course. There are 13 steps in this project. Begin below to review your project scenario.
Transcript
System Development or Application Assurance
Your vulnerability assessment has been completed, and it’s a good thing, because you found several system weaknesses in the area of application software security.
If these weaknesses were exploited, it could ruin your company’s reputation. Not to mention causing major disruptions to operations and unexpected costs.
You plan on following up on these issues this afternoon, but it’s about lunchtime, so you head out for a quick bite to eat.
You pass by Maria Sosa’s office and see her at her desk. You knock on her door frame, peek inside, and ask if she has a minute. Maria motions to you. “Come on in.”
“What brings you to my office?”
You give her a high-level overview of your findings, and tell her that after lunch, you plan to start taking an even closer look.
Maria says: “That sounds great. Can you write up your analysis and recommendations for solutions? I’d like to share this with important stakeholders at the executive meeting next week. How does that sound?”
You nod in agreement. Then you make a beeline back to your office and grab an energy bar from your desk. You need to prepare for your presentation for the meeting next week.
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. (ATTACHED)
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.
Software Vulnerability Assessment Template
Application Software that Could Present Vulnerabilities
Note: You can add more rows to the bottom of the table if needed.
2
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.
2
Course Resource
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
o 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
o with all sections
Overview
o Include:
▪ introduction and purpose of the report
•
•
•
•
•
•
Software Vulnerability Assessment (one-column table from
Step 1)
o comprehensive list of application software that could
present vulnerability concerns
Procurement Policy List and Acceptance Procedures (twocolumn table from Step 3)
o Policies of concern and specific procedures to test them
Testing and Validation Procedures (from Step 6)
o Include specific testing and validation recommendations
Supply Chain Cyber Security Risk (two- to three-page report,
Step 9)
o Include:
▪ identified cybersecurity risks in the procurement
process of the supply chain concerns and security
recommendations.
Acquisition Alignment (one-page report: Step 10)
o Include:
▪ recommendations for alignment of the supply chain
processes from start to ongoing maintenance
Software Risk Mitigation Recommendations (two- to threepage report, Step 12)
o Include:
▪ proposed software risk mitigation recommendations
