Chpt 1 - System Authorization Lifecycle Flashcards
Initiation Phase
Security Categorization
Preliminary risk assessment
POA&M generated from the risk assessment to document controls to implement for addressing potential risks and vulnerabilities
Controls are defined and refined
Acquisition / Development Phase
Security functional requirements analysis
Security assurance requirements analysis
Cost considerations and reporting
Security planning
Security control development
Developmental security test and evaluation
Implementation Phase
Once the certification test plan is developed, it is executed during this phase to ensure required controls are in place and working
Certification test plan results are recorded in the certification test plans report which goes into the System Authorization Package for the system
Security Plan updated to record test results and document status of controls
With this approach, the AO has all necessary documentation to make an authorization decision
Operations / Maintenance Phase
System owners must exercise controls that allow continuous monitoring of the security environment.
Owners review it for possible needs for recertification and accreditation following significant events (intrusions, new threats, changes in system components, facility, etc)
First evaluate need for recertification by reviewing the impact of the change via a Risk Assessment
Reaccreditation may be required every 2-3 years regardless of changes
Disposition Phase
Ensure data is purged to prevent disclosure
Integrity of data may require archival and storage
Risk assessment should be conducted and remediation plan with a POAM developed
System authorization procedures in this phase are scaled-down versions of processes from previous phases
Often retiring one system means replacing it with another, linking their lifecycle activities can make sense.
Precertification Phase
tasks performed to prepare for certifying
Validation Phase
tasks to get actual certification
Integrating system authorization into the SDLC is promoted by _____
the consistency of the project manager / system owner in recertification and validation.
Reasons for failure 1
Program Scope
incomplete identification and inventory of systems leads to incomplete application of controls
Reasons for failure 2
Assessment Focus
The program never leaves the assessment phase, so remediation / mitigation isn’t applied
Reasons for failure 3
Short-Term thinking
Organizations only focus on day to day requirements. Solutions are point solutions that don’t contribute to overall security architecture
Reasons for failure 4
Long-Term thinking
focusing on strategy alone prohibits implementation
You have to translate the requirements identified in the security architecture down to the implementation level
Reasons for failure 5
Poor Planning
Failure to recognize the costs can stop efforts at following through
Fits and starts lose the confidence of management who become inclined to scrap it
Unrealistic requirements
Misaligned responsibilities assigned to personnel
Failure to correctly identify assumptions
Failure to recognize limitations of system authorization contributes to poor planning
Reasons for failure 6 Lack of Responsibility
Must distinguish program-level responsibilities for the enterprise, and system-level responsibilities for individual systems
A single entity cannot do both
Reasons for failure 7 Excessive Paperwork
too much bureaucracy slows and stops development
