OBJECTIVE 1.2 Summarize

Summarize fundamental security concepts

This objective covers the conceptual foundations that every other objective builds on. If you don’t internalize these, the rest of the exam is guesswork.

The CIA Triad

Three properties every security program exists to protect:

Confidentiality — Only authorized entities can access data.

  • Encryption (at rest, in transit), access controls, data classification
  • Breach of confidentiality: unauthorized data exposure, exfiltration

Integrity — Data is accurate, complete, and unaltered by unauthorized parties.

  • Hashing, digital signatures, checksums, version control
  • Breach of integrity: data tampering, man-in-the-middle modification, log deletion

Availability — Systems and data are accessible when needed by authorized users.

  • Redundancy, load balancing, backups, DDoS mitigation
  • Breach of availability: ransomware, DDoS, hardware failure

Exam trap: Questions will describe a scenario and ask which CIA property is most affected. Ransomware affects availability (you can’t access your data) even though it technically encrypts it. Data exfiltration affects confidentiality. An attacker modifying database records affects integrity.

Non-repudiation

The assurance that someone cannot deny having performed an action. Requires both:

  • Authentication — proving who performed the action
  • Integrity — proving the action/data wasn’t altered after the fact

Implemented through digital signatures (asymmetric cryptography). The signer’s private key creates the signature; anyone with the public key can verify it. The signer cannot deny signing because only they hold the private key.

AAA Framework

Authentication — Proving identity. “Who are you?”

  • Something you know (password, PIN)
  • Something you have (smart card, hardware token, phone)
  • Something you are (fingerprint, retina, facial recognition)
  • Somewhere you are (geolocation, IP range)

Authorization — Determining permissions. “What can you do?”

  • After authentication, the system checks what resources the identity can access
  • Implemented via ACLs, RBAC, ABAC, group policies

Accounting — Tracking activity. “What did you do?”

  • Audit logs, session logging, SIEM correlation
  • Essential for forensics, compliance, and non-repudiation

Zero Trust

Core principle: Never trust, always verify. No implicit trust based on network location, device ownership, or previous authentication.

Key tenets:

  • Verify explicitly — Authenticate and authorize every access request based on all available data (identity, device health, location, anomalies)
  • Least privilege accessJIT (Just-In-Time) and JEA (Just-Enough-Access) permissions
  • Assume breach — Design every layer as if the attacker is already inside

Control Plane vs. Data Plane:

  • Control plane: Policy engine + policy administrator making access decisions
  • Data plane: Where the actual traffic flows, gated by policy enforcement points

Exam focus: Zero trust is not a product you buy — it’s an architecture model. Expect questions about what constitutes zero trust vs. what doesn’t (VPN alone is NOT zero trust).

Gap Analysis

Comparing current security posture against a desired state (framework, policy, or baseline) to identify deficiencies.

  • Conduct against frameworks like NIST CSF, ISO 27001, CIS Controls
  • Output: prioritized list of gaps with remediation recommendations
  • Feeds directly into risk management and budget decisions

Gap Analysis Process

CompTIA tests the process steps, not just the definition:

  1. Define the desired state: Select a target framework or standard (NIST CSF, ISO 27001, CIS Controls, or organizational policy)
  2. Assess current state: Document existing controls, policies, and capabilities through interviews, documentation review, and technical assessment
  3. Identify gaps: Compare current state against desired state. Each gap is a control or capability that exists in the target but not in the organization.
  4. Prioritize gaps: Rank by risk impact, regulatory requirement, and implementation difficulty
  5. Develop remediation plan: For each gap, define the action needed, responsible party, timeline, and estimated cost
  6. Execute and track: Implement remediations and monitor progress. Re-assess periodically.

Exam tip: Gap analysis is a planning tool, not a technical scan. It compares policy/process/control maturity against a standard — it’s not a vulnerability scan.

Physical Security

Often overlooked but heavily tested:

  • Bollards — Posts preventing vehicle-borne attacks on buildings
  • Fencing — Perimeter demarcation; height matters (3ft = demarcation, 6ft = deterrent, 8ft+ = serious barrier)
  • Access control vestibule (mantrap) — Two interlocked doors; prevents tailgating
  • Video surveillance — Detective + deterrent; PTZ cameras for active monitoring
  • Security guards — The only control that can make judgment calls in real-time
  • Access badges — Something you have; often combined with PIN (two-factor)
  • Lighting — Deterrent control; eliminates hiding spots

Physical Security Depth

Standoff distance: The controlled area between a building’s perimeter and the structure itself. Prevents vehicle-borne IED damage. Bollards, planters, and barriers enforce standoff distance. The further you keep threats from the building, the lower the blast impact.

Environmental controls:

  • HVAC security: Data center cooling is a critical dependency. Loss of cooling = forced shutdown to prevent hardware damage. HVAC systems should be monitored and physically secured.
  • Fire suppression: Wet pipe (water — cheap, effective, damages equipment), dry pipe (water held back until activation), clean agent (FM-200, Novec 1230 — safe for electronics, no residue), pre-action (combines dry pipe + detection — two triggers required)
  • Humidity controls: Too low = static discharge risk. Too high = condensation/corrosion. Data centers target 40-60% relative humidity.
  • Temperature monitoring: Continuous monitoring with automated alerting. Hot aisle/cold aisle containment in data centers.

Exit controls:

  • Emergency exit doors with alarms (allow egress, detect/deter unauthorized use)
  • Anti-passback: badge must be used to enter AND exit — prevents lending badges or tailgating
  • Emergency evacuation procedures must not be defeated by security controls (fire code compliance)

Deception and Disruption Technologies

Honeypot — Decoy system designed to attract attackers. Detective control — any interaction with a honeypot is suspicious by definition.

Honeynet — Network of honeypots simulating a realistic environment. More convincing than a single decoy.

Honeyfile — Decoy document (e.g., “passwords.xlsx”) that triggers an alert when accessed. High-confidence indicator of compromise.

Honeytoken — Fake credentials, API keys, or data records planted in systems. If they appear in authentication logs or exfiltrated data, you know you’ve been breached.

Deception Technology Depth

Honeytoken monitoring:

  • Plant fake credentials in credential stores, code repos, or configuration files
  • Monitor authentication systems for any use of honeytoken credentials — any login attempt is a confirmed IOC
  • Plant fake database records (canary rows) — if they appear in data exports or on the dark web, you know exactly which dataset was breached
  • AWS example: Create an IAM access key that’s never used legitimately. If CloudTrail logs any API call with that key, it’s an attacker.

Honeypot deployment considerations:

  • Low-interaction: Emulates services at a surface level. Easy to deploy, low risk. Captures attacker IP, port scans, basic exploit attempts. Examples: Cowrie (SSH), Dionaea.
  • High-interaction: Full operating system with real or near-real services. More convincing but higher risk (attacker could use it as a pivot). Requires monitoring and containment.
  • Detection evasion by attackers: Sophisticated attackers fingerprint honeypots by checking for unrealistic system profiles (too many open ports, default configurations, lack of legitimate traffic). Effective honeypots must look like real production systems with realistic traffic patterns, appropriate patch levels, and believable data.

Offensive Context

Zero trust exists because perimeter-based security failed. If you assume the attacker is already inside your network — which they probably are — then “trust but verify” is backwards. The attacker’s perspective validates the assume-breach model: once past the perimeter, traditional networks offer minimal resistance to lateral movement. Every zero-trust control (microsegmentation, continuous authentication, device health checks) is a direct response to specific offensive techniques.