Step 8: Submit IT Operations and Risk Management Briefing
Step 8: Submit IT Operations and Risk Management Briefing
As a synthesis of all prior steps in this project, you will now develop and submit the first component of your deliverable to your CISO: the
Cyber Operations and Risk Management Briefing. The briefing will consist of a written evaluation and video presentation. Each team member should develop his or her own briefing and submit independently. You may, however, use your team’s discussion area to share your findings with your peers. Refer to the
CISO Deliverable Overview
for a full list of requirements for the briefing.
Research and evaluate the maintenance requirements for each option identified in the software development matrix you submitted in the previous step. What resources and processes are required for each option? You should also address the schedule to implement the recommended software and identify any potential impacts to the mission, any vulnerabilities or risks, and the likelihood of success.
Your video presentation should brief organizational stakeholders on your research, evaluation of alternatives, and recommendations.
Submit your briefing for review and feedback.
To submit your briefing:
· Follow the instructions below to submit the written portion of your briefing.
·
How to submit the video: To submit the video, you may either upload it to OneDrive using your UMGC account or upload it to a video-sharing service. Once you have uploaded the video, copy the link and include it in a document or in the assignment folder.
Now that you have completed the briefing and video, it’s time to turn back to the situational reports that you and your team have been compiling for the CISO.
Course Resource
CISO Deliverable Overview
This document contains full details for each final assignment to be assessed, as well as guidelines for video submissions.
As a synthesis of prior steps and interim submissions, you will be assessed on the following assignments:
1. Cyber Operations and Risk Management Briefing
2. Intelligence Debriefing
3. Lessons Learned Video Presentation
4. Next Steps for the Computer Security Incident Response
1. Cyber Operations and Risk Management Briefing
Using the Software Development Life Cycle Assessment and Software Development Matrix you create during the project, you will develop a
Cyber Operations and Risk Management Briefing for your nation’s CISO and other stakeholders. The briefing will consist of a written evaluation and video presentation. The briefing should include each of the following items:
· identification of the software assurance needs and expectations of the organization
· description of the key attributes of the current software development life cycle (SDLC)
· identification of any known supply chain risks
· identification of vulnerabilities in the existing software used
· identification of software options that could meet the organization’s needs
· evaluation of software options and recommendation(s) for your organization, with each supported by a rationale
· evaluation of supply chain options and recommendation(s) for your organization, with each supported by a rationale
· explanation of the costs involved in your recommendations
· recommendations for contract language that would be used to ensure that supply chain, system, network, and operational security were met
Use the dropbox to submit the written portion of your briefing.
To submit your briefing:
· Use the dropbox to submit the written portion of your briefing.
·
How to submit the video: To submit the video, you may either upload it to your OneDrive using your UMGC account, or upload it to a video-sharing service. Once you have uploaded the video, copy the link and include it in a document or in the dropbox text field.
2. Intelligence Debriefing
Using the Business Continuity Plan and Situation Reports you created throughout the project, you will create an
Intelligence Debriefing and a
Lessons Learned Video Presentation to share with your CISO.
This report will be from all information from all events that occurred during the summit. In the report, it will detail all technical information that was derived and any linkage to impacted systems identified in the BCP, possible methods of intrusion, and if events can be linked to one another. Write eight to 10 pages describing the events throughout the summit and all indicators shared by fellow nations. Determine what the malware types were and how they can be discovered in the future, and how they can be mitigated whether by detection systems or simply by having end users take awareness training.
Items below are required in the report for technical staff.
· current system standings
· modifications that can be made to stop this style of threat until a patch is created
· reputation and brand damage
· lost productivity due to downtime or system performance
· system availability problems
· determining root causes
· technical support to restore systems
· compliance and regulatory failure costs
3. Lessons Learned Video Presentation
As a synthesis of the prior steps in the project, you will create a
lessons learned video presentation to share with your CISO.
Create a five- to 10-minute video/PowerPoint voice recording that would be presented to the CISO and the nation’s leader concerning attacks, evidence acquired, attribution, impact, business recovery, and remediation success. Areas that should be discussed are defined below.
Use this opportunity to describe not only what occurred during the attack and the results of evidence items but also how operations and communications can be done in a secure fashion. Also describe the need for information sharing and how it can be possible between nations and private business operations without source attribution. Is source attribution needed?
Use this opportunity for any lessons learned throughout the project that IT staff can take back to business units to incorporate into daily operations. Recall the threats you received. If you were the leader of the group, what would you want the CISO to know in case of an event? What could have been identified earlier as a critical system that may have been protected? Also, take a look back at your team’s BCP and discover any setbacks that may happen once an event occurs. Describe any additions or changes that you would incorporate in the plan. Describe the following information in your video at a minimum and additional topics that could better the operational tempo of business units.
Recovery: How the incident was contained and eradicated
· The work performed during recovery
· Areas where the incident response team was effective
· Areas that need improvement
· Which security controls failed (including monitoring tools)?
· How can we improve those controls?
· How can we improve the security awareness programs?
· What were the current operating system vulnerabilities that were leveraged to execute the attack?
· How can managing patches and basic operating system security enhance security from known threats?
To submit the video: You may either upload the video to OneDrive using your UMGC account, or upload it to a video-sharing service. Once you have uploaded the video, include the link in a document and submit it using the dropbox provided.
4. Next Steps for the Computer Security Incident Response
Written recommendations based on the results of an incident response investigation need to be developed to support the organization’s security assessment and training efforts. Your team needs to further develop your recommended “next steps” (from Step 10, SITREP 3). Your deliverable will be to write a report on malware, encryption, ransomware, and communications and network security to inform the CISO and CISO staff about the next steps that should be taken.
Your deliverable will be an assessment that consists of explanatory material to aid organizational leadership in understanding malware and system infections, and the investigative report that summarizes findings from the SITREP to substantiate whether a specific incident qualifies as ransomware. The report documents what is known about the Reveton malware and should provide concrete steps for protecting the organization and its computer systems from future attacks.
© 2023 University of Maryland Global Campus
All links to external sites were verified at the time of publication. U
Project 3, Step 7: Business Continuity Plan
Team United Kingdom: Michael Arizieh, Julian Chandler, Justin Basagic, Ayman Gismalla Mohammed, Oluwasegun “Saji” Ijiyemi
University of Maryland Global Campus
CMP 670 9047 Capstone in Cybersecurity (2231)
Prof. Thaddeus Janicki
Feb 25, 2023
Table of Contents
Table of Contents………………………………………………………………………………………………..……………………..2
Introduction
………………………………………………………………………………………………………..……………………..3
Development Methodologies
…………………………………………………………………..……………..………………….3
Phases of Software Life Cycle………………………………………………………………………………..……………………5
Software Development Matrix….………………………………………………………………………………..………………7
Ad-Hoc Wireless Network………………………………………………………………………………………………..………..9
Ransomware Preparation…………………………………………………………………………………………………..………9
Incident Response Plan……………………………………………………………………………………………………………..10
Conclusion………………………………………………………………………………………………………………………………..12
References……………………………………………………………………………………………………………………………….13
Introduction
The process, procedures, or phases used to create a model for the development of software or/and its life cycle management are referred to as a software development life cycle (SDLC). It includes all of the early phases, including analysis and model creation, through to the software’s ultimate implementation and the ensuing post-development management process, including assessment and testing. Every software’s intended ultimate purpose is taken into account during development. There is a lot of processing and computing involved in the actual development of the software. Hence, a process overview document defining the process’s scope and complexity is required. By doing this, it is made sure that the finished software is highly reliable and functions as planned.
Development Methodologies
Software development approaches for common software come in a variety of forms. Different businesses must utilize different approaches, however in order to implement software successfully, a company must follow a standardized software development methodology. The various kinds of software models include:
There are six phases to the widely used waterfall software development paradigm, which is distinguished by not returning to a stage from earlier in the process. It might not be possible to complete each phase independently in practice. But, it is possible—and even necessary—to go back and redo earlier processes if the functional requirements have changed or if there is a need for improvement. As a result, the waterfall model’s foundation has been used to build additional life cycle models. The waterfall approach is widely employed in real-world situations, especially when creating large-scale business software systems. Its application can be traced back to the industrial industry’s software development procedures.
Agile software development has benefits and drawbacks, but one benefit is that a model of the system is available early on, making it simpler to identify any functional or design faults. In order to satisfy clients, this also takes into account their requirements. Likewise, like other approaches, it takes into account the needs, suggestions, and project satisfaction of the client. The primary distinction is that the agile development method does not explicitly identify the software’s final product from the beginning.
The waterfall and extreme programming development go hand in hand. However, the stages are shorter than usual because the software engineers concentrate primarily on one key component of the software system at a time.
The SDLC version known as rapid application development is not recommended for building complicated apps that will process large numbers of transactions. This is because the FFIEC’s methodology requires a software procedure that could take 30 to 90 days to complete.
Phases of the Software Life Cycle
The following steps are included in the seven-step software development life cycle:
Define the project. The project’s concept must be explained in the first phase. It entails defending the project’s need as well as outlining the goals it seeks to achieve. This phase involves conducting a feasibility study to identify the project’s objectives and how they will be achieved.
Defined user needs. The intended use and features of the software are defined in the second stage of the SDLC. In order to build features to be incorporated in the graphical user interface, such as screen layouts, business rules, process diagrams, pseudocode, and other documentation, it is early in the process and should involve consulting the end user.
Definition of system requirements. The third phase in the SDLC for project scope definition is this one. Documentation for the desired software capabilities is begun. Work plan flow charts are created for the team. The expected expenditures and required resources for the project’s execution.
Design and analysis. The definition of the software’s structure and key components is the following phase. The system’s whole set of input and output mechanisms is described. Furthermore, the databases’ content is constructed.
Software construction and testing. The fifth step is the software’s coding. The created design is converted into a form that the computer can execute in this programming activity. It also involves the building of the database for the software. After the software is created, it is tested to identify and correct any problems or errors that may have been introduced during the development process.
Installation and instruction. This is the following step, which entails data conversion, final testing, software manufacturing, and the acquisition/purchase of the necessary software/hardware. After the software deployment, the end users are instructed on its operation, including how to make input, receive output, and utilize its general features.
Operation. This concludes the seven-step SDLC model. It requires a comprehensive view of the whole life cycle of the model. In this step, long-term software risks are considered. This includes critical system updates and protection against future compromises, such as infiltration.
Software Development Matrix
Table 1: Software Development Matrix.
Software Development Methodology
Pros and Cons
Software Assurance Concerns
Waterfall Model
Pros: Effective for less experienced teams, cost effective, progress of system development is measurable
Cons: inflexible, slow, costly, cumbersome, little room for use of iteration, no room to move backwards, only forward
A methodology that prevents developers from moving backwards to earlier phases and only permits them to work independently on one phase at a time raises questions about its viability..
Prototype Model
Pros: compared to other models, it is more flexible and open to change, excellent for addressing confusing objectives, and it is more experimental.
Cons: The lack of a strong approval procedure and supervision, frequent substantial requirements changes, and maybe inadequate documentation
If the team utilizing the model lacks experience, there may be issues because it could lead to more “prototyping” than true system design.
Agile Software Development
Pros :Eliminates “silos” between team members, makes it possible to find new requirements as work is going on, and is adaptable and customer-focused.
Cons: They demand a lot of resources, need intense collaboration and communication, and have less predictability in the final outcome than more structured models.
It could be challenging to achieve a desired end state once the process is finished because the Agile development model lacks strict constraints and a set timeline. Teams must maintain discipline to make sure that the system’s original goal is achieved even when additional requirements are added. Moreover, it is not a particularly useful paradigm for handling big tasks.
Rapid Application Development
Pros: flexible, encourages and prioritizes customer feedback, development time is reduced, integration is involved from project inception.
Cons: works best with smaller teams, is challenging to administer, necessitates talented developers, and is pricey.
This model depends on the client being accessible to test prototypes, therefore in comparison to some of the other models, it necessitates greater involvement from the end user, which is not always feasible.
Dynamic Systems Development
Pros: emphasizes the importance of focusing on the clearly defined strategic goals, prioritizes the early delivery of actual advantages to the business, makes progress across the organization simple to understand, and ensures that projects are delivered on time while yet allowing for some flexibility.
Cons: high managerial overhead, expensive implementation, ineffective for small enterprises, and less adaptable than other iterative procedures.
Although still an iterative style of development, this technique is substantially less flexible than other iterative models because of the strong emphasis on corporate objectives.
As a result, this procedure will enable you to achieve your goals, even though more optimal answers might be discovered as you go along.
Spiral Model
Pros: The combination of linear and iterative processes improves risk mitigation and helps identify the optimal methodology to apply in a project when it is initially unclear.
Cons: Choosing the ideal methodology might be challenging due to the variety of options available, the need for a qualified project manager, and the limited potential to reuse due to each project’s intense customization.
Due to this methodology’s high degree of adaptability and flexibility, if a competent project manager is not in charge of overseeing software development, it is likely that a less than perfect model will be chosen for the project. It raises questions to use this methodology with a team of inexperienced individuals.
Extreme Programming
Pros: modifications may be done with very little notice, constant testing aids in the development of stable software, and close customer interaction is maintained.
Cons: Very resource-intensive, demands significant customer involvement, and calls for a disciplined team to stay on track with the original goals.
When working on projects, it’s crucial to have a structured team in place because of this method’s dynamic nature. Without discipline, the dynamic nature of this paradigm can cause the team to deviate from the intended results at first.
Feature-Driven Development
Pros: Features sets are broken down into smaller chunks and iterative releases, making it easier to track and solve potential errors. Pros: user-centric approach; works well with large-scale projects.
Cons: lack of written documentation, preference for individual code ownership over team ownership, and not suited for smaller projects.
The end user may not receive adequate documentation, which could lead to assurance problems resulting from an uneven adoption. The intended result may have been coded, but it may not have been used by the business if the software development team does not take the time to discuss functionality with users.
Joint Application Development
Pros: Strongest emphasis on collaborative collaboration between end users and the developed model, efficient for developing and achieving well-defined requirements, group collaboration typically speeds up completion.
Cons: Goal alignment may be challenging due to differences in opinion, and a strong emphasis on collaboration may distract users from routine tasks.
The main issue with this model is that by aggressively involving end users in the development process, opposing opinions between end users or between end users and developers may hamper the team’s ability to stay focused and achieve desired results.
Lean Development
Pros: prioritizes waste reduction and optimization, delivers quickly, is inexpensive, and is easily scalable
Cons: Requires a large team, high skill level, and robust documentation
As there are fewer subteams in this model, there must be strong coordination between them all, hence it is crucial that every team has the necessary work ethic and skill set.
The project as a whole will fall apart if any team struggles to complete its task.
Rational Unified Process
Pros: The waterfall method of breaking projects into four distinct phases has the advantage of encouraging more stakeholder feedback and being adaptable to change.
Cons: Despite its iterative nature, the process is still rather rigid and can overly rely on stakeholder feedback. It also moves very slowly.
Although there are instructions and resources available online on how to handle the process, the main issue with using this approach is that it is still a highly complicated and chaotic process. It will take a disciplined team to make sure that project deliverables are met. The team must also keep working toward the initially agreed-upon results while depending on stakeholder feedback and preventing feedback from derailing the project’s initial goals.
Scrum Development
Pros: include being rapid and effective, breaking down development projects into small portions, improving team visibility through daily meetings, and incorporating stakeholder feedback.
Cons: lack of a set completion date; high cooperation requirement; challenging for large teams; daily meetings may be annoying to team members; requires experienced team members.
The main problems with scrum development are related to the fact that, like some of the other models mentioned, it necessitates efficient teamwork. The project as a whole may be in peril if one team member fails to perform. The lack of a clear end date may also result in instances where the project deliverable is outdated by the time it is finished.
Normal operating standards, practices, and procedures for operating systems in businesses need to have the right plans in place so they can deal with problems that come up because of emergencies or disasters that can hurt their operations, such as delaying transactions or shipments of goods. Private companies and government agencies in the United Kingdom face cyber security vulnerabilities that pose challenges to successfully do their jobs. To deal with these network-related risks, they need IT specialists to collaborate on incident response teams that investigate cyber-attacks. Malware attacks frequently look at how susceptible their victims’ systems are to come up with ways to infiltrate target systems. However, IT experts can track such incidents from the beginning by using the proper investigative steps. Most network-related attacks come from former employees who used to work for the organization or from current employees who pose an internal threat and can work with cyber criminals to set up malware attacks. Even though BCP should involve all stakeholders in an emergency, the steps in the plan don’t control what attackers do. Instead, they give management teams the chance to take the necessary steps during a crisis and get things back to normal as one way to recover through operating system protections.
Ad-hoc Wireless Network
Even though using an ad hoc wireless network for this Global Summit is useful, it poses a security risk to the network security. Peer networks, which are what most people call ad hoc wireless networks, are comprised of nodes that allow devices to talk with one another without a central device. The wireless router used for secure communications on an ad hoc wireless network must be set up on the same wireless channel and have the same service set identifier (SSID). Because there are centralized devices at this global summit, the infrastructure mode would be set up. With so many mobile devices around, it is important to be able to share files easily and directly with other users. This type of network, however, can quickly become overburdened in a conference type scenario.
Ransomware Preparation
Ransomware can have a crippling effect on the system tools and especially at a conference type situation. Team UK would set rules that would flag any type of abnormal data running through the network. This could be abnormal get requests, or devices trying to call out to malicious IP addresses. Conduct an investigation into the origin of the attack and what data has been compromised and make a response plan. The ransom should not be paid under any circumstances, because there is no guarantee that the attackers will return the systems to their normal state safely.
Incident Response Plan
The process of making plans for what to do in case of a security incident is called incident response planning (IRP). Think of IRP as a process that is both proactive and reactive. Creating an IRT plan is a thorough process that we will only briefly touch on here.
The proactive way to respond to an incident is a resource intense process that ensure an organization is ready to respond to an incident. On the proactive path, employees are trained, specific notification procedures are made, and specific roles, responsibilities, and teams are assigned.
Response to an incident is a reactive process with four main themes: preparation, detection an analysis, containment, and post-incident activity.
Before sounding the breach alarm, make sure that there has been a real attack and not just a technology error or failure. The process will continue if the event is then labeled as a verified incident. After the breach has been confirmed, the type of breach must be found.
Finding out what kind of breach it is will help figure out what kind of resources will be needed to help fix it and who to tell. After the type of breach is known, the code, or level of seriousness, of the incident must be stated. By figuring out what kind of incident it is, the incident response team will be able to follow the right steps to deal with it.
During the detection and analysis phase itself, data is gathered that will be used in the analysis stage. Detection means getting information from IT systems, security tools, publicly available information, and people inside and outside the organization.
Analysis means the organizations needs to set up a baseline for the affected systems, flagging events, and seeing if and how they differ from normal behavior.
Containment means to stop an attack from spreading or from being as bad as it could be. As part of the containment process, it is important to find the host that is attacking and confirm its IP address. The Post-Incident Activity phase is the fourth step in the incident response policy. During this phase, data is collected, including, but not limited to, audit logs, inventory logs, video evidence, account activity, system activity, and any other information that might help find the cause of the incident.
Table 2. Incident Response Flow
Conclusion
Team UK learned a number of valuable insights into the software development life cycle and the different methods used to develop software. We learned the pros and cons of the different methods and will carry that forward into recommendations to the CISO. Our team researched wireless networks and the risks associated with them and potential avenues to mitigate those risks. Team UK also learned about Incident response plans and the importance of the incident response flow chart and how each step relates to the other.
References
#1 leading software professionals. Software Development UK. (2022, January 10). Retrieved February 28, 2023, from https://www.softwaredevelopment.co.uk/blog/what-is-software-development/#:~:text=The%20software%20development%20life%20cycle%20can%20be%20broken%20down%20into,testing%2C%20deployment%2C%20and%20maintenance.
Mitigating malware and ransomware attacks. NCSC. (n.d.). Retrieved February 28, 2023, from https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks
Mitigating malware and ransomware attacks. NCSC. (n.d.). Retrieved February 28, 2023, from https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks#stepsifinfected
Network architectures. NCSC. (n.d.). Retrieved February 28, 2023, from
https://www.ncsc.gov.uk/collection/device-security-guidance/infrastructure/network-architectures
NIST Incident Response Plan: Building your IR process. Cynet. (2022, December 1). Retrieved February 28, 2023, from https://www.cynet.com/incident-response/nist-incident-response/
Secure development and deployment guidance. NCSC. (n.d.). Retrieved February 28, 2023, from https://www.ncsc.gov.uk/collection/developers-collection
image1
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
