CYB 670 Proj 3 step 8

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