The SOC Analyst
Glossary

In 1989 a Harvard-trained biologist mailed 20,000 floppy disks to attendees of a World Health Organization AIDS conference. The disks were labeled "AIDS Information Introductory Diskettes." Insert one, and after the 90th reboot it hid your directories, scrambled the file names on your C drive, and printed a demand: send $189 to a PO box in Panama to get them back. That program, the AIDS Trojan, is the first ransomware on record.

A honey account is a fake user account that exists for one reason: nobody legitimate should ever touch it. No real person logs in with it. No service authenticates against it.

Definition A honeypot is a deliberately deployed decoy system, server, or network resource designed to lure attackers away from real production assets, expose their tactics, and generate actionable threat intelligence. Unlike perimeter controls that block threats at the gate, a honeypot lets an attacker inside a controlled, isolated trap and then watches everything they do. The name draws from the same logic used in espionage: bait with something irresistible, then observe who takes it and how.

Every alert from a honeypot is, by definition, suspicious. There is no legitimate reason for anyone to touch it. A production server throws thousands of benign events an analyst has to wade through to find the one that matters.

Nobody has a business reason to use the AWS key buried in a README that says "DO NOT USE." No analyst queries the customer record for "Aaron Aaaardvark." No service authenticates with the svc-backup-old account that was decommissioned in 2022. So when one of those gets touched, you do not have to ask whether it is suspicious. It is.

One spoofed email is enough. An attacker studies a finance team on LinkedIn, copies the CEO's writing style, and sends an invoice attachment to an accounts-payable clerk. The clerk opens it.

A flat network is one stolen credential away from a full breach. An attacker phishes one user, lands on one laptop, and from there moves sideways to the file server, the domain controller, and the backup system, because the network trusted everything already inside it. That implicit trust is the thing a zero trust strategy removes.

A 60-person company signs a security contract because the price is the lowest on the table. Six months later a phished credential turns into a ransomware event at 11 p.m. on a Saturday. The company opens a ticket.

A small business gets quoted a number for a security tool, balks, and buys nothing. A year later it pays a ransomware demand, eats the downtime, and rebuilds from backups it never tested. The tool would have cost a fraction of the incident.

A small company posts a "cybersecurity expert" job. The description asks for a penetration tester, a SOC analyst, an incident responder, a cloud architect, and a compliance lead, in one person, for one salary. Six weeks later there are forty applications, half of them unqualified, and the few good candidates have three other offers.

Most zero trust programs that fail do not fail on the architecture. They fail on the rollout. A team reads NIST SP 800-207, agrees the model is right, then tries to re-authenticate every user, segment every subnet, and instrument every application in one release.

A small business already spends on security. There is an endpoint tool, a firewall, maybe a managed provider on retainer. Then the owner asks for more money to add detection coverage or a backup that actually gets tested, and the request dies in a budget meeting.

The breach a small business misses is rarely the hooded stranger. It is the office manager who kept a copy of the client list on the way out, the bookkeeper who clicked a fake invoice, or the contractor whose login was never disabled after the project ended. Every one of those people was supposed to be there.

The fastest phishing victims click in 21 seconds. That is the median time between opening the email and clicking the malicious link, according to Verizon's 2026 Data Breach Investigations Report. No security team reacts that fast.

A ransomware affiliate posts in a Russian-language forum that they have breached a regional hospital network and will leak patient records unless paid. A vendor analyst already sits in that forum under a persona built over two years. They direct-message the affiliate, ask which hospital, and get a screenshot of a file tree as proof.

A bank keeps its core ledger on hardware in its own building because a regulator says it has to, and runs its mobile app on public cloud because thirty million customers hit it at 8 a.m. and almost nobody at 3 a.m. A hospital stores patient records on dedicated servers it controls and bursts its imaging-analysis jobs into rented GPUs when the queue backs up. Neither of these is "moving to the cloud" or "staying on-prem." Both are running two environments at once and pretending, for the people who use them, that it is one.

An attacker phishes a developer's laptop on the corporate network. From there they reach an on-prem Active Directory account, and because that account is federated into the company's AWS tenant through the same identity provider, the same stolen credential works in the cloud. No second exploit.

One compromised host should expose one machine. On a virtualized server it can expose forty. A hypervisor is the software layer that runs many virtual machines on one piece of hardware, and it sits below all of them.

An engineer writes twelve lines of Terraform to stand up an S3 bucket for log storage. The block leaves off one argument, so the bucket defaults to no encryption and a public ACL. They apply it, the pipeline goes green, and a publicly readable bucket is now live.

Pull the authentication logs from any modern breach and the entry point is almost never an exploit. It is a login. The 2025 Verizon Data Breach Investigations Report puts credential abuse as the single largest initial-access vector, and CrowdStrike's 2026 Global Threat Report found 82 percent of detections were malware-free, with adversaries operating through valid credentials and trusted pathways rather than dropping a payload.

Pull the access report for any system that has been running for five years and you will find the same thing. Accounts for people who left in 2022. A marketing analyst who still has the finance permissions from a project that ended last spring.

The login looked clean. Right username, right password, multi-factor satisfied. The account was a real employee's, the session a valid one.

Compromise one identity provider and an attacker does not break into one application. They get a key to every application that trusts it. The IdP is the single system that decides who a user is and issues the token everything downstream accepts, which is exactly why it sits at the top of an attacker's target list.

Look at the intrusions a SOC actually works, and most of them did not start with malware. They started with a login. A valid account, a real password, a session that looked exactly like the user it impersonated.

Most modern intrusions do not start with malware. They start with a login. An attacker with a valid username and password does not trip a single signature, does not drop a file an endpoint agent can quarantine, and does not need an exploit.

A contractor account needs to reach one finance application for ninety days. On a flat network, the firewall that lets it reach that app lets it reach the file servers, the domain controllers, and the jump box sitting on the same subnet. The contractor never touches those, but the credential can, and so can anyone who steals it.

Identity theft does not start the day money leaves your account. It starts months earlier, in a data breach you never heard about, with a credential that was reused, or with one convincing email that harvested a password. By the time a fraudulent loan or a drained account shows up, the attacker has already done the hard part: they collected enough of your identity to impersonate you to someone who trusts it.

A help-desk ticket reset an executive's password at 2 a.m. The reset was legitimate, processed through the real self-service portal, satisfying every check. Minutes later the account enrolled a new MFA device, granted itself membership in a privileged group, and began pulling files from a finance share it had never touched.

In its 2026 Global Threat Report, CrowdStrike found that 82% of detections were malware-free. The attacker did not drop a payload your EDR could flag. They logged in.

Open the IIS log on a webshell-hit server and the compromise is usually right there in space-delimited text. A POST to /uploads/test.aspx returning 200, followed minutes later by a string of GET requests to that same .aspx carrying cmd=whoami in the URI query. One client IP.

A SIEM alert fires at 3:08 a.m.: a service account just authenticated to a domain controller it has never touched, from a workstation in finance. Somebody has to decide, in the next few minutes, whether that is a misconfigured backup job or an attacker three hops into the network. That decision, made fast and under incomplete information, is the job of an incident responder.

02:14. An EDR alert fires: a host is encrypting files in bulk. Ninety seconds later, a second host starts.

A SOC analyst gets an EDR alert at 03:40: a finance workstation is beaconing to an IP nobody recognizes. What happens in the next ten minutes is decided entirely by whether the team has a plan. With one, the analyst pulls up the malware playbook, checks the severity matrix, isolates the host through the EDR console, snapshots memory, and pages the on-call lead, all from a runbook that already answered every question.

A process opens a Word document, then spawns PowerShell, which reaches out to the internet and pulls down a script that reads the memory of the system's credential store. Every one of those programs is signed and trusted. No known-bad file hash is on disk, no flagged IP is contacted, and a tool matching only against lists of known-bad artifacts sees nothing wrong.

A SOC analyst pulls a firewall log and finds a workstation beaconing to 185.220.101.47 every 60 seconds, at 3 a.m., long after the user went home. The IP belongs to no business service. That single artifact, an outbound connection to a known-bad address, is an indicator of compromise.

Indicators of Compromise (IOCs) An Indicator of Compromise (IOC) is a piece of forensic evidence that signals a network, endpoint, or system has likely been breached. Unlike a warning that an attack *might* occur, an IOC is evidence that one *already has* whether through malware installation, unauthorized access, credential theft, or data exfiltration. Think of IOCs as the digital breadcrumbs attackers leave behind.

A ransomware crew hits a hospital. The attack encrypts the systems that hold patient records, so clinicians cannot reach them and surgeries are delayed: a loss of availability. Before encrypting, the attackers copied the records out to leak them, exposing patient data: a loss of confidentiality.

A startup needs forty servers for a three-day load test, then zero. Buying that hardware would be absurd: the machines would sit dark for the other 362 days of the year. Instead the team opens a console, launches forty virtual servers in a few minutes, runs the test, and deletes them.

A developer needs a new environment: three EC2 instances, a load balancer, a security group, an S3 bucket, and the IAM roles to tie them together. The old way was a ticket, a console, and an afternoon of clicking. The IaC way is a forty-line file committed to a repo, a pull request, and a pipeline that builds the whole stack in minutes and tears it down the same way.

A single Terraform file declares a storage bucket. One line sets its access policy to public. The file passes code review because nobody reads the policy block closely, merges to main, and the pipeline applies it across three environments in under a minute.

A database server's disk fills to 100 percent at 3 a.m. and the application starts throwing 500s. The on-call engineer sees it because a monitoring agent reported disk usage every fifteen seconds and an alert fired at 85 percent. That is infrastructure monitoring doing its day job: catching the operational failure before users do.

A login form asks for a username and password. An attacker types ' OR '1'='1 into the username field and leaves the password blank. The application takes that text and pastes it straight into a database query.

A departing engineer pulls the full source repository to a personal drive in the two weeks before resigning. A frustrated admin who was passed over for promotion starts logging in at 2 a.m. and browsing share drives that have nothing to do with their role. A well-meaning analyst emails a customer export to a personal Gmail address to finish a report from home.

The hardest intrusions to catch are the ones that do not look like intrusions. A database administrator runs a query at 2 a.m. that returns the full customer table. An engineer two weeks from their last day copies a source repository to a personal drive.

A SAST scanner flags a SQL query as risky and a DAST scanner reports the same endpoint returns a database error. Neither tells you whether the flaw is actually reachable, or which exact line built the query. An IAST agent does both at once: it sits inside the running application, watches the malicious request flow through the code, and reports that this parameter, on this endpoint, reached this line, and the database executed the injected string.

In October 2016 a botnet built from cameras, DVRs, and home routers knocked Twitter, Reddit, Spotify, and Netflix offline for hours. The malware, Mirai, did not crack anything. It logged in.

A workstation starts reaching out to an external host every sixty seconds, on port 443, in small even bursts. The firewall waves it through, outbound HTTPS is allowed, that is the rule. Nothing about the connection breaks policy.

Two analysts look at the same intrusion and reach for different evidence. The first pulls a firewall log, finds a workstation beaconing to 185.220.101.47 at 3 a.m., and matches it against a threat feed: known-bad address, confirmed. The second watches a process tree, sees a Word document spawn PowerShell, which downloads a script that reads credential-store memory, and flags the sequence as an attack in progress.

An auditor does not ask whether you have a firewall. They ask to see the risk assessment that decided you needed one, the policy that governs it, the owner accountable for it, the log that proves it runs, and the management review where someone looked at all of that and signed off. ISO compliance is the discipline of being able to answer all five.

A penetration tester's first finding is almost never a clever exploit. It is an asset the defender did not know existed: a forgotten staging server still answering on port 443, a developer's test VM spun up in a cloud account nobody monitors, a network switch running firmware from three owners ago. The control stack was fine.