Security Engineering / Fundamentals / Architecture concepts

Fundamental 10

Architecture
concepts CASB, SWG, ZTNA, SASE, SSE, DLP, EDR, XDR, SIEM, SOAR. These are categories of control, not products. Netskope sells you three of them in one console; SentinelOne sells another. Learn the categories and you can evaluate any vendor, read any analyst report, and spot when a renewal is buying you something you already own.

vocabulary layerread before the tools shelf

Tier 0 · Groundthe frame

Two questions organise everything

For any control, ask: where does it sit (endpoint, network, identity, application, data) and when does it act (before, during, or after the event). Every acronym below is one cell in that grid.

Module 0.1

The control grid

Where each category lives

Category	Sits at	Acts	Core question it answers
SWG	Network (inline proxy)	During	Should this user reach this website?
CASB	Network + SaaS API	During & after	What is happening inside our SaaS?
ZTNA	Broker between user and app	Before & during	May this identity+device reach this private app?
DLP	Anywhere data moves	During	Is sensitive data leaving?
EDR/XDR	Endpoint agent	During & after	What is this process doing, and can I undo it?
SIEM	Central log platform	After (near-real-time)	What does everything together tell me?
SOAR	Workflow layer over SIEM	After	How do we respond consistently and fast?
IdP + CA	Identity	Before	Who is this, on what device, and should they in?
CSPM/CNAPP	Cloud control plane	Continuous	Is the cloud configured safely?
Email security	Mail flow or mail API	Before & after delivery	Is this message what it claims to be?

Vendor translation: Netskope = SWG + CASB + DLP + ZTNA (an SSE platform). SentinelOne = EDR/XDR. Google SecOps = SIEM + SOAR. Abnormal = email security, API-delivered. Nothing in that list overlaps by accident; overlaps that do exist (DLP in Netskope vs DLP in Workspace) need a deliberate decision about which is authoritative.

Tier 1 · Mechanicsdefinitions with teeth

The categories, properly

Module 1.1

SWG — Secure Web Gateway

The descendant of the office web proxy

A forward proxy for outbound web traffic. Classic functions: URL categorisation and blocking, malware scanning, file-type control, SSL/TLS inspection, bandwidth control, and per-user logging.

What changed: the appliance in the office became a cloud service, because users left the office. That is the whole "cloud SWG" pitch — same control, delivered from provider POPs near the user rather than by backhauling traffic to headquarters.

Strength: universal — covers any web destination, including ones you have never heard of.
Limit: only sees what it can decrypt and what is steered through it. Categorisation of new domains lags.

Module 1.2

CASB — Cloud Access Security Broker

Four modes, and the one that actually matters

A CASB understands SaaS applications rather than just websites. It knows that a POST to a particular URL means "shared a file externally" and that a given login belongs to a personal rather than corporate tenant.

Mode	How	Sees	Trade-off
Inline forward proxy	Agent/tunnel steers traffic	Real-time activity, can block	Managed devices only
Inline reverse proxy	IdP redirects sessions	Unmanaged/BYOD to SSO apps	Sanctioned apps only; breakage risk
API (out-of-band)	OAuth into the SaaS tenant	Data at rest, sharing, config, past events	Not preventive; minutes-delayed
Log analysis (shadow IT)	Ingest firewall/proxy logs	Which apps are in use at all	Discovery only

App instance awareness is the capability that justifies a CASB over a plain SWG: distinguishing drive.google.com belonging to your tenant from a personal Google account, and allowing one while blocking uploads to the other. A URL filter fundamentally cannot do this.

In this stack: Netskope provides all four modes. The API mode against Google Workspace is what finds a file that was already shared publicly last Tuesday — the inline proxy can never tell you that.

Module 1.3

ZTNA — Zero Trust Network Access

Why it replaces VPN rather than competing with it

VPN: user ──▶ [ tunnel ] ──▶ NETWORK ──▶ every host they can route to ZTNA: user ──▶ [ broker ] ──▶ ONE APP (connector dials out; nothing inbound)

Principles: no inbound exposure (the connector inside the network initiates the session outward), per-application authorisation evaluated on every session, identity plus device posture as the gate, and no lateral reachability — the user never gets an IP route into the LAN.

Practical benefits you can defend to a regulator: dramatically smaller blast radius from a stolen laptop; per-app audit trail rather than "connected to VPN at 09:12"; and contractors reaching exactly one internal tool without a network account.

Module 1.4

SASE and SSE — the umbrella terms

Marketing words with a real definition underneath

SASE (Secure Access Service Edge, coined by Gartner in 2019) = network functions (SD-WAN, routing, WAN optimisation) + security functions (SWG, CASB, ZTNA, FWaaS) delivered together as a cloud service, close to the user.

SSE (Security Service Edge) = the security half only: SWG + CASB + ZTNA (+ FWaaS/DLP), minus the SD-WAN. Most FinTechs buy SSE, because they have no branch WAN to converge — everyone is remote and everything is SaaS.

Say it plainly: "SSE is one agent and one policy engine that decides what internet, what SaaS and what internal apps a user may reach, enforced in the provider's cloud rather than in the office." That sentence is more useful in a design review than the acronym.

Module 1.5

DLP — Data Loss Prevention

Detection techniques and why tuning dominates

DLP is a matching engine plus an enforcement point. The engine's techniques, weakest to strongest:

Regex / pattern — card numbers, IBANs, NI numbers. Cheap, noisy. Always pair with a checksum (Luhn for PANs) and proximity keywords.
Dictionary / keyword lists — project code names, "confidential".
Exact Data Match (EDM) — fingerprints of your real customer records; very low false positives, needs a data feed.
Indexed Document Matching / fingerprinting — hashes of specific documents and their fragments.
Classification labels — trust the label applied at creation (Workspace labels, MIP). Best signal when labelling is actually adopted.
ML classifiers / OCR — screenshots of a spreadsheet, source code detection, "resume" or "financial statement" classifiers.

Enforcement points: endpoint (USB, print, clipboard), network/inline (upload to a web app), API (data already at rest in SaaS), and email. The same policy intent must usually be expressed separately in each — a coordination problem, not a technology problem.

The universal DLP failure: deploying in block mode on day one. Standard approach is monitor-only → measure hit rate → tune severity and exceptions → alert the user (coaching) → then block the narrow, high-confidence subset. A DLP programme that fires 500 alerts a day is worse than none, because everyone learns to ignore it.

Module 1.6

EDR, XDR and the endpoint layer

Why the agent sees what the network cannot

AV asks "is this file bad?" (signatures, hashes). EDR asks "is this behaviour bad?" — recording process creation, file and registry writes, network connections and injections, then correlating them into a chain, with the ability to isolate the host and roll changes back.

XDR extends the same correlation across identity, email, cloud and network telemetry. In practice the boundary between XDR and SIEM is commercial rather than technical; the honest question is which platform owns correlation and which owns retention and compliance search.

EPP vs EDR: EPP is the preventive part (blocking known-bad before execution), EDR the detect-and-respond part. Modern agents like SentinelOne are both, which is why "does it replace AV?" is a yes for licensing purposes.

Module 1.7

SIEM and SOAR

Aggregation, normalisation, detection, workflow

1Collect — forwarders, APIs, feeds from every source

2Normalise — parse vendor formats into one schema (Google SecOps calls this UDM)

3Enrich — identity, asset, threat intel, geo, prevalence

4Detect — rules and analytics generate alerts

5Respond — SOAR builds cases, runs playbooks, calls other tools' APIs

The normalisation step is the one people underestimate. Without it, a detection for "failed logon" must be written five times for five products. With it, one rule covers everything that maps to the same event type — which is exactly the argument for learning UDM before writing YARA-L.

Drill 1

A user uploads a customer list to their personal Google Drive from a managed laptop. Which control category is positioned to stop it at the moment it happens?

Inline CASB + DLP. Only an inline control acting during the upload can block it, and only instance awareness can tell a personal Drive from the corporate one — a plain URL filter sees the same domain for both. The API-mode CASB is scoped to your own tenant, so it never sees the personal account. The SIEM finds out afterwards; ZTNA governs private apps, not SaaS uploads.

Checkpoint 1I can define each acronym in one sentence, place it on the where/when grid, and say which product in this stack implements it.

Tier 2 · Engineerdesign

Composing controls

Module 2.1

Defence in depth without duplication

Layering deliberately rather than accidentally

Trace one attack chain and mark which layer owns each step. A phishing-to-exfiltration chain, with this stack named:

1Malicious email arrives → email security (Abnormal) + Workspace auth checks

2User clicks link → SWG URL verdict (Netskope), DNS blocking

3Credential entered on lookalike page → IdP phishing-resistant MFA prevents reuse

4Payload executes → EDR behavioural detection + rollback (SentinelOne)

5C2 established → SWG/firewall egress control, beacon detection in SIEM

6Data staged and uploaded → DLP inline + CASB API sharing alerts

7Whole chain reconstructed → SIEM (Google SecOps) + SOAR case

Two useful outputs from this exercise: any step with no owner is a gap; any step with three owners is where you are paying three times and should decide who is authoritative.

Module 2.2

Evaluating a category before evaluating a vendor

Questions that survive the demo

What must be true for this to see anything? (agent installed, traffic steered, OAuth granted, logs forwarded)
What is its blind spot by design? Every control has one; a vendor who denies it is selling.
What does it emit? Log schema, API, webhook — because it must reach the SIEM.
What happens when it fails? Fail-open (traffic flows unchecked) or fail-closed (users blocked)? Know which, and make it a conscious choice.
Who operates it day to day? The in-house team or an MSSP — and what evidence do we get either way?
What does exit look like? Policy export, log export, and the operational resilience requirement to have a tested exit plan for material providers.

Checkpoint 2I can map an attack chain to owning controls, identify gaps and duplication in this stack, and run a category-level evaluation independent of vendor marketing.

Referencesearchable