eEDA Exam - Guided By RedBlock
eEDA - Enterprise Defense Administrator
eEDA Field Guide — Enterprise Defense Administrator (INE)
The complete, hands-on study guide for the INE eEDA (Enterprise Defense Administrator) Blue Team certification — defensive engineering end to end: secure-engineering fundamentals, Governance/Risk/Compliance (GRC), Identity and Access Management (IAM), Security Administration (hardening, firewalls, IDS/IPS, logging), vulnerability management, monitoring/SIEM, and incident response. Every concept is paired with configuration examples, baselines, and a build-it-in-your-lab approach so you can implement and defend a properly secured enterprise.
Keywords & topics: enterprise defense administrator, blue team, defensive engineering, system hardening, CIS Benchmarks, NIST CSF & SP 800-53, ISO 27001, CIS Controls, MITRE ATT&CK, GRC, risk management, change management, BCP/DR, identity and access management, RBAC/ABAC, Active Directory hardening, MFA, SSO/federation, PAM, firewall default-deny, IDS/IPS (Snort/Suricata), SIEM (Wazuh/Elastic/Security Onion), log aggregation, detection engineering, vulnerability management, incident response (NIST SP 800-61), defense in depth, zero trust, least privilege.
What eEDA validates: the ability to implement and defend a properly secured enterprise infrastructure — not just know-about, but configure, harden, and verify real controls in a hands-on, lab-based exam reproducing a standard enterprise network. You're tested across four domains: Secure Engineering Fundamentals (12%), GRC (24%), IAM (28%), and Security Administration (36%).
⚠️ Defensive & authorized use. This is blue-team engineering — securing systems you own or are responsible for. Practice in your own lab. If you verify defenses with any offensive testing, do it only against your own systems. The eEDA is under NDA — learn the engineering thoroughly and practice it hands-on; don't seek or share actual exam content.
Table of Contents
eEDA Overview & Exam Strategy
Defensive Security Fundamentals (CIA, AAA & Core Principles)
Defense in Depth, Zero Trust & Resilient Design
The Cyber Kill Chain & MITRE ATT&CK for Defenders
Network Security Architecture & Segmentation
Governance, Risk & Compliance (GRC) Fundamentals
Risk Management — Assessment, Quantification & Treatment
Security Frameworks — NIST CSF, SP 800-53, ISO 27001, CIS
Compliance, Laws & Regulations
Policies, Standards, Procedures & Baselines
Change Management
Business Continuity & Disaster Recovery (BCP/DR)
Identity & Access Management — Fundamentals
Authentication — Passwords, MFA & Beyond
Authorization & Access Control Models (RBAC/ABAC/MAC/DAC)
Directory Services — Active Directory & LDAP Hardening
Single Sign-On & Federation (SAML, OAuth, OIDC)
Privileged Access Management (PAM)
The Identity Lifecycle — Provisioning to De-provisioning
Security Administration — Overview & Secure Admin Practices
System Hardening — Windows & Linux (CIS Benchmarks)
Firewall Architecture & Default-Deny Rulesets
IDS/IPS — Snort & Suricata
Endpoint Security & EDR
Secure Configuration & Baseline Management
Vulnerability Management
Logging, Log Aggregation & Log Management
SIEM, Detection Engineering & Alerting
Security Monitoring — Wazuh, Elastic & Security Onion
Incident Response (NIST SP 800-61)
Cryptography & PKI for Defenders
Data Security, Classification & DLP
Cloud, Email & Web Defensive Controls
Documentation, Reporting & Communication
Building the Defensive Lab
Capstone — Securing an Enterprise End to End
Exam-Day Strategy & Study Plan
Practical Commands, Configs & Queries Reference
Glossary & Quick Reference
1. eEDA Overview & Exam Strategy
What it is. The eEDA (Enterprise Defense Administrator) is INE Security's hands-on Blue Team certification. It validates basic defensive engineering — the practical ability to build, harden, administer, monitor, and defend a secure enterprise infrastructure. Where offensive certs prove you can break in, the eEDA proves you can keep attackers out and detect them when they try — by correctly configuring real defensive controls.
Exam format. A hands-on, lab-based exam that reproduces a standard enterprise network, with specific tasks to complete plus multiple-choice questions. You're graded not just on knowledge but on your ability to apply it — hardening a server, isolating a network zone, configuring IAM, writing firewall rules, building monitoring. Practice the engineering hands-on; reading alone won't pass it.
The four domains (and weights):
| Domain | Weight | What it covers |
|---|---|---|
| Security Administration | 36% | Harden systems; design & build secure environments; vulnerability mitigation; logging/monitoring/alerts |
| Identity & Access Management | 28% | IAM components & controls; implement authentication, authorization, directory, MFA, lifecycle |
| Governance, Risk & Compliance | 24% | GRC principles; risk identification & quantification; change management; frameworks & baselines |
| Secure Engineering Fundamentals | 12% | Core defensive terminology; long-term strategic, resilient security design |
Strategy that scores:
- Hands-on practice is mandatory. Build the lab (§35) and do the work — harden a server against CIS, stand up AD with RBAC and MFA, write default-deny firewall rules, build a Wazuh/ELK pipeline, run an incident through the IR lifecycle. The exam tests doing, not reciting.
- Default-deny thinking. Start closed, open deliberately, document why. Applies to firewalls, permissions, services, ports — everything.
- Least privilege everywhere. When in doubt, grant less. The single most-tested principle across IAM and admin tasks.
- Verify your work. Confirm a control actually does what you configured — test the firewall rule, confirm the account is really removed, check the alert fires. Defensive tasks often hinge on a precise requirement (a zone that must be isolated, an account that must be gone).
- Think in the five working areas. Fundamentals, GRC, IAM, Security Administration, and (within Admin) vulnerability management & monitoring. Most tasks map to one — identify which and apply its principles.
- Weight your prep. Security Administration (36%) + IAM (28%) = 64% of the exam and are the most hands-on — spend the most time there; GRC (24%) is conceptual but heavy; Fundamentals (12%) is foundational and quick.
The defensive engineer's mindset. You are building and maintaining a resilient system under the assumption that attackers will try and may get in. So you layer controls (defense in depth), minimize what each component can do (least privilege), segment to contain breaches, harden every system to a baseline, and monitor so you'll see an attack and can respond. That mindset — not any single tool — is what the eEDA certifies.
2. Defensive Security Fundamentals (CIA, AAA & Core Principles)
Everything in defensive engineering rests on a handful of principles. Internalize these — they're the "why" behind every control and the 12% Fundamentals domain.
The CIA Triad — the three goals of security:
- Confidentiality — information is accessible only to authorized parties. Controls: encryption (at rest & in transit), access control, least privilege, data classification, DLP. Threat: data breach/leak.
- Integrity — data and systems are accurate and unaltered by unauthorized parties. Controls: hashing, digital signatures, file-integrity monitoring (FIM), change control, input validation, backups. Threat: tampering, corruption.
- Availability — systems and data are accessible to authorized users when needed. Controls: redundancy, failover, backups, DDoS protection, capacity planning, BCP/DR. Threat: DoS, outage, ransomware.
Every control you implement and every risk you assess maps to one or more of these — frame your thinking in CIA.
Extended models: some add Authenticity (verifying identity/origin) and Non-repudiation (can't deny an action — via logging + signatures), giving the AAA of information security; and the Parkerian Hexad (adds possession/control, authenticity, utility). For eEDA, CIA + authenticity + non-repudiation is the working set.
AAA (of access control) — Authentication, Authorization, Accounting:
- Authentication — who are you? (verify identity — §14).
- Authorization — what may you do? (enforce permissions — §15).
- Accounting (Auditing) — what did you do? (log and track activity — §27). Enables non-repudiation and detection.
Core defensive principles (the heart of the fundamentals domain):
- Least Privilege — every user, process, and system gets the minimum access needed to do its job, and no more. Limits blast radius of compromise. The most important and most-applied principle.
- Defense in Depth — layered, overlapping controls so no single failure is catastrophic (§3).
- Zero Trust — never trust, always verify; no implicit trust based on network location (§3).
- Separation of Duties (SoD) — split critical tasks across people so no one person can abuse the whole process (e.g., the person who requests access isn't the one who approves it).
- Need to Know — access limited to information required for one's role (confidentiality-focused complement to least privilege).
- Fail-Safe / Fail-Secure (default-deny) — on failure or ambiguity, deny access and close down rather than open up. "Secure by default."
- Secure by Design / Secure by Default — security built in from the start, with the most secure configuration as the default, not an add-on.
- Economy of Mechanism (keep it simple) — simpler designs have fewer flaws and are easier to secure and audit.
- Complete Mediation — check authorization on every access, not just the first.
- Open Design — security shouldn't depend on secrecy of the design ("no security through obscurity"); it should hold even if the design is known.
- Least Common Mechanism — minimize shared resources/mechanisms between users to reduce cross-contamination.
- Psychological Acceptability — controls must be usable, or people will bypass them.
- Resilience & Redundancy — assume components fail; design to continue operating and to recover.
Key terminology (the fundamentals vocabulary):
Asset anything of value (data, systems, people, reputation)
Threat a potential cause of harm (actor or event)
Threat actor the entity behind a threat (criminal, insider, nation-state, hacktivist)
Vulnerability a weakness a threat can exploit
Exploit the method/code that leverages a vulnerability
Risk likelihood × impact of a threat exploiting a vulnerability
Control / Countermeasure / Safeguard a measure that reduces risk
Attack surface the sum of points where an attacker could interact with a system
Attack vector the path/method used to attack
Exposure being susceptible to a loss
Residual risk risk remaining after controls are applied
Control categories (how controls are classified — eEDA tests this):
- By function: Preventive (stop it — firewall, access control, hardening), Detective (notice it — IDS, logging, monitoring), Corrective (fix/recover — backups, patching, IR), Deterrent (discourage — warning banners, visible cameras), Compensating (alternative when the primary isn't feasible), Directive (mandate — policies).
- By type: Technical/Logical (firewalls, encryption, MFA), Administrative/Managerial (policies, training, risk assessments), Physical (locks, guards, cameras).
A mature program layers all categories — e.g., for data theft: policy (administrative/directive) + access control & encryption (technical/preventive) + logging & DLP alerts (technical/detective) + backups & IR (corrective).
The defensive equation to carry everywhere: reduce likelihood (preventive controls) + reduce impact (segmentation, least privilege, backups) + increase detection (monitoring) + enable response (IR) = managed risk. That's the whole job in one line.
3. Defense in Depth, Zero Trust & Resilient Design
The Fundamentals domain emphasizes long-term strategic design of resilient security. Two architectural philosophies dominate: defense in depth and zero trust.
Defense in Depth (layered security). No single control is perfect, so you deploy multiple, overlapping layers such that an attacker must defeat several to succeed, and a failure of one is caught or contained by others. The layers (outside-in):
PEOPLE & POLICY security awareness, policies, training, acceptable use
PHYSICAL facility access, locks, cameras, environmental controls
PERIMETER / NETWORK firewalls, segmentation, IDS/IPS, VPN, DMZ
HOST / ENDPOINT hardening, EDR/antivirus, host firewall, patching
APPLICATION secure coding, input validation, WAF, app hardening
DATA encryption, access control, DLP, classification, backups
IDENTITY (cross-cutting) authentication, MFA, least privilege, PAM
MONITORING (cross-cutting) logging, SIEM, detection, alerting
Example: to protect a database — network segmentation (it's in a restricted zone) + host hardening + database access control + least-privilege service account + encryption at rest + DLP + logging/monitoring + backups. If the perimeter is breached, segmentation contains it; if a host is compromised, least privilege limits it; if data is accessed, encryption and DLP reduce impact; and monitoring detects it. Layered, overlapping, with no single point of total failure.
Zero Trust (ZTA). The modern evolution: "never trust, always verify." Eliminate implicit trust based on network location — a user/device inside the corporate network is not automatically trusted. Every access request is authenticated, authorized, and continuously validated.
- Core tenets: verify explicitly (every request, using identity + device + context); use least-privilege access (just-in-time, just-enough); assume breach (segment, limit blast radius, monitor everything).
- Building blocks: strong identity (MFA, device identity), micro-segmentation (fine-grained network segmentation, down to workload level), least-privilege/just-in-time access, continuous monitoring & validation, and policy-based access decisions (a policy engine evaluating each request).
- Contrast with the old "castle-and-moat": the old model trusted everything inside the perimeter (so one breach = free lateral movement). Zero trust removes that implicit trust — there is no "inside."
For the exam: understand that zero trust means per-request verification, least privilege, micro-segmentation, and assume-breach — and how it improves on perimeter-only defense.
Resilient & strategic design (the 12% domain's "long-term strategic planning"). Defensive engineering isn't one-time; it's designing systems that withstand, adapt to, and recover from attacks and failures over time:
- Redundancy & high availability — no single points of failure; failover, clustering, redundant links/power.
- Fault tolerance & graceful degradation — continue operating (perhaps reduced) when a component fails.
- Recoverability — backups, DR, and the ability to restore to a known-good state quickly (ties to BCP/DR, §12).
- Secure baselines & standardization — consistent hardened configurations across the fleet (easier to secure, monitor, and recover — §25).
- Scalability of controls — security that grows with the organization (centralized identity, automated config management, scalable logging).
- Continuous improvement — the security posture is maintained and improved over time (patching, re-assessment, threat-informed updates), not set-and-forget.
- Threat-informed design — architect against how adversaries actually operate (kill chain / ATT&CK, §4) — place detection and controls where attackers must pass.
The strategic deliverable: a security architecture that is layered (defense in depth), trust-minimizing (zero trust), resilient (redundant, recoverable), standardized (baselines), monitored (so you see attacks), and continuously improved. The eEDA fundamentals domain asks you to think this way; the hands-on domains ask you to build it.
4. The Cyber Kill Chain & MITRE ATT&CK for Defenders
To defend effectively, you must understand how attacks unfold — then place controls and detection along the attacker's path. Two models frame this.
The Cyber Kill Chain (Lockheed Martin) — a 7-stage model of an intrusion. For defenders, each stage is an opportunity to disrupt the attack (the earlier the cheaper):
1. Reconnaissance attacker researches the target Defend: minimize public exposure, monitor scanning
2. Weaponization builds the exploit/payload Defend: (attacker-side) threat intel
3. Delivery sends it (email, web, USB) Defend: email/web filtering, awareness, disable autorun
4. Exploitation exploits a vulnerability Defend: patching, hardening, EDR, least privilege
5. Installation installs malware/persistence Defend: EDR, app allow-listing, monitor persistence
6. Command & Control establishes remote control (C2) Defend: egress filtering, DNS/proxy monitoring, IDS
7. Actions on Objectives steals/encrypts/destroys data Defend: DLP, segmentation, backups, monitoring
Defensive use: map your controls to the chain and ensure coverage at every stage — if you can break the chain at any link, you stop the attack. Earlier disruption (delivery/exploitation) is cheaper than later (actions on objectives). This is "threat-informed defense."
MITRE ATT&CK — the modern, granular knowledge base of adversary tactics (the why — the goal) and techniques (the how), based on real-world observations. The enterprise tactics (roughly in order):
Reconnaissance · Resource Development · Initial Access · Execution · Persistence ·
Privilege Escalation · Defense Evasion · Credential Access · Discovery ·
Lateral Movement · Collection · Command & Control · Exfiltration · Impact
Defensive uses (critical for the Security Administration & monitoring domains):
- Detection engineering — build detections mapped to specific ATT&CK techniques (e.g., T1059 command/scripting, T1003 credential dumping, T1021 lateral movement, T1486 ransomware). Know what telemetry reveals each.
- Coverage assessment — use the ATT&CK Navigator to map which techniques your controls/detections cover and find gaps (a "heat map" of defensive coverage).
- Threat-informed hardening — prioritize controls against the techniques most relevant to your environment and threat model.
- Purple teaming — validate detections by (safely, on your own systems) simulating techniques and confirming they're caught.
Kill Chain vs ATT&CK (when to use which): the Kill Chain is a simple, linear narrative for strategy and awareness ("where in the attack are we, and can we break the chain?"); ATT&CK is granular and operational for detection engineering and coverage ("which specific techniques can we detect/prevent?"). A defensive engineer uses both — the Kill Chain to reason about layered disruption, ATT&CK to build and measure concrete detections.
The defender's framing: attacks are a process with many steps. You don't need to stop every step — you need layered controls and detection across the process so you prevent what you can, detect what you can't prevent, and respond before the attacker reaches their objective. Place your defenses where the attacker must operate, and instrument those choke points.
5. Network Security Architecture & Segmentation
Network design is foundational to enterprise defense — proper segmentation contains breaches and is a recurring hands-on exam task. Default-deny and least privilege apply to networks just as to accounts.
Network segmentation — why it's the backbone of containment. Dividing the network into isolated zones means a compromise in one zone doesn't give free access to others. It limits lateral movement (the attacker's key tactic), reduces attack surface per zone, enables tailored controls per sensitivity level, and contains incidents.
A standard enterprise zone model:
INTERNET (untrusted)
│ firewall
DMZ / Perimeter Zone public-facing services (web, mail, DNS, VPN) — exposed, so isolated from internal
│ firewall
INTERNAL / CORPORATE ZONE user workstations, general services
│ firewall
SERVER / DATACENTER ZONE internal servers (AD, file, app) — tighter controls
│ firewall
RESTRICTED / SECURE ZONE crown jewels: databases, PII, financial systems — strictest controls
MANAGEMENT ZONE admin/management interfaces, jump hosts — isolated, MFA-protected
OT / IOT ZONE (if present) operational technology / IoT — isolated from IT
GUEST ZONE untrusted guest Wi-Fi — isolated from corporate
Principle: traffic between zones is default-deny, with specific allowed flows based on business need (least privilege for networks). The more sensitive the zone, the stricter the controls and the fewer the allowed flows.
Segmentation mechanisms:
- VLANs — logical layer-2 segmentation; separate broadcast domains. Combined with inter-VLAN firewall/ACL control.
- Subnets & routing — layer-3 separation; route control between segments.
- Firewalls between zones — enforce the default-deny inter-zone policy (§22).
- ACLs on routers/switches — additional traffic control.
- Micro-segmentation — fine-grained, often host/workload-level isolation (zero-trust style, via host firewalls or SDN), so even within a zone, only required flows are allowed.
- Private VLANs / port isolation — isolate hosts even within a VLAN.
- Air-gapping — physical isolation for the most critical systems (where feasible).
The DMZ pattern (classic, exam-relevant). Public-facing services go in a DMZ between two firewall boundaries: the outer firewall allows limited internet traffic to the DMZ services; the inner firewall tightly restricts DMZ→internal traffic. So if a public server is compromised, the attacker is contained in the DMZ and can't freely reach the internal network. Example flows: internet→DMZ web server on 443 (allowed); DMZ web server→internal DB on the DB port only (allowed, specific); DMZ→anything else internal (denied).
Key supporting controls:
- Firewalls at every zone boundary with default-deny rulesets (§22).
- IDS/IPS monitoring inter-zone and perimeter traffic (§23).
- Network Access Control (NAC) — authenticate/posture-check devices before granting network access (ties to zero trust); place unknown/non-compliant devices in a quarantine VLAN.
- VPN for remote access — encrypted, authenticated (MFA), terminating into a controlled zone, not flat internal access.
- Egress filtering — control outbound traffic too (not just inbound) — this disrupts C2 and exfiltration (kill-chain stages 6–7). Default-deny egress with allowed destinations is powerful and often overlooked.
- Secure management plane — admin interfaces on an isolated management network/VLAN, accessed via hardened jump hosts/bastions with MFA; never expose management to the general network or internet.
Designing segmentation (the hands-on skill): (1) classify systems by sensitivity and function; (2) group like-sensitivity systems into zones; (3) define only the necessary flows between zones (default-deny everything else); (4) enforce with firewalls/ACLs/VLANs; (5) place monitoring at boundaries; (6) verify isolation (confirm a host in the user zone genuinely cannot reach the restricted zone except via allowed flows). Document the zones, flows, and rationale.
The principle: segment to contain. Assume any single system may be breached, and design the network so that breach can't spread — least-privilege flows, default-deny between zones, isolated management, egress control, and monitoring at the boundaries. A well-segmented network turns a potential enterprise-wide compromise into a contained, detectable incident.
6. Governance, Risk & Compliance (GRC) Fundamentals
GRC (24% of the exam) is the organizational framework within which security operates — the policies, risk decisions, and regulatory obligations that direct the technical controls. Defensive engineering doesn't happen in a vacuum; GRC tells you what to protect, how much, and why.
The three pillars:
- Governance — the direction and oversight of security: leadership, strategy, policies, roles/responsibilities, and accountability. It answers "who decides, who's responsible, and what are the rules?" Includes the security policy framework, a security steering committee, defined roles (CISO, data owners, system owners, custodians, users), and alignment of security with business objectives.
- Risk Management — identifying, assessing, and treating risk to an acceptable level (§7). It answers "what could go wrong, how bad, how likely, and what do we do about it?"
- Compliance — meeting external obligations (laws, regulations, contracts, standards) and internal policies. It answers "what are we required to do, and can we prove we're doing it?" (§9).
Key governance concepts:
- Roles & responsibilities (know these):Data Owner accountable for data (classification, who may access) — a business role System Owner accountable for a system Data Custodian implements/maintains controls on data (often IT) Data Steward day-to-day data quality/management Data Processor processes data on behalf of the owner/controller (esp. privacy law) CISO / Security sets security strategy & oversight Users follow policy; responsible for their actions
- Security policy framework (the document hierarchy — §10): Policies (high-level mandates) → Standards (specific mandatory requirements) → Procedures (step-by-step how-to) → Guidelines (recommended best practice) → Baselines (minimum security configurations).
- Due care vs due diligence — due care = taking reasonable steps to protect (acting responsibly); due diligence = the ongoing effort to ensure due care is maintained (monitoring, assessing, verifying). "Due diligence is doing the homework; due care is acting on it."
- Accountability & auditability — actions are traceable to individuals (via logging, §27), and the program can be audited against its policies and frameworks.
GRC's relationship to the technical work. GRC sets the requirements; security administration implements them; monitoring verifies them; and the results feed back into risk decisions. For example: a regulation (compliance) requires protecting cardholder data → a policy mandates encryption and access control → standards/baselines specify how → security administration implements it → monitoring/audit verifies it → risk management tracks residual risk. The eEDA tests your ability to connect these — e.g., "map controls to NIST CSF" or "create an acceptable cybersecurity baseline from a framework."
Why a defensive engineer needs GRC. You can't secure everything equally — GRC (via risk management) tells you where to focus (highest risk, regulatory must-haves); governance gives you the authority and structure (policies, roles) to act; compliance defines non-negotiable requirements. GRC turns "do security" into a prioritized, accountable, defensible program. The 24% weight reflects that the exam expects you to operate within — and help build — this framework.
7. Risk Management — Assessment, Quantification & Treatment
Risk management is the engine of GRC and an explicit eEDA objective ("identify and quantify levels of risk and impact"). It's how an organization decides what to protect, how much to spend, and what to accept.
The risk equation: Risk = Likelihood × Impact (of a threat exploiting a vulnerability against an asset). More fully, risk arises when a threat exploits a vulnerability to harm an asset, with a certain likelihood and impact. Reduce any factor → reduce risk.
The risk management lifecycle:
1. IDENTIFY — catalogue assets (and their value), threats, and vulnerabilities.
2. ASSESS/ANALYZE — determine likelihood & impact for each risk (qualitative and/or quantitative).
3. PRIORITIZE — rank risks (risk matrix / risk register) by severity.
4. TREAT — choose a response for each risk (below).
5. MONITOR & REVIEW — track risks and controls over time; reassess as things change.
Risk assessment approaches:
- Qualitative — rate likelihood and impact on scales (Low/Medium/High, or 1–5) and combine in a risk matrix (likelihood × impact → risk level). Fast, subjective, good for prioritization and communication. The common default.Risk Matrix (example): Impact → Low Medium High Critical Likelihood High Med High High Critical Medium Low Med High High Low Low Low Med High
- Quantitative — assign monetary values (for cost-benefit decisions):AV Asset Value (what the asset is worth) EF Exposure Factor (% of asset value lost in an incident) SLE Single Loss Expectancy = AV × EF ARO Annualized Rate of Occurrence (how many times per year) ALE Annualized Loss Expectancy = SLE × ARO ← the key number # A control is cost-justified if its annual cost < the ALE reduction it provides. # Example: AV=$100k, EF=50% → SLE=$50k; ARO=0.2 (once per 5 yrs) → ALE=$10k/yr. # A $3k/yr control that eliminates this risk saves $7k/yr net → justified.
- Hybrid / semi-quantitative — combine both. Most real programs use qualitative for breadth and quantitative for major decisions.
Risk treatment (the four responses — know these cold):
- Mitigate (Reduce) — apply controls to lower likelihood and/or impact (the most common — harden, patch, segment, add detection).
- Transfer (Share) — shift risk to another party (cyber insurance, outsourcing with contractual liability).
- Avoid — eliminate the risk by not doing the risky activity (e.g., don't deploy the risky service; decommission the exposed system).
- Accept — knowingly accept the risk (when cost of treatment > the risk, or residual risk is within appetite) — formally documented and approved.
(Some add "Reject" — ignoring risk — which is not a legitimate strategy and a finding if observed.)
Key concepts:
- Risk appetite / tolerance — how much risk the organization is willing to accept; treatment decisions are made against this threshold.
- Residual risk — the risk remaining after controls are applied; must fall within risk appetite or be formally accepted.
- Inherent vs residual risk — inherent = before controls; residual = after.
- Risk register — the living document tracking each risk: description, likelihood, impact, owner, treatment, status, residual risk. A core GRC artifact.
- Risk owner — the person accountable for managing a specific risk.
Threat modeling & business impact (related):
- Threat modeling — systematically identifying threats to a system (e.g., STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to find where controls are needed.
- Business Impact Analysis (BIA) — identifies critical business functions and the impact of their disruption; produces RTO (Recovery Time Objective — max tolerable downtime) and RPO (Recovery Point Objective — max tolerable data loss), which drive BCP/DR (§12).
The defensive engineer's use of risk: risk management tells you where to spend your limited time and budget — the highest likelihood × impact risks, and the regulatory must-dos, come first. It also justifies controls (to leadership, via ALE or risk reduction) and documents accepted risk. On the exam, expect to identify/quantify risks, choose treatments, and tie controls to risk reduction. The mantra: you can't eliminate all risk — you manage it to an acceptable level, cost-effectively, and document your decisions.
8. Security Frameworks — NIST CSF, SP 800-53, ISO 27001, CIS
Frameworks are the standardized blueprints for a security program — the eEDA explicitly tests "industry-standard frameworks" and "creating acceptable cybersecurity baselines." Know what each framework is for and how they fit together.
NIST Cybersecurity Framework (CSF) — a voluntary, risk-based framework organizing security into functions (the most-cited model; learn it):
IDENTIFY — understand your assets, risks, and context (asset inventory, risk assessment, governance)
PROTECT — safeguards to limit/contain impact (access control, awareness, data security, maintenance,
protective technology — most hardening/IAM lives here)
DETECT — identify security events (continuous monitoring, detection processes, anomalies)
RESPOND — act on detected incidents (response planning, communications, analysis, mitigation)
RECOVER — restore capabilities after an incident (recovery planning, improvements, communications)
# (CSF 2.0 adds a GOVERN function wrapping the others — governance/risk/oversight.)
Use: CSF is the high-level organizing structure for a whole program; "mapping controls to NIST CSF" (an exam task) means placing each control under the right function/category. It's framework-agnostic about how — it tells you what outcomes to achieve.
NIST SP 800-53 — a comprehensive catalog of security and privacy controls (hundreds of controls in families like AC Access Control, AU Audit & Accountability, CM Configuration Management, IA Identification & Authentication, IR Incident Response, SC System & Communications Protection, SI System & Information Integrity, etc.). Use: the detailed "what controls exist and what they require"; US federal baselines (Low/Moderate/High) are built from it. Where CSF says "protect," 800-53 gives the specific controls.
ISO/IEC 27001 — the international standard for an Information Security Management System (ISMS) — a management-system approach (people, process, governance) that organizations get certified against. Paired with ISO 27002 (the controls guidance). Built around the Plan-Do-Check-Act (PDCA) continuous-improvement cycle, risk assessment, a Statement of Applicability, and management commitment. Use: the governance/management framework for a certifiable, auditable program; emphasizes process and continual improvement, not just controls.
CIS Controls — a prioritized, actionable set of defensive actions (currently 18 controls, grouped into Implementation Groups IG1/IG2/IG3 by organization size/maturity). Use: "where do I start / what matters most?" — the most practical, prioritized to-do list for defense (e.g., inventory assets, inventory software, data protection, secure config, account/access management, continuous vuln management, audit log management, email/web protections, malware defenses, data recovery, network infrastructure, monitoring, awareness, incident response, pen testing). Highly hands-on and eEDA-aligned.
CIS Benchmarks — consensus secure-configuration baselines for specific systems (Windows Server, Linux distros, databases, browsers, cloud, network devices). Each benchmark is a detailed checklist of hardening settings with rationale. Use: the concrete "how to harden this exact system" — directly used in the Security Administration hardening tasks (§21, §25). This is the baseline source for "creating acceptable cybersecurity baselines."
Others worth knowing:
- MITRE ATT&CK (§4) — adversary technique knowledge base (detection/coverage).
- PCI DSS (§9) — mandatory controls for payment-card data.
- NIST SP 800-61 (§30) — incident handling.
- NIST SP 800-37 (RMF) — the Risk Management Framework process (categorize, select, implement, assess, authorize, monitor).
- COBIT — IT governance framework (business-IT alignment).
- OWASP — web application security.
How they fit together (the mental model):
GOVERNANCE/ISMS: ISO 27001 (certifiable management system) or NIST CSF+RMF (US public sector)
↓ gives structure & risk process
WHAT TO ACHIEVE: NIST CSF functions (Identify/Protect/Detect/Respond/Recover)
↓ organizes outcomes
WHICH CONTROLS: NIST SP 800-53 (comprehensive catalog) or CIS Controls (prioritized actions)
↓ specifies controls
HOW TO CONFIGURE: CIS Benchmarks (exact hardening settings per system)
THREAT LENS: MITRE ATT&CK (what to detect), Kill Chain (where to disrupt)
Creating a cybersecurity baseline (an exam deliverable): pick the relevant framework(s) for the organization's size, sector, and obligations → select the applicable controls (CIS Controls for prioritization, 800-53 for comprehensiveness) → define the minimum secure configuration using CIS Benchmarks → document it as the organization's baseline standard → apply it consistently (config management, §25) → measure compliance and improve. The baseline is the minimum acceptable security configuration every system must meet.
The principle: frameworks give you a proven, standardized, defensible structure so you're not inventing security from scratch — CSF for organization, 800-53/CIS Controls for the control set, CIS Benchmarks for exact configuration, ISO 27001 for the management system, and ATT&CK for the threat lens. The eEDA expects you to know what each is for and to use them to build baselines and map controls.
9. Compliance, Laws & Regulations
Compliance is meeting external legal/regulatory/contractual obligations (and internal policy). A defensive engineer must know the major regimes, what each protects, and that compliance drives mandatory controls. (Compliance ≠ security — it's the floor, not the ceiling — but non-compliance has legal/financial consequences, so it's non-negotiable.)
Major regulations & standards (know what each is for):
GDPR (EU) — personal data protection & privacy for EU residents; consent, data-subject rights,
breach notification (72h), data minimization, DPO, heavy fines. (Also UK GDPR.)
HIPAA (US) — protected health information (PHI); Privacy & Security Rules; safeguards for
healthcare data; breach notification.
PCI DSS — payment card data (not a law — a card-industry standard, contractually mandated);
12 requirements incl. network security, encryption, access control, monitoring,
vulnerability management. Very prescriptive.
SOX (US) — financial reporting integrity for public companies; IT controls over financial
systems (access, change management, audit).
GLBA (US) — financial institutions' protection of customer financial data.
CCPA/CPRA (CA) — California consumer privacy rights (GDPR-like for California residents).
FERPA (US) — student education records.
NIS2 (EU) — cybersecurity for critical/essential services.
FISMA (US) — federal information security (drives NIST RMF/800-53 use).
CMMC (US) — cybersecurity maturity for defense contractors.
Key compliance concepts:
- Scope — which systems/data fall under a regulation (e.g., PCI applies to the cardholder-data environment; reducing scope via segmentation reduces compliance burden — a defensive-engineering win).
- Mandatory controls — regulations prescribe (sometimes specifically) required safeguards; these become non-negotiable requirements for your baselines/policies.
- Data residency / sovereignty — laws requiring data to stay in/avoid certain jurisdictions (drives architecture/location decisions).
- Breach notification — many regimes require notifying regulators/affected parties within a set time (e.g., GDPR 72h) — ties to incident response (§30).
- Audits & evidence — compliance must be demonstrable; you need documentation, logs, and evidence that controls are in place and working (ties to logging/accountability).
- Attestation / certification — some require formal certification (ISO 27001) or audit reports (SOC 2 Type II) you provide to customers/regulators.
- Contractual obligations — customer contracts and third-party agreements impose security requirements (and you impose them on your vendors — supply-chain/vendor risk).
Frameworks that help achieve compliance: NIST CSF/800-53, ISO 27001, and CIS Controls (§8) map to most regulatory requirements — implementing a solid framework-based program covers much of compliance. Control mapping (showing how your controls satisfy each regulatory requirement) is a core GRC activity and a defensible way to demonstrate compliance.
The defensive engineer's role in compliance: translate regulatory requirements into technical controls and baselines, implement them, generate the evidence (logs, configs, reports) that proves compliance, support audits, and use segmentation to reduce scope. Understand that compliance sets the mandatory minimum; good security goes beyond it. On the exam, know the major regimes, what data each protects, and that compliance obligations become required controls.
10. Policies, Standards, Procedures & Baselines
The security policy framework is how governance is operationalized — the documented rules that direct behavior and configuration. The eEDA tests "write a policy" and "create baselines." Know the document hierarchy and how to write each.
The document hierarchy (from high-level to specific):
POLICY — high-level management MANDATE; the "what and why"; mandatory; rarely changes.
e.g., "All data must be classified and protected according to its classification."
STANDARD — specific MANDATORY requirements that support a policy; the "what, specifically."
e.g., "All laptops must use full-disk encryption (AES-256)."
PROCEDURE — step-by-step HOW-TO; mandatory; detailed instructions.
e.g., "To encrypt a laptop: 1) enable BitLocker, 2) escrow the key to..., 3) verify..."
GUIDELINE — RECOMMENDED best practice; advisory (not mandatory); the "should."
e.g., "Users should avoid storing sensitive data on local drives where possible."
BASELINE — minimum security CONFIGURATION standard for a system type.
e.g., "Windows Server baseline = CIS Level 1 + these org-specific settings."
The relationship: policies set direction → standards & baselines make it concrete & measurable → procedures tell people exactly how → guidelines advise. Everything traces up to a policy.
Essential enterprise policies (know the common set):
Information Security Policy (overarching) Acceptable Use Policy (AUP)
Access Control Policy Password / Authentication Policy
Data Classification & Handling Policy Data Retention & Disposal Policy
Change Management Policy Incident Response Policy
Business Continuity / DR Policy Remote Access / BYOD Policy
Encryption Policy Logging & Monitoring Policy
Vendor / Third-Party Risk Policy Vulnerability & Patch Management Policy
Physical Security Policy Security Awareness & Training Policy
Anatomy of a good policy (how to write one — exam skill):
Purpose why the policy exists
Scope who/what it applies to (people, systems, data, locations)
Policy statements the actual mandatory rules (clear, enforceable, measurable)
Roles & responsibilities who does/enforces what
Compliance / enforcement consequences of violation
Exceptions how to request/approve deviations
References related policies, standards, regulations, frameworks
Review cycle owner, approval, and review date (policies are living documents)
Writing tips: make statements clear, enforceable, and measurable ("passwords must be ≥14 characters" not "passwords should be strong"); align to a framework (cite CSF/ISO/CIS); keep policies stable and put changeable specifics in standards; ensure management approval (authority) and periodic review.
Data classification (a core policy — drives most data controls): classify data by sensitivity so controls match value. Typical scheme:
Public no harm if disclosed
Internal low harm; internal use only
Confidential significant harm if disclosed (PII, financials)
Restricted/Secret severe harm (trade secrets, regulated data, credentials)
Each level gets handling rules (access, encryption, storage, transmission, disposal). Classification drives least-privilege access, encryption requirements, DLP, and retention.
Creating a baseline (the hands-on deliverable, ties to §8/§25): select a framework (CIS Benchmark for the system type) → choose the applicable level/settings → add org-specific requirements → document as the minimum security configuration standard → apply consistently and measure compliance → review/update. The baseline is what every system of that type must meet before and during production.
The principle: policies give you documented, approved authority to enforce security and a consistent, measurable standard to hold systems and people to. "If it isn't written down, it isn't a policy" — and unwritten rules can't be enforced or audited. The framework (policy→standard→procedure→baseline) turns governance intent into implementable, verifiable requirements. The eEDA expects you to write them and build baselines from frameworks.
11. Change Management
Uncontrolled change is a top cause of outages and security gaps; a structured change management process is an explicit eEDA objective. It ensures changes are reviewed, approved, tested, documented, and reversible — protecting integrity and availability.
Why change management matters for security: unmanaged changes introduce misconfigurations, open vulnerabilities, break controls, and cause outages; attackers also hide malicious changes among legitimate ones. Controlled change gives you a reviewed, approved, documented, auditable trail — supporting integrity, availability, accountability, and the ability to roll back.
The change management process (standard flow):
1. REQUEST (RFC) — a Request for Change: what, why, who, when, systems affected.
2. REVIEW / ASSESS — evaluate risk, impact, security implications, dependencies, and rollback.
3. APPROVE — the Change Advisory Board (CAB) or authority approves/denies/defers.
(segregation: requester ≠ approver — separation of duties.)
4. TEST — validate the change in a non-production environment where possible.
5. SCHEDULE — plan the change window (minimize business impact; notify stakeholders).
6. IMPLEMENT — make the change per the plan, with a rollback plan ready.
7. VERIFY — confirm the change worked AND that security controls still function.
8. DOCUMENT / CLOSE — record what was done, the outcome, and update the CMDB/baselines.
9. REVIEW (post-impl)— for significant/failed changes, review lessons learned.
Key concepts & roles:
- RFC (Request for Change) — the formal change request.
- CAB (Change Advisory Board) — reviews/approves changes (balances agility and control).
- Change types: Standard (pre-approved, low-risk, routine — e.g., a defined patch), Normal (goes through full review/approval), Emergency (expedited process for urgent fixes, with retrospective review).
- Rollback / back-out plan — how to reverse the change if it fails (mandatory for significant changes).
- CMDB (Configuration Management Database) — the record of configuration items and their state; updated by changes (ties to config management, §25).
- Maintenance window — the scheduled time for changes to limit disruption.
- Separation of duties — the person requesting/implementing shouldn't be the sole approver.
Change management & security specifically:
- Security review of changes — assess each change for security impact (does it open a port, change access, affect a control, introduce a vulnerability?).
- Patch management (a specialized change process) — test → approve → schedule → deploy → verify patches, balancing speed (close the vuln) with stability (don't break production) (§26).
- Configuration drift — unmanaged changes cause systems to drift from the secure baseline; change management + config management prevents/detects drift (§25).
- Emergency changes still get documented and reviewed afterward — an untracked "quick fix" is a security and audit gap.
The principle: change management brings discipline, review, approval, documentation, and reversibility to how systems evolve — preventing the misconfigurations and outages that uncontrolled change causes, maintaining the secure baseline, and giving you an auditable trail. For the exam, know the process (RFC → review → approve → test → implement → verify → document), the roles (CAB), the change types, and the importance of rollback plans and separation of duties.
12. Business Continuity & Disaster Recovery (BCP/DR)
Availability is a CIA pillar, and resilience is a Fundamentals theme — BCP/DR ensures the organization can continue operating during and recover after a disruption (cyberattack, outage, disaster). An eEDA objective under GRC.
BCP vs DR (distinguish them):
- Business Continuity Plan (BCP) — the broad plan to keep the whole business (or its critical functions) running during a disruption — processes, people, facilities, communications, and IT. Business-focused.
- Disaster Recovery Plan (DR) — the IT-focused subset: how to restore IT systems and data after a disaster. DR is a component of BCP.
The foundation — Business Impact Analysis (BIA): identifies the organization's critical business functions, the impact of their disruption over time, and their dependencies — producing the key recovery metrics:
RTO (Recovery Time Objective) — max tolerable DOWNTIME for a function/system (how fast must it recover)
RPO (Recovery Point Objective) — max tolerable DATA LOSS (how much data can be lost → backup frequency)
MTD (Maximum Tolerable Downtime)— the absolute limit before unacceptable harm
WRT (Work Recovery Time) — time to verify & resume normal operations after restoration
These metrics drive the design: a function with a 1-hour RTO and 5-minute RPO needs hot standby and near-continuous replication; a function with a 1-week RTO and 24-hour RPO can use daily backups and slower recovery. Match the (costly) recovery capability to the business need.
Backups (the bedrock of recovery):
- Backup types: Full (everything), Incremental (changes since last backup — fast backup, slower restore), Differential (changes since last full — slower backup, faster restore). Snapshots for fast point-in-time.
- The 3-2-1 rule: 3 copies of data, on 2 different media, with 1 off-site (and ideally 1 offline/immutable — critical against ransomware).
- Offline/immutable backups — air-gapped or write-once backups that ransomware can't encrypt/delete — a key modern defense.
- Test restores — a backup you haven't tested restoring is not a reliable backup; regularly verify you can actually recover within RTO/RPO.
- Encryption & access control on backups (they contain your sensitive data).
DR strategies (by recovery speed/cost — ties to the cloud-DR concepts):
Cold site facility/space only; slowest, cheapest (days to recover)
Warm site partially equipped; moderate (hours–days)
Hot site fully equipped, near-real-time replicated; fast, expensive (minutes–hours)
Cloud DR backup/restore, pilot light, warm standby, or active-active (scalable options)
Choose per RTO/RPO and criticality — not everything needs a hot site.
High availability vs DR (distinguish): HA = preventing downtime via redundancy within normal operations (clustering, failover, redundant components — keeps running through component failures); DR = recovering after a major disaster. You need both: HA for day-to-day resilience, DR for catastrophic events.
Plan components & lifecycle:
- Plan contents: critical functions & systems (from BIA), recovery procedures, roles/responsibilities, communication plan (incl. who to notify), backup/recovery details, alternate sites, and contact lists.
- Testing (essential — an untested plan is unreliable): walkthrough/tabletop (discuss), simulation, parallel test (recover alongside production), and full interruption (actually fail over — highest confidence, highest risk). Test regularly and update.
- Maintenance — review and update plans as the environment changes.
BCP/DR & cyber incidents (modern relevance): ransomware makes BCP/DR a frontline security control — tested, offline/immutable backups and a rehearsed recovery plan are what let you recover without paying. BCP/DR connects to incident response (§30): IR contains/eradicates; DR restores.
The principle: assume disruptions will happen and plan to continue operating and recover within tolerable limits. The BIA (→ RTO/RPO) drives the design; tested backups (3-2-1, offline/immutable) are the foundation; HA handles routine failures, DR handles disasters; and the plan must be documented, role-assigned, and regularly tested. For the exam, know BCP vs DR, BIA/RTO/RPO/MTD, backup types & 3-2-1, site types, HA vs DR, and the testing methods.
13. Identity & Access Management — Fundamentals
IAM (28% of the exam) is controlling who can access what, and ensuring they are who they claim to be — the foundation of enterprise security and a heavily hands-on domain. "Identity is the new perimeter" (zero trust). This section frames IAM; §14–19 drill each part.
What IAM is: the policies, processes, and technologies that manage digital identities and their access to resources, across the full lifecycle (create → use → remove). It implements AAA: Authentication (verify identity), Authorization (grant appropriate access), Accounting (log/audit access).
The core IAM components:
IDENTITY a digital representation of a user/service/device (account + attributes)
AUTHENTICATION proving the identity is genuine (§14)
AUTHORIZATION determining what an authenticated identity may do (§15)
ACCESS CONTROL enforcing authorization decisions (the models in §15)
DIRECTORY the central store of identities & attributes (AD/LDAP — §16)
PROVISIONING creating/updating access (onboarding, role changes — §19)
DE-PROVISIONING removing access (offboarding — §19)
SSO / FEDERATION one identity across many systems/organizations (§17)
PAM managing privileged/admin access (§18)
MFA multi-factor authentication (§14)
IGA Identity Governance & Administration (policies, reviews, certification)
Key IAM concepts:
- Identity vs account vs credential: identity = the person/entity; account = the system representation; credential = the proof (password, key, token).
- Principal / subject — the entity requesting access; object — the resource being accessed.
- Least privilege — the governing principle: grant the minimum access needed (the most-tested idea in this domain).
- Separation of duties — split sensitive capabilities so no single identity can abuse a whole process.
- Identity Governance — the oversight layer: access reviews/recertification, policy enforcement, role management, and audit — ensuring access stays appropriate over time (people accumulate access — "privilege creep" — without it).
- Just-in-Time (JIT) access — grant privileged access only when needed, for a limited time (zero-trust/PAM concept).
- Non-human identities — service accounts, machine identities, API keys — often over-privileged and poorly managed; a growing risk area requiring the same lifecycle rigor.
Why IAM is central (and 28% of the exam): the vast majority of breaches involve compromised or misused credentials/access. Strong IAM — strong authentication (MFA), least-privilege authorization, tight lifecycle (especially de-provisioning), privileged access control, and governance (reviews) — prevents, limits, and detects most attacks. It's the control that most directly stops attackers from getting in and from moving/escalating once in. The eEDA tests you implementing IAM, not just describing it.
The IAM mindset (carry through §14–19): every identity gets verified strongly, granted least privilege, managed through its whole lifecycle (and promptly removed when no longer needed), with privileged access tightly controlled and all access governed, reviewed, and logged. Build that, and you've addressed the single largest category of enterprise risk.
14. Authentication — Passwords, MFA & Beyond
Authentication verifies an identity is genuine — the "who are you?" of AAA. Weak authentication is a top breach cause; strong authentication (especially MFA) is among the highest-impact controls. A core hands-on IAM skill.
The authentication factors (know these):
SOMETHING YOU KNOW — password, PIN, passphrase, security question (knowledge)
SOMETHING YOU HAVE — token, smartcard, phone (authenticator app), key (possession)
SOMETHING YOU ARE — biometrics: fingerprint, face, iris, voice (inherence)
SOMEWHERE YOU ARE — location/geolocation (context) (location)
SOMETHING YOU DO — behavioral biometrics (typing pattern, gait) (behavior)
Multi-Factor Authentication (MFA): requiring two or more factors from different categories (a password + a phone code is MFA; two passwords is not). MFA dramatically reduces account takeover because a stolen password alone is useless. Enforce MFA everywhere, especially for: all remote access, all privileged/admin accounts, email, VPN, and externally-facing services. A top eEDA control — be ready to "enforce MFA."
- MFA methods (strongest → weakest): hardware security keys / FIDO2 (phishing-resistant, best) > authenticator apps (TOTP/push) > SMS/email codes (weakest — SIM-swap/interception risk, avoid for high-value). Push MFA has "MFA fatigue" risk — use number-matching.
- Passwordless — FIDO2/passkeys, certificate-based — strong and increasingly preferred.
Password security (still ubiquitous — know current guidance):
- Modern best practice (NIST SP 800-63B-influenced): favor length over complexity (long passphrases); check against breach/compromised-password lists and block common/breached passwords; don't force arbitrary periodic rotation (rotate on compromise instead — forced frequent rotation leads to weak, predictable passwords); allow/encourage password managers; support MFA.GOOD policy: min length ~12–14+, block breached/common passwords, no mandatory periodic rotation (unless compromise), allow long passphrases & password managers, enforce MFA. OUTDATED: force complex 90-day rotation with arbitrary complexity rules → users pick weak, predictable patterns. (Know the modern guidance differs from legacy.)
- Storage: passwords must be salted and hashed with a strong, slow algorithm (bcrypt, scrypt, Argon2, or PBKDF2) — never plaintext or fast/unsalted hashes.
- Account protections: lockout / throttling after failed attempts (defeats brute force), rate limiting, and monitoring for spray/brute-force (ties to detection).
Authentication protocols & mechanisms (enterprise context):
Kerberos — AD's authentication protocol (tickets; mutual auth; no password over the wire)
LDAP (bind) — directory authentication
RADIUS / TACACS+— network device & remote-access authentication (AAA for infrastructure)
SAML / OAuth / OIDC — federated authentication (§17)
Certificate-based (PKI) — mutual TLS, smartcards (§31)
EAP (802.1X) — network access authentication (NAC)
Common authentication attacks & defenses (defender's view):
ATTACK DEFENSE
brute force / spraying lockout/throttling, MFA, strong passwords, monitoring/alerting
credential stuffing MFA, breached-password checks, monitoring, rate limiting
phishing MFA (phishing-resistant FIDO2), awareness, email filtering
pass-the-hash / Kerberos abuses least privilege, credential hardening, Credential Guard, monitoring
MFA fatigue / SIM swap number-matching MFA, avoid SMS for high-value, limit prompts
The principle: make authentication strong and multi-factor, store credentials safely (salt+slow hash), follow modern password guidance (length, breach-checking, no forced rotation), protect against brute force (lockout/throttling), and enforce MFA everywhere that matters — remote access, privileged accounts, email, VPN. MFA is the single highest-leverage authentication control. For the exam, know the factors, MFA (and method strength), modern password policy, secure storage, and the attack/defense pairs.
15. Authorization & Access Control Models (RBAC/ABAC/MAC/DAC)
Authorization determines what an authenticated identity may do — the "what can you access?" of AAA — and access control enforces it. Choosing and implementing the right model (especially RBAC) is a core IAM skill, built on least privilege.
The access control models (know all four — eEDA tests them):
- DAC (Discretionary Access Control) — the resource owner decides who gets access and grants permissions at their discretion (e.g., file owners setting permissions, Windows/Linux file ACLs). Flexible but inconsistent and hard to govern at scale; prone to over-sharing. "The owner decides."
- MAC (Mandatory Access Control) — access is governed by system-enforced security labels/clearances, not user discretion; the system (policy) decides based on classification (e.g., Secret/Top-Secret clearances; SELinux/AppArmor enforce MAC on Linux). Rigid, high-security (military/government). "The system enforces labels; users can't override."
- RBAC (Role-Based Access Control) — access is assigned by role (job function), and users get permissions by being assigned to roles. The enterprise standard — scalable, consistent, auditable, and the natural fit for least privilege. "Permissions by role, users by assignment."
- ABAC (Attribute-Based Access Control) — access decisions are made dynamically from attributes (of the user, resource, action, and environment/context) evaluated against policies (e.g., "allow if dept=Finance AND device=managed AND time=business-hours AND resource.classification≤Confidential"). The most flexible/granular; underpins zero-trust policy engines; more complex to manage.
- (Also: Rule-Based access control — access per explicit rules, e.g., firewall ACLs, time-of-day rules; and PBAC policy-based, closely related to ABAC.)
RBAC in depth (the one you'll implement):
- Define ROLES by job function (e.g., HR-Clerk, Finance-Manager, Helpdesk, DB-Admin).
- Assign PERMISSIONS to roles (least privilege: each role gets only what that job needs).
- Assign USERS to roles (users inherit the role's permissions; a user may hold multiple roles).
- Use ROLE HIERARCHIES where sensible (senior roles inherit junior permissions).
- Enforce SEPARATION OF DUTIES (some roles are mutually exclusive, e.g., can't both request AND
approve payments).
BENEFITS: scalable (change the role, not every user), consistent, auditable, least-privilege-friendly,
simplifies onboarding/offboarding (assign/remove roles) and access reviews.
Designing RBAC (a hands-on exam task): (1) inventory job functions and the access each needs; (2) define roles accordingly with least privilege; (3) map permissions to roles; (4) assign users to roles; (5) enforce separation of duties and avoid "role explosion"/over-broad roles; (6) review regularly (recertification) to prevent privilege creep. Document the role model.
Core authorization principles:
- Least privilege — grant the minimum access needed (the governing principle; default to less).
- Need to know — access only to the information required for the role.
- Default-deny — no access unless explicitly granted (the authorization default).
- Separation of duties — split sensitive capabilities across roles/people.
- Complete mediation — check authorization on every access, not just the first.
- Privilege creep — the tendency for users to accumulate access over time (via role changes without removal); countered by access reviews and clean de-provisioning (§19).
Enforcement mechanisms (where authorization lives): file/folder ACLs (NTFS, POSIX), AD group membership (the practical RBAC vehicle in Windows enterprises — groups = roles), application-level roles/permissions, database GRANTs, network ACLs/firewall rules, and policy engines (ABAC/zero-trust).
The principle: enforce least privilege through a well-designed RBAC model (the enterprise default), understand when MAC (high-security labels), DAC (owner-discretion), and ABAC (dynamic/context-based, zero-trust) apply, default to deny, enforce separation of duties, and review access regularly to fight privilege creep. For the exam, know the four models cold, design and implement RBAC, and always default to granting less.
16. Directory Services — Active Directory & LDAP Hardening
The directory is the central store of identities and the heart of enterprise IAM — most enterprises run Active Directory (AD). Standing up and hardening a directory is a core hands-on eEDA skill (the study plan has you "stand up a directory and administer identity securely").
What a directory service is: a centralized database of identities (users, groups, computers) and their attributes, providing authentication and authorization services across the enterprise. LDAP is the protocol for querying/modifying directories; Active Directory is Microsoft's directory service (LDAP-based, with Kerberos authentication, DNS integration, and Group Policy).
Active Directory core concepts (know the structure):
FOREST the top-level security/administrative boundary (one or more domains)
DOMAIN an administrative/identity boundary (users, computers, policies)
TREE domains sharing a contiguous namespace
OU (Organizational Unit) containers for organizing objects & applying Group Policy
OBJECTS users, groups, computers, service accounts
GROUPS security groups (for permissions — the RBAC vehicle) & distribution groups
DOMAIN CONTROLLER (DC) servers running AD; authenticate users; hold the directory (NTDS.dit)
GPO (Group Policy Object) centrally enforce configuration/security settings across OUs
GLOBAL CATALOG forest-wide search/index
KERBEROS AD's authentication protocol (tickets)
Privileged AD groups to know & protect (Tier 0 — crown jewels):
Domain Admins full control of the domain
Enterprise Admins full control of the forest
Schema Admins can modify the AD schema
Administrators local/DC admin
# Minimize membership of these; they are the highest-value targets. Use tiering (below).
AD / directory hardening (the defensive engineering — know these):
- LEAST PRIVILEGE: minimize Domain/Enterprise Admin membership; use delegated, scoped admin roles;
separate admin accounts from daily-use accounts (no email/web on admin accounts).
- ADMIN TIERING (Tier 0/1/2): isolate DC/identity admin (Tier 0) from server (Tier 1) and
workstation (Tier 2) admin; never use Tier-0 creds on lower-tier machines (stops credential theft
from cascading). Use Privileged Access Workstations (PAWs) for admin.
- STRONG AUTHENTICATION: MFA for admins; smartcards/FIDO2 where possible; disable legacy/weak protocols.
- PROTECT CREDENTIALS: enable Credential Guard; disable NTLM where feasible (prefer Kerberos); protect
LSASS; use the Protected Users group & "sensitive, cannot be delegated" for privileged accounts;
manage service-account passwords with gMSA (group Managed Service Accounts).
- SECURE DOMAIN CONTROLLERS: treat DCs as the most sensitive assets — minimal software, no browsing,
restricted logon, physical/VM security, dedicated management, patched promptly.
- GROUP POLICY FOR SECURITY BASELINES: push hardening via GPO (password/lockout policy, audit policy,
disable legacy protocols, restrict RDP, etc.) — centralized, consistent enforcement.
- PASSWORD & LOCKOUT POLICY: strong per modern guidance (§14); fine-grained password policies for
privileged accounts; account lockout to slow brute force.
- LDAP SECURITY: use LDAPS (LDAP over TLS); require LDAP signing & channel binding; disable anonymous
binds; restrict who can query sensitive attributes.
- DISABLE LEGACY: disable SMBv1, LLMNR/NBT-NS (poisoning risk), unconstrained delegation; review
Kerberos delegation; remove stale accounts/computers.
- MONITORING & AUDITING: enable AD audit logging (logon events, group changes, privilege use,
replication); monitor for suspicious activity (e.g., mass changes, new admins, DCSync-like
replication from non-DCs, Kerberoasting patterns) — feed the SIEM (§28). Deploy honeytoken accounts.
- CLEAN LIFECYCLE: promptly disable/remove departed users & stale objects (§19); regular access reviews.
- BACKUP & RECOVERY: back up AD (system state); have a tested DC recovery / forest-recovery plan.
LDAP hardening (non-AD directories): use LDAPS/StartTLS (encrypt), require authenticated binds (no anonymous), enforce strong authentication, apply least-privilege ACLs on directory entries/attributes, restrict/monitor queries, and keep the directory server patched and segmented.
Why the directory matters so much: compromise of the directory (especially AD Domain Admin / a Domain Controller) = compromise of the entire enterprise — it controls authentication and authorization for everything. That's why directory hardening (least privilege, tiering, credential protection, DC security, monitoring) is among the highest-value defensive work and a major IAM exam focus.
The principle: the directory is the keys to the kingdom — secure it accordingly: minimize and tier privileged access, protect credentials and Domain Controllers, enforce hardening via Group Policy, use strong authentication (MFA) for admins, secure LDAP (LDAPS), disable legacy protocols, monitor for attacks, and maintain a clean lifecycle and tested recovery. For the exam, know AD structure, the privileged groups, and how to harden the directory hands-on.
17. Single Sign-On & Federation (SAML, OAuth, OIDC)
SSO lets users authenticate once and access many systems; federation extends identity across organizational boundaries. Both improve security (fewer passwords, centralized control, easier MFA) and usability — an IAM objective ("understand SSO, federation").
Single Sign-On (SSO): one authentication grants access to multiple applications/services within a domain of trust. Security benefits: fewer passwords for users to manage (less reuse/weak passwords), centralized authentication (enforce MFA and policy in one place), centralized logging/visibility, and faster de-provisioning (disable one identity → access to all SSO apps is cut). Trade-off: the SSO identity becomes a high-value single point — so protect it strongly (MFA, monitoring).
Federation: establishing trust between separate identity domains/organizations so users authenticated in one (the Identity Provider / IdP) can access resources in another (the Service Provider / SP / Relying Party) without a separate account. Enables cross-org SSO (e.g., logging into a SaaS app with your corporate identity, or "Sign in with..." ).
- IdP (Identity Provider): authenticates the user & asserts their identity (e.g., your AD/Entra/Okta)
- SP / RP (Service Provider / Relying Party): trusts the IdP's assertion & grants access (the app)
- TRUST + an ASSERTION/TOKEN: the IdP issues a signed token the SP validates.
The key protocols (know what each is for):
- SAML 2.0 — XML-based; the enterprise federation/SSO standard for web apps. The IdP issues a signed SAML assertion the SP validates. Common for corporate SaaS SSO. (Security: validate signatures, prevent assertion tampering/replay — ties to the eWPTX SAML attacks on the defensive side.)
- OAuth 2.0 — an authorization framework (delegated access): lets an app access resources on a user's behalf via access tokens and scopes, without sharing the password. OAuth is about authorization/delegation, not authentication per se. (e.g., "allow this app to read your calendar.")
- OpenID Connect (OIDC) — an authentication layer built on top of OAuth 2.0; adds an ID token (JWT) proving who the user is. The modern standard for web/mobile/API SSO and "Sign in with..." OIDC = authentication; OAuth = authorization; they're used together.
- WS-Federation — older Microsoft federation protocol (legacy).
Security considerations for SSO/federation:
- Protect the IdP — it's the crown jewel; compromise = access to all federated apps. MFA, hardening, monitoring, and tight admin control on the IdP.
- Validate tokens/assertions properly — verify signatures, issuer, audience, and expiration; prevent replay and tampering (defensive counterpart to token attacks).
- Enforce MFA and conditional/contextual access at the IdP — one place to enforce strong auth and policy (device posture, location, risk) for all federated apps (zero-trust).
- Scope & least privilege — OAuth scopes should be minimal; review app consents/permissions (over-broad OAuth grants are a risk).
- Secure token transport & storage — TLS everywhere; protect tokens on the client; short token lifetimes + refresh.
- De-provisioning — ensure removing the central identity promptly cuts federated access (the SSO benefit — but verify it works end to end).
- Logging — centralize authentication logs from the IdP for monitoring.
The principle: SSO/federation centralizes identity — which is a security win (one place for strong auth, MFA, policy, logging, and fast de-provisioning) if you protect the central IdP heavily and validate tokens correctly, and a concentrated risk if you don't. Use SAML/OIDC for SSO, OAuth for delegated authorization, enforce MFA/conditional access at the IdP, apply least-privilege scopes, and secure the whole token flow. For the exam, know SSO vs federation, IdP/SP, and SAML vs OAuth vs OIDC (authN vs authZ).
18. Privileged Access Management (PAM)
Privileged accounts (admins, root, service accounts) are the highest-value targets — their compromise means widespread control. PAM is the discipline of securing, controlling, and monitoring privileged access — a critical IAM control ("understand privileged access management").
What counts as privileged: domain/enterprise admins, local admins/root, database admins, network-device admins, cloud admins, application admins, service accounts, API keys/machine identities, and emergency "break-glass" accounts. These hold the keys — attackers specifically target them for escalation and lateral movement.
Core PAM controls (know these):
- VAULT CREDENTIALS: store privileged credentials in a secure, encrypted vault; no shared/embedded
passwords; check-out/check-in workflow; automatic password rotation after use.
- LEAST PRIVILEGE & JUST-ENOUGH-ADMIN: grant the minimum privilege for the task; scoped admin roles,
not blanket Domain Admin.
- JUST-IN-TIME (JIT) ACCESS: grant privilege only WHEN needed, for a LIMITED time, then revoke
(eliminates standing privilege — a major attack-surface reduction).
- SEPARATE PRIVILEGED ACCOUNTS: admins use dedicated admin accounts (distinct from daily-use accounts);
no email/web browsing on privileged accounts.
- MFA FOR ALL PRIVILEGED ACCESS: always.
- SESSION MANAGEMENT & RECORDING: broker privileged sessions through a controlled gateway; record/monitor
them (accountability + forensics).
- PRIVILEGED ACCESS WORKSTATIONS (PAWs): dedicated hardened, isolated machines for admin tasks (no
internet/email) — prevents credential theft from a compromised daily workstation.
- APPROVAL WORKFLOWS: require request/approval for elevated access (separation of duties).
- SERVICE-ACCOUNT MANAGEMENT: inventory, least-privilege, rotate; prefer managed identities / gMSA;
no interactive logon; no human-shared passwords.
- MONITORING & ALERTING: log and alert on all privileged activity — unusual admin actions, new admin
accounts, privilege escalation, after-hours admin use (feed the SIEM, §28).
- BREAK-GLASS ACCOUNTS: a tightly-controlled emergency account (highly monitored, strong credential,
used only in emergencies, alerts on any use).
PAM + admin tiering (ties to §16): combine PAM with the tier model — Tier 0 (identity/DC admin) credentials never touch Tier 1/2 systems, so a compromised workstation can't yield domain admin. JIT + tiering + PAWs together dismantle the attacker's escalation/lateral-movement playbook (pass-the-hash, credential theft).
Why PAM matters: most serious breaches involve privilege escalation and the abuse of privileged credentials to move laterally and reach crown jewels. PAM directly counters this by eliminating standing privilege (JIT), vaulting and rotating credentials, isolating admin (PAWs/tiering), requiring MFA, and monitoring every privileged action — turning the attacker's favorite path into a controlled, logged, time-limited, and alerting one.
The principle: treat privileged access as the highest-risk access and control it accordingly — vault and rotate credentials, grant just-in-time and just-enough privilege, use separate admin accounts and PAWs, require MFA, record and monitor privileged sessions, and manage service accounts with the same rigor. For the exam, know what's privileged, the PAM controls (especially JIT, vaulting, separate admin accounts, MFA, session monitoring), and how PAM + tiering stops escalation and lateral movement.
19. The Identity Lifecycle — Provisioning to De-provisioning
Managing identity across its full lifecycle — joiner, mover, leaver — is an explicit eEDA objective ("run the full identity lifecycle including clean de-provisioning"). Gaps here (especially failed de-provisioning) are a top cause of unauthorized access.
The identity lifecycle (JML — Joiner/Mover/Leaver):
JOINER (Provisioning) — create the identity & grant appropriate access when someone joins/changes in.
- create account; assign ROLES (RBAC) per job function (least privilege); provision to needed
systems; issue credentials & MFA; document. Ideally AUTOMATED from an HR system (authoritative source).
MOVER (Re-provisioning) — adjust access when role/department changes.
- CRITICAL: REMOVE old access when granting new (don't just add) — else PRIVILEGE CREEP accumulates.
- re-evaluate roles; apply the new role's least-privilege access; revoke what's no longer needed.
LEAVER (De-provisioning) — remove ALL access promptly when someone leaves.
- DISABLE the account immediately (often before/at termination); revoke all access, sessions, tokens,
and privileged access; reclaim devices/credentials; transfer/handle data & mailbox; remove from
groups/apps; then delete per retention policy. Don't forget SSO/federated apps, VPN, remote access,
service accounts the person held, and physical access.
Why de-provisioning is the critical control. Orphaned/active accounts of departed employees (or stale access after role changes) are a prime vector for unauthorized access and insider threat — and a frequent audit finding. Prompt, complete de-provisioning (especially for privileged accounts and at involuntary terminations) is one of the highest-value IAM controls. Automate it from the HR/authoritative source so leaving triggers immediate disablement across all systems.
Supporting lifecycle controls & concepts:
- Authoritative source / HR integration — drive provisioning/de-provisioning automatically from HR (the source of truth for who works here and in what role) → less manual error, faster, consistent.
- Automated provisioning (IGA / SCIM) — identity-governance tools and the SCIM protocol automate account creation/updates/removal across apps.
- Access reviews / recertification — periodic reviews where managers/owners re-confirm each person's access is still appropriate; revoke what isn't. Catches privilege creep, orphaned access, and SoD violations. A key Identity Governance activity and audit requirement.
- Least privilege at every stage — grant only what the role needs, and remove it when the need ends.
- Separation of duties — enforce across role assignments (and in the lifecycle process itself: the requester ≠ approver ≠ implementer).
- Account types to manage distinctly: regular users, privileged/admin accounts (§18), service/non-human accounts (inventory, least-privilege, rotate, and decommission when the app retires), contractor/temporary accounts (with expiration dates), and emergency accounts.
- Dormant/stale account cleanup — regularly find and disable/remove inactive accounts.
- Credential lifecycle — issue, rotate, and revoke credentials/keys/certs through their lifecycle.
The lifecycle & the exam. Expect to implement this: create accounts with role-based least-privilege access, handle a role change by removing old access, and — a very common task — cleanly de-provision a departed user (disable, revoke everywhere, including the easily-forgotten SSO/VPN/privileged/service access). Verify the removal is complete.
The principle: manage every identity through its whole lifecycle — provision with least-privilege roles, re-provision on changes by removing old access, and de-provision promptly and completely when people leave — ideally automated from HR, with periodic access reviews to catch drift. Clean de-provisioning and regular recertification are the controls that prevent the accumulated, orphaned, and excessive access attackers and insiders exploit. For the exam: joiner/mover/leaver, the primacy of complete de-provisioning, and access reviews against privilege creep.
20. Security Administration — Overview & Secure Admin Practices
Security Administration is the largest domain (36%) and the most hands-on — the day-to-day work of configuring, hardening, maintaining, and verifying defensive controls. This section frames it and covers secure-admin habits; §21–30 drill each capability.
What security administration covers (the eEDA objectives):
- Analyze IT systems and ensure they're properly secured (hardening — §21, §25)
- Design & build a secure IT environment per business requirements (architecture — §3, §5, §36)
- Identify, analyze, and mitigate vulnerabilities (vulnerability management — §26)
- Understand logging types, log aggregation, and alerts (logging/SIEM/detection — §27-29)
# plus firewalls (§22), IDS/IPS (§23), endpoint security (§24), and incident response (§30).
Secure administration practices (how to administer securely — a tested habit set):
- Least privilege & separate admin accounts — admins use dedicated, scoped admin accounts (not their daily user accounts); no email/web browsing while using admin credentials (§18).
- Secure the management plane — administer via isolated management networks, hardened jump hosts/bastions, and PAWs; never expose management interfaces (RDP/SSH/web consoles) to the general network or internet; MFA on all admin access.
- Encrypted, authenticated admin access — SSH (keys, not passwords), RDP over secured channels, HTTPS consoles; disable insecure protocols (Telnet, HTTP management, SNMPv1/2, FTP).
- Change control — make changes through the change-management process (§11), with testing and rollback; avoid ad-hoc production changes.
- Document everything — configurations, baselines, changes, and rationale (§34); maintain accurate inventories/CMDB.
- Monitor admin activity — log and alert on privileged actions (§28); admins are accountable and auditable.
- Maintain baselines & patch — keep systems at the secure baseline (§25) and patched (§26); detect and remediate drift.
- Least functionality — disable/remove unneeded services, ports, software, and accounts (reduce attack surface — a hardening theme throughout).
- Verify your work — after any change/config, confirm the control actually does what's intended and that you didn't break another control (the exam-critical habit).
The administrator's recurring toolkit (across the domain):
Hardening: CIS Benchmarks, GPO (Windows), Ansible/scripts, STIG/SCAP, security baselines
Firewall: pfSense/OPNsense, iptables/nftables, Windows Firewall, cloud security groups
IDS/IPS: Snort, Suricata, Zeek
Endpoint: EDR/AV, host firewall, application allow-listing
Vuln scanning: OpenVAS/Greenbone, Nessus
Logging/SIEM: Wazuh, Elastic Stack (ELK), Security Onion, syslog, Windows Event Forwarding
Config mgmt: Ansible/Puppet/Chef, GPO, CMDB
The mindset for the Security Administration domain: every system is configured to a secure baseline, runs with least functionality (only what's needed) and least privilege, is patched and free of known vulnerabilities, sits behind default-deny network controls, is monitored (logs → SIEM → alerts), and is administered securely (isolated management, separate admin accounts, MFA, change control, documentation). You build that and verify it. The next sections are the how-to for each piece.
21. System Hardening — Windows & Linux (CIS Benchmarks)
Hardening = reducing a system's attack surface and strengthening its configuration to a secure baseline. It's a core, repeated hands-on task ("harden a server against CIS Benchmarks; measure before/after attack surface"). The method is the same for any system; the specifics come from CIS Benchmarks.
The universal hardening methodology (applies to any OS/device/app):
1. START FROM A BASELINE — use the relevant CIS Benchmark (or STIG) for the exact system/version.
2. MINIMIZE ATTACK SURFACE (least functionality):
- remove/disable unneeded SERVICES, FEATURES, SOFTWARE, and ROLES
- close/disable unneeded PORTS (verify with a port scan before/after)
- remove/disable unnecessary ACCOUNTS (default, guest, unused); rename/secure built-in admin
3. SECURE ACCESS & AUTHENTICATION:
- strong auth; MFA where possible; least-privilege accounts; strong password/lockout policy
- restrict remote admin (SSH keys, RDP restrictions); disable insecure protocols
4. APPLY SECURITY SETTINGS:
- OS security options, audit/logging policy, firewall, access controls per the benchmark
5. PATCH — bring to current patch level; enable/verify update mechanisms (§26)
6. ENABLE LOGGING & MONITORING — audit policy on; forward logs to the SIEM (§27)
7. ENCRYPT — disk encryption, encrypted protocols, secure key storage where applicable
8. DOCUMENT & VERIFY — record the config as the baseline; VERIFY with a scan/audit (SCAP, CIS-CAT,
or a vuln scan) and compare attack surface before/after.
Windows Server hardening (key areas — enforced largely via Group Policy / Local Security Policy):
- Accounts: rename/disable default admin, remove guest, strong password & lockout policy, least privilege,
separate admin accounts, restrict "log on locally"/"log on through RDP" rights.
- Services & features: remove unneeded roles/features; disable unnecessary services; least functionality.
- Network: Windows Firewall (default-deny inbound), disable SMBv1, disable LLMNR/NBT-NS, restrict RDP
(NLA, limited users, not internet-exposed), disable legacy TLS/ciphers.
- Audit policy: enable advanced audit logging (logon, account mgmt, privilege use, process creation with
command line, object access as needed) → forward to SIEM.
- Security options: UAC on, disable anonymous SMB/LSA enumeration, LAPS for local-admin passwords,
Credential Guard, Attack Surface Reduction rules, Defender/EDR enabled.
- Patching: WSUS/update management; prompt patching.
- Apply via GPO for consistency across the fleet; verify with a CIS/SCAP scan.
Linux hardening (key areas):
- Accounts: no unnecessary accounts; strong auth; sudo for least-privilege admin (no routine root login);
disable root SSH login; SSH key auth (disable password auth where possible); lock unused accounts.
- Services: disable/remove unneeded services & packages (systemctl disable); least functionality.
- Network: host firewall (iptables/nftables/ufw/firewalld) default-deny; disable unused network services;
secure/disable insecure daemons.
- SSH hardening: key-based auth, no root login, strong ciphers/MACs, limit users/groups, change defaults,
idle timeout, fail2ban for brute-force protection.
- Filesystem: proper permissions, separate partitions (/tmp, /var) with noexec/nosuid/nodev where apt,
remove SUID/SGID from unneeded binaries, secure /etc/passwd & /etc/shadow (perms).
- Kernel/OS: sysctl hardening (ASLR, disable unneeded protocols, network params), SELinux/AppArmor
(mandatory access control — enforce).
- Auditing: enable auditd & syslog; forward logs to SIEM; file-integrity monitoring (AIDE).
- Patching: package manager updates; unattended-upgrades for security patches.
- Verify with Lynis / OpenSCAP / CIS-CAT.
CIS Benchmarks (your baseline source): consensus, system-specific hardening checklists, each setting with rationale, impact, and audit/remediation steps. Levels: Level 1 (practical, broadly applicable, minimal functionality impact) and Level 2 (stricter, higher security, may impact functionality — for high-security environments). Pick the level per the system's role/risk. CIS-CAT (the assessment tool) and OpenSCAP/SCAP automate checking a system against the benchmark — use them to measure and verify hardening.
Measuring before/after (the exam's "measure attack surface" point): before hardening, inventory open ports (port scan), running services, accounts, and a vulnerability-scan result; after hardening, repeat and compare — fewer open ports, fewer services/accounts, fewer vulnerabilities, and a passing CIS/SCAP score demonstrate the reduced attack surface. This evidence is part of the deliverable.
The principle: harden every system to a secure baseline by removing what isn't needed (least functionality), securing what is (access, settings, encryption), patching, enabling logging, and verifying — using CIS Benchmarks as the authoritative configuration standard and automated tools (GPO, Ansible, SCAP/CIS-CAT) to apply and check at scale. Measure the before/after attack surface to prove it. For the exam, know the methodology and be ready to harden Windows/Linux against CIS hands-on.
22. Firewall Architecture & Default-Deny Rulesets
Firewalls enforce the network segmentation (§5) and the organization's traffic policy. Designing and documenting default-deny firewall rulesets across zones is a core, explicitly-tested hands-on skill.
Firewall types & placement:
- Network firewalls — between zones and at the perimeter (pfSense/OPNsense, commercial NGFWs). Enforce inter-zone and internet policy.
- Next-Generation Firewalls (NGFW) — add application awareness, IPS, identity integration, TLS inspection.
- Host-based firewalls — on each endpoint/server (Windows Firewall, iptables/nftables) — defense in depth, micro-segmentation.
- Cloud security groups / NACLs — firewall equivalents in cloud (stateful SGs, stateless NACLs).
- Stateful vs stateless — stateful tracks connections (allows return traffic automatically — the norm); stateless evaluates each packet independently (ACLs).
- WAF — application-layer firewall for web apps (filters HTTP attacks — complements, doesn't replace, network firewalls).
Default-deny — the governing principle. The ruleset denies all traffic by default and explicitly allows only what's required (least privilege for networks). This means the final (implicit or explicit) rule is deny-all, and every allowed flow is a deliberate, documented exception based on business need. Start closed, open deliberately, document why — the exam's stated approach.
Rule design & structure:
- EXPLICIT ALLOW rules for required flows (specific source, destination, port/protocol, direction)
- EXPLICIT DENY + LOG for traffic you want to notice being blocked (e.g., deny & log internal→restricted)
- DEFAULT DENY ALL at the end (the catch-all)
- ORDER MATTERS: rules are evaluated top-down, first match wins — put specific rules before general ones
- LEAST PRIVILEGE per flow: narrowest source/destination/port (not "any any")
- BOTH DIRECTIONS: control INBOUND and especially EGRESS (outbound) — egress filtering disrupts C2/exfil
- DOCUMENT each rule: purpose, owner, business justification, review date
Example zoned ruleset (conceptual — a DMZ web app):
# Internet → DMZ
ALLOW internet → dmz_web tcp/443 (public web access) [log]
DENY internet → internal any (no direct internet→internal) [log]
# DMZ → Internal (minimal, specific)
ALLOW dmz_web → app_server tcp/8080 (web→app tier only)
DENY dmz_web → any_internal any (DMZ can't roam internal) [log]
# Internal tiers
ALLOW app_server → db_server tcp/5432 (app→DB on DB port only)
DENY user_zone → restricted any (users can't reach crown jewels) [log]
# Management
ALLOW mgmt_jumphost → servers tcp/22,3389 (admin only from jump host)
DENY any → mgmt_zone any (management isolated) [log]
# Egress (outbound control)
ALLOW internal → internet tcp/443,80 (via proxy) (controlled web egress)
DENY internal → internet any (default-deny egress) [log]
# Catch-all
DENY any → any any (DEFAULT DENY) [log]
Key firewall practices:
- Default-deny inbound AND egress — egress filtering is often neglected but is powerful against C2/exfiltration.
- Least-privilege flows — never "any any"; narrow source/dest/port.
- Log denies (and key allows) — feed the SIEM; blocked traffic is a detection signal (§28).
- Rule hygiene — periodically review and remove stale/overly-broad rules; document every rule's justification; avoid rule sprawl.
- Change control — firewall changes go through change management (§11).
- Segment the management interface — administer the firewall from the management zone only; MFA.
- Secure the firewall itself — harden it, patch it, back up its config, restrict admin access.
- Verify — test that allowed flows work and (critically) that denied flows are actually blocked (the exam-critical verification).
The principle: firewalls enforce segmentation and traffic policy through default-deny rulesets that explicitly allow only required, least-privilege flows — inbound and egress — with every rule documented and justified, denies logged to the SIEM, rules kept clean, and the configuration verified (allowed flows work, denied flows are blocked). For the exam, design and document default-deny rulesets across zones, control egress, and verify isolation.
23. IDS/IPS — Intrusion Detection & Prevention
IDS/IPS inspect network (or host) traffic for malicious activity — a key detective (IDS) / preventive (IPS) control and an explicit eEDA task ("configure IDS/IPS"). They're how you see and optionally block attacks traversing the network.
IDS vs IPS:
- IDS (Intrusion Detection System) — detects and alerts on malicious/suspicious traffic; passive (monitors a copy of traffic via a SPAN/TAP); doesn't block. Detective control.
- IPS (Intrusion Prevention System) — detects and blocks malicious traffic inline (sits in the traffic path); can drop/reset connections. Preventive control. (An IPS is an inline IDS with blocking.)
- NIDS/NIPS = network-based (monitor network traffic); HIDS/HIPS = host-based (monitor a single host's activity — e.g., Wazuh/OSSEC agents, §29).
Detection methods (know these):
- Signature-based — matches known-attack patterns/signatures (like antivirus). Accurate for known threats, low false positives, but misses novel/zero-day attacks and needs constant signature updates. (Snort/Suricata rules.)
- Anomaly-based — baselines "normal" and flags deviations. Can catch unknown/novel attacks, but higher false positives and requires tuning/baselining.
- Behavioral / heuristic — detects attack-like behaviors.
- Mature deployments combine them.
The common tools (eEDA-relevant):
- Snort — the classic open-source signature-based IDS/IPS; rule-based.
- Suricata — modern, multi-threaded IDS/IPS; Snort-rule-compatible, plus protocol analysis, file extraction, and EVE JSON logging (easy SIEM integration). Often preferred now.
- Zeek (Bro) — network analysis/monitoring (rich connection/protocol logs) rather than pure signature IDS — excellent telemetry source (pairs with IDS; part of Security Onion).
- Security Onion — a distro bundling Suricata/Zeek + the analysis stack (§29).
Deploying IDS/IPS (the hands-on):
- PLACEMENT: at network choke points — the perimeter, between zones, and monitoring sensitive segments.
IDS taps a copy of traffic (SPAN/mirror port or TAP); IPS sits inline.
- RULES/SIGNATURES: load and UPDATE rule sets (e.g., Emerging Threats, Snort community/registered rules);
enable rules relevant to your environment; write custom rules for your specifics.
- TUNE to reduce false positives: disable irrelevant rules, set thresholds, suppress known-benign;
tuning is essential or analysts drown in noise (and real alerts get missed).
- MODE: start IDS (alert-only) to observe & tune, then move critical rules to IPS (block) once confident
(blocking legitimate traffic is a risk — tune first).
- INTEGRATE with the SIEM: send IDS/IPS alerts (Suricata EVE JSON / Snort logs) to the SIEM for
correlation, alerting, and investigation (§28).
- MONITOR & RESPOND: alerts feed detection/IR; validate and act on them.
Example Snort/Suricata rule anatomy (illustrative):
alert tcp any any -> $HOME_NET 445 (msg:"Possible SMB exploit attempt"; flow:to_server; \
content:"|..|"; sid:1000001; rev:1;)
# action proto src → dest port (metadata: message, flow, content match, rule id)
Strengths & limits (for the report/exam): IDS/IPS give crucial network visibility and blocking of known threats at choke points, but signature IDS misses novel attacks, encrypted traffic limits inspection (TLS inspection or endpoint visibility needed), and untuned deployments generate noise. They're one layer — combine with endpoint detection (EDR), logging/SIEM, and segmentation.
The principle: deploy IDS/IPS at network choke points to detect (IDS) and block (IPS) malicious traffic, using updated, tuned rule sets (signature + anomaly), start in alert-mode to tune then enable blocking for high-confidence rules, and integrate alerts into the SIEM for correlation and response. It's a key network-layer detective/preventive control — one layer of defense in depth, best paired with endpoint and log-based detection. For the exam, know IDS vs IPS, detection methods, Snort/Suricata, placement, tuning, and SIEM integration.
24. Endpoint Security & EDR
Endpoints (workstations, servers) are where attackers land (via phishing/exploits) and operate, so endpoint security is a critical defensive layer. Modern endpoint defense centers on EDR plus hardening, host firewall, and application control.
The endpoint security stack (layers on the host):
- Antivirus / Anti-malware (EPP — Endpoint Protection Platform) — signature + heuristic + behavioral malware detection/blocking. The baseline (e.g., Microsoft Defender).
- EDR (Endpoint Detection and Response) — rich endpoint telemetry (process, file, registry, network activity), behavioral detection of attack techniques, investigation (process trees/timelines), and response (isolate host, kill process, quarantine). The modern core of endpoint defense. XDR extends correlation across endpoint + network + email + cloud.
- Host-based firewall — default-deny inbound at the host (defense in depth, micro-segmentation).
- HIDS/FIM — host intrusion detection & file-integrity monitoring (detect unauthorized changes to critical files — e.g., Wazuh agent, AIDE, OSSEC).
- Application allow-listing (allowlisting) — only approved applications may run (e.g., AppLocker/WDAC) — extremely effective against malware/unknown executables (default-deny for software).
- Disk encryption — BitLocker/LUKS (protects data at rest / stolen devices).
- Patch & configuration management — keep endpoints hardened (§21) and patched (§26).
- Device control — restrict USB/removable media (exfiltration/malware vector).
- Browser & email protections — the main delivery vectors (§33).
EDR in defensive operations (ties to monitoring/IR):
- Detection — EDR flags attack behaviors (process injection, credential dumping, suspicious PowerShell, ransomware behavior) mapped to ATT&CK.
- Investigation — the process tree/timeline shows exactly what happened on a host (what spawned what, network connections, file changes) — core to triage/IR (§30).
- Response — one-click host isolation (network-quarantine while preserving for investigation), process termination, and file quarantine — critical containment actions.
- Telemetry → SIEM — EDR events feed the SIEM for correlation across the environment (§28).
- Threat hunting — EDR data enables proactive hunting for undetected threats.
Endpoint hardening priorities (reduce what attackers can do):
- Application allow-listing (block unauthorized executables) — one of the most effective controls
- Remove local admin from users (least privilege) — stops much malware & lateral movement
- ASR rules / exploit protection (block common attack behaviors: Office→child-process, LSASS access)
- Disable unneeded features (macros from internet, scripting hosts where unused, legacy protocols)
- Patch promptly; keep EDR/AV enabled & updated; disk encryption; host firewall default-deny
- LAPS for unique local-admin passwords; Credential Guard (protect credentials in memory)
The principle: defend endpoints in layers — EDR as the detection/response core, plus hardening (least functionality, no local admin, application allow-listing, ASR), host firewall, FIM, encryption, patching, and device control — with endpoint telemetry feeding the SIEM and EDR enabling fast isolation and investigation during incidents. Endpoints are where attacks land and operate, so strong, monitored, hardened endpoints (with the ability to isolate fast) are essential. For the exam, know the stack (EPP/EDR/host-firewall/FIM/allow-listing/encryption), EDR's detect-investigate-respond role, and endpoint hardening priorities.
25. Secure Configuration & Baseline Management
Consistent, secure configuration across the environment — and keeping it that way — is foundational defensive engineering. It ties together hardening (§21), change management (§11), and baselines (§8/§10).
Secure baselines (the standard every system must meet). A baseline is the documented minimum-secure configuration for a system type (server OS, workstation, database, network device, cloud resource). Built from CIS Benchmarks (+ org-specific requirements), it defines exactly how each system type should be configured. Every new system is deployed to the baseline; every existing system is measured against it.
Configuration management (keeping systems at baseline — at scale):
- STANDARDIZE: golden images / hardened templates built to the baseline → consistent, secure deployment.
- AUTOMATE: config-management tools (Ansible, Puppet, Chef, SCCM) and GPO (Windows) apply and ENFORCE
the baseline across the fleet — consistent, repeatable, and self-correcting.
- INVENTORY (CMDB): maintain an accurate inventory of assets and their configurations (you can't secure
or detect drift on what you don't know exists). Asset inventory is CIS Control #1 for a reason.
- DETECT DRIFT: continuously compare running configs to the baseline (config management, SCAP/CIS-CAT
scans, FIM) and flag/auto-remediate deviations. Unmanaged drift reintroduces vulnerabilities.
- CHANGE CONTROL: all config changes go through change management (§11) → no ad-hoc drift.
- VERSION CONTROL: baselines and config-as-code are versioned (track what changed, roll back).
- MEASURE COMPLIANCE: regularly scan systems against the baseline (SCAP/CIS-CAT) and report compliance %.
Configuration drift — the core problem. Over time, manual changes, exceptions, and neglect cause systems to drift from the secure baseline — reopening ports, weakening settings, falling behind on patches. Drift silently erodes your security posture and reintroduces vulnerabilities. The defenses: automate baseline enforcement (config management continuously reasserts the desired state), detect drift (scanning/FIM/config-management reporting), and gate changes (change management). A system that was hardened once but drifts is not a hardened system.
Infrastructure/config as code (modern approach): define configuration in version-controlled code (Ansible playbooks, etc.) and deploy/enforce it automatically → consistency, repeatability, auditability, and fast recovery (rebuild to a known-good state). This makes baselines enforceable and self-healing rather than aspirational.
The lifecycle (tie it together):
DEFINE baseline (CIS + org reqs, §8/§10) → BUILD golden image/templates → DEPLOY via automation →
ENFORCE continuously (config mgmt) → DETECT drift (scan/FIM) → REMEDIATE (auto or via change control) →
MEASURE compliance → UPDATE baseline (as threats/requirements evolve, via change management) → repeat.
The principle: security isn't a one-time hardening — it's defining secure baselines, deploying consistently to them (golden images/automation), enforcing them continuously (config management/GPO), detecting and remediating drift, and measuring compliance — all within change control and asset inventory. Automation and inventory make this achievable at scale; drift detection keeps it honest. For the exam, know baselines, config management/automation, the CMDB/inventory, configuration drift and how to prevent/detect it, and compliance measurement (SCAP/CIS-CAT).
26. Vulnerability Management
Vulnerability management is the continuous process of identifying, assessing, prioritizing, remediating, and verifying weaknesses — an explicit eEDA objective ("identify, analyze, and mitigate vulnerabilities"). It's ongoing defensive work, not a one-time scan.
The vulnerability management lifecycle:
1. DISCOVER/INVENTORY — know your assets (can't scan/secure what you don't know exists — CIS #1).
2. SCAN/ASSESS — scan systems for known vulnerabilities (and misconfigurations).
3. PRIORITIZE — rank by risk (severity + exploitability + asset criticality + exposure).
4. REMEDIATE/MITIGATE — patch, reconfigure, or apply compensating controls.
5. VERIFY — re-scan to confirm the vulnerability is fixed.
6. REPORT & IMPROVE — track metrics & trends; feed risk management; repeat continuously.
Scanning — types & tools:
- Scanner tools: OpenVAS/Greenbone (open-source), Nessus (limited free tier), Qualys, Rapid7. These check systems against databases of known vulnerabilities (CVEs) and misconfigurations.
- Authenticated (credentialed) vs unauthenticated scans (know the difference — an eEDA point):UNAUTHENTICATED: scans from the outside with no credentials → sees what an external/unauth attacker sees (exposed services, some version-based findings). Less thorough; fewer false negatives from patch detection; more false positives. AUTHENTICATED: scans WITH credentials (logs in) → deep view of installed patches, configurations, local vulnerabilities, and misconfigurations. Far more thorough and ACCURATE → preferred for internal vulnerability management. (Use both: unauth shows external exposure; auth shows true state.)
- Scan scope/frequency: regular scheduled scans (e.g., weekly/monthly), plus after major changes; agent-based scanning for always-on coverage.
- Vulnerability scanning ≠ penetration testing: scanning identifies known vulnerabilities (automated, broad); pen testing exploits them to prove impact (manual, deep). Both have a place.
Prioritization (you can't fix everything at once):
- SEVERITY: CVSS score (0–10: Low/Medium/High/Critical) — base severity.
- EXPLOITABILITY: is there a public exploit? Is it being actively exploited in the wild (e.g., CISA KEV
catalog)? Actively-exploited vulns jump the queue regardless of CVSS.
- ASSET CRITICALITY & EXPOSURE: a critical vuln on an internet-facing crown-jewel system >> the same on
an isolated test box. Weight by business impact and exposure.
- RISK-BASED PRIORITIZATION: combine severity + exploitability + asset context → fix the real risk first,
not just the highest CVSS.
Remediation & patch management:
- Patch management (the primary remediation — a specialized change process): identify applicable patches → test (avoid breaking production) → approve → schedule → deploy → verify. Balance speed (close the vuln) vs stability. Automate where safe (WSUS/SCCM, Linux unattended-upgrades).
- Mitigate/compensating controls when you can't patch immediately: configuration changes, disabling the vulnerable feature, network isolation/segmentation, WAF/IPS virtual patching, or increased monitoring — reduce risk until a fix is possible.
- Accept (with documentation) only when justified and within risk appetite.
- SLAs by severity: define remediation timeframes (e.g., Critical within X days, High within Y) tied to risk.
Verification & metrics: re-scan to confirm remediation (close the loop — don't assume a patch applied cleanly). Track metrics: open vulnerabilities by severity, mean time to remediate (MTTR), patch compliance %, recurring vulnerabilities, and trend over time — these show program effectiveness and feed risk reporting.
The principle: vulnerability management is a continuous lifecycle — maintain asset inventory, scan regularly (prefer authenticated scans for accuracy, plus unauthenticated for external exposure), risk-prioritize (severity + active exploitation + asset criticality, not just CVSS), remediate (patch, or mitigate with compensating controls, or formally accept), verify by re-scanning, and track metrics. It's how you systematically reduce the exploitable attack surface over time. For the exam, know the lifecycle, authenticated vs unauthenticated scanning, OpenVAS/Nessus, risk-based prioritization, patch management, and verification.
27. Logging, Log Aggregation & Log Management
"Understand logging types, log aggregation methods, and alerts" is an explicit eEDA objective. Logs are the raw material of detection, investigation, accountability, and compliance — you can't detect or investigate what you don't log and centralize.
Why logging matters (the four purposes): detection (spot attacks via log analysis/alerts), investigation/forensics (reconstruct what happened), accountability/non-repudiation (trace actions to individuals — the "Accounting" in AAA), and compliance (many regulations mandate logging and retention). Logging underpins the entire Detect/Respond side of defense.
Log sources & types (know the landscape):
- OS/system logs: Windows Event Logs (Security/System/Application), Linux syslog/journald, auditd
- Authentication: logons/failures (Windows 4624/4625), sudo, VPN, directory (AD) auth
- Security events: account/group changes, privilege use, policy changes, object access
- Application logs: web servers, databases, business apps
- Network devices: firewall (allow/deny), router/switch, proxy, DNS, VPN, NAC
- Security tools: IDS/IPS alerts (Suricata/Snort), EDR/AV events, WAF, DLP
- Cloud logs: CloudTrail/Activity/Audit logs (control-plane & identity)
Key Windows Event IDs (high-value for security — know these):
4624 logon success (check Logon Type) 4625 logon failure (brute-force signal)
4672 special privileges assigned 4688 process creation (enable command-line auditing!)
4720 user created 4726 deleted 4728/4732/4756 added to group
4740 account lockout 4698 scheduled task created 7045 service installed
1102 SECURITY LOG CLEARED (!) 4104 PowerShell ScriptBlock logging
4768/4769 Kerberos TGT/TGS 4776 NTLM auth
# Enable the auditing that generates these (advanced audit policy, command-line process auditing,
# PowerShell logging) — default logging misses a lot.
Log aggregation & centralization (the method): forward logs from all sources to a central platform so they can be searched, correlated, retained, and protected together.
- Linux: syslog / rsyslog / syslog-ng forwarding to a central collector.
- Windows: Windows Event Forwarding (WEF) to a collector, or agents (Winlogbeat, Wazuh agent).
- Agents/shippers: Beats (Filebeat/Winlogbeat), Fluentd, Wazuh agents, NXLog → to the SIEM.
- Normalization: parse disparate formats into common fields so you can query across sources (CIM-style).
- Central platform: a SIEM / log-management system (Wazuh, Elastic Stack, Security Onion, Splunk — §29).
WHY CENTRALIZE: cross-source correlation, single search, tamper-resistance (attackers clear LOCAL logs),
retention/compliance, and alerting.
Log management essentials:
- Time synchronization (NTP) — all sources on synchronized, consistent time (UTC) — essential for correlating events across systems. (Misaligned clocks scramble timelines.)
- Retention — keep logs long enough for investigation and compliance (varies by regulation; balance cost); define a retention policy.
- Log integrity & protection — protect logs from tampering/deletion (attackers clear logs — Event ID 1102 — to hide tracks); centralize quickly, use write-once/immutable storage where possible, and restrict/monitor access to logs. Logs may contain sensitive data → access-control the logs themselves.
- Completeness / coverage — ensure the right events are actually being logged (enable the needed audit policies; a technique you don't log is invisible). Know your logging blind spots.
- Volume management — logging everything at full verbosity is costly/noisy; log what's security-relevant, tune, and manage volume.
The principle: log the security-relevant events from every source, centralize them (aggregation) with synchronized time, protect their integrity, retain them appropriately, and ensure coverage — because logs are the foundation of detection, investigation, accountability, and compliance. Centralization is critical (cross-source correlation + tamper-resistance). For the exam, know the log sources & types, key Windows Event IDs, aggregation methods (syslog/WEF/agents → central platform), time sync, retention, and log integrity/protection. (Detection/alerting on these logs is §28.)
28. SIEM, Detection Engineering & Alerting
A SIEM turns centralized logs (§27) into detection and alerts — the active defensive capability of noticing attacks. Detection engineering (writing and tuning the rules that fire alerts) is where logging becomes defense.
What a SIEM does (Security Information and Event Management):
COLLECT ingest logs/events from all sources (the aggregation of §27)
NORMALIZE parse into common fields so you can search/correlate across sources
CORRELATE combine multiple events into meaningful detections (rules/analytics)
ALERT generate alerts when detection logic matches → to analysts (or SOAR)
INVESTIGATE search, dashboards, and pivoting over all data (incident analysis)
REPORT dashboards, metrics, and compliance reporting; retention
Common platforms (eEDA-relevant): Wazuh (free, security-focused — SIEM + HIDS/FIM + vuln detection), Elastic Stack / ELK (Elasticsearch + Logstash/Beats + Kibana; Elastic Security adds SIEM), Security Onion (free NSM+SIEM distro bundling Suricata/Zeek/Elastic/Wazuh), Splunk, Microsoft Sentinel, QRadar. (§29 covers building with these.)
Detection engineering (writing detections — the core skill):
- DEFINE THE BEHAVIOR to detect (map to MITRE ATT&CK technique where possible).
- IDENTIFY THE TELEMETRY that reveals it (which log/event shows this behavior — §27).
- WRITE THE RULE: a query/condition over the telemetry that fires when the behavior occurs.
- TUNE: eliminate false positives (exclude known-good) and false negatives (ensure real cases match);
test the rule actually fires on the target behavior.
- MAP COVERAGE: track detections against ATT&CK to find gaps (coverage map).
- MAINTAIN: update as the environment and threats change.
Example detection logic (conceptual — adapt to your SIEM's query language):
# Brute force: many failed logons then a success for one account
EventID=4625 grouped by account/source → count > threshold in short window → then a 4624 → alert
# Suspicious execution: Office spawning a shell
ParentImage in (winword,excel,outlook) AND Image in (powershell,cmd,mshta) → alert
# Credential dumping tell: non-system process accessing LSASS (from EDR/Sysmon EID 10)
# Log cleared (anti-forensics): EventID=1102 → high-severity alert
# New admin account / privileged group change: 4720 / 4728/4732 to a privileged group → alert
# Lateral movement: 4624 Logon Type 3/10 from one account to many hosts in a short window
# IDS/IPS alert correlated with the same host's other activity
# Impossible travel / anomalous login (with geo enrichment)
Alerting — making alerts actionable (not noise):
- Severity/prioritization — classify alerts (Critical/High/Medium/Low) so the important ones surface; prioritize by impact and confidence.
- Reduce false positives (tuning) — the #1 operational challenge; noisy alerts cause alert fatigue and missed real threats. Tune rules, add exclusions, set thresholds, and baseline normal.
- Correlation > single events — the strongest detections combine signals (failed-logons → success → new-admin → lateral movement tells a story a single event doesn't).
- Enrichment — add context (threat intel, asset criticality, user/geo) to alerts for faster triage.
- Routing & response — alerts go to analysts (or trigger automated response via SOAR); feed the incident response process (§30).
- Validate detections — test that your rules actually fire (e.g., via safe, authorized simulation / purple teaming) — an undetected attack is a coverage gap.
Metrics: detection coverage (vs ATT&CK), false-positive rate, mean time to detect (MTTD), alert volume, and time-to-triage — track to improve the detection program.
The principle: a SIEM turns centralized logs into detection and prioritized, actionable alerts — write detections mapped to attack behaviors (ATT&CK), correlate across sources, tune relentlessly to cut false positives (fight alert fatigue), enrich for context, map coverage to find gaps, and validate that detections fire. This is how you see attacks and trigger response — the active half of defense that complements prevention. For the exam, know what a SIEM does, the common platforms (esp. Wazuh/ELK/Security Onion), how to write & tune detection rules (and which telemetry reveals which attacks), and how alerts feed incident response.
29. Security Monitoring — Wazuh, Elastic & Security Onion
The study plan has you "build a monitoring pipeline (Wazuh or ELK): collect, centralize, correlate, alert; create detection rules and verify they fire." This section is the hands-on how-to for standing up monitoring in your lab — a concrete, tested exam skill.
The monitoring pipeline (the architecture to build):
[ endpoints/servers/network/security tools ] ← log sources (§27)
│ agents / forwarders (Wazuh agent, Beats, syslog, WEF, Suricata EVE)
▼
[ COLLECTION / INGESTION ] centralize & parse
▼
[ STORAGE / INDEXING ] searchable store (Elasticsearch / indexer)
▼
[ CORRELATION / DETECTION ] rules & analytics → alerts (§28)
▼
[ VISUALIZATION / ALERTING ] dashboards (Kibana), alerts to analysts → incident response (§30)
Option A — Wazuh (security-focused, all-in-one, great for the lab):
WHAT IT IS: open-source security platform = SIEM + HIDS + FIM + log analysis + vulnerability detection +
compliance checks. Agents on hosts + a central Wazuh manager + a dashboard (OpenSearch/Kibana-based).
BUILD:
1. Install the Wazuh manager + indexer + dashboard (single-node for a lab).
2. Deploy Wazuh AGENTS on your Windows/Linux hosts → they ship logs & host telemetry to the manager.
3. Wazuh applies its RULESET out of the box: FIM (file-integrity monitoring), log analysis, rootkit/
anomaly detection, SCA (security configuration assessment vs CIS), and vulnerability detection.
4. VIEW alerts/events in the dashboard; map to MITRE ATT&CK (Wazuh tags techniques).
5. WRITE CUSTOM RULES/DECODERS for your environment; tune to cut false positives.
6. VERIFY detections fire (e.g., trigger a benign test like creating a user / editing a monitored file
→ confirm the alert appears). Configure alerting (email/integration).
WHY IT'S GREAT FOR eEDA: it bundles HIDS + FIM + log SIEM + CIS compliance checks + vuln detection in one
free platform you can stand up quickly and that maps directly to the exam's monitoring/detection goals.
Option B — Elastic Stack (ELK):
COMPONENTS: Elasticsearch (store/search) + Logstash and/or Beats (Filebeat/Winlogbeat — collect/ship) +
Kibana (visualize) [+ Elastic Security for SIEM detection rules].
BUILD:
1. Stand up Elasticsearch + Kibana.
2. Ship logs in via Beats (Winlogbeat for Windows events, Filebeat for logs/Suricata) and/or Logstash.
3. Parse/normalize (Logstash pipelines / ingest pipelines / ECS fields).
4. Build dashboards in Kibana; create detection rules (Elastic Security / alerting).
5. Tune and VERIFY rules fire.
Option C — Security Onion (network-centric NSM + SIEM distro):
WHAT IT IS: a free distribution bundling Suricata + Zeek (network monitoring) + Wazuh + Elastic +
analyst tools, pre-integrated. Great for NETWORK security monitoring plus host telemetry.
BUILD: deploy the distro, connect it to a SPAN/mirror port (to see network traffic) and point host
agents/logs at it → you get network IDS alerts (Suricata), rich network logs (Zeek), host events
(Wazuh), and an analyst console — a full NSM+SIEM lab in one.
Making it effective (the practices that matter):
- Coverage — ensure you're collecting the right telemetry (enable the audit policies/Sysmon/command-line logging that reveal attacks — §27); a detection needs its telemetry.
- Normalization & correlation — parse into common fields; correlate across host + network + security-tool data for strong detections (§28).
- Detection rules mapped to ATT&CK — build/enable detections for the behaviors that matter; verify they fire (trigger benign test activity and confirm the alert) — the study plan's explicit goal.
- Tuning — cut false positives so real alerts aren't buried.
- Dashboards & alerting — visualize posture; route alerts to trigger investigation/IR.
- Integrate the sources — firewall, IDS/IPS (Suricata EVE), EDR, OS logs, AD, DNS/proxy — the more correlated sources, the better the detection.
The principle: build an end-to-end monitoring pipeline — collect telemetry from hosts and network, centralize and normalize it, apply detection rules (mapped to ATT&CK), tune out noise, visualize, and alert — using free platforms (Wazuh for an all-in-one security SIEM+HIDS+FIM+compliance, ELK for a flexible stack, Security Onion for network-centric NSM). Then verify your detections actually fire. This is the hands-on capability that makes "Detect" real. For the exam, be able to stand up Wazuh/ELK, ship logs, create and verify detection rules, and build dashboards/alerts.
30. Incident Response (NIST SP 800-61)
When prevention fails and detection fires, incident response (IR) is how you contain, eradicate, recover, and learn — minimizing damage. The NIST SP 800-61 lifecycle is the standard, and understanding it is an eEDA readiness criterion ("walk an incident through the response lifecycle").
The NIST SP 800-61 incident response lifecycle:
1. PREPARATION — BEFORE incidents: IR plan & playbooks, team & roles, tools, logging/monitoring
(§27-29), communications plan, training, and the ability to respond
(access, authority, backups, contacts). The investment that makes IR work.
2. DETECTION & ANALYSIS — identify that an incident is occurring (alerts from SIEM/EDR/IDS, reports),
then analyze: what happened, scope, affected systems/data, severity, and
the attack path. Document and prioritize.
3. CONTAINMENT, ERADICATION & RECOVERY —
CONTAIN: stop the spread/damage (short-term: isolate host via EDR, block IP/account, segment;
long-term: temporary fixes while preparing eradication). Balance speed vs evidence
preservation and business impact.
ERADICATE: remove the threat — delete malware, remove persistence & attacker access, close the
vulnerability/entry point, reset compromised credentials.
RECOVER: restore systems to normal (from clean backups/rebuilds), verify they're clean, and
monitor closely for recurrence. Return to production carefully.
4. POST-INCIDENT ACTIVITY (Lessons Learned) — review what happened, what worked/didn't, root cause, and
improvements; update controls, detections, and the plan; report. Feeds back
into Preparation (continuous improvement).
(The SANS PICERL model is equivalent: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned.)
Key IR concepts & roles:
- Incident vs event: an event is any observable occurrence; an incident is an event (or series) that violates security policy or threatens CIA. Triage decides which events are incidents.
- IR plan & playbooks — the documented process and per-incident-type procedures (malware, phishing, ransomware, account compromise, data breach) — prepared in advance.
- CSIRT/IR team & roles — who does what; incident commander, analysts, and cross-functional members (legal, comms, management, IT).
- Severity/classification — triage incidents by impact to prioritize.
- Containment strategy — short-term (immediate isolation) vs long-term; weigh stopping damage vs preserving evidence vs business disruption.
- Evidence & forensics — preserve evidence (logs, images, memory) with chain of custody; capture volatile data (memory) before powering off; hash for integrity (ties to logging §27).
- Communication — internal (team, management) and external (customers, regulators — breach notification per compliance, §9; e.g., GDPR 72h), handled per the plan.
- Recovery & BCP/DR — IR contains/eradicates; DR restores (§12) — tested backups (esp. offline/immutable) are what enable recovery without paying ransom.
- Metrics: MTTD (detect), MTTR (respond/recover), dwell time — track to improve.
The defensive engineer's role in IR: you build the preparation that makes IR possible (logging, monitoring, detections, backups, segmentation to contain, and the ability to isolate/revoke fast) and often perform detection/analysis and initial containment (isolate a host via EDR, block an indicator, disable an account). Your hardening and segmentation limit incidents; your monitoring detects them; your backups/DR recover from them. IR ties the whole defensive program together.
Containment & response capabilities to have ready (ties back to earlier sections):
- Host isolation (EDR) — network-quarantine a compromised endpoint fast (§24)
- Account disable/credential reset — cut off compromised identities (§18-19)
- Network block/segment — firewall rules to block C2/exfil, isolate a zone (§5, §22)
- Clean, tested backups (offline/immutable) — recover without paying ransomware (§12)
- Centralized logs & EDR telemetry — reconstruct the incident (§27-29)
- Documented playbooks & contacts — act fast, correctly, and consistently
The principle: assume incidents will happen and be prepared — plan, playbooks, team, logging/monitoring/detection, backups, and containment capabilities — then execute the lifecycle: detect & analyze → contain, eradicate & recover → learn and improve. Speed matters (lower MTTD/MTTR = less damage), evidence preservation matters, and lessons-learned feeds continuous improvement. For the exam, know the NIST 800-61 lifecycle cold, the incident-vs-event distinction, containment/eradication/recovery, evidence handling, breach notification, and how your defensive engineering (monitoring, backups, segmentation, isolation) enables effective response.
31. Cryptography & PKI for Defenders
Cryptography protects confidentiality and integrity (and enables authenticity/non-repudiation) across data at rest, in transit, and in authentication. A defensive engineer must know how to apply and manage crypto correctly — not design algorithms, but deploy, configure, and avoid misuse.
Core concepts (know the vocabulary):
- Symmetric encryption — one shared key encrypts & decrypts; fast; for bulk data. AES (AES-256) is the standard. Challenge: securely sharing the key.
- Asymmetric encryption (public-key) — a key pair (public + private): encrypt with public/decrypt with private (confidentiality), or sign with private/verify with public (authenticity). RSA, ECC (elliptic curve — smaller keys, efficient). Solves key distribution; slower, so often used to exchange a symmetric key.
- Hashing — one-way function producing a fixed fingerprint; for integrity and password storage. SHA-256 (good), SHA-1/MD5 (broken — don't use for security). Password hashing uses slow, salted algorithms (bcrypt/scrypt/Argon2/PBKDF2).
- Digital signatures — hash + encrypt-with-private-key → proves integrity + authenticity + non-repudiation (the signer can't deny it; the content can't be altered).
- MAC / HMAC — keyed hash for integrity + authenticity (shared key).
- Key exchange — Diffie-Hellman (and ECDH) to establish a shared secret over an insecure channel; perfect forward secrecy (PFS) ensures past sessions stay safe if a key is later compromised.
Where crypto protects (apply it here):
DATA IN TRANSIT: TLS (HTTPS, LDAPS, SMTPS, etc.), VPN (IPsec/WireGuard/OpenVPN), SSH — encrypt all
sensitive network traffic; disable weak protocols/ciphers (no SSLv3/TLS1.0/1.1; strong cipher suites).
DATA AT REST: full-disk encryption (BitLocker/LUKS), database/file/field encryption, encrypted
backups — protects stolen media and limits breach impact.
AUTHENTICATION: password hashing (salted, slow), certificate-based auth, signed tokens.
INTEGRITY: hashing/signatures for files, code signing, FIM.
Public Key Infrastructure (PKI) — managing certificates & trust (know this):
- CERTIFICATE (X.509): binds a public key to an identity, signed by a trusted CA.
- CA (Certificate Authority): issues & signs certificates; the root of trust. Root CA (offline, highly
protected) → Intermediate CA(s) → end-entity certs (a trust chain/hierarchy).
- RA (Registration Authority): verifies identities before issuance.
- TRUST CHAIN: clients trust a cert if it chains to a trusted root CA.
- REVOCATION: CRL (Certificate Revocation List) & OCSP — check whether a cert is revoked.
- CERT LIFECYCLE: request (CSR) → validate → issue → deploy → monitor/renew → revoke/expire.
USES: TLS server/client certs, code signing, email (S/MIME), smartcard/cert-based auth, device identity.
ENTERPRISE PKI: an internal CA (e.g., AD Certificate Services) issues certs for internal TLS, device/
user auth, VPN, etc. — a powerful identity & encryption enabler (and a high-value target to protect).
Defensive crypto management (the engineer's job — where crypto fails is usually management, not math):
- Use strong, current algorithms & configurations — AES-256, SHA-256+, TLS 1.2/1.3 with strong cipher suites, RSA-2048+/ECC; disable weak/legacy (MD5, SHA-1, DES/3DES, RC4, SSLv3, TLS 1.0/1.1). Scan your TLS configs.
- Key management (the hard part) — generate, store (HSM/secrets manager/key vault), distribute, rotate, and revoke keys securely; never hardcode keys (in code/configs/prompts); restrict access; back up keys securely. A leaked/mismanaged key defeats the encryption.
- Certificate management — track certs, monitor expiry (expired certs cause outages), automate renewal, protect private keys, and secure the CA (an internal CA compromise = forge any identity).
- Enforce encryption via policy (encryption policy, §10): what must be encrypted at rest/in transit and how.
- Avoid common mistakes — weak algorithms, hardcoded/reused keys, improper cert validation (accepting invalid/self-signed in production), ECB mode, static IVs, rolling your own crypto.
The principle: apply strong, correctly-configured cryptography to protect data in transit (TLS/VPN/SSH), at rest (disk/db/backup encryption), and for authentication & integrity (hashing, signatures, PKI) — and recognize that the real work (and the real failures) is in key and certificate management: strong algorithms, secure key storage/rotation, protected CAs, monitored cert expiry, and disabling weak legacy crypto. For the exam, know symmetric/asymmetric/hashing/signatures, where each applies, TLS/VPN, PKI (CA/cert/revocation/trust chain), and secure key management.
32. Data Security, Classification & DLP
Protecting data — the ultimate asset — ties together classification, access control, encryption, and loss prevention. The CIA triad is ultimately about the data; this section consolidates the data-centric controls.
Data classification (the foundation — drives every other data control): classify data by sensitivity (§10) — e.g., Public / Internal / Confidential / Restricted — so controls match value. Classification determines who may access it (least privilege/need-to-know), whether it's encrypted, how it's stored/transmitted/retained/disposed, and what monitoring (DLP) applies. You can't protect data appropriately if you don't know what you have and how sensitive it is — so data discovery and inventory come first.
Data states & their protections:
DATA AT REST stored (disk, DB, backup, files) → encryption, access control, classification labels
DATA IN TRANSIT moving over networks → TLS/VPN/encrypted protocols (§31)
DATA IN USE being processed (memory) → access control, secure handling, rights management
Core data-security controls:
- Access control & least privilege / need-to-know — only authorized identities access data, scoped to the minimum (IAM, §13-19). The primary confidentiality control.
- Encryption — at rest and in transit per classification (§31).
- Data Loss Prevention (DLP) — detects and prevents unauthorized data exfiltration/leakage. DLP inspects data in motion (network/email/web), at rest (stored, to find mis-stored sensitive data), and in use (endpoint — USB, clipboard, uploads), matching patterns (PII, card numbers, keywords, classification labels) and blocking/alerting on policy violations. Example: block an email containing card numbers to an external recipient; alert on a bulk upload of a sensitive file to personal cloud storage.
- Rights management (IRM/DRM) — persistent protection/controls that travel with the document (restrict copy/print/forward even after it leaves).
- Data masking / tokenization / anonymization — reduce exposure of sensitive data in non-production, analytics, or displays (show only last-4; replace with tokens).
- Backups — availability & recovery for data (§12); encrypted, 3-2-1, offline/immutable.
- Secure disposal — sanitize/destroy data at end of life (secure wipe, degaussing, physical destruction) per a data retention & disposal policy — "deleted" files and decommissioned media are a breach vector.
- Database security — least-privilege DB accounts, encryption (TDE/column), auditing, patching, network isolation, no default creds.
- Monitoring — log and alert on sensitive-data access (detect exfiltration/misuse — §28).
Data lifecycle (manage data cradle-to-grave):
CREATE/COLLECT → CLASSIFY → STORE (encrypt/access-control) → USE (least privilege) → SHARE (controlled,
DLP) → ARCHIVE/RETAIN (per policy & compliance) → DISPOSE (secure destruction).
Minimize data (collect/keep only what's needed) — less data = less risk.
Privacy angle (ties to compliance, §9): personal data (PII/PHI) carries legal obligations (GDPR/HIPAA/CCPA) — classification, access control, encryption, minimization, retention limits, breach notification, and data-subject rights. Treat privacy-regulated data as Restricted.
The principle: protect data by knowing what you have (discovery + classification), then applying access control (least privilege/need-to-know), encryption (at rest & in transit), DLP (detect/prevent exfiltration), minimization & retention limits, and secure disposal — across the full data lifecycle, with monitoring on sensitive-data access and heightened controls for privacy-regulated data. Data is the asset the whole program exists to protect. For the exam, know data classification, data states & their protections, DLP, secure disposal, and the data lifecycle.
33. Cloud, Email & Web Defensive Controls
Modern enterprises live in the cloud and are attacked primarily through email and the web. A defensive engineer secures these high-exposure surfaces.
Email security (the #1 attack delivery vector — phishing/malware).
- SECURE EMAIL GATEWAY: anti-spam, anti-phishing, anti-malware (attachment scanning/sandboxing), URL
rewriting/filtering, and impersonation/BEC protection on inbound mail.
- EMAIL AUTHENTICATION (anti-spoofing — know these three):
SPF — authorizes which servers may send for your domain (DNS record).
DKIM — cryptographically signs messages (integrity + sender authenticity).
DMARC — ties SPF/DKIM to the visible From domain + a policy (none/quarantine/reject) + reporting.
→ Configure all three (DMARC at enforce/reject) to stop spoofing of your domain.
- ATTACHMENT/LINK PROTECTION: sandbox detonation, block dangerous attachment types, safe-links.
- USER AWARENESS: phishing training & reporting button (users are a key detection/defense layer).
- DLP on OUTBOUND email (prevent data exfiltration, §32).
Web security (browsing & web apps).
- WEB PROXY / SECURE WEB GATEWAY: filter malicious/inappropriate sites, inspect traffic, block known-bad
domains/categories, enforce policy. (Also provides egress control & C2 disruption, §5.)
- DNS SECURITY / FILTERING: block known-malicious domains at DNS; DNS logging (great for detecting C2/
malware/exfil); consider protective DNS.
- WAF (Web Application Firewall): protect your web apps from web attacks (SQLi/XSS/etc.) — app-layer
defense complementing network firewalls.
- TLS everywhere; HSTS; secure headers (CSP, X-Frame-Options) for your web apps.
- BROWSER HARDENING: patch browsers, restrict plugins, isolation where needed.
Cloud security (ties to the ARTE/AZRTE/ICCA cloud disciplines — defensive view).
- SHARED RESPONSIBILITY: the provider secures the cloud infrastructure; YOU secure your data, identities,
configurations, and access IN the cloud. Know the split per service model (IaaS/PaaS/SaaS).
- IDENTITY & ACCESS (the cloud perimeter): strong IAM, MFA everywhere (esp. admin/root), least-privilege
roles/policies, no long-lived over-privileged keys, conditional access.
- SECURE CONFIGURATION: avoid the top cloud breach cause — MISCONFIGURATION (public storage buckets,
over-permissive IAM, open security groups, disabled logging, unencrypted data). Use CSPM tools and
cloud CIS Benchmarks to find & fix misconfigs.
- NETWORK: security groups/NACLs (default-deny), segmentation (VPCs/subnets), private endpoints, no
needless public exposure.
- DATA: encryption at rest/in transit, key management (KMS/Key Vault), private storage, classification.
- LOGGING/MONITORING: enable cloud audit logs (CloudTrail/Activity/Audit), send to SIEM; cloud-native
detection (GuardDuty/Defender for Cloud/Security Command Center).
- POSTURE MANAGEMENT: continuous CSPM to detect config drift & compliance gaps; secure the CI/CD &
secrets; container/K8s hardening for cloud workloads.
The principle: secure the high-exposure surfaces — email (gateway + SPF/DKIM/DMARC + sandboxing + awareness, since it's the top delivery vector), web (secure web gateway/proxy + DNS filtering + WAF + egress control), and cloud (strong IAM + MFA, secure configuration to avoid the misconfiguration epidemic, network controls, data encryption, and audit logging to the SIEM — within the shared-responsibility model). These are where attacks arrive and where modern data lives. For the exam, know email authentication (SPF/DKIM/DMARC) and gateway controls, web/DNS filtering and WAF, and cloud security fundamentals (shared responsibility, IAM/MFA, misconfiguration, logging).
34. Documentation, Reporting & Communication
The study plan includes a documentation guide and templates — because defensive engineering must be documented to be maintainable, auditable, repeatable, and defensible. Documentation is a graded, professional skill and threads through every domain.
Why documentation matters in defense: it enables consistency (others can follow/reproduce your work), auditability/compliance (prove controls exist and work), accountability (who did/decided what), maintainability (future admins understand the environment), incident response (accurate info when it matters), and continuity (knowledge survives staff turnover). "If it isn't documented, it doesn't exist" — for audits, handoffs, and IR.
Key documentation artifacts a defensive engineer produces/maintains:
GRC: policies, standards, procedures, baselines (§10); risk register & assessments (§7);
compliance/control mappings; BCP/DR plans (§12).
ARCHITECTURE: network diagrams (zones/flows), data-flow diagrams, system inventories (CMDB),
security architecture docs.
CONFIGURATION: hardening baselines & checklists, firewall rule documentation (with justification),
config-as-code, build/golden-image docs.
IAM: role definitions (RBAC), access matrices, lifecycle procedures, access-review records.
OPERATIONS: change records (RFCs), patch/vuln reports, monitoring/detection rule docs, runbooks.
INCIDENT: IR plan & playbooks, incident reports (timeline, impact, actions, lessons learned).
ASSESSMENT: security assessment reports, audit evidence, metrics/dashboards.
Writing effective security documentation (principles):
- Clear & precise — unambiguous; a reader can act on it without guessing. Define the exact requirement (a zone that must be isolated, an account that must be removed).
- Accurate & current — documentation that's out of date is dangerous (people trust it); review/update as the environment changes.
- Appropriately detailed — procedures/runbooks detailed enough to follow and reproduce; policies high-level and stable.
- Justified — record the why (rationale for a firewall rule, a risk-acceptance decision, a config choice) — essential for audits and future maintainers.
- Audience-aware — executive summaries (risk, business language) for leadership; technical detail for engineers.
- Templated & consistent — use standard templates (policy template, risk assessment, IR report, change record) for consistency and completeness.
- Version-controlled & owned — track changes, assign owners, and set review cycles.
Reporting (communicating security to stakeholders):
- To leadership: risk posture, key risks, compliance status, incidents, and metrics — in business terms, enabling decisions.
- Security metrics/KPIs: patch compliance, vulnerability trends, MTTD/MTTR, detection coverage, access-review completion, incident counts/severity — show program effectiveness and justify investment.
- Incident reports: clear timeline, scope/impact, root cause, actions taken, and recommendations.
- Audit evidence: demonstrable proof controls exist and operate (configs, logs, reports, records).
The principle: document everything — policies/baselines/architecture/configs/IAM/operations/incidents — clearly, accurately, with rationale, kept current and version-controlled, using consistent templates — because defensive engineering must be auditable, maintainable, reproducible, and defensible. And communicate security effectively to the right audiences (business terms for leadership, technical detail for engineers, metrics to show effectiveness). For the exam's hands-on tasks, documenting what you did and why (and verifying it) is part of the deliverable — don't skip it.
35. Building the Defensive Lab
The eEDA is hands-on — you must practice the engineering. A home defensive lab lets you build, harden, break (your own systems, to verify defenses), monitor, and respond. The study plan builds in a lab throughout; here's how to assemble one.
The lab architecture (a miniature enterprise):
HYPERVISOR (host everything): VirtualBox / VMware Workstation (free-ish) / Proxmox (free, great for a
dedicated box). Enough RAM/CPU/disk (16GB+ RAM ideal; SSD).
NETWORK (segmented — the point):
[ WAN / Internet ]
│
FIREWALL/ROUTER VM: pfSense or OPNsense ← create multiple interfaces/VLANs for zones
├── DMZ segment (a web server VM)
├── Internal/User segment (a Windows client VM)
├── Server segment (Windows Server = Domain Controller; a Linux server)
├── Restricted segment (a "database" VM)
└── Management segment (your monitoring + admin)
CORE VMs:
- Windows Server (Active Directory DC) — IAM, GPO hardening, directory (§16)
- Windows client — domain-joined endpoint (hardening, EDR, logging)
- Linux server (Ubuntu/CentOS) — hardening (§21), services
- pfSense/OPNsense — firewall/segmentation/IDS (§22-23)
- MONITORING VM: Wazuh (or ELK, or Security Onion) — SIEM/HIDS/FIM/detection (§29)
- Vulnerability scanner — OpenVAS/Greenbone or Nessus Essentials (§26)
- (optional) a "victim"/test VM for safely validating detections against YOUR OWN systems
What to practice in the lab (mapped to the domains):
FUNDAMENTALS/ARCH: build the segmented network; implement zones; practice default-deny & kill-chain
thinking; design for defense-in-depth.
GRC: write policies & baselines; do a risk assessment; map controls to NIST CSF.
IAM (28%): stand up AD; design RBAC roles & AD security groups; enforce MFA; run the full
identity lifecycle (joiner/mover/leaver, clean de-provisioning); harden the DC;
practice PAM concepts (separate admin accounts, tiering).
SECURITY ADMIN (36%): harden Windows & Linux to CIS (measure before/after); build & document default-deny
firewall rulesets across zones; configure Suricata/Snort IDS/IPS; set up endpoint
security; manage configuration/baselines.
VULN MGMT: run authenticated & unauthenticated scans; prioritize; remediate; re-scan to verify.
MONITORING/DETECT: build the Wazuh/ELK pipeline; collect logs from all VMs; create detection rules;
VERIFY they fire (trigger benign test activity on your own systems); build dashboards.
INCIDENT RESPONSE: walk a (simulated, benign) incident through the NIST lifecycle end to end.
INTEGRATION: secure the WHOLE environment across all domains, then verify each control works.
Lab best practices:
- Isolate the lab — keep it on an isolated host-only/internal network (don't expose vulnerable test systems to your real network or the internet); snapshot VMs so you can revert.
- Any offensive testing is against YOUR OWN lab systems only — to verify your defenses (does the firewall actually block it? does the detection fire?) — never against anything you don't own.
- Snapshots — take snapshots before changes so you can experiment and roll back.
- Document as you go — practice the documentation (§34); build your baselines and runbooks for real.
- Iterate — build → harden → verify → monitor → simulate an incident → improve.
Free resources to pair with the lab: TryHackMe & LetsDefend (blue-team paths, SOC practice), Blue Team Labs Online (defensive scenarios), and the tool docs (pfSense/OPNsense, Wazuh, Security Onion, Suricata). The DFIR Report (real intrusion analyses) shows what you're defending against.
The principle: build a segmented, miniature enterprise and practice the full defensive engineering workflow in it — harden systems, stand up and secure AD/IAM, design default-deny firewalls, deploy IDS and a Wazuh/ELK monitoring pipeline, scan and remediate vulnerabilities, create and verify detections, and run an incident through the lifecycle — then secure the whole thing end to end and verify every control. The eEDA tests doing; the lab is where you learn to do it. Isolate the lab, snapshot often, document everything, and only test defenses against your own systems.
36. Capstone — Securing an Enterprise End to End
The culmination: secure a complete enterprise environment across all domains (the study plan's integrating exercise and the shape of the exam). This section is the end-to-end methodology that ties everything together — build, harden, secure, monitor, and verify a whole environment.
The scenario (example): you're handed a standard enterprise network — a firewall, a DMZ web server, internal user workstations, a Windows Server (to be the Domain Controller), a Linux application server, and a database holding sensitive data — with business requirements (e.g., "the database must be isolated; only the app server may reach it," "all admin access requires MFA," "the finance data is Confidential," "we must meet a given baseline"). Secure it, and verify.
The end-to-end methodology (apply all five areas):
1. UNDERSTAND REQUIREMENTS (read carefully — tasks hinge on specifics)
- what must be isolated, who needs what access, what data is sensitive, which baseline/framework,
what compliance applies. Note every precise requirement (a zone that MUST be isolated, an account
that MUST be removed). Default-deny thinking from the start.
2. ARCHITECT & SEGMENT (Fundamentals)
- design zones (DMZ / user / server / restricted / management); define ONLY the necessary inter-zone
flows (default-deny everything else); plan defense-in-depth layers.
3. GOVERNANCE & RISK (GRC)
- identify assets & risks; set baselines (CIS + requirements); write/apply the relevant policies;
map controls to the framework; document decisions and risk acceptances; use change control.
4. IDENTITY & ACCESS (IAM — 28%)
- stand up AD; design RBAC roles & groups per job function (least privilege); enforce MFA (esp.
admin/remote); harden the DC; separate admin accounts / tiering (PAM); implement the identity
lifecycle; set strong password/lockout policy via GPO.
5. HARDEN & SECURE SYSTEMS (Security Admin — 36%)
- harden every system to the CIS baseline (measure before/after); least functionality (disable
unneeded services/ports/accounts); patch; disk encryption; endpoint security/EDR; secure admin
access (jump host, MFA, encrypted protocols).
6. NETWORK CONTROLS
- configure the firewall default-deny rulesets across zones (allow only required flows, control
egress, log denies); deploy/tune IDS/IPS at choke points; secure the management plane.
7. DATA PROTECTION
- classify data; encrypt at rest & in transit; least-privilege access to the sensitive DB; DLP/
monitoring on sensitive data; backups (3-2-1, offline/immutable) with tested restore.
8. VULNERABILITY MANAGEMENT
- scan (authenticated) for vulnerabilities & misconfigurations; remediate (patch/reconfigure);
re-scan to verify.
9. MONITORING & DETECTION
- build the logging pipeline (all systems → Wazuh/ELK); enable the right audit policies; create
detection rules mapped to ATT&CK; VERIFY they fire; build dashboards & alerts.
10. INCIDENT READINESS
- IR plan/playbooks; containment capabilities ready (host isolation, account disable, network block);
tested backups/DR; know you can detect, contain, and recover.
11. VERIFY EVERYTHING (the critical, exam-defining step)
- confirm EACH control actually does what's intended: the restricted zone is truly isolated (test it);
the removed account is really gone (check everywhere incl. SSO/VPN); the firewall blocks what it
should (test allowed AND denied flows); the hardening holds (re-scan); the detections fire (trigger
benign test activity); backups restore. A configured-but-unverified control is not done.
12. DOCUMENT
- the architecture, baselines, firewall rules (with justification), RBAC model, configurations,
and what you verified. The documentation is part of the deliverable.
The integration mindset (what the capstone/exam tests): the domains aren't separate — they combine into one secure environment. Segmentation (Fundamentals) + least-privilege firewall rules (Admin) contain breaches; AD/RBAC/MFA (IAM) control access; hardening + patching (Admin/VulnMgmt) reduce attack surface; monitoring (Admin) detects what gets through; IR + backups (GRC/Admin) recover; and GRC/policies/baselines/documentation tie it together and make it defensible. You demonstrate you can build, secure, and verify a whole enterprise, applying the right principle to each task.
The exam-aligned habits to carry through the capstone:
- Read carefully — a task often hinges on one precise requirement.
- Default-deny — start closed, open deliberately, document why.
- Least privilege everywhere — when in doubt, grant less.
- Verify your work — confirm each control truly does what you configured.
- Think in the domains — identify which area a task belongs to and apply its principles.
- Document — what you did, why, and that you verified it.
The principle: the capstone is securing a complete enterprise end to end — architect and segment, govern and baseline, control identity and access, harden and patch systems, enforce default-deny networking, protect data, manage vulnerabilities, build monitoring and detection, prepare for incidents, and — above all — verify every control and document it. That integrated, verified, documented defensive build is what the eEDA certifies. Practice it end to end in your lab until the workflow is second nature.
37. Exam-Day Strategy & Study Plan
Exam approach (apply these to every task):
- Read carefully. Defensive tasks often hinge on a specific requirement — a zone that must be isolated, an account that must be removed, a particular baseline. Identify the exact requirement before acting.
- Default-deny thinking. Start closed, open deliberately, and document why — for firewalls, permissions, services, ports.
- Least privilege everywhere. When in doubt, grant less. The most-applied principle across IAM and admin tasks.
- Verify your work. Confirm each control actually does what you configured — test the firewall rule, check the account is truly removed (everywhere), re-scan the hardened host, confirm the alert fires. A configured-but-unverified control loses points.
- Think in the domains. Most tasks map to Fundamentals, GRC, IAM, or Security Administration — identify which and apply its principles.
- Document. For hands-on tasks, recording what you did, why, and that you verified it is part of the deliverable.
- Manage time by weight. Security Admin (36%) + IAM (28%) = 64% and the most hands-on — prioritize; don't rabbit-hole.
Study plan (~8–12 weeks, hands-on throughout — adjust the calendar, keep the sequence):
Weeks 1–2 SECURE ENGINEERING FUNDAMENTALS: CIA, least privilege, defense-in-depth, zero trust;
kill chain & ATT&CK; BUILD THE LAB (hypervisor, segmented network, firewall); practice
segmentation. Goal: think defensively + a working lab. (§2–5, §35)
Weeks 3–4 GRC: NIST CSF, ISO 27001, CIS; write a policy; do a risk assessment; map controls to CSF;
control types; BCP/DR & change management. Goal: the organizational framework. (§6–12)
Weeks 5–6 IAM (28%): stand up AD/LDAP; design RBAC; enforce MFA; run the full identity lifecycle incl.
clean de-provisioning; SSO/federation; PAM. Goal: administer enterprise identity securely. (§13–19)
Weeks 7–8 SECURITY ADMINISTRATION (36%): harden Windows & Linux to CIS (measure before/after); design &
document default-deny firewall rules across zones; configure IDS/IPS; set up logging;
secure admin practices. Goal: configure, harden, maintain controls hands-on. (§20–25)
Weeks 9–10 VULN MGMT & MONITORING: authenticated/unauthenticated scans; prioritize & remediate; build a
Wazuh/ELK monitoring pipeline (collect/centralize/correlate/alert); create & VERIFY detection
rules; walk an incident through the IR lifecycle. Goal: find weaknesses & detect attacks. (§26–30)
Weeks 11+ INTEGRATION & CONSOLIDATION: practice documentation & templates (§34); do the CAPSTONE — secure
a whole environment across all five domains, then verify each control (§36); drill weak domains;
final pass through everything.
Readiness criteria (can you do all of these hands-on?):
[ ] Apply core security principles (CIA, least privilege, defense-in-depth, zero trust)
[ ] Understand the major GRC frameworks & risk management; write a policy & do a risk assessment
[ ] Administer a directory (AD/LDAP) & enforce sound IAM (RBAC, MFA, full lifecycle, clean de-provisioning)
[ ] Harden Windows & Linux against a secure baseline (CIS) and measure the improvement
[ ] Design & document default-deny firewall rulesets across zones; control egress
[ ] Configure IDS/IPS; identify vulnerable systems with authenticated & unauthenticated scanning
[ ] Build a working monitoring pipeline (Wazuh/ELK) with detection rules that you've verified fire
[ ] Understand & walk through the incident response lifecycle (NIST 800-61)
[ ] Secure a full environment end to end across all domains — and VERIFY every control
[ ] Document your work clearly, with rationale
Common mistakes to avoid: studying without hands-on practice (fatal for this exam); not verifying controls actually work; forgetting default-deny/least-privilege; incomplete de-provisioning (missing SSO/VPN/privileged/service access); over-broad firewall rules ("any any"); neglecting egress control and logging; missing a precise task requirement; and poor documentation. Practice environments: your own lab (§35), plus TryHackMe, LetsDefend, and Blue Team Labs Online for guided blue-team practice.
38. Practical Commands, Configs & Queries Reference
A hands-on, copy-paste reference across every domain — real commands, configurations, and detection queries for your own lab/authorized systems. This is the "do it" companion to the concepts above.
A. Linux Hardening & Auditing
# --- Enumerate & reduce attack surface ---
ss -tulpn # listening ports/services (what's exposed)
systemctl list-unit-files --type=service --state=enabled # enabled services
systemctl disable --now <service> # disable unneeded service
apt list --installed | rpm -qa # installed packages (remove what's not needed)
sudo apt purge <pkg> / sudo dnf remove <pkg>
# --- Accounts & auth ---
awk -F: '($3>=1000){print $1}' /etc/passwd # human accounts
awk -F: '($3==0){print $1}' /etc/passwd # UID-0 accounts (should be only root)
sudo passwd -l <user> # lock an account
sudo usermod -s /usr/sbin/nologin <svc> # no shell for service accounts
chage -l <user> # password aging
sudo chage -M 365 -W 14 <user> # max age / warn (modern: length>rotation)
grep -E 'PermitRootLogin|PasswordAuthentication' /etc/ssh/sshd_config
# --- SSH hardening (/etc/ssh/sshd_config) ---
# PermitRootLogin no
# PasswordAuthentication no (use keys)
# PubkeyAuthentication yes
# Protocol 2 ; X11Forwarding no ; MaxAuthTries 3 ; LoginGraceTime 30
# AllowGroups sshusers ; ClientAliveInterval 300
sudo systemctl restart sshd
sudo apt install fail2ban && sudo systemctl enable --now fail2ban # brute-force protection
# --- Firewall (host) ---
sudo ufw default deny incoming && sudo ufw default allow outgoing
sudo ufw allow from 10.0.10.0/24 to any port 22 proto tcp # scoped SSH
sudo ufw enable && sudo ufw status verbose
# --- File permissions / SUID ---
sudo find / -perm -4000 -type f 2>/dev/null # SUID binaries (review/remove unneeded)
sudo find / -perm -2000 -type f 2>/dev/null # SGID
sudo find / -type f -perm -o+w 2>/dev/null # world-writable files
stat /etc/shadow # should be 640 root:shadow or stricter
# --- Kernel / sysctl hardening (/etc/sysctl.d/99-hardening.conf) ---
# net.ipv4.conf.all.rp_filter=1
# net.ipv4.icmp_echo_ignore_broadcasts=1
# net.ipv4.conf.all.accept_redirects=0
# net.ipv4.conf.all.send_redirects=0
# kernel.randomize_va_space=2 (ASLR)
sudo sysctl --system
# --- MAC (SELinux / AppArmor) ---
getenforce ; sudo setenforce 1 ; sestatus # SELinux (RHEL)
sudo aa-status # AppArmor (Debian/Ubuntu)
# --- Auditing (auditd) ---
sudo apt install auditd
sudo auditctl -w /etc/passwd -p wa -k identity # watch /etc/passwd writes
sudo auditctl -w /etc/shadow -p wa -k identity
sudo auditctl -w /etc/sudoers -p wa -k priv
sudo auditctl -a always,exit -F arch=b64 -S execve -k exec # log command execution
sudo ausearch -k identity | aureport
# File integrity monitoring:
sudo apt install aide && sudo aideinit && sudo aide --check
# --- Automated audit / CIS checks ---
sudo apt install lynis && sudo lynis audit system # security audit + hardening index
# OpenSCAP against a CIS/STIG profile:
sudo oscap xccdf eval --profile <cis_profile> --report report.html <ssg-xml>
B. Windows Hardening & Auditing (PowerShell / CLI)
# --- Enumerate & attack surface ---
Get-Service | Where-Object {$_.Status -eq 'Running'} # running services
Get-NetTCPConnection -State Listen | Select LocalPort,OwningProcess # listening ports
Get-WindowsOptionalFeature -Online | ? State -eq Enabled # features (disable unneeded)
Get-LocalUser ; Get-LocalGroupMember Administrators # accounts / local admins
Disable-LocalUser -Name Guest
# --- Disable legacy/insecure protocols ---
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 0 # disable SMBv1
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
# Disable LLMNR (poisoning): GPO > Turn OFF Multicast Name Resolution (or registry EnableMulticast=0)
# Disable NBT-NS per-adapter; disable TLS1.0/1.1 via registry/IIS Crypto.
# --- Local security / password & lockout policy ---
net accounts /minpwlen:14 /maxpwage:unlimited /lockoutthreshold:5 /lockoutduration:15
secedit /export /cfg C:\secpol.cfg # export local security policy to review
# Apply security baseline via GPO (domain) or LGPO.exe (standalone) using Microsoft Security Baselines.
# --- Audit policy (generate the security events in §27) ---
auditpol /get /category:* # view current audit policy
auditpol /set /subcategory:"Process Creation" /success:enable # 4688
auditpol /set /subcategory:"Logon" /success:enable /failure:enable # 4624/4625
auditpol /set /subcategory:"Security Group Management" /success:enable # 4728/4732
# Enable command-line in 4688: GPO > Include command line in process creation events = Enabled
# Enable PowerShell ScriptBlock logging (4104): GPO > Windows PowerShell > Turn on Module/ScriptBlock Logging
# --- Firewall (Windows) ---
Set-NetFirewallProfile -Profile Domain,Public,Private -DefaultInboundAction Block -DefaultOutboundAction Allow
New-NetFirewallRule -DisplayName "Allow RDP mgmt" -Direction Inbound -Protocol TCP -LocalPort 3389 `
-RemoteAddress 10.0.10.0/24 -Action Allow
Get-NetFirewallRule | ? Enabled -eq True | Select DisplayName,Direction,Action
# --- Defender / EDR & ASR ---
Get-MpComputerStatus # Defender status
Set-MpPreference -AttackSurfaceReductionRules_Ids <GUID> -AttackSurfaceReductionRules_Actions Enabled
Set-MpPreference -EnableNetworkProtection Enabled
# LAPS (unique local-admin passwords): install & configure Windows LAPS / Microsoft LAPS.
# --- BitLocker (disk encryption) ---
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector
# --- Patch state ---
Get-HotFix | Sort InstalledOn -Descending | Select -First 10
C. Active Directory & IAM (PowerShell)
Import-Module ActiveDirectory
# --- Users & lifecycle (joiner/mover/leaver) ---
New-ADUser -Name "Jane Doe" -SamAccountName jdoe -UserPrincipalName [email protected] `
-Path "OU=Users,DC=corp,DC=local" -AccountPassword (Read-Host -AsSecureString) `
-Enabled $true -ChangePasswordAtLogon $true
Add-ADGroupMember -Identity "RBAC-Finance-ReadOnly" -Members jdoe # role assignment (RBAC)
# Mover: remove old role, add new (don't just add — fight privilege creep)
Remove-ADGroupMember -Identity "RBAC-Helpdesk" -Members jdoe -Confirm:$false
# Leaver: clean de-provisioning
Disable-ADAccount -Identity jdoe # disable immediately
Get-ADPrincipalGroupMembership jdoe | ? Name -ne "Domain Users" | ForEach-Object {
Remove-ADGroupMember -Identity $_ -Members jdoe -Confirm:$false } # strip group memberships
Move-ADObject -Identity (Get-ADUser jdoe).DistinguishedName -TargetPath "OU=Disabled,DC=corp,DC=local"
# --- Audit / hygiene (access reviews & stale accounts) ---
Get-ADGroupMember "Domain Admins" # review privileged membership
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly # stale accounts (>90d)
Get-ADUser -Filter {Enabled -eq $true -and PasswordNeverExpires -eq $true} # pw-never-expires
Get-ADUser -Filter * -Properties servicePrincipalName | ? servicePrincipalName # accounts with SPNs (Kerberoast exposure)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} # unconstrained delegation (risk)
# --- Fine-grained & default password policy ---
Get-ADDefaultDomainPasswordPolicy
New-ADFineGrainedPasswordPolicy -Name "AdminsPSO" -Precedence 10 -MinPasswordLength 20 `
-LockoutThreshold 5 -ComplexityEnabled $true
Add-ADFineGrainedPasswordPolicySubject "AdminsPSO" -Subjects "Domain Admins"
# --- gMSA (managed service-account passwords) ---
New-ADServiceAccount -Name "svc_app" -DNSHostName app.corp.local `
-PrincipalsAllowedToRetrieveManagedPassword "AppServers"
# --- Harden / protect privileged accounts ---
Add-ADGroupMember "Protected Users" -Members admin1 # stronger credential protection
Set-ADAccountControl admin1 -AccountNotDelegated $true # "sensitive, cannot be delegated"
# LDAPS check:
Test-NetConnection dc1.corp.local -Port 636
D. Firewall & Segmentation Configs
# --- Linux nftables (default-deny) ---
sudo nft add table inet filter
sudo nft 'add chain inet filter input { type filter hook input priority 0 ; policy drop ; }'
sudo nft 'add chain inet filter forward { type filter hook forward priority 0 ; policy drop ; }'
sudo nft 'add chain inet filter output { type filter hook output priority 0 ; policy accept ; }'
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input ip saddr 10.0.10.0/24 tcp dport 22 accept # scoped SSH
sudo nft add rule inet filter input tcp dport 443 accept # web
sudo nft add rule inet filter input log prefix "DROP-IN " drop # log denies
sudo nft list ruleset
# --- Linux iptables equivalent (default-deny) ---
sudo iptables -P INPUT DROP ; sudo iptables -P FORWARD DROP ; sudo iptables -P OUTPUT ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -s 10.0.10.0/24 -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -j LOG --log-prefix "DROP-IN " # log before drop (policy drops at end)
sudo iptables-save > /etc/iptables/rules.v4
# --- pfSense / OPNsense (GUI concepts for the lab) ---
- Interfaces: create WAN, LAN, DMZ, SERVER, RESTRICTED, MGMT (VLANs/physical).
- Firewall > Rules per interface: DEFAULT is deny; add EXPLICIT allow rules per zone, least-privilege:
DMZ: allow DMZ_web → APP:8080 ; block DMZ → LAN (any) [log]
LAN: allow LAN → internet 80/443 (via proxy) ; block LAN → RESTRICTED [log]
RESTRICTED: allow APP → DB:5432 only ; block all else [log]
MGMT: allow MGMT jump host → servers 22/3389 ; block any → MGMT [log]
- Enable logging on deny rules → ship to SIEM (Status > System Logs / remote syslog).
- Services > Suricata/Snort: enable IDS/IPS on interfaces (below).
- Egress: add an explicit default-deny-out with allowed destinations (egress filtering).
E. IDS/IPS — Suricata & Snort
# --- Suricata ---
sudo apt install suricata
sudo suricata-update # fetch/update rule sets (ET Open etc.)
sudo suricata -T -c /etc/suricata/suricata.yaml # test config
sudo suricata -i eth1 -c /etc/suricata/suricata.yaml # run on an interface (or IPS: -q 0 with NFQUEUE)
sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")' # watch alerts (JSON → SIEM)
# HOME_NET / EXTERNAL_NET set in suricata.yaml; enable rule files; tune to cut false positives.
# --- Example Suricata/Snort rule (defensive detection) ---
# alert on SMB connection attempts to internal hosts (tune for your env):
# alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"External SMB to internal"; flow:to_server;
# sid:1000001; rev:1;)
# alert on DNS query to a known-bad domain:
# alert dns $HOME_NET any -> any any (msg:"DNS to suspicious TLD"; dns.query; content:".xyz";
# sid:1000002; rev:1;)
# test rule syntax:
sudo suricata -T -S local.rules -l /tmp
# --- Snort 3 ---
sudo snort -c /usr/local/etc/snort/snort.lua --rule-path /usr/local/etc/snort/rules -i eth1 -A alert_fast
F. Vulnerability Management & Scanning
# --- nmap (discovery + service/version + basic vuln scripts) ---
sudo nmap -sn 10.0.0.0/24 # host discovery
sudo nmap -sS -p- --min-rate 2000 <target> # full TCP port scan
sudo nmap -sV -sC <target> # service/version + default scripts
sudo nmap --script vuln <target> # NSE vuln scripts
sudo nmap -p445 --script smb-security-mode,smb2-security-mode <target> # SMB signing posture
sudo nmap --script ssl-enum-ciphers -p443 <target> # TLS config review (weak ciphers/protocols)
# --- OpenVAS / Greenbone (authenticated vuln scanning) ---
sudo apt install openvas && sudo gvm-setup && sudo gvm-check-setup
sudo gvm-start # web UI (https://127.0.0.1:9392) → create target, add CREDENTIALS for an
# AUTHENTICATED scan (far more thorough), run the scan, review by severity (CVSS), remediate, RE-SCAN.
# --- Nessus Essentials (free tier) ---
# install, create a "Basic Network Scan", add credentials (authenticated), scan, export the report.
# --- Linux patching / verification ---
sudo apt update && sudo apt upgrade -y # (test first in change mgmt)
sudo unattended-upgrades --dry-run # automated security patching
sudo dnf updateinfo list security # RHEL security updates
# Windows: WSUS/SCCM; Get-HotFix to verify; re-scan to confirm remediation.
G. Logging, Auditing & Telemetry (generate the data)
# --- Linux: centralize syslog to the SIEM ---
# /etc/rsyslog.d/50-forward.conf : *.* @@10.0.50.10:514 (TCP to collector)
sudo systemctl restart rsyslog
sudo journalctl -u sshd -S "today" # query the journal
sudo ausearch -m execve -ts today # auditd command-execution events
# --- Windows: query & forward events ---
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:text /c:20 # recent failed logons
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624} -MaxEvents 20 |
Select TimeCreated, @{n='User';e={$_.Properties[5].Value}}, @{n='LogonType';e={$_.Properties[8].Value}}
Get-WinEvent -FilterHashtable @{LogName='Security';Id=1102} # SECURITY LOG CLEARED (alert on this!)
# Windows Event Forwarding (WEF): configure a collector (wecutil qc) + source subscription (GPO), or
# ship with Winlogbeat/Wazuh agent to the SIEM.
# --- Sysmon (rich endpoint telemetry — deploy with a good config) ---
sysmon64.exe -accepteula -i sysmonconfig.xml # install with config (e.g., SwiftOnSecurity/Olaf)
sysmon64.exe -c sysmonconfig.xml # update config
# gives EID 1 (process+cmdline+hashes), 3 (network), 10 (LSASS access), 11 (file), 13 (registry), 22 (DNS)
# → forward Microsoft-Windows-Sysmon/Operational to the SIEM.
H. SIEM / Monitoring — Wazuh & Elastic (build the pipeline, §29)
# --- Wazuh (all-in-one SIEM + HIDS + FIM + SCA + vuln detection) ---
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh && sudo bash ./wazuh-install.sh -a # single-node
# → dashboard on https://<server> ; default creds printed by the installer.
# Deploy an agent (Linux):
sudo WAZUH_MANAGER="10.0.50.10" apt install wazuh-agent -y
sudo systemctl enable --now wazuh-agent
# Agent (Windows): install MSI with WAZUH_MANAGER=10.0.50.10 ; start the service.
sudo /var/ossec/bin/agent_control -l # list connected agents
# FIM is on by default (syscheck); add watched dirs in ossec.conf <syscheck>.
# Security Configuration Assessment (CIS checks) runs automatically → view in the dashboard.
# Custom rule example (/var/ossec/etc/rules/local_rules.xml):
# <rule id="100100" level="12"><if_sid>5710</if_sid><match>Failed password</match>
# <description>SSH brute-force attempt</description></rule>
sudo /var/ossec/bin/wazuh-logtest # test a log line against rules (verify detections)
# --- Elastic (ELK) ---
# install Elasticsearch + Kibana; ship logs with Beats:
# Winlogbeat (Windows events), Filebeat (logs incl. Suricata eve.json), Auditbeat (Linux audit).
# e.g. filebeat modules enable suricata ; filebeat setup ; service filebeat start
# Build detection rules in Kibana > Security > Rules; dashboards in Kibana.
I. Detection Queries (verify & hunt — Splunk SPL / KQL / Wazuh)
# --- Splunk SPL ---
# Brute force then success:
index=win EventCode=4625 | stats count by Account_Name,src | where count>20
index=win (EventCode=4625 OR EventCode=4624) Account_Name=<u> | sort _time | table _time EventCode src
# Suspicious execution (Office→shell):
index=sysmon EventCode=1 ParentImage="*\\winword.exe" Image="*\\powershell.exe" | table _time host CommandLine
# Security log cleared:
index=win EventCode=1102 | table _time host Account_Name
# New privileged-group member:
index=win (EventCode=4728 OR EventCode=4732) Group_Name="Domain Admins" | table _time Member_Name
// --- Microsoft Sentinel / Defender KQL ---
SecurityEvent | where EventID==4625 | summarize count() by Account, IpAddress | where count_>20
DeviceProcessEvents | where InitiatingProcessFileName=="winword.exe" and FileName=="powershell.exe"
SecurityEvent | where EventID==1102 // log cleared
DeviceEvents | where ActionType=="OpenProcessApiCall" and FileName=="lsass.exe" // LSASS access
# --- Wazuh (search the dashboard / rule matches) ---
# alerts are indexed; filter by rule.level>=10, rule.groups, MITRE technique (rule.mitre.id),
# agent.name; verify a detection by triggering benign test activity and confirming the alert appears.
(KQL here is for defensive SIEM querying — Microsoft Sentinel/Defender — not the same as a DB query language.)
J. Incident Response — Triage Commands
# --- Linux live triage ---
who ; w ; last -20 # current/recent logins
ps auxf # process tree
ss -tunap # active connections + owning process
ls -la /proc/<pid>/exe /proc/<pid>/cwd # a suspicious process's binary/cwd
sudo find / -mtime -1 -type f 2>/dev/null # files changed in last day
sudo grep -i "accepted\|failed" /var/log/auth.log | tail
crontab -l ; ls -la /etc/cron* /etc/systemd/system # persistence check
# Preserve volatile evidence BEFORE power-off (memory first — order of volatility).
# --- Windows live triage ---
Get-CimInstance Win32_Process | Select ProcessId,ParentProcessId,Name,CommandLine # procs+args
Get-NetTCPConnection -State Established | Select RemoteAddress,RemotePort,OwningProcess
Get-ScheduledTask | ? State -ne 'Disabled' ; Get-CimInstance Win32_StartupCommand # persistence
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624,4672} -MaxEvents 50 # recent logons
# Sysinternals: autorunsc -a *, procexp, tcpview, sigcheck (unsigned in system dirs).
# --- Containment actions (ties to §30) ---
EDR: isolate/network-quarantine the host (one click) — preserve for investigation.
AD: Disable-ADAccount <compromised_user> ; reset credentials ; revoke sessions/tokens.
Net: firewall rule to block the C2 IP / isolate the zone.
Recover from CLEAN, tested backups; re-image where warranted; verify clean before return.
K. Cryptography / TLS / PKI (OpenSSL)
# --- Hashing & integrity ---
sha256sum file.iso # verify integrity against a published hash
openssl dgst -sha256 file.bin
# --- Password hashing (for /etc/shadow-style) ---
openssl passwd -6 'StrongPassphrase' # SHA-512 crypt
mkpasswd -m sha-512 # (whois pkg)
# --- TLS inspection / posture ---
openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
nmap --script ssl-enum-ciphers -p443 host # weak protocols/ciphers (disable TLS1.0/1.1, RC4, 3DES)
testssl.sh host # thorough TLS audit (if installed)
# --- PKI: generate a key + CSR, self-sign a CA, issue a cert ---
openssl genrsa -out server.key 2048 # (or ECC: openssl ecparam -genkey -name prime256v1)
openssl req -new -key server.key -out server.csr -subj "/CN=app.corp.local"
# Internal CA:
openssl genrsa -out ca.key 4096
openssl req -x509 -new -key ca.key -days 3650 -out ca.crt -subj "/CN=Corp Internal CA"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 365 -out server.crt
openssl verify -CAfile ca.crt server.crt # validate the chain
openssl x509 -in server.crt -noout -text # inspect the cert
# Protect ca.key (offline/HSM); monitor cert expiry; publish CRL/OCSP.
L. Network & Monitoring Utilities
tcpdump -ni eth1 'tcp port 445 or port 3389' # capture suspicious lateral-movement traffic
zeek -i eth1 # rich network logs (conn/dns/http/ssl) for monitoring
dig @<dns> suspicious-domain.tld ; whois <ip> # enrich indicators
arp -a ; ip neigh # local hosts (segmentation verification)
# Verify segmentation (from a host in the user zone — should FAIL to reach restricted):
nc -zv 10.0.40.10 5432 # expect: connection refused/timeout if the firewall isolates correctly
How to use this reference: pair each command block with the matching concept section (hardening §21/§25, firewall §22, IDS §23, IAM §16/§19, vuln mgmt §26, logging §27, SIEM/detection §28-29, IR §30, crypto §31). Run everything in your own lab (§35), and — the eEDA habit — verify: after each config, confirm the control actually does what you intended (the firewall blocks the denied flow, the account is truly removed, the hardened host passes a re-scan, the detection rule fires on benign test activity).
39. Glossary & Quick Reference
Fundamentals: CIA (Confidentiality/Integrity/Availability) · AAA (Authentication/Authorization/Accounting) · least privilege · defense in depth · zero trust (never trust, always verify; assume breach; micro-segmentation) · separation of duties · need to know · default-deny / fail-secure · secure by design/default · control categories (preventive/detective/corrective/deterrent/compensating/directive; technical/administrative/physical) · asset/threat/vulnerability/risk/exploit/control/residual risk.
Threat models: Cyber Kill Chain (7 stages) · MITRE ATT&CK (tactics & techniques; Navigator for coverage) · STRIDE (threat modeling).
Network: segmentation · zones/DMZ · VLAN/subnet · micro-segmentation · default-deny firewall · egress filtering · NAC · jump host/bastion/PAW · IDS vs IPS (detect vs block; Snort/Suricata/Zeek) · WAF.
GRC: governance/risk/compliance · NIST CSF (Identify/Protect/Detect/Respond/Recover[/Govern]) · NIST SP 800-53 (control catalog) · ISO 27001 (ISMS, PDCA) · CIS Controls (prioritized) · CIS Benchmarks (config baselines) · risk = likelihood × impact · qualitative/quantitative (SLE/ARO/ALE) · risk treatment (mitigate/transfer/avoid/accept) · risk appetite/register/residual risk · due care/due diligence · BIA → RTO/RPO/MTD · BCP vs DR · 3-2-1 backups · change management (RFC/CAB) · policy/standard/procedure/guideline/baseline · data classification.
Compliance: GDPR · HIPAA · PCI DSS · SOX · GLBA · CCPA · NIST SP 800-61 (IR) · breach notification.
IAM: authentication factors (know/have/are) · MFA (FIDO2 > authenticator > SMS) · password policy (length, breach-check, no forced rotation; salt+slow hash) · access control models (DAC/MAC/RBAC/ABAC) · AD (forest/domain/OU/GPO/DC/Kerberos) · AD hardening & tiering · LDAP/LDAPS · SSO · federation (IdP/SP) · SAML/OAuth/OIDC (authN vs authZ) · PAM (JIT, vaulting, PAW, session recording) · identity lifecycle (joiner/mover/leaver, de-provisioning) · access reviews / recertification · privilege creep.
Security Admin: hardening (least functionality; CIS Level 1/2; SCAP/CIS-CAT) · baseline / config management / drift (golden images, Ansible/GPO) · vulnerability management (authenticated vs unauthenticated scans; OpenVAS/Nessus; CVSS; risk-based prioritization; patch management; verify by re-scan) · endpoint/EDR/XDR (detect-investigate-respond; host isolation; application allow-listing; FIM) · logging (sources, Windows Event IDs, aggregation via syslog/WEF/agents, NTP, retention, integrity) · SIEM (Wazuh/ELK/Security Onion/Splunk) · detection engineering (map to ATT&CK; correlate; tune; verify fires) · alerting / alert fatigue · MTTD/MTTR.
Incident Response: NIST SP 800-61 lifecycle (Preparation → Detection & Analysis → Containment/Eradication/Recovery → Lessons Learned) · PICERL · incident vs event · containment/eradication/recovery · evidence/chain of custody · playbooks.
Crypto/Data: symmetric (AES) / asymmetric (RSA/ECC) / hashing (SHA-256; bcrypt/Argon2) / digital signatures / PKI (CA/cert/CRL-OCSP/trust chain) · data at rest/in transit/in use · DLP · data classification · secure disposal · 3-2-1 backups.
Cloud/Email/Web: shared responsibility · cloud IAM/MFA · misconfiguration (top cloud risk) · CSPM · SPF/DKIM/DMARC · secure email/web gateway · DNS filtering · WAF.
The six exam habits: read carefully · default-deny · least privilege · verify your work · think in the domains · document.
End of guide. The eEDA certifies that you can build, harden, administer, monitor, and defend a secure enterprise — hands-on. Master the fundamentals (CIA, least privilege, defense in depth, zero trust); work within GRC (frameworks, risk, change, BCP/DR); administer identity securely (AD, RBAC, MFA, clean lifecycle, PAM); and do the security administration (harden to CIS baselines, default-deny firewalls, IDS/IPS, vulnerability management, logging/SIEM/detection, incident response). Build it all in a lab, secure a full environment end to end, and — the habit that defines a defensive engineer — verify every control actually does what you intended, and document it. Default-deny, least privilege, and verify: carry those three through every task and you'll pass the exam and do the job.