2.2 Understand Security Concepts

Why these seven concepts are the SSCP's working vocabulary

Knowledge area 1.2 — Understand security concepts — is the language every later SSCP domain uses. Access control, monitoring, incident response, cryptography, and network security are implementations of a short list: confidentiality, integrity, availability, accountability, non-repudiation, least privilege, and segregation of duties (SoD). If you cannot tell which concept a control is serving, you will pick the wrong tool under pressure — encrypting a file that needed a hash, or adding a firewall rule that does nothing for a repudiation dispute.

These are not slogans. On an SSCP shift they decide whether a contractor sees payroll, whether a syslog pipeline can be trusted in a hearing, whether a patch window takes the warehouse scanner offline, and whether one person can both grant Domain Admin and hide the grant.

Confidentiality, integrity, and availability

The CIA triad is the classic trio of security objectives.

Confidentiality is the property that information is not disclosed to unauthorized people, processes, or devices. Operations examples include Transport Layer Security (TLS) for data in transit, full-disk encryption on laptops, data classification and need-to-know, redacting Social Security numbers in SOC tickets, and refusing to email a payroll export in the clear. Confidentiality fails when a help-desk technician dumps a user database to a personal USB drive "to work at home," even if that technician is a long-tenured employee.

Integrity is the property that data and systems are not altered in an unauthorized or undetected way. Operations examples include cryptographic hashes on build artifacts, file integrity monitoring (FIM) on /etc and web roots, signed operating-system updates, change tickets before a firewall push, and write-once storage for audit logs. Integrity also includes the clocks: if Network Time Protocol (NTP) is wrong, you cannot sequence events. Integrity fails when an administrator "fixes" a log line after a mistake, or when a patch is installed from an unsigned mirror.

Availability is the property that authorized users can use systems when they need them. Operations examples include clustered authentication servers, tested backups, distributed denial-of-service (DDoS) protections, redundant power in the data center, and change windows that do not collide with peak shipping. Availability fails when a poorly tested ACL locks every remote engineer out of the jump host, or when ransomware encrypts the only backup.

CIA is a triad because you trade among the three. Turning off a noisy Intrusion Detection System (IDS) signature to "keep the network fast" may help availability and harm integrity and confidentiality. Forcing every packet through a mis-sized inspection appliance can protect confidentiality while creating an outage. SSCP items often hide that trade in a stem about a business deadline.

Accountability and non-repudiation

Accountability means a security-relevant action can be traced to a unique, responsible identity. It answers "who did what, when, from where?" Unique user IDs, disabled shared root logins, multi-factor authentication (MFA) for privileged paths, session recording on jump hosts, and Security Information and Event Management (SIEM) correlation are accountability controls. A service account named svc-backup is accountable only if a named owner exists, the secret is not in a wiki, and its use is logged. A team that shares NetAdmin cannot later prove which engineer opened a port.

Non-repudiation is the stronger claim that a party cannot credibly deny having performed an action. It usually requires integrity-protected evidence plus a binding to an identity: digital signatures, trusted timestamps, and audit trails the actor cannot edit. Non-repudiation is why privileged users must not be local administrators of the log collectors that record their work. Hashing a file proves integrity of the bytes; it does not by itself prove who created the file. A digital signature over that hash, plus a key that only one person controls, is what supports non-repudiation.

Accountability is the everyday operations requirement. Non-repudiation is what you need when the action may be disputed — a funds transfer, a certificate revocation, a change that took production down, or an automated decision that affected a customer.

Least privilege

Least privilege means a subject gets only the access required to perform an authorized task, for only as long as needed. For people: a help-desk role that can reset passwords after identity proofing but cannot edit Group Policy. For systems: a backup service that can read volumes but cannot authenticate interactive users. For network devices: an ACL that permits only the required ports between two subnets, default deny. Just-in-time privileged access, break-glass accounts that page the SOC when used, and regular access recertification are how operations keep least privilege from rotting.

Least privilege supports confidentiality (fewer people see payroll), integrity (fewer people can change the firewall), and availability (a compromised help-desk account cannot wipe storage arrays). The exam trap is treating "I might need it someday" as a reason to grant Domain Admin.

Segregation of duties: help desk versus security administrator

Segregation of duties (SoD) — also called separation of duties — splits a sensitive process so no single person can complete it end to end without detection. It is least privilege applied to a workflow, not only to a permission bit.

A realistic mid-size operations split:

If the same engineer resets passwords, adds themselves to Domain Admins, pushes firewall changes, and administers the SIEM, SoD is theater. Small teams still implement SoD with compensating controls: a second approver in another time zone, automated tickets that a manager must sign, and log forwarding to a collector the change-maker cannot edit.

SoD also shows up between development and production, between requestor and implementer of a change, and between the person who runs payroll jobs and the person who creates vendor accounts. The exam likes the help-desk versus security-admin contrast because both roles have daily access and different blast radii. A help-desk technician who can both reset MFA and enroll a new device for any executive can impersonate that executive. A security administrator who is the only person who can read the logs of their own firewall pushes can hide an unauthorized rule. Split those powers, or add a compensating reviewer who does not share them.

The diagram below shows how the seven 1.2 concepts connect in operations: CIA states the objectives, accountability and non-repudiation bind actions to people, and least privilege plus SoD keep any one identity from owning the whole path.

Automation and AI still owe CIA and accountability

ISC2 has folded artificial intelligence (AI) and automation into the SSCP domains rather than creating a separate AI exam. For Domain 1, the practitioner message is blunt: machines do not get a pass on the triad or on accountability.

An AI-assisted ticket bot that can disable accounts is a privileged subject. It needs a unique identity, least privilege (disable, not domain-join), SoD (a human approves mass disablement), confidentiality (it must not dump ticket bodies containing passwords into a training set), integrity (model and prompt changes go through change management so algorithmic integrity is preserved), and availability (a bad model update must be roll-backable). Logging its actions to a shared chatbot account destroys accountability: when a user is locked out, you cannot tell whether the bot, a technician, or an attacker did it.

Automated playbooks, infrastructure-as-code, and machine-learning detections tell the same story. If a security orchestration playbook quarantines a host, the action must map to a control owner, a change record, and an immutable log. If a model drifts and starts dropping true-positive ransomware alerts, availability of detection — and therefore integrity of the environment — has failed. Transparency and a named human who can explain the action are how you remain "seen to adhere" to policy when the actor is software.

Non-human identities need recertification the same way people do. A forgotten API key with Owner on a cloud subscription is a least-privilege failure with no badge photo attached. Adaptive authentication and behavioral analytics can support access decisions, but they do not replace unique IDs, SoD on approvals, or the duty to keep a human accountable for a destructive action.

Putting 1.2 together

When a stem describes a control, name the concept it primarily serves, then check the side effects on the others. Encrypting backups without testing restores can raise confidentiality and wreck availability. Sharing an admin password can keep a 2 a.m. outage short and destroy accountability. Granting a contractor "temporary" Domain Admin without an expiry is a least-privilege and SoD failure waiting to become a confidentiality incident. Design the workflow so the help desk can recover users, the security administrator can recover systems, and neither can silently become the other.