4.8.1. Secure Development Through the System Lifecycle
💡 First Principle: Each lifecycle phase has a unique security contribution that cannot be replicated by any other phase — skipping security at any phase creates a gap that downstream phases can detect but cannot cost-effectively repair.
System Development Lifecycle Phases and Security Integration
| Phase | Primary Activity | Security Integration | Key Security Output |
|---|---|---|---|
| Initiation | Define business need, authorize project | Initial risk assessment, preliminary security categorization | Security requirements baseline |
| Development/Acquisition | Design and build (or buy) the system | Threat modeling, secure architecture review, security requirements | Threat model, security architecture document |
| Implementation | Deploy to production environment | Security testing (SAST, DAST, pentest), security configuration | Security test results, hardening checklist |
| Operation/Maintenance | Run and maintain in production | Continuous monitoring, patch management, change control | Vulnerability reports, audit logs |
| Disposal | Retire the system | Media sanitization, data migration, license termination | Certificate of destruction, data disposition record |
Initiation phase security is where the most consequential decisions are made at the lowest cost. A risk assessment at initiation determines the system's security categorization (using FIPS 199 for federal systems or organizational classification for commercial). This categorization drives every subsequent control selection — a system categorized as "high impact" for confidentiality requires fundamentally different architecture than one categorized as "low impact."
Scenario: a government agency initiates a new citizen-facing portal. At initiation, the risk assessment identifies that the system will process PII including Social Security numbers. The security categorization assigns "high" for confidentiality. This single decision at initiation means the development team must implement encryption at rest and in transit, multi-factor authentication, database activity monitoring, and quarterly penetration testing. If the categorization is deferred to the implementation phase, the team discovers these requirements after building an architecture that does not support them — requiring costly redesign.
Threat modeling during design identifies attack surfaces before code is written. Using frameworks like STRIDE, the security team systematically analyzes each component and data flow for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege threats. A threat identified during design costs a whiteboard eraser to fix; the same threat found in production costs an emergency patch, regression testing, change management, and potential incident response.
Certification and Accreditation / Assessment and Authorization
Federal systems use a formal process to authorize system operation:
| Term | Framework | Meaning |
|---|---|---|
| Certification (legacy DITSCAP/DIACAP) | Pre-2010 DoD | Technical evaluation of security controls |
| Accreditation (legacy) | Pre-2010 DoD | Management decision to accept residual risk and authorize operation |
| Assessment (current NIST RMF) | NIST SP 800-37 | Independent evaluation of control implementation and effectiveness |
| Authorization (current) | NIST RMF | Authorizing Official's formal decision to accept risk and grant ATO |
The Authorization to Operate (ATO) is the critical output: a formal, documented decision by the Authorizing Official (a senior executive, not a technical role) that the residual risk of operating the system is acceptable. The ATO is time-limited — typically three years — after which the system must be reassessed.
The Authorizing Official cannot delegate accountability. They can delegate the assessment work to assessors and the technical evaluation to the ISSO (Information System Security Officer), but the risk acceptance decision is theirs alone. This is a governance principle: the person who accepts risk must have the authority and accountability to make that decision.
⚠️ Exam Trap: The Authorizing Official is NOT the CISO, ISSO, or system owner. The AO is a senior executive with the authority to accept organizational risk. The ISSO manages day-to-day security operations; the system owner is accountable for the system's mission function; the CISO establishes security policy. The AO makes the formal risk acceptance decision. The exam tests role distinctions within the authorization process.
Reflection Question: A system receives its ATO with several accepted risks documented as Plan of Action and Milestones (POA&M) items. Eighteen months later, the system undergoes a major upgrade that changes the authentication architecture. Does the existing ATO remain valid? What process must occur, and who makes the determination?
