Security Concepts and Practices

1.1 Comply with codes of ethics

Core idea: ethical escalation.

Scenario: A technician is asked to hide a control failure from an audit because the outage window has already closed.

Practitioner response: Escalate through the approved ethics and governance path, preserve facts, and refuse to falsify evidence.

Concepts to Understand

• ISC2 Code of Ethics: ISC2 Code of Ethics is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• organizational code of ethics: organizational code of ethics is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.2 Understand security concepts

Core idea: security principles.

Scenario: A privileged operations team can approve, implement, and verify its own emergency firewall changes.

Practitioner response: Separate approval, implementation, logging, and review duties so no single party controls the whole evidence path.

Concepts to Understand

• confidentiality: confidentiality is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• integrity: integrity is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• availability: availability is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• accountability: accountability is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• non-repudiation: non-repudiation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• least privilege: Least privilege is not just a policy phrase. It means giving the minimum authority needed, reviewing it, and removing it when the need ends.
• segregation of duties: segregation of duties is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.3 Identify and implement security controls

Core idea: control selection.

Scenario: A data center review finds visitor logs, camera coverage, firewall rules, and policy exceptions all need evidence.

Practitioner response: Map each requirement to administrative, technical, and physical controls with documented review evidence.

Concepts to Understand

• technical controls: technical controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• physical controls: physical controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• administrative controls: administrative controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• compliance assessment: compliance assessment is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• periodic audit and review: periodic audit and review is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.4 Document and maintain functional security controls

Core idea: control function.

Scenario: A compensating control was approved for a legacy system but never retested after a network redesign.

Practitioner response: Revalidate the compensating control, document its limits, and track corrective action to restore the intended control function.

Concepts to Understand

• deterrent controls: deterrent controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• preventive controls: preventive controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• detective controls: detective controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• corrective controls: corrective controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• compensating controls: compensating controls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.5 Support and implement asset management lifecycle

Core idea: asset lifecycle.

Scenario: Retired laptops still have local data, untracked software licenses, and no destruction certificates.

Practitioner response: Use inventory, ownership, sanitization, license reconciliation, retention, and destruction evidence before disposal.

Concepts to Understand

• process planning and initiation: process planning and initiation is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• development or acquisition: development or acquisition is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• inventory and licensing: inventory and licensing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• implementation and assessment: implementation and assessment is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• operation, maintenance, and end of life: operation, maintenance, and end of life is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• archival and retention: archival and retention is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• disposal and destruction: disposal and destruction is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.6 Support and implement change management lifecycle

Core idea: change governance.

Scenario: A network team wants to bypass change review for a rule that grants broad administrative access during troubleshooting.

Practitioner response: Use the emergency change path, document security impact, time-bound the access, and require post-implementation review.

Concepts to Understand

• change roles and responsibilities: change roles and responsibilities is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• communications and audit: communications and audit is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• security impact analysis: security impact analysis is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• configuration management: configuration management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.7 Support and implement security awareness and training

Core idea: awareness operations.

Scenario: Repeated phishing reports show users recognize malicious email but do not know where to report it.

Practitioner response: Tune awareness around reporting behavior, reinforce the channel, and measure response improvement after exercises.

Concepts to Understand

• social engineering awareness: social engineering awareness is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• phishing exercises: phishing exercises is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• tabletop exercises: tabletop exercises is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• awareness communications: awareness communications is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

1.8 Collaborate with physical security operations

Core idea: physical security.

Scenario: A contractor needs temporary data center access and wants to bring a personal diagnostic laptop.

Practitioner response: Coordinate visitor authorization, escorting, device restrictions, access logging, and badge expiration with physical security.

Concepts to Understand

• facility assessment: facility assessment is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• badging and visitor management: badging and visitor management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• personal device restrictions: personal device restrictions is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

Preventive vs Detective vs Corrective Controls

Exam clue: Do not call a monitoring control preventive unless it actually blocks the action.

technical vs administrative vs physical controls

This comparison is covered through the domain objectives above and the SSCP review sheet.

accountability vs non-repudiation

This comparison is covered through the domain objectives above and the SSCP review sheet.