The CIA triad

Each leg is examined the same way: an attack that breaks it, an everyday event that erodes it, and a countermeasure.

The supporting concepts: worth a line each if the question is worth eight marks:

• Under confidentiality: sensitivity (harm if disclosed), discretion (an operator controlling disclosure to limit damage), criticality (how mission-critical the information is), concealment (hiding: security through obscurity), secrecy, privacy (personally identifiable information), seclusion (storing something out of the way, with strict access control) and isolation (keeping things separated so information does not commingle).
• Under integrity: accuracy, truthfulness, authenticity, non-repudiation, accountability, responsibility, validity (all false information excluded), completeness (all true information included) and comprehensiveness (the entire scope collected, with any limitation documented).
• Under availability: usability, accessibility (the widest range of subjects can interact with the resource regardless of capability) and timeliness (prompt, low-latency response).
• Availability depends on the other two. Without integrity and confidentiality, availability cannot be meaningfully maintained. Data that is available but wrong is worth nothing.

Controls, mapped to the leg they serve: the answer an examiner is looking for when a question says “how would you achieve each”:

CIA priority: why OT flips the triad to AIC

• Every organisation has unique security requirements, so the importance of C, I and A differs. Deciding which matters most is essential to crafting a sufficient security solution, you cannot maximise all three at once.
• Military and government organisations tend to prioritise confidentiality above integrity and availability, a leaked plan is worse than a slow one.
• Private companies tend to prioritise availability above the other two, a shop that is down is losing money every minute.
• Operational Technology follows AIC. Even inside a private company, IT systems follow CIA but OT systems: PLCs (programmable logic controllers), SCADA and MES (manufacturing execution systems): put availability above all, and value integrity over confidentiality.
• Why: an OT system is controlling something physical. A turbine, a pump, a production line. Stopping it is a safety and production event; the setpoints it is executing are rarely secret, but a wrong setpoint is dangerous. Hence A > I > C.
• The Maroochy Shire case makes the point: a former contractor used a stolen laptop and radio equipment to access the SCADA system controlling sewage pumps, releasing over 800,000 litres of raw sewage into rivers, parks and a hotel's grounds. Nothing confidential leaked, the damage was entirely to availability and physical integrity.

The CNSS security model (McCumber cube)

• CNSS is the Committee on National Security Systems. Its model shows the three dimensions central to any discussion of InfoSec, drawn as a 3×3×3 cube.
• Dimension 1: security goals (information characteristics): confidentiality, integrity, availability.
• Dimension 2: information states (location): storage, transmission, processing.
• Dimension 3: security control categories: technology, policy and practices, people (education, training and awareness).
• The purpose of the model is to identify gaps in the coverage of an InfoSec programme. Each of the 27 cells is a question: “how do we protect the integrity of data while it is being processed?” An empty cell is an uncovered risk.

Worked cells: the concrete controls the deck puts in the grid:

The risk vocabulary: assets, threats, vulnerabilities

These definitions get quoted back verbatim in answers all through the paper. Learn them in this order, because each one builds on the last.

• Attack surface: all the vulnerabilities or weaknesses in the security controls that an attacker could exploit. Attack vectors are the routes threat actors use to gain unauthorised access. Attacks are prolific because the attack surface keeps growing: IoT and smart devices, mobile, home networks, data centres, the supply chain.
• Actors posing risk to a business: cyber criminals after money or saleable data; industrial competitors and foreign state actors seeking economic advantage; APTs gathering military and national intelligence; hackers who find it an enjoyable challenge; hacktivists with political or ideological motives; and employees or others with legitimate access, whether by accident or deliberate misuse.

Risk management: the process, and Sun Tzu

The Sun Tzu framing, which the deck leans on and which makes a tidy opening paragraph:

• “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither, you will succumb in every battle.”
• Know yourself: identify, examine and understand your valuable information assets and how each is protected while being processed, stored and transmitted. A database security administrator asks: what type of data is stored, where are the servers, what DBMS is it.
• Know the enemy: identify, examine and understand the threats facing those assets. For a web application that means XSS, SQL injection, DoS, CSRF/XSRF, and so on.
• All three communities of interest must take part: InfoSec, IT, and the business/non-technical side. Together they locate operational weaknesses, understand how information is processed, stored and transmitted, and identify what resources are available. Only then can a strategic plan of defence be developed.
• Risk management is not install-and-forget. It is a process of creating safeguards and controls that are then reviewed.

Risk identification, the five steps

Risk identification begins with self-examination. Managers identify the information assets, classify them into useful groups, and prioritise them by overall importance.

1. Create an inventory of information assets: people, procedures, data and information, software, hardware, networking elements. Do this without prejudging the value of anything; value is assigned later.
2. Classify and organise those assets meaningfully: into the six categories above, reflecting sensitivity and security priority. A classification scheme must be comprehensive (every inventoried asset fits a category) and mutually exclusive (each asset sits in exactly one).
3. Assign a value to each asset: a relative, comparative judgement so the most valuable get the highest priority.
4. Identify threats to the catalogued assets: threat identification, then threat assessment.
5. Pinpoint vulnerable assets by tying specific threats to specific assets.

Attributes to record, by asset type:

Assigning value, the questions to ask. Which asset is most critical to the organisation's success? Which generates the most revenue? The highest profitability? Which is most expensive to replace? Most expensive to protect? Whose loss or compromise would be most embarrassing or create the greatest liability?

• Weighted factor analysis is the final step: score each asset against each criterion, multiply by the criterion's weight, and sum to a single figure. That produces the ranked list separating critical from non-critical assets.
• Threat assessment criteria: which threat represents the most danger, judged on the probability of it attacking, the frequency with which it can occur, the amount of damage it could create, the cost to recover, and which threats need the greatest expenditure to prevent.
• The TVA worksheet combines the two lists: assets with their vulnerabilities down one axis, prioritised threats across the other. Each cell is a threat to vulnerability pair to be assessed. This is the deliverable that feeds risk assessment.

Risk assessment, the risk determination formula

• Likelihood: an overall rating, often on a defined numerical scale such as 0.1 to 1.0, of the probability that a specific vulnerability will be exploited.
• Asset value: a weighted score from the risk identification stage (1 to 100, or low/medium/high).
• Percentage mitigated by current controls: if a vulnerability is fully managed by an existing control it can be set aside; if partially controlled, estimate the fraction handled.
• Uncertainty: you cannot know everything about every vulnerability, and the degree to which a control reduces risk is itself an estimate. Uncertainty is a manager's judgement from experience. If assumptions are 90% accurate, uncertainty is 10%.

Quantitative risk analysis: AV, EF, SLE, ARO, ALE

This is the case-study question and the stated assignment. Learn the five formulas cold; they are almost free marks if you show the working.

Quantitative versus qualitative: the comparison question:

Most real programmes are hybrid: qualitative screening to find the handful of risks worth the effort, then quantitative analysis on those.

Selecting security controls: purpose × mechanism

Controls are classified twice over, and a good answer gives both axes with an example in each cell.

By purpose, what the control is trying to do:

• Preventive: stops a security issue from occurring. Firewall rule, MFA, encryption, locked door.
• Deterrent: discourages a policy violation. Warning banner, visible CCTV, published sanctions.
• Detective: identifies issues requiring investigation. IDS, log review, SIEM alert, audit.
• Corrective: modifies the environment to return systems to normal after unwanted activity, or stops an attack in progress. Quarantining a file, terminating a session, applying a patch.
• Recovery: remediates issues that have already occurred. Restoring from backup, failing over to a DR site.
• Compensating: an alternative when the primary control is not feasible; must give equivalent protection.

By mechanism, how it is implemented:

• Technical (logical): uses technology to achieve the objective: ACLs, encryption, IPS, MFA.
• Administrative (managerial): uses process: policies, background checks, awareness training, separation of duties.
• Physical: impacts the physical world: fences, guards, locks, mantraps, fire suppression.

The three broad categories the deck names for identifying possible controls are policies (the general approach to handling a threat), programs (activities the organisation performs to improve security) and technical controls (hardware or software mechanisms managing access and protecting resources).

Risk treatment, the four responses

• Acceptance must be documented and owned. Silent acceptance: nobody decided, it just never got fixed: is negligence, not treatment.
• Residual risk is what remains after treatment. There is always some; the question is whether it is below the organisation's stated appetite.
• Transference does not transfer accountability. Insurance pays for the loss; the regulator and your customers still come to you.

NIST RMF, and “you can't boil the ocean”

Why the statement is true, in risk-management terms:

• The asset inventory of any real organisation runs to thousands of items, and the TVA worksheet pairs every one against every plausible threat. If you assume every threat can and will attack every asset, the project scope becomes too complex to finish, which is exactly why the deck manages threat identification and vulnerability identification separately and only coordinates them at the end.
• Risk can only be reduced to an acceptable level, never to zero, so past a certain point extra spend buys almost nothing.
• Hence weighted factor analysis, the ranked vulnerability risk worksheet, and the whole apparatus of ordering risks. The ordering is the deliverable.

The NIST Risk Management Framework (SP 800-37) is the formal version of that idea, seven steps that force prioritisation before spending:

1. Prepare: set context: roles, risk appetite, organisation-wide strategy, and the assessment approach. This is where “what are we not going to do” gets decided.
2. Categorise: classify the system and the information it processes by the impact of losing confidentiality, integrity or availability. This is the step that stops you boiling the ocean: a low-impact system does not get high-impact controls.
3. Select: choose the control baseline matching that categorisation, then tailor it: add, remove or substitute controls for this system's actual risk.
4. Implement: deploy the controls and document how they were implemented.
5. Assess: test whether the controls are implemented correctly, operating as intended and producing the desired outcome.
6. Authorise: a senior official formally accepts the residual risk and permits the system to operate. An explicit, accountable acceptance decision.
7. Monitor: continuously watch control effectiveness, changes to the system and the threat environment, and feed changes back into the cycle.

Policies, standards, baselines, guidelines and procedures

The single most reusable list in the course, it is asked here and again in Chapter 7.

• Policies are the least expensive means of control and often the most difficult to implement. They cost only the management time to create, approve and communicate them, plus the employee time to integrate them into daily work: trivial next to technical controls, even with an outside consultant. But they are frequently impracticable, lack commitment, or do not match the organisation's objectives, because they depend on people changing behaviour.
• The basic rules for shaping a policy: never conflict with law; stand up in court; be properly supported and administered; contribute to the success of the organisation; involve the end users of the information systems.
• Example policies you should be able to name: Acceptable Use Policy, Data Breach Response Policy, Disaster Recovery Plan, Business Continuity Plan, Remote Access Policy, Access Control Policy.

Chapter 7 takes this further into the NIST SP 800-14 three tiers: EISP, ISSP and SysSP, and into what makes a policy legally enforceable. If a question asks about policy for eight marks, cover both this hierarchy and those tiers.

Case study: the dormant account nobody closed

The scenario. A former Vice President of Technology, terminated three years earlier, remotely accessed his old employer’s internal email system. His old credentials still worked. He read executive and HR mail for over five months, focusing on discussions about employee terminations, then used an anonymous webmail account to warn two employees they were about to be fired.

(a) What happened, and how did the organisation suffer.

• Financial loss: over $100,000 spent investigating the breach.
• Operational disruption and loss of confidentiality: the two warned employees reported the leak to their supervisors, exposing private executive-level communications and forcing an internal scramble.

(b) The factors that led to it. A failure of basic policy and procedure, not of technology:

• No offboarding process. The leaver’s accounts and credentials were never deactivated or revoked on termination. This is the root cause.
• No password management. User IDs and passwords remained virtually unchanged over three years, so old credentials stayed valid indefinitely.
• No access audits. A dormant account belonging to a terminated employee logged in remotely for five months and nobody reviewed active accounts or watched remote access logs.

(c) What should have been done.

• Implement an offboarding policy: a formal, mandatory procedure that terminates all system access (email, network, remote access) the moment employment ends.
• Enforce password management: a strong password policy with rotation at regular intervals for all users, privileged accounts especially.
• Conduct regular access audits: periodic review of every user account to find and disable stale, orphaned or unauthorised ones. A review would have flagged a terminated VP’s account immediately.
• Monitor remote access logs: a three-year dormant account suddenly logging in is exactly the anomaly monitoring exists to catch. Detection would have taken minutes, not five months.

The examinable point: every control that would have stopped this is administrative, not technical. It is the cheapest category of control, and the one this organisation skipped.

Password attacks

All four are brute force in the broad sense: they gain access to accounts when passwords are unknown, or when password hashes have been obtained. What differs is how they spread the attempts, and that is chosen to dodge lockout.

Defence, in order of effect: phishing-resistant MFA, which makes a correct password insufficient; blocking known-breached and common passwords rather than forcing complexity rules; lockout or progressive delay tuned so it stops guessing without enabling a lockout DoS; detection rules built on the signals in the table above; and salted, slow password hashing so a stolen database resists dictionary attack.

Cross-site scripting: reflected, stored and DOM based

The comparison question turns on two things: where the payload lives, and how execution is reached.

Across all three: set session cookies HttpOnly so stolen script cannot read them, and Secure plus SameSite so they are not leaked or replayed. This limits the payoff even when injection succeeds.

Cross-site request forgery (XSRF or CSRF)

• The trust relationship is the whole point. XSS exploits the trust a user has in a website to execute code on the user computer. XSRF exploits the trust a remote site has in a user system to execute commands on the user behalf.
• How it works. It makes the reasonable assumption that users are often logged into many different websites at the same time. The attacker embeds code in one website that sends a command to a second website. When the user clicks the link on the first site, they are unknowingly sending a command to the second, and if they happen to be logged in there, the command may succeed.
• The banking example. An attacker wanting to steal funds posts a link on an online forum. The link is actually a request to the money transfer site issuing a transfer to the attacker account. The attacker leaves it posted and waits for a logged-in user to click.

Ways to protect against XSRF, which is asked as a question on its own:

1. Anti-CSRF tokens. Create web applications that use secure tokens the attacker would not know to embed in the links. A unique, unpredictable, per-session or per-request token is placed in the form and validated server side. This is the primary defence.
2. Check the referring URL. Only accept requests that originated from your own site, by validating the Referer or Origin header.
3. SameSite cookies. Set session cookies to SameSite=Lax or Strict so the browser does not attach them to cross-site requests at all, which removes the ambient authority the attack depends on.
4. Use the right HTTP method. Never allow state-changing actions over GET, so a plain link or image tag cannot trigger them.
5. Re-authenticate or step up for sensitive actions. Require the password, an MFA prompt or a confirmation step for transfers, password changes and email changes.
6. Short sessions and explicit logout, which shrink the window in which the user is logged in and therefore exploitable.

SQL injection

• What it is. Like XSS, SQL injection sends unexpected input to a web application. But instead of using that input to fool a user, it uses it to gain unauthorised access to the underlying database. The input breaks out of the data context and is executed as part of the SQL statement.
• Why it is riskier than XSS from the organisation point of view. A successful XSS compromises the sessions of users who visit a page. A successful SQL injection can read, modify or destroy the entire database at once, which is every user rather than one, and it happens server side where the crown jewels are.

Protecting against SQL injection, in the deck order:

1. Use prepared statements. Prepared statements, including parameterised queries and stored procedures, store the SQL statement on the database server where only DBAs and authorised developers can modify it. The application may pass parameters to it but cannot alter the underlying structure of the statement, so injected text can never become code. This is the real fix.
2. Perform input validation. Allow-list the expected type, length, format and range on every parameter. A supporting control, not a substitute for the first.
3. Limit account privileges. The application database account should hold the minimum rights it needs. If it cannot DROP, an injection cannot DROP either. This limits blast radius rather than preventing the flaw.

Reconnaissance attacks

Reconnaissance lets an attacker find weak points to target directly with their attack code. Tool developers have automated it, and the three stages run in strict order, each narrowing the target set:

1. IP probes, also called IP sweeps or ping sweeps, are usually the first reconnaissance carried out against a targeted network. Output: a list of live hosts. Nmap is the most common tool for both this and port scanning.
2. Port scans. With a list of active systems in hand, the attacker probes them to determine what public services are running on each machine. Web servers, file servers and other servers supporting critical operations are prime targets.
3. Vulnerability scans. Having picked a specific system, the attacker needs a specific vulnerability that can be exploited to gain the desired access permissions. Popular tools: Nessus, OpenVAS, Qualys, Core Impact, Nexpose. These are the same tools defenders run in Chapter 7, which is the point: the difference is authorisation, not technique.

Masquerading attacks: IP spoofing and session hijacking

IP spoofing. The attacker reconfigures their system so it carries the IP address of a trusted system, then attempts to reach other external resources. This is surprisingly effective on networks without adequate filtering. Administrators should configure filters at the perimeter of each network so that:

• Packets with internal source IP addresses do not enter the network from outside.
• Packets with external source IP addresses do not exit the network from inside.
• Packets with private IP addresses do not pass through the router in either direction, unless specifically allowed as part of an intranet configuration.

These three simple filtering rules eliminate the vast majority of IP spoofing attacks and greatly enhance network security.

Session hijacking. A malicious individual intercepts part of the communication between an authorised user and a resource, then takes over the session and assumes that user identity. Common techniques:

• Capturing the authentication details exchanged between client and server, then using them to assume the client identity.
• Tricking the client into thinking the attacker system is the server, acting as the middleman while the client sets up a legitimate connection to the real server, then disconnecting the client.
• Reusing cookie data from a user who did not properly close the connection.

Defence. Encrypt everything in transit so tokens cannot be captured; regenerate the session identifier on privilege change and at login; set cookies HttpOnly, Secure and SameSite; bind sessions to additional context; enforce idle and absolute timeouts; and log out properly.

The four critical web application vulnerabilities, side by side

An asked question wants all four in one answer. Give the one-line mechanism, the trust that is abused, and the impact, then finish with shared best practice.

Best practices that raise resilience against all four:

1. Validate input, encode output. Allow-list what comes in; encode for the exact context it goes out into (HTML, attribute, JavaScript, URL, SQL). The two halves fix different problems and you need both.
2. Never build code by string concatenation. Prepared statements and parameterised queries for SQL; safe DOM APIs and templating with automatic escaping for HTML.
3. Enforce anti-CSRF tokens and SameSite cookies on every state-changing endpoint, and never allow state change over GET.
4. Harden the session: HttpOnly, Secure, SameSite, regeneration at login, idle and absolute timeouts.
5. Apply least privilege to the application database account and the service account, so a successful attack has the smallest possible blast radius.
6. Use memory-safe languages or safe APIs where buffer overflow is possible, plus compiler protections: stack canaries, ASLR, DEP, bounds checking.
7. Add a Content Security Policy that blocks inline script, which turns most XSS from a compromise into a blocked console error.
8. Test continuously: SAST and DAST in the pipeline, dependency and supply-chain scanning, a WAF as compensating control, and periodic penetration testing.
9. Handle errors quietly. Verbose database and stack-trace errors hand the attacker the map, as the Chapter 7 DREAD example shows.
10. Train the developers. Every one of these four is a known, solved class of bug; they recur because the people writing the code were never shown them.

The threat intelligence lifecycle

A continuous loop, not a one-time process. Raw data enters at collection, finished intelligence exits at dissemination, and feedback refines the requirements that drive the next cycle. Each phase depends on the quality of the one before it.

Worked example of phase 1: a bank CISO defines three PIRs before a digital banking rollout. Which threat actors target mobile banking infrastructure? What are current attack trends against fintech APIs? What fraud techniques are emerging in our region? Everything downstream is scoped by those three questions.

PASTA: Process for Attack Simulation and Threat Analysis

Unlike DREAD, which is a scoring rubric, PASTA is a full seven-stage methodology that is risk-centric and business-aware. It is the one to cite when a question asks for a complete process rather than a checklist.

1. Define objectives. Understand business goals, compliance requirements and risk appetite.
2. Define technical scope. Map the technical environment: infrastructure, applications, dependencies, data flows.
3. Application decomposition. Break the application into components: data flows, trust boundaries, entry points, assets.
4. Threat analysis. Identify realistic threats using threat intelligence, attacker profiles and historical data. This is where MITRE ATT&CK plugs in.
5. Vulnerability and weakness analysis. Correlate known vulnerabilities, CVEs and code weaknesses with the threats identified.
6. Attack modelling and simulation. Build attack trees and simulate how an attacker would chain vulnerabilities together to reach a goal.
7. Risk and impact analysis. Quantify the business impact of successful attacks and prioritise countermeasures accordingly.

The Cyber Kill Chain

• Developed by Lockheed Martin. It models the sequential stages an adversary must complete to execute an attack successfully, and gives defenders a structured map of where to detect, disrupt or respond at each stage.
• Seven stages, and the defensive value is that breaking any one link breaks the chain. The earlier you break it, the cheaper the incident.

The hunter toolkit

SIEM querying, using the pipe-based query language of a platform such as Logpoint or GuardSix. Core syntax: label= or category= filters events by type, | chains commands, chart count() by field aggregates and groups, and order by count() desc sorts.

Notice the pivot pattern: each query output becomes the next query filter, file hash to user to IP to C2 category. That is hypothesis-driven hunting in action, and it is the Diamond Model pivot expressed as queries.

YARA matches malware by content and structure rather than by hash. Hashes break on the tiniest file change; YARA rules survive minor variants. A rule has three parts: meta (author, description), strings (the patterns to match) and condition (logic combining them).

osquery treats every endpoint like a queryable SQL database. You ask questions about running processes, open ports, installed software and scheduled tasks across the whole fleet using familiar SQL. Commonly hunted tables: processes, listening_ports, startup_items, scheduled_tasks, logged_in_users, installed programs.

That single query finds every host where Microsoft Word spawned PowerShell, the classic malicious-macro pattern, and it is the same hypothesis as ATT&CK T1059.

A threat hunting playbook is a documented, repeatable hunt procedure rather than a one-off search. Six parts: 1 the hypothesis, what are we testing; 2 the ATT&CK technique it maps to; 3 the data sources required; 4 the query or steps, the reusable procedure itself; 5 expected findings, what normal versus suspicious looks like; 6 the escalation path, who to notify if confirmed.

A hunt report serves two audiences from one investigation. The technical hunt report for the SOC and IR team carries full methodology, queries used, raw findings and IoCs, and technical remediation steps. The executive summary for leadership carries business impact, risk level, plain-language findings and resourcing implications. A good report has six sections: hypothesis and scope; methodology (tools, data sources, queries); findings confirmed or denied with evidence; impact assessment; remediation actions taken or recommended; and lessons learned feeding playbook updates.

SIEM: Security Information and Event Management

• Why it emerged. Manual log review could not keep pace once organisations ran hundreds of systems generating millions of events a day.
• What it solves. It gives a single, searchable view across firewalls, endpoints, identity and applications, and turns raw log volume into a manageable number of prioritised alerts.
• Common features: search, dashboards, reporting, alerting, incident and case management, and threat investigation.
• In this course the reference implementation is GuardSix or Logpoint, built on its own indexing engine with a fast pipe-based query language for pivoting across massive log volumes during a hunt. The query examples in Chapter 3 are that language.
• Its limitation, which sets up SOAR. A SIEM tells you something happened. It does not do anything about it, and it generates far more alerts than a human team can work through.

SOAR: Security Orchestration, Automation and Response

• Why it emerged. SIEMs began generating more alerts than analysts could triage manually. SOAR closed that gap. It exists because the previous tool worked too well.
• What it solves. It cuts mean time to respond by automating containment: disabling accounts, blocking IPs, isolating hosts. And it gives every investigation structured case management instead of scattered email threads.
• Three words in the name, three jobs. Orchestration connects the tools so one action can drive many systems. Automation executes the repetitive steps without a human. Response is the containment and remediation itself.
• In practice pre-built playbooks trigger directly off SIEM correlation rules, so a credential-compromise flow can run end to end with no analyst click.

UEBA: User and Entity Behaviour Analytics

• Why it emerged. Compromised credentials and insider threats look like normal activity to rule-based detection. There is no signature for a valid user doing valid things at the wrong time, so a SIEM rule cannot express the problem.
• What it solves. It surfaces unusual login times, data access volumes and lateral movement that rules alone miss, and it detects malicious insiders acting entirely within their own legitimate permissions. That last case is invisible to every other tool on this page.
• How it scores. Every entity is scored against its peer group in real time, so a finance user is compared with other finance users rather than with an absolute threshold.
• The catch: it needs a period of learning before it is useful, and an anomaly is not the same as an attack. Its output is a starting point for investigation, which is why it pairs with analytics-driven hunting in Chapter 3.

EDR: Endpoint Detection and Response

• Why it emerged. Signature-based antivirus could not catch fileless malware or living-off-the-land attacker techniques. When the attacker uses PowerShell, there is no malicious file for a scanner to find.
• What it solves. It reconstructs the full process tree behind an attack for fast, accurate investigation, and it lets an analyst isolate a compromised host from the network in seconds rather than hours.
• Antivirus compared with EDR. Antivirus asks is this file known bad and blocks it. EDR asks is this behaviour normal, records everything so the answer can be revisited later, and gives the analyst an action to take. Detection plus telemetry plus response, rather than detection alone.
• Its limitation, which sets up XDR. It sees the endpoint and only the endpoint. An attack that crosses email, identity, network and cloud shows up as four unrelated fragments.

XDR: Extended Detection and Response

• Why it emerged. EDR, network detection, email and cloud tools ran as disconnected silos with no shared context. Each was individually correct and collectively useless.
• What it solves. It reduces the number of consoles an analyst must pivot between mid-investigation, and it catches multi-stage attacks that span several layers before any single tool sees the full picture.
• In practice an XDR incident auto-correlates four separate signals into one prioritised case in under two minutes, and the isolate-host action runs directly from the detection with no console switching.
• XDR compared with SIEM, since this is the distinction most often muddled. A SIEM is vendor-neutral and log-centric: it ingests anything, stores it for years, and you write the correlation rules. XDR is telemetry-centric and mostly single-vendor: correlation is built in and pre-tuned across that vendor sensors, so it works out of the box but only across what it integrates with. Compliance and retention pull you toward SIEM; speed of detection pulls you toward XDR. Most organisations run both.

All five compared, and how they enhance posture together

This is the asked question. Give the table, then the integration story, then the posture benefits.

How this enhances the organisation security posture, the closing paragraph:

• Coverage. Together the five cover logs, identity, endpoint, network and cloud, so there is no layer where an attacker can operate unobserved.
• Detection of the unknown. UEBA, NDR and EDR are behavioural, so they catch what has no signature: fileless malware, insiders, stolen credentials, novel campaigns.
• Speed. XDR removes the console-switching that dominates investigation time, and SOAR removes the human from the repetitive containment steps. Both attack dwell time, which is the number that determines how bad an incident becomes.
• Consistency. Playbooks mean the response at 3am on a Sunday matches the response at 2pm on a Tuesday.
• Analyst leverage. Automating triage and containment frees skilled people to do the threat hunting in Chapter 3, which is where the unknown-unknowns are found.
• Compliance and forensics. The SIEM archive provides the retained, searchable evidence that audits in Chapter 7 depend on, and that post-incident analysis needs.

What a Security Policy Framework is

• Written instructions from management on the proper, secure use of information and assets.
• Provides structure and expresses the will of management in controlling behaviour.
• Creates a productive work environment, free of unnecessary distraction and misuse.
• Is the essential foundation of an effective InfoSec programme, and the reference point for audits and legal disputes.
• The paradox to quote: policy is the least expensive control, costing only the time to write, approve and communicate it, a fraction of what technical controls cost. Yet it is often the hardest to implement, because it depends on people changing behaviour.

The policy hierarchy

From high-level intent down to step-by-step action. Each layer supports the one above, and the mandatory or recommended column is where marks are won or lost.

The trap: the hierarchy runs broader and more general at the top, more specific and technical at the bottom, but guideline is the only recommended layer. Procedures sit at the bottom and are still mandatory. Getting that right is usually worth a mark on its own.

What makes a policy effective and enforceable

Five basic rules for shaping a policy. It must:

• Never conflict with law.
• Stand up in court if challenged.
• Be properly supported and administered.
• Contribute to the success of the organisation.
• Involve the end users of the information systems.

Six conditions for enforceability. A policy is only enforceable if it is:

1. Developed using industry-accepted practices
2. Distributed by all appropriate methods
3. Read by all employees
4. Understood by all employees
5. Formally agreed to by act or affirmation
6. Uniformly applied and enforced

Why the last one matters most: a policy enforced selectively is worse than no policy, because inconsistent enforcement is precisely what a dismissed employee argues in a tribunal. Uniform application is what makes the document survive a legal challenge.

NIST SP 800-14: EISP, ISSP and SysSP

Every information security policy fits into one of three categories. This is the most frequently asked structure in the chapter.

EISP in detail. It sets the strategic direction, scope and tone for all of the organisation security efforts; it is an executive-level document owned by senior management or the CISO; it assigns responsibilities for the various areas of information security; and it guides development, implementation and management of the security programme. Its components:

• An overview of the corporate philosophy on security
• The structure of the InfoSec organisation and who fills each role
• Shared responsibilities for everyone: employees, contractors, consultants, partners, visitors
• Role-unique responsibilities specific to each function, for example HR versus Marketing

ISSP in detail. It provides detailed, targeted guidance instructing staff in the secure use of a technology; it protects both employee and organisation from inefficiency and ambiguity; and it indemnifies the organisation against liability for an employee misuse. It is deliberately generic on vendors, for example remote access only via a company VPN without naming a product, so vendors can change without a rewrite.

• Common ISSP topics: email, internet and web use, BYOD, home use of equipment, personal devices on the network, anti-malware configuration, and a no-hacking or no-testing-of-controls rule.
• What a complete ISSP contains: statement of policy (scope, applicability, technology addressed, responsibilities); authorised access and usage (fair use, privacy); prohibited use (misuse, criminal, harassing, IP violations); systems management (monitoring, encryption, virus protection); violations of policy (reporting procedures and penalties); policy review and modification; and limitations of liability.

SysSP in detail. Focused on a single system, a firewall, a web server, even one computer. It has two parts, and the distinction between them is a published question:

Why both halves are needed: without the management guidance an administrator may configure the firewall as they see fit, possibly against the organisation intent, and nobody can later say the configuration was wrong. The two are often combined into a single document, and SysSPs frequently function as standards or procedures.

What an audit is, and why it is an assurance engagement

• Reasonable assurance, not full assurance. This is the phrase the question wants. Because audits rely on sampling, they reduce risk to an acceptable level rather than eliminating it. An auditor examines a sample of transactions or configurations and concludes about the whole; that inference is strong but never certain. Discrepancies and findings are reported to the Audit Committee.
• Scope of an IT security audit. It assesses the security of the networked infrastructure: systems, networks, operating systems and applications. It is performed by someone with technical and business knowledge of the IT estate. Auditors interview key staff, run vulnerability assessments and penetration tests, and catalogue existing controls. The goal is to confirm compliance, confirm assets are protected, and recommend improved controls.
• Auditing subject areas: applications (ERP, email, scheduling, what users see), databases (which organise and serve the data), system platforms (the operating environments), networks (firewalls, switches, routers) and data-centre facilities (the physical building and racks).

The IT audit process: six phases

A repeatable cycle from planning through to tracking issues to closure.

1. Planning. Define objectives, scope, risk and controls; build checklists; schedule the work; hold the kick-off meeting.
2. Fieldwork and documentation. Run the checklist, gather data and conduct interviews, record findings in working papers.
3. Issue discovery and validation. List potential concerns and validate them with the client before reporting, in good time. Validating first is what stops the report carrying findings that turn out to be misunderstandings.
4. Solution development. Agree an action plan, via a recommendation, a management response, or a jointly agreed solution.
5. Report drafting and issuance. Scope, executive summary, issues and action plans, conclusion. Then distribute.
6. Issue tracking. Follow up to closure, escalate as a last resort, and validate the fix. Without this phase the whole audit is advisory.

Regulation, standard and framework: three different things

GDPR, HIPAA and SOC 2 at a glance

SOC 2 Type I versus Type II, worth knowing because it is the difference between design and reality. Type I attests that controls are suitably designed at a point in time. Type II attests that they operated effectively over a period, typically 6 to 12 months. Customers ask for Type II.

Three ways to assess security

They overlap, but each answers a different question, and depth increases as you go down.

The rule of thumb to quote: a vulnerability assessment tells you the doors are unlocked; a penetration test walks through them and shows what is behind.

The assessment lifecycle. Whatever the depth, a disciplined assessment follows the same repeatable path:

1. Scope and plan. Agree targets, rules of engagement, timing and authorisation.
2. Discover. Enumerate assets, services and the attack surface.
3. Analyse. Identify and rank weaknesses, remove false positives.
4. Report. Communicate findings, risk ratings and recommendations.
5. Remediate. Owners fix the issues per the agreed action plan.
6. Verify. Re-test to confirm the fix, then repeat the cycle.

Vulnerability scanning

• What it does. Software compares systems against a database of known vulnerabilities (CVEs) and misconfigurations.
• Broad, fast and repeatable, which makes it ideal to run frequently and on a schedule.
• Output: a prioritised list of findings, usually scored by severity.
• It does not exploit, so expect false positives that a human must validate. This is the trade for safety and speed.
• Common types: network, host, web-application, database and cloud-config scans.
• Authenticated versus unauthenticated. A credentialed scan logs in and reads actual patch levels, so it is far more accurate. An unauthenticated scan sees only what an outsider sees, which is a different and also useful question.
• Tools: Nessus, OpenVAS, Qualys, Nexpose.

Scan cadence: continuously or weekly for critical external assets; monthly for internal infrastructure; after every significant change or new deployment; and quarterly ASV scans, which are required by PCI-DSS.

Penetration testing

How much does the tester know?

Common engagement targets: external network, internal network, web application, wireless, social engineering, physical, cloud, and mobile or API.

Six phases, a structured methodology following PTES and mirroring the attacker kill chain:

1. Reconnaissance. Gather information: OSINT, footprinting, passive and active recon.
2. Scanning and enumeration. Map live hosts, open ports, services and versions.
3. Gaining access. Exploit a weakness to get an initial foothold.
4. Maintaining access. Escalate privilege, move laterally, establish persistence.
5. Covering tracks. Understand how an attacker would evade detection. In an authorised test this is documented rather than actually done, so the client can measure their own detection capability.
6. Analysis and reporting. Document the path, the impact and the evidence, and recommend fixes.

Vulnerability scan versus penetration test. Complementary rather than competing. Most programmes need both:

Anatomy of a findings report

A good report speaks to executives and engineers in the same document, which is why it has six parts rather than one.

Scoring and prioritising risk

You cannot fix everything at once, so severity plus context decides what goes first.

Severity is not the whole story. Prioritise with context: asset value and exposure, exploitability and threat intelligence, existing compensating controls, and business impact.

The line to quote: a medium on an internet-facing crown-jewel system can outrank a high on an isolated test box. CVSS scores the vulnerability; only you can score the asset.

Remediation, tracking and re-test

Three ways to agree an action plan, in increasing order of how likely the fix is to happen:

1. Recommendation. The auditor recommends a fix, but it may not be acted on. Weakest, because nobody is obliged to respond.
2. Management response. The auditor reports the issue and management must formally respond, accepting, rejecting or scheduling it. This creates an accountable record.
3. Solution. Client and auditor mutually agree the action plan. Most effective, because the people who have to do the work have already committed to it.

Issue tracking, until every finding is resolved: assign an owner and a due date, track to closure, escalate as a last resort, then re-test and validate.