The SOC Analyst
Glossary

Most breaches you will investigate are not exotic. They are an account that could reach something it never should have. A help-desk technician's token that opened a domain controller.

What is Access Directory? An access directory is a centralized database or service that stores and manages information about users, devices, resources, and the permissions that govern who can access what within a network. It serves as the authoritative source for authentication and authorization decisions across an organization's IT environment.

Pull the access log off a compromised web server and the intrusion is usually sitting in plain text. One source IP hitting /wp-login.php four hundred times in a minute, then a single 200 where every other attempt returned 401. A GET for /etc/passwd with a path-traversal string in the URI.

A domain admin logon at 3 a.m. from a workstation that has never touched a privileged account is either your on-call engineer or an attacker who already owns your network. Active Directory auditing is what turns that event from a line nobody reads into an alert somebody acts on. Active Directory is the authentication and authorization core of most enterprise networks.

Steal one certificate from one server and you can sign in as anyone, with no password, no MFA prompt, and no failed-login event for the SOC to catch. That certificate lives on an AD FS server, and the technique that abuses it has a name: Golden SAML. Active Directory Federation Services is the Microsoft component that brokers single sign-on between an on-premises Active Directory and external applications.

Compromise one domain controller and you own every account, every machine, and every file share it authenticates. That is why almost every hands-on-keyboard intrusion ends up in Active Directory, and why securing it is less about a single setting than about denying an attacker the chain of small wins that leads from one phished laptop to Domain Admin. Active Directory (AD) runs authentication and authorization for most enterprise Windows estates.

A valid username and a valid password tell you almost nothing. The same credential can come from the user's registered laptop on the corporate network at 9 a.m. or from a fresh host in a hosting-provider IP range at 3 a.m., minutes after the password showed up in a combo list. Static authentication treats both the same: credentials match, access granted.

Signature antivirus asks one question of every file: have I seen this exact thing before? An attacker beats it by changing one byte. Repack the payload, the hash changes, the signature misses, and the same malware walks past a tool that was watching for it.

In early 2020, a routine software update went out to customers of SolarWinds Orion. It was signed, it looked legitimate, and it carried a backdoor. Up to 18,000 organizations installed it.

In 2018, researchers stuck a few black-and-white stickers on a stop sign. To a person it was still obviously a stop sign. To the deep-learning classifier that a self-driving car would use, it now read as a 45 mph speed-limit sign, in every frame of a drive-by video.

A user's browser homepage changes on its own. Every search now routes through a domain nobody recognizes, the new-tab page is stuffed with ads, and a toolbar appeared that no one installed. The endpoint is not encrypted, no data alarm has fired, and the user can still work.

In November 2025, Anthropic reported a cyber-espionage campaign in which a Chinese state-sponsored group used an AI model to run 80 to 90 percent of the operation on its own: reconnaissance, vulnerability discovery, exploit development, credential harvesting, and data extraction across roughly thirty targets. Humans stepped in only at four to six decision points per campaign. The model did the rest, firing thousands of requests at peak.

A security team gets a cloud alert at 02:00. An IAM role that normally touches three storage buckets just listed forty, from an IP in a region the company does not operate in. No malware.

A signature catches what you have already seen. An anomaly model catches what you have not. That is the whole reason a SOC reaches for anomaly detection.

In November 2025, Anthropic reported that a Chinese state-sponsored group (tracked as GTG-1002) ran a cyber-espionage campaign in which the AI model handled 80 to 90 percent of the operation on its own: reconnaissance, exploit development, credential harvesting, lateral movement, and exfiltration across roughly thirty targets. Humans picked the targets and set the goals. The model did the work.

The endpoint in your fleet that used to send a screen region to a cloud API now keeps a rolling index of everything the user saw, stored on the local disk, generated by a model running on a chip your EDR cannot see inside. That is the security story of the AI PC, and it is mostly missing from the marketing. The pitch is battery life and on-device assistants.

A mid-size enterprise feeds its SIEM hundreds of gigabytes of logs a day. A static correlation rule reads each event against a fixed condition and fires when it matches. The attacker, meanwhile, now moves from first access to a second host in 29 minutes on average, and in one 2026 case began exfiltrating data four minutes after landing.

In January 2024, a finance worker at the engineering firm Arup joined a video call with people who looked and sounded like the company CFO and several colleagues. Everyone on the call was a deepfake. The worker authorized 15 transfers totaling about 200 million Hong Kong dollars, roughly 25.6 million US dollars, before anyone realized the meeting never happened.

Two vendors stand on the same stage and both say "AI-native." One built its platform on a single cloud data lake, runs machine-learning models directly on that unified telemetry, and ships every detection with the raw events that triggered it. The other took a fifteen-year-old correlation engine, wired a large language model onto the alert output, and changed the slide deck. Same two words, opposite architectures. "AI-native" is supposed to name the first one.

Two products both say "AI-powered XDR" on the data sheet. One runs a machine-learning model on a single unified telemetry store and ships a verdict with the raw events that triggered it. The other forwards alerts from six separate consoles into a large language model that writes a summary after the fact.

A stolen password is a valid password. The login succeeds, the session is authorized, and every signature-based control waves it through. What gives the attacker away is not the credential.

Amazon Web Services (AWS): Amazon Web Services (AWS) is a comprehensive cloud computing platform provided by Amazon that delivers on-demand IT resources over the internet. Instead of owning physical servers or data centers, businesses can rent computing power, storage, and other services on a pay-as-you-go basis. Launched publicly in 2006, AWS pioneered the modern cloud computing model by offering scalable infrastructure as web services.

API Security Application Programming Interfaces (APIs) are the invisible backbone of the modern internet. Every time a mobile app fetches your location, a payment gateway processes a transaction, or a SaaS platform syncs data between tools, an API is doing the work. API security is the practice of protecting these interfaces from threats that could compromise the data they transmit, the systems they connect to, or the business logic they expose.

An attacker does not need to break your code to read another customer's data. They just change the ID in the request. GET /api/accounts/1023 returns your record; GET /api/accounts/1024 returns someone else's, because the endpoint checked that you were logged in but never checked that account 1024 was yours.

A web app starts throwing 500 errors at 02:14. The on-call engineer looks at the error log and finds a stack trace pointing at a deserialization routine, with the same malformed payload arriving every few seconds from one IP. That single line of evidence, written by the application itself, is the difference between "the site is down" and "someone is exploiting CVE-whatever in our payment module." The infrastructure logs say the box is healthy.

A checkout service starts returning HTTP 500s on one in twenty requests. The host is up, CPU is flat, the firewall logs nothing. Infrastructure monitoring says the box is healthy, and it is right.

Prevention fails. Plan for the minute after it does. A patched, hardened, well-monitored application still goes down.

A scanner reports two findings on the same application. One is a CVSS 9.8 in a parsing library that ships in the code but is never called, on an internal service behind two layers of network segmentation, with no public exploit. The other is a CVSS 6.5 in the login path of an internet-facing payment API, with a working exploit on GitHub and an EPSS probability climbing past 0.7.

Most breaches start in the application, not the network. An attacker does not need to defeat a firewall when a login form accepts injected SQL, a file upload runs as code, or an imported library carries a known remote-code-execution flaw. The application is the door, and application security is the discipline of making sure it does not open for the wrong request.

The flaw that breaches you in production was almost always introduced months earlier, in a design decision, a line of code, or a dependency someone added without reading the changelog. By the time it shows up as an alert, the cheap window to fix it has closed. Application security best practices exist to move the catch forward, to the design review, the commit, the pull request, where a fix costs minutes instead of an incident.

Run SAST, DAST, IAST, and SCA against the same application and you get four dashboards, four severity scales, and the same SQL injection reported three different ways. One scanner calls it CWE-89, another calls it "tainted input to query," a third buries it under two thousand other findings. The flaw is real, but the output is noise, and a developer staring at four tools does not know which finding to fix first or whether two of them are the same bug.

A team running SAST, DAST, SCA, and a runtime tool does not have one application security problem. It has four dashboards, four severity scales, and four backlogs that do not agree with each other. The same SQL injection flaw shows up as a SAST finding, a DAST alert, and an IAST trace, counted three times, owned by no one, sitting next to ten thousand findings nobody has triaged.

A team running SAST, DAST, SCA, secrets scanning, and a runtime sensor does not have a detection problem. It has a correlation problem. Six tools emit tens of thousands of findings a month across six dashboards, the same vulnerable Log4j dependency shows up as four separate tickets, and nobody can answer the one question that matters: which of these is actually reachable, in a service we expose, holding data we care about.

A single unpatched library took down Equifax. The flaw was in Apache Struts, a dependency the application pulled in, and a scanner that read the software bill of materials would have flagged it before the breach. That is the job application security testing does: find the exploitable weakness in code, configuration, and dependencies before an attacker finds it in production.

Point a scanner at a login page without credentials and it sees the login page. It cannot click past it, so it never tests the dozens of authenticated endpoints behind it, where the order history, the admin panel, and the password-reset logic live. OWASP's own guidance is blunt about the gap: an unauthenticated dynamic scan reaches only the small slice of an application a logged-out stranger can touch.

Antivirus asks "is this file known to be bad?" and blocks it if the answer is yes. Application whitelisting asks the opposite question: "is this file on my approved list?" and blocks it if the answer is no. That inversion is the whole idea.

A workstation on the same subnet as your domain controller starts answering for an IP it does not own. It sends a stream of unsolicited ARP replies that say "the gateway is at my MAC address." Within seconds the victim's ARP cache and the gateway's ARP cache both point at the attacker, and every packet between them now takes a detour through a machine that was never supposed to be in the path. No exploit fired.

A SAST scanner flags 400 findings. A DAST scan adds 120 more. Software composition analysis reports 900 vulnerable dependencies.

A typical AppSec program runs SAST, DAST, SCA, secrets scanning, container scanning, and a cloud posture tool. Each one has its own dashboard, its own severity scale, and its own idea of what a "critical" is. The same vulnerable log4j dependency shows up in the SCA tool, the container scanner, and the runtime tool as three separate findings, none of them aware of the other two.

Pull the asset inventory for almost any organization and it will be wrong. Not maliciously, just stale. A marketing subdomain spun up for a campaign three years ago, still resolving, still running an unpatched CMS.

The asset that gets you breached is almost never the one in the CMDB. It is the staging server someone spun up for a demo and forgot, the S3 bucket a marketing contractor made public, the forgotten subdomain still pointing at a decommissioned load balancer, the VPN appliance two versions behind because nobody owned the patch. None of these were tracked.

Every service you expose, every account with admin rights, every macro Office is allowed to run is a door an attacker can try. Attack surface reduction is the discipline of removing doors you do not need and locking the ones you do. The math is simple and unforgiving.

In the 2026 Verizon Data Breach Investigations Report, exploitation of a software vulnerability was the way into 31 percent of breaches, overtaking stolen credentials for the first time in nineteen years of the report. Phishing accounted for 16 percent. Credential abuse, last year's leader, dropped to 13 percent.

A contractor logs into the finance app at 02:00 from a personal laptop in a country the company does not operate in, and asks to export the payroll table. Every credential checks out. Role-based access would see a valid "finance-readonly" role and hand over the file.

Six weeks after the breach, the only question that matters is "what did they touch?" The answer is either sitting in your audit logs or it is gone. An audit log entry that reads DeleteTrail from an IAM role that has never called it before, at 02:14, from an IP in a country you do not operate in, is the difference between scoping an incident in hours and guessing for months. That single record names the actor, the action, the time, and the source.

A single commercial feed can push tens of thousands of new indicators a day. An analyst reading them one at a time, looking each up, deciding what to block, and pushing it to the sensors would never finish the first hour's batch before the next arrived. So nobody does that by hand.

Open the IAM console on an account that has run for two years and read the credential report. You will usually find an access key that has not rotated since the account was created, a few users with AdministratorAccess attached directly, and a root account whose MFA status reads "not enabled." None of that is an AWS bug. Each is a default left unchanged, and each is the kind of setting that turns a stolen key into a full account takeover.

An S3 bucket holding customer data goes public at 02:14. The on-call engineer opens CloudWatch, finds clean dashboards, no alarms, normal latency, and concludes nothing happened. The bucket is still public.

An attacker steals a long-lived access key from a developer laptop, calls AssumeRole from an IP in another country, enumerates S3 with ListBuckets, and copies a sensitive bucket out through a VPC endpoint. Every one of those actions is an ordinary AWS API call. Nothing exploited a flaw.

A migration team lifts a fleet of on-premises servers into Amazon EC2 over a weekend. The application works Monday morning. What also came along: a security group that allowed 0.0.0.0/0 on port 3389 because the old data-center firewall used to block it, a service account whose long-lived credentials are now reachable from the public internet, and an S3 bucket created to stage the data that nobody set to private.