Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Cybersecurity Analyst

A cybersecurity analyst monitors an organisation for behaviour that was not agreed upon, which is a perfectly reasonable job except that the organisation itself was not agreed upon either, and most of its behaviour was not agreed upon by anyone who would admit to it. You learn to translate "we think something happened" into logs, detections, timelines, contained hosts, remediation tickets, and a dashboard of alerts that fired for twenty thousand events overnight, of which one mattered and the dashboard is not volunteering which. The threat actor follows your password policy less carefully than the defender, who wrote it; the compliance checkbox proves posture was excellent at the precise moment it was photographed, like a tidy desk captured before the audit and rebuilt into entropy by lunchtime. This guide travels from reading a network diagram without flinching to running detection and response across a whole estate, with practical stops at monitoring, triage, vulnerability, identity, forensics, and the recurring discovery that an alert is a question the system is too polite to phrase. The grand objective is noticing the right thing quickly enough to matter; the daily evidence is usually a closed ticket, a tuned rule, and a threat report that, against all commercial instincts, recommends not buying anything new.

Things to recognise

• A control listed as implemented on a checklist may be implemented only on the systems someone remembered to include; the asset inventory, not the checklist, is the authority on what is actually defended.
• A "for testing" firewall rule tends to outlive the test, the tester, and the reason for testing, and it accrues additional trusting traffic the way a quiet harbour accrues boats.
• Frameworks compare posture to a catalog, not to an adversary; full compliance can coexist happily with a thoroughly compromised estate, which is why frameworks and monitoring are separate disciplines.

Take the useful exit

Level 1 · Novice

Read the network before declaring the perimeter a polite suggestion

You inspect networks, asset inventories, control catalogs, and framework checklists without changing anything, learning how a well-intentioned firewall can be rendered entirely optional by a single exception nobody documented.

You begin with read-only artifacts: network diagrams, asset inventories, the CIS Controls catalog, the NIST Cybersecurity Framework functions, and a spreadsheet of exceptions that pre-dates everyone currently employed. Network security is the practice of understanding protocols, segmentation, and the attack surface that the network politely exposes to anyone who asks; security frameworks are catalogues of controls grouped into functions like identify, protect, detect, respond, and recover, which exist so that posture can be discussed without anyone having to agree on what "good" means. You review these with engineers, operators, and an experienced analyst so that the gap between "what we have" and "what the checklist assumes we have" becomes a named list rather than a feeling.

Suppose you are handed a firewall ruleset export and a framework self-assessment. In a read-only sandbox, you trace which subnets can reach the database tier, note a rule allowing a broad source range "for testing" dated three years ago, and map the finding to the NIST protect function. You record the rule, its source, its probable owner, and the control it undermines; you change nothing. Removing the rule yourself would be efficient in the manner of a tourist who repaves a country road, and the resulting outage would be attributed to security with impressive enthusiasm. One annotated gap is an observation with good posture; the remediation ticket belongs to the asset owner, who has not yet been told they own it.

Words from the spaceship manual, translated

Attack surface: The set of points where an attacker could touch a system — open ports, exposed services, user accounts, internet-facing applications. It is not a number; it is a map, and the parts no one has drawn are usually the parts that matter.
Security framework: A structured catalog of controls and outcomes, such as CIS Controls or the NIST Cybersecurity Framework, used to assess and communicate posture. It turns "we are doing security" into a list whose individual items can be confirmed, denied, or embarrassed.
Segmentation: Dividing a network into zones that restrict what can reach what, so a compromised laptop cannot simply walk into the payroll database. Segmentation is a design choice that has to be enforced, not a feeling one declares in a policy document.
Exception: A documented allowance for a control to be waived or deferred, typically with an owner, a reason, and an expiry. An exception without an expiry date is not a waiver; it is a permanent architecture described in apologetic language.