The software development lifecycle has the following typical phases (note that this is not exact in the CBK and many methodologies/phases may overlap):
Planning/initiation – creation of project, includes scope, budget/cost, objectives, strategies, and schedules.
Functional requirements definition – security controls and compliance defined. Functional requirements as well.
System design specifications – designing the software and architecture, outputs, data flows and interfaces.
Development – development of the source code.
Acceptance – testing the system to make sure it performs within the environment. May be part of the certification and accreditation process. Can include subphases such as:
- Testing/evaluation of controls – formal testing processes occur, such as choosing test data, includes fuzzy testing (unexpected data), data validation, bounds checking, and sanitizing any production data.
- Certification/Accreditation – AKA authorization to put the system into production. Certification is the technical analysis of system controls. Accreditation is the authorizing official sign-off to put the system into production.
Transition to production/implementation – moving from the acceptance phase into production. This phase includes training and awareness, accreditation, installation, parallel operations with an old system that is being replaced.
Revision/replacement – periodic evaluations for flaws and revisions, and to replace any faulty components that have or could cause security incidents.
Maintenance/operation – system usage across the enterprise. System performance monitoring, regular change management process, backup and recovery procedures, risk analysis that accompanies recertification/accreditation (due to a relocation, change in data classification, or major system change).
We have a pneumonic to help you remember these phases. If you put them together it’s a jumbled mess of PFSDATCTRM. You’ve all heard the saying that “the way to a man’s heart is through his stomach”, so we came up with this: “Please fry some dead animals to catch the right man.”
The system lifecycle (SLC) has two phases after the SDLC completes: 1) Operations and maintenance support, post-installation. And 2) Decommissioning and disposal and system replacement.
The software environment encompasses the spectrum or scope of an application’s reach, from beginning to end of life, to the people who develop and use it. For example, a government agency who creates and updates software for a mainframe that’s hosted onsite and only used by that agency doesn’t have a very large software environment. On the other hand, a COTS product that is used by Macbooks for video and audio editing and sourced from public code repositories has a much larger software environment. Such an environment would include where the code came from, who further developed it, who the customers are, and the environment of the Macbook creators. It could also include firmware and drivers for any hardware that supports video and audio editing, along with their respective developers and customers.
During a system’s design and development is when developers will have the best opportunity to address potential exploitable vulnerabilities that might be inadvertently added to a system and thus more difficult to remove during test and security assessment.
Risk control factors are at their highest point once software has made its way into the hands of users.
Effective security in system development is achieved by:
Statements of purpose/requirements → shaped into detailed system specifications → embodies business logic → guides testing efforts → shapes the user procedures, workflows, and training.
Inverse relationship between Development Time and Error Impact:
This section presented some strange wording that you might need to be aware of. Basically if security alarm thresholds are too high – this means that a lot are being prevented from alerting – then you risk a security incident happening, or being undetected. If security alarm thresholds are too low – this means that a lot (too many) are being allowed to send alerts – then you risk not getting any work done. Management needs to help determine the risk appetite for all projects in order to manage this.
This is the phased approach to software development where one phase must be completed before the next one starts. Simple mistakes made at each phase (of any development methodology) can lead to exploitable vulnerabilities down the road. The phases of waterfall are:
- Concept or mission needs identification
- Requirements definition
- Systems design
- Software and data systems coding
- Unit, subsystem, and systems testing
- Acceptance testing
- Deployment to operational use
Benefit of waterfall is that it ensures that phases are done diligently. Downfall is that phases cannot work on their portion concurrently and thus slows progress. Business value is not demonstrated until the end of a project.