CISSP Course Notes

Security and Risk Management connects governance, risk, compliance, authorization, privacy, policy, awareness, and continuity planning. Risk decisions consider threats, vulnerabilities, likelihood, impact, organizational context, and risk tolerance. The authorizing official accepts residual risk based on current security and privacy information. Controls may be common, system-specific, or hybrid and must be assessed for correct implementation and effectiveness. Policies and awareness programs translate management expectations into consistent behavior. Business continuity planning identifies critical functions, dependencies, recovery priorities, alternate operating methods, and communication requirements so essential operations can continue or recover during disruption. Privacy programs manage risks to individuals from PII processing.

• Confusing initial, ongoing, and reauthorization – understand the trigger for each.

• Remember the authorizing official's role is to accept risk, not mitigate it.

Asset Security focuses on classifying information and assets according to the potential impact of loss of confidentiality, integrity, or availability; refining provisional impact levels using organizational and mission context; and applying handling, protection, sanitization, and destruction requirements throughout the information lifecycle. Sanitization decisions should consider media characteristics, confidentiality requirements, organizational controls, data-protection needs, implementation constraints, and the ability to verify the result. Media movement and disposition should be tracked, and outsourcing destruction does not transfer the organization’s responsibility for protecting the data.

• Confusing provisional and final impact levels – remember, provisional is just the starting point.

• Think about the potential consequences of a compromise – what could go wrong?

This objective covers key agreement and transport mechanisms for establishing and protecting symmetric keys. This objective covers the entire lifecycle of cryptographic keys – from creation to destruction. Understanding these processes is key to secure key management. This objective assesses your ability to evaluate a system's security architecture. It centers on understanding the system of interest, its complexities, and associated risks. Apply design principles contextually – tailoring is essential. Cyber resiliency principles are rooted in security and related fields.

• Confusing public- and private-key roles in confidentiality or key-transport scenarios. When a public key is used to encrypt or transport protected material, the corresponding private key is used to decrypt it; digital-signature use follows a different operation.

• Automated key transport reduces backup needs for static keys. Manual key transport requires robust backup procedures.

Secure networks start with firewall policy and risk-based traffic handling. Firewalls have limitations, and internal attacks can bypass perimeter-only defenses. VPNs provide protected connectivity across untrusted networks; segmentation and access control depend on the surrounding network architecture, routing, and policy. Remote-host traffic follows the configured VPN routing model.

• Confusing gateway-to-gateway and host-to-gateway VPNs – understand their distinct purposes.

• Think about the traffic types and protocols involved when designing a firewall architecture.

Control access by verifying identity and authenticator control and applying granular access policies. Federation relies on trust relationships and assertions between identity providers and relying parties; credential service provider functions may participate depending on the architecture. Access control can be continuously evaluated and adjusted. Authentication assurance requirements are selected through applicable risk assessment and digital-identity guidance rather than a direct Low/Moderate/High-to-AAL mapping.

• Confusing the authenticator secret with the authenticator output – the secret is long-term, the output is short-term.

• Remember the roles: RP grants access, Verifier confirms identity.

Security Assessment and Testing is risk-driven: define what the assessment must determine, choose the appropriate assessment objects, and use examine, interview, and test methods to gather sufficient evidence. Reused assessment results can reduce duplicate effort, but only when their credibility and applicability are still valid. Systems may depend on inherited common controls, so assess those dependencies and understand how common-control weaknesses affect dependent systems. System risk categorization and assessment objectives guide control selection, testing priorities, and the scope of follow-up work when required evidence is missing.

• Treating an assessment as a checklist instead of gathering evidence that supports defined determination statements.

• Identify the assessment objective first: what exactly must be proved or determined?

Security Operations covers incident management, personnel and facility protection, logging and monitoring, recovery, and operational event analysis. Incident response follows defined criteria and roles rather than ad hoc reaction. Physical security uses layered administrative, technical, and physical safeguards to protect people, buildings, equipment, utilities, and environmental dependencies. Logging requires appropriate source configuration, time synchronization, protected storage, retention, and review. Recovery actions should be scoped, prioritized, communicated, validated, and aligned with business needs. Event interpretation must account for the specific log source, platform, user context, and surrounding activity.

• Jumping directly to recovery before containment and eradication are sufficiently complete.

• For incident questions, identify the current response phase before selecting the next action.

Apply the SSDF to reduce software vulnerabilities and prevent future issues. Manage software supply-chain risk by assessing third-party components, protecting software integrity, and integrating risk management throughout the software lifecycle. This objective covers selecting application security testing for container technologies. It focuses on executable code testing and sandboxed environments. Secure coding requires a committed leadership team and consistent integration throughout the SDLC, supported by automation and appropriate toolchains. Apply code decisions based on storage and access control principles. Least privilege is key – grant only necessary access.

• Confusing the SSDF with a specific tool or technology. The SSDF is about processes and practices, not specific solutions.

• Focus on the overall goals of the SSDF: vulnerability reduction and prevention.