Software Development Life Cycle Assessment
Due to the increasing volume of cybersecurity incidents caused by bad actors, organizations, there is a pressing demand for organizations to protect their information systems and networks. One type of cybersecurity attack that has caused havoc on organizational information systems and networks is the ransomware attack, where organizational information and data assets are locked up and held for ransom by an attacker. To address this type of attack on the critical infrastructure, a plan to address ransomware that includes its prevention, mitigation strategies, and procedures to restore system services if an attack was successful. A business continuity plan (BCP) must be detailed to include a network diagram of the critical systems, incident response planning that includes incident reporting procedures, encryption policies, and disaster recovery procedures. A BCP will be robust enough to restore network and information services in a reasonable amount of time following a successful ransomware attack that has taken systems offline.
As a part of BCP, this document discusses the Software Development Life Cycle (SDLC), as one of the major impacts that support viable and resilient cybersecurity posture, especially for organizations who are involved in the development and deployment software that is developed in-house for use throughout their information systems network. Since a robust BCP plan is essential to sustain the viability and operational effectiveness of the network, the software must be developed securely to eliminate or significantly reduce its exposure as an attack vector.
Business Continuity Planning (BCP)
The BCP describes the policies, standards, best practices, and normal operating procedures for operating systems, application systems, and critical systems deployed on the Canadian information systems network. BCP provides direction for viable software design and deployment that will assist the developer to protect systems against malware, viruses, memory-based attacks, DoS/DDoS (Denial of Service/Distributed Denial of Service) attacks, and other cybersecurity risks. Further, BCP discusses suitable testing, active and passive monitoring of executed programs, and continuous monitoring of data that transitions the network.
Software Development Life Cycle (SDLC)
The Software Development Life Cycle (SDLC) is a systematic and linear process, used as one of the many models, by the software development industry to design, develop, test, deploy, and retire software. The intent of using the SDLC is to produce high-quality software that addresses the user’s needs. The SDLC can be applied to operating system development, application system development, and has been reported as one of the models that can be applied to hardware and software configuration project (Crnkovic & Larsson, 2006).
At the onset of a project, the SDLC is initiated to document the initial design concept. Through its linear process, the project is refined, developed, tested, deployed for the users to use, and is ultimately retired once the project has met reasonable end-of-life. The SDLC is often referred to as Waterfall Model since the SDLC emphasizes a logical progression of steps similar to the direction water flows from one phase too, which suggests that each phase cannot be revisited after completion (Sarycheva, 2019). The SDLC, as well as other design models, have a primary goal to create results that meet user expectations (Cohen & Haan, 2010). The SDLC contains several variants, discussed in the section below, since the SDLC, while supportive of a viable process for software development, is rather rigid and not adaptable to several development situations (Ghahrai, 2018). While there are variants of the SDLC model, the most common model contains seven discrete phases including (1) Planning, (2) System Analysis, (3) System Design, (4) Development, (5) Testing, (6) Implementation, and (7) Maintenance. However, while the 7-phase SDLC has been described, other researchers indicate that the SDLC can be described in a 5-phase model, by collapsing a few steps together. Each phase of the 7-phase SDLC model is described below:
Planning (Phase One): Phase one, the planning phase, is the most crucial phase of the SDLC since the breadth and scope of the project is delineated. During phase one, the scope of the project and funding is specified. A key element is that the executive sponsor provides support for the project. A needs analysis, requirements specification, and a project plan is created. Costs, time, tasks, and resources are specified. Phase one will set the scope, duration, and funding for the development project, planning, and preparation in this phase are essential.
System Analysis (Phase Two): During phase two, the requirements are analyzed and fleshed out, providing more specificity. The user’s requirements are analyzed and are used to create Functional Requirement Documents (FRD). The functional requirements drive the specific design for programs and modules used in the design and development phases and assist in the initial creation of test cases used in the testing phase. The systems analysis phase also results in screen prototypes, preliminary data and process flow documents, and other supporting diagrams that will help drive the system design process.
System Design (Phase Three): Phase Three systems design results in high-level design specifications including system design documentation that contains diagrams including (a) context diagram(s), (b) data flow diagrams, © flow charts, (d) data modeling (for databases), and other diagrammatic tools that will support the overall design of the system. Further, use cases are derived that will support the subsequent development and testing phases. Also, based on use cases, prototypes are developed and approved by users.
Development (Phase Four): The development phase begins when the delineated functional requirements are transitioned into a programming language. Before taking the functional specifications into code, the systems analyst segments the functions into modules that are commonly distributed to the development team for coding. Also, during the development phase, test cases are built that will later be used in the testing phase to confirm that the system works as expected. Due to the nature of coding, module testing, the construction of test cases, and compliance with development standards, the development phase is typically one of the longest phases in the SDLC model.
Testing (Phase Five): While unit testing is commonly done during the development phase, the testing phase of the SDLC involves several testing types. This includes string testing, where a series of programs/modules are tested for interaction, system testing, where the entire system is tested for functionality, and user testing, where users confirm that the project meets their desired expectation. In each test type, test cases that were previously developed in the development phase are used to validate and verify that the code works as expected. Any changes are noted and can be (a) either fixed immediately or (b) are noted as subsequent changes that will be done once the system is implemented.
Implementation (Phase Six): The implementation phase where modules and programs are deployed from a testing environment into a production environment. During implementation, final verification and validation of the new code and system is done to confirm that the system still executes as expected. Before the roll-out from a test environment to the production environment, a roll-back strategy is designed. The roll-back occurs if the new system is implemented into the production environment and the new system does not perform as expected. Rolling back the environment to a previous state is necessary when a new system does not perform as expected to keep the overall information and networking system in a consistent state.
Maintenance (Phase Seven): The final phase of the SDLC model consists of maintenance. Aside from the lengthy duration of the development cycle, maintenance is generally the longest. Maintenance occurs when the new system is running in the production environment and users are requesting changes to adhere to new business requirements. Also, aside from maintaining code to support new/updated business requirements, the maintenance phase incorporates a retirement sub-phase whereby a system that is in production that is being replaced by a newer system is rolled out of production (or retired) in a measured way.
Variants of the Software Development Lifecycle
There are several variants of the Software Development Life Cycle. The SDLC has been noted as a rigid model and, due to the variety of ways that organizations operate, variants to the SDLC have emerged (Sami, 2012). Several variants are noted below:
Incremental SDLC Model: The Incremental SDLC Model allows for incremental software development by dividing a large information systems project into several smaller chunks. Each of the smaller chunks will be designed with their own SDLC. This model divides the project into smaller subsets, prioritizes the requirements, and implements each subset until all functionality has been implemented (Ghahrai, 2018). There are fundamental strengths in using the Incremental Model. Key portions of the system or high-risk functions can be developed and implemented first. This approach limits the costs and risks. However, the entire SDLC must first be designed before segmenting the project into its constituent parts, so there are no-cost savings in the design aspect, in contrast to the traditional SDLC. However, to its benefit, the Incremental SDLC allows for basic functional requirements to be released to the market early (Kissel, Stine, Scholl, Rossman, Fahlsing, & Gulick, 2008).
Rapid Application Model (RAD): The Rapid Application Model (or spiral model) is a common development model and is part of an agile development approach. As an alternative to the traditional SDLC, its emphasis is on rapid prototyping and iterative delivery of software (Powell-Morse, 2016). As a cyclical model, constituent parts of the overall system can be developed with fewer people and delivered quickly. Also, there is a necessary involvement of users in the development, deployment, and approval for deployed software. Significant benefits of using RAD include cost savings and user involvement. A drawback is that some systems cannot be segmented into small discrete chunks and, thereby, development cannot be achieved by using RAD. Further, Powell-Mores (2016) not that the RAD model cannot be effectively used with older systems and that RAD gives the sense that the system development will never end for a given application.
Structured Evolutionary Prototyping Model: The Structured Evolutionary Prototyping Model uses a porotype (model) that is used to support user requirements before any lengthy design time spent by the development team. Instead, the prototype is used as a model that is built on over time (evolutionary) and confirms the requirements defined by the user and development time. As a benefit to the customer, the prototype allows the customer to visualize the actual system and to iteratively make recommendations for modifications. The prototyping process allows for better understanding and communication between the development team and the customer about system requirements (Harris, 2018).
Spiral SDLC Model: The Spiral SDLC Model combines the features of the Structured Evolutional Prototyping Model and the SDLC model. The Spiral model places an emphasis on risk analysis and management. The Spiral model requires subject matter expertise and uses incremental releases through each iteration (Gurendo, 2015). The Spiral Model provides a benefit to the development team and customer as it provides an early warning of insurmountable project risk (Gurendo, 2015). However, the model can be complex and necessitates expertise. Due to this, time spent evaluating risks within the model may be too time-intensive for small projects (Kissel, 2008). A modification to the RAD model is the Agile Development model, whereby the initial specifications are divided into smaller projects and each of the smaller projects is launched as an individual RAD project.
V-Shaped SDLC Model: The V-Shaped SDLC Model is also known as the Verification and Validation (V & V) Model. Verification and validation are focused on the linkage between each corresponding development stage and its associated testing stage. Each development/testing iteration can only move forward to a successive phase once the prior stage has been (Rajkumar, 2016). The V-Shaped SDLC Model emphasizes planning for verification and validation early on since each deliverable is fully tested. However, the V & V model does not readily handle dynamic requirement change (Rajkumar, 2016).
Software Development Approaches
Several software development approaches embody methods and techniques that drive the deliverables for user deliverables. The approaches include:
Prototype Model: As a variant of the SDLC, the prototype model is used to develop project requirements, especially when users are unclear about expectations. Models are successively built to enhance specifications for the overall software development project (GeeksforGeeks, 2018).
Agile Software Development: Agile software development is a development process whereby solutions are derived through the collaborative effort of cross-functional teams that self-organize to address end-user needs for software (Wikipedia, 2020).
Rapid Application Development (RAD): Rapid application development is a particular form of agile software development that incorporates user feedback into the development process to achieve conformity with user expectations and requirements (Singh, 2019).
Dynamic Systems Development: Dynamic Systems Development (DSDM) is a technique that couples with the agile framework based on the Prato philosophy of 80% of the application are delivered in 20% of the time. The focus on DSDM is on leveraging iterative coding to address the 80% (or bulk) of the requirements in a rapid manner (GeeksforGeeks2, 2019).
Spiral Model: The spiral model is an iterative model where each iteration of the ‘spiral’ successively addresses the risks and requirements of the given project. The exact number of iterations or spirals is not known and will vary with each project (Kumar, 2018).
Extreme Programming: Extreme programming is similar to agile programming, where the focus is to improve the quality of software, primarily, with an ability to adapt to the changing requirements of the client (Powe1l-Morse, 2017).
Feature-Driven Development: Feature-Driven Development is a focus of agile development whereby a client-valued function is defined within the context of use cases, which serve as a primary source for planning (Ambler, 2018).
Joint Application Development (JAD): Joint Application Development (JAD) is a method that involves the end-users in the design and development of software through the use of multiple JAD sessions, or collaborative workshops, where the development team and user community discuss user expectations and requirements (Rouse, 2007).
Lean Development: Lean development, or lean software development, follow a repeatable process that relies on quality standards and team collaboration to address the specifications for software development (Planview, 2020).
Rational Unified Processes: RUP is an IBM software development process that divides the development process into four discrete phases, which include (a) business modeling, (b) analysis and design, © implementation/testing, and (d) deployment (TechTerms, n.d.).
Scrum Development: Scrum development relies on a framework of team collaboration to solve complex software products that incorporate events, artifacts, and rules that bind software specifications (SCRUM, n.d.).
Each of the above software development techniques noted in the table below that includes a) the Software Development Methodology, b) Pros and Cons, and c) Software Assurance Concerns.
- Pros: Clear understanding of scheduling.
- Built-in steps to resolve development issues.
- Cons: Difficult to define objectives.
- Extended time to complete deliverables. (Globalluxsoft, 2017)
- Due to the amount of time involved with this methodology it may not be viable to select this SDLC.
- Pros: Good return for time and costs.
- Increased employee empowerment.
- Cons: Excessive development time.
- Misunderstanding and confusion. (te<huz, 2018)
- This is more time-intensive and could cause the project to exceed the time allowed for the development of the solution also added complexity could confuse.
Agile Software Development
- Pros: Ease of responses to change.
- Increased flexibility throughout the development cycle
- Cons: Misunderstanding of methodology.
- Difficulty predicting outcomes.
- Since there are many opportunities for change this could lead to misunderstandings and communication issues.
Rapid Application Development
- Pros: Minimizes the development time.
- Champions user feedback.
- Cons: Typically requires highly proficient developers.
- Increased dependency on development skills. (te
- To keep pace with this SDLC highly skilled talent is a need that adds to the overall complexity of the development process.
Dynamic Systems Development
- Pros: Resilient to changes throughout development.
- Able to adhere to budgetary requirements.
- Cons: Requires highly proficient developers.
- Nontraditional, more difficult to communicate and understand.
- This requires higher-skilled developers which would be more difficult to troubleshoot and resolve issues as they arise.
- Pros: High level of flexibility, ease of making changes.
- Good fit for addressing challenging projects.
- Cons: Not a good fit for small or simple projects
- The final product is difficult to determine early in development. (te
- This is not a good solution for smaller projects and it is challenging to assure the outcome of the development process during the phases of development.
- Pros: Solutions are developed quickly, fast turnaround.
- Lower cost since faster development allows for fewer changes throughout the process.
- Cons: The faster pace is due to less documentation done.
- Higher pressure at a faster pace methodology. (te<huz, 2018)
- Due to the faster pace of this SDLC, there is less time for documentation and an increased likelihood of mistakes being made.
- Pros: Good for large scale projects.
- Resulting features are better than in the beginning.
- Cons: Not a good fit for smaller projects or teams.
- Documentation is scarce if any. (Globalluxsoft, 2017)
- This is not ideal for smaller projects and would result in less documentation being available with the final deliverable.
Joint Application Development
- Pros: Requirements are well defined and clearly understood.
- Maintains continuous and proper communication between clients and developers.
- Cons: Time intensive to develop a full solution.
- Considerable investment in planning and requirements can increase total costs. (te
- Since this is time-intensive the duration of the project could exceed the due date of the deliverable and the longer this takes the higher costs would be incurred.
- Pros: Low cost, economical choice.
- The team is motivated to have high standards and make every feature perfect.
- Cons: Documentation needs to be precise and analysts need to have full understanding to be effective.
- Requires highly skilled developers with immense knowledge in the field. (Globalluxsoft, 2017)
- If documentation is not 100% accurate and well put together this could cause catastrophic errors that could comprise the development project.
Rational Unified Process
- Pros: Ample amount of resources and literature is dispensed by its creators.
- Emphasizes maintaining precise documentation.
- Cons: Complex methodology which requires expert developers.
- Components can rarely be reused hence the time spent is for a single purpose. (te<huz, 2018)
- Highly skilled developers are required and much of the progress is only valid for specific sections and cannot be utilized in other areas.
- Pros: High adaptivity to requirements amidst the project management cycle.
- The product owner is constantly in communication with the development team.
- Cons: Requires senior developers to control SDLC.
- Initial timeframes are adjusted too often difficult to stay on schedule. (Globalluxsoft, 2017)
- This is difficult to deliver a product on a firm date and time also it hinges on having highly skilled developers.
Table 1: Software Methodology Comparison
Software Development Security Testing
Software Development Security Testing requires that the software developer of an application, system component, or system service to perform many attack surface reviews. The reviews should be periodic and intentional since malicious actors are constantly developing new threats to software (Force & Initiative, 2013). The essence of security testing is for the developer (or the development team) to understand the weak and evolving weaknesses in application software or operating system software. For software development, the attack surface includes:
- An understanding by the developer of the value of data used in the software and how the developed code protects the data,
- The sum of all paths that data and commands can ingress and egress from the software,
- An inspection to ensure that code that protects these noted data and command paths; including the resource that the program connects to
- An examination into the facilities that provide authentication and authorization to the execution of the code on the system,
- Validation and verification of the data stream to examine for suitable encoding, decoding and encryption/decryption of the data
- The use of encryption, checksums, data integrity, and access auditing is used (Force & Initiative, 2013).
To effect a software security testing, a baseline must first be established so that any future changes can be measured and confirmed to the baseline. To this end, the development of an attack surface map must be created. The attack surface map denotes several potential attack vectors including points of entry to the software, such as in the use of HTTP headers, or user display forms, or the use of run-time arguments must be defined, as they present attack vectors that an attacker can leverage. Further, aside from the ingress/egress of data and the many methods that a program can use for input, processing, and output, it serves the developer to ask “How will the attacker view the code?”, which may provide additional insight to the developer in code reviewfor security. Also, the use of vulnerability scanning tools, such as Abby Scan, AppScan, and many others that are noted on the OWASP website (OWASP, n.d.) can support the developer in mitigating security issues in developed code. Once an attack surface map is developed, a priority ranking of high-risk areas are to be identified and addressed. Developing secure code is a process and necessitates the use of a configuration management process, the establishment of a baseline for program security, and the use of an attack surface map to prioritize risk that must be addressed.
Capability Maturity Model
The Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI) at Carnegie Mellon University is a methodology and framework used to describe and support the future refinement of an organization’s software development process (Rouse, 2007). The model uses five-levels to successively identify increasingly more mature processes for development. Essentially, the CMM establishes a framework for continuous improvement (CI) by providing five levels of software maturity as noted below:
- Level 1 — Initial: Processes used for development are disorganized and may even be chaotic. Project success is dependent on individual efforts. Project success is considered to be non-repeatable since processes are not sufficiently defined and documented.
- Level 2 — Repeatable: Basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.
- Level 3 — Defined: The organization has developed a software process, including more defined documentation, standardization, and integration that can support repeatability.
- Level 4 — Managed: An organization monitors and controls processes by collecting data and performing analysis. Metricssupport repeatability.
- Level 5 — Optimized: An organization’s processes are constantly improved by monitoring feedback of current processes. Additional innovative processes are introduced to support the organization’s repeatability (Rouse, 2007).
The Software Development Life Cycle provides several variations for developing software. These variations arose because the fluid nature of organizations needed approaches that were more suitable to the environment and culture of the organization, in contrast to the rigid approach that the traditional SDLC offered. The security of the software being developed is essential during this process and is a key focus of any software development. Finally, understanding the organization’s maturity level, based on the SEI CMM, will allow the organization to improve our documentation and processes that will, in effect, further support our cybersecurity posture.
Cohen, S. & Haan, U. (2010). A software system development life cycle model for improved stakeholders’ communication and collaboration. Retrieved January 30, 2020, from International Journal of Computers Communications & Control, 5(1), 20–41.
Crnkovic, I. & Larsson, S. (2006). Component-based development process and component lifecycle In Software Engineering Advances. Retrieved January 30, 2020, from International Conference on (pp. 44–44). IEEE.
GeeksforGeeks. (2018, April 5). Software Engineering: Prototyping Model. Retrieved February 9, 2020, from https://www.geeksforgeeks.org/software-engineering-prototyping-model/
GeeksforGeeks2. (2019, June 18). Dynamic Systems Development Method (DSDM). Retrieved February 9, 2020, from https://www.geeksforgeeks.org/dynamic-systems-development-method-dsdm/
Ghahrai, A. (2018). The Incremental SDLC Model. Retrieved January 30, 2020, from https://www.testingexcellence.com/incremental-model/.
Globalluxsoft, (2017). 5 Popular Software Development Models with their Pros and Cons. Retrieved February 7, 2020, from https://medium.com/globalluxsoft/5-popular-software development-models-with-their-pros-and-cons-12a486b569dc
Gurendo, D. (2015). Software Development Life Cycle, Spiral Model. Retrieved January 30, 2020 from https://xbsoftware.com/blog/software-development-life-cycle-spiral-model/.
Harris, K. (2018). Difference with Evolutionary Prototyping. Retrieved January 30, 2020 from https://prototypeinfo.com/evolutionary-prototyping-and-throw-away-prototyping/
Kissel, R. L., Stine, K. M., Scholl, M. A., Rossman, H., Fahlsing, J., & Gulick, J. (2008). Security considerations in the system development life cycle (No. Special Publication (NIST SP)-800–64 Rev 2).
Kumar, S. (2018, May 28). Software Engineering: Spiral Model. Retrieved February 9, 2020, from https://www.geeksforgeeks.org/software-engineering-spiral-model/
OWASP. (n.d.). Vulnerability Scanning Tools. Retrieved January 28, 2020, from https://owasp.org/www-community/Vulnerability_Scanning_Tools
Planview. (2020, February 8). 7 Guiding Principles of Lean Development. Retrieved February 9, 2020, from https://leankit.com/learn/lean/principles-of-lean-development/
Powell-Morse, A. (2016). Rapid Application Development (RAD): What is it and how do you use it? Retrieved January 30, 2020 from https://airbrake.io/blog/sdlc/rapid-application-development.
Powell-Morse, A. (2017, November 2). Extreme Programming: What Is It And How Do You Use It? Retrieved February 9, 2020, from https://airbrake.io/blog/sdlc/extreme-programming
Rouse, M. (2007, March 1). What is JAD (Joint Application Development) ? — Definition from WhatIs.com. Retrieved February 9, 2020, from https://searchsoftwarequality.techtarget.com/definition/JAD
Rouse, M. (2007, April 6). What is Capability Maturity Model (CMM)? — Definition from WhatIs.com. Retrieved January 28, 2020, from https://searchsoftwarequality.techtarget.com/definition/Capability-Maturity-Model
Sami, M. (2012). Software Development Life Cycle Models and Methodologies. Retrieved January 31, 2020 from https://melsatar.blog/2012/03/15/software-development-life-cycle-models-and-methodologies/.
Sarycheva, Y. (2019). Waterfall Model in SDLC. Retrieved January 30, 2020 from https://xbsoftware.com/blog/software-development-life-cycle-waterfall-model/.
SCRUM. (n.d.). What is Scrum? Retrieved February 9, 2020, from https://www.scrum.org/resources/what-is-scrum
Singh. (2019, December 6). What Is Rapid Application Development (RAD)? Retrieved February 9, 2020, from https://blog.capterra.com/what-is-rapid-application-development/
TechTerms. (n.d.). RUP (Rational Unified Process). Retrieved February 9, 2020, from https://techterms.com/definition/rup
te<huz, (2018).=”” 12=”” 2020,=”” 7,=”” https://www.techuz.com/blog/top-12-sdlc-methodologies-with-pros-and-cons/
Wikipedia. (2020, February 7). Agile software development. Retrieved February 9, 2020, from https://en.wikipedia.org/wiki/Agile_software_development
About the Author
Dr. Ron McFarland, CISSP, PMP is a Cyber Security Analyst at CMTC. He received his doctorate from Nova Southeastern University’s School of Engineering and Computer Science and a post-doc graduate certificate in Cyber Security Technologies and a MSc in Cybersecurity Technology from the University of Maryland (Global Campus). He also holds multiple security certificationsincluding the prestigious Certified Information Systems Security Professional (CISSP) certification and several Cisco certifications. He is a guest blogger at the Wrinkled Brain Network (https://wrinkledbrainnetwork.com/ ), a blog dedicated to Cyber Security and Computer Forensics. Dr. McFarland can be reached at his University of Maryland email is: firstname.lastname@example.org