Blue Team & Defensive Security

State which organizations, services, environments, identities, data, and threat scenarios the defensive function covers. Define what it delivers: monitoring, alert triage, threat hunting, incident coordination, detection engineering, intelligence integration, validation, reporting, and advisory support. Record exclusions, hours, escalation channels, response authority, dependencies, and degraded-mode behavior. “Monitor everything” is not a scope.

Applied exercise — design a three-tier service

1. Select one customer-facing service and document owner, data classification, availability need, identities, components, and critical threat scenarios.
2. Define Tier 1 validation steps, Tier 2 investigation scope, specialist triggers, incident declaration authority, and business-owner response authority.
3. Create one case state diagram, one escalation matrix, one shift-handover template, and degraded-mode procedure for SIEM or identity-platform failure.
4. Run a tabletop alert through the process. Measure decision time, handoff loss, repeated work, unavailable context, and ambiguous authority.
5. Revise the service catalogue and record the remaining accepted risks.

Evidence gate: another shift can inherit the case and explain current state, supporting evidence, open questions, next action, owner, deadline, and authority without contacting the original analyst.

1200km: SOC Tier 1 onboarding guide · Primary: NIST SP 800-61r3

Maintain stable records for applications, services, hosts, cloud resources, containers, devices, networks, identities, credentials, data stores, software, vulnerabilities, vendors, and owners. Record source, verification time, lifecycle state, confidence, aliases, and relationships. Separate authoritative inventory from discovered evidence and analyst inference.

Applied exercise — enrich an internet alert

1. Start with one outbound network event. Resolve endpoint, user, process, service, owner, environment, and event-time IP allocation from authoritative sources.
2. Resolve destination name, IP, ASN, certificate, passive history, reputation, and known intelligence with collection times and source citations.
3. Separate confirmed entity links, time-bounded observations, heuristics, and unrelated shared-hosting results.
4. Recalculate priority using asset importance, exposure, behavior, confidence, and potential impact—not reputation score alone.
5. Record which enrichment changed the decision and which merely increased noise.

Boundary: active scanning, sandbox submission, file upload, third-party lookup, or external AI processing may disclose customer data or touch systems outside authority. Use approved providers, sanitized inputs, and explicit assessment authorization.

For each priority behavior, name the actor, action, object, outcome, source and destination, session, process or request lineage, privilege, timestamp semantics, and expected benign context. Identify the source that can observe each element and the control point that can respond. ATT&CK detection strategies and analytics can help organize behavior and mutable environmental elements; note that the older ATT&CK data-source catalogue is retained for reference but deprecated from v18 onward.

Minimum telemetry contract

Applied exercise — onboard one high-value source

1. Select one behavior and write the exact fields needed to distinguish malicious, administrative, automated, and ambiguous activity.
2. Generate controlled success, failure, denial, and edge-case events. Preserve source output.
3. Trace each record through collection, parsing, normalization, enrichment, storage, query, rule, alert, and case.
4. Stop the collector, delay the queue, rotate a credential, change one field type, and exceed the normal rate. Verify health detection and recovery.
5. Publish the source contract, coverage limit, retention, owner, support path, cost, and test fixtures.

Primary: OCSF · OpenTelemetry logs · ATT&CK detection strategies · CISA logging guidance

Define the adversary or risky behavior, why it matters in this environment, required telemetry, observable sequence, expected legitimate behavior, entity scope, time window, threshold, severity rationale, case fields, analyst decision, response options, owner, and limitations. Map ATT&CK only when the behavior supports the mapping. A technique label does not prove coverage of every implementation of that technique.

Portable rule metadata

Sigma provides a structured, shareable rule format with log source, detection logic, status, references, tags, false-positive notes, severity, and other metadata. Conversion does not make a rule production-ready: field mappings, backend semantics, case sensitivity, wildcard behavior, escaping, aggregation, time windows, null handling, and source availability must be validated in the destination.

title: Suspicious Encoded PowerShell With Network Follow-On
id: 0d5e5d83-17d1-4fc6-bdaf-6c524d1fd086
status: experimental
description: Lab example; validate field mappings and benign automation locally.
logsource:
  product: windows
  category: process_creation
detection:
  selection_image:
    Image|endswith: '\powershell.exe'
  selection_flag:
    CommandLine|contains:
      - ' -enc '
      - 'FromBase64String'
  condition: selection_image and selection_flag
falsepositives:
  - Approved administrative automation
level: medium
tags:
  - attack.execution
  - attack.t1059.001

Applied exercise — productionize one analytic

1. Start with a behavior hypothesis and build positive, near-positive, benign, malformed, duplicate, late, and missing-field fixtures.
2. Implement the smallest logic that separates the labeled fixtures. Document every field and backend assumption.
3. Replay against representative historical data. Review sampled matches and non-matches; record label criteria and uncertainty.
4. Deploy in observation mode, measure volume and latency, simulate the behavior safely, and verify alert and case content.
5. Release with owner, runbook, monitoring, change record, rollback, review date, and explicit coverage boundary.

Evidence gate: the rule repository, generated backend query, deployed object, test result, observed event, alert, case, analyst decision, and response evidence are linked by stable identifiers and versions.

1200km: Newest Detection Engineering Techniques · From Threat Intelligence to Detection · Primary: Sigma rule documentation

Derive the hypothesis from threat intelligence, an incident, a coverage gap, a new technology, an anomaly, or a control change. State actor or behavior, target population, expected observables, data sources, time window, alternative explanations, and a disconfirmation condition. Example: “On managed Windows endpoints, an adversary may execute encoded PowerShell from an Office child process and make a new outbound connection within five minutes; approved deployment tooling is the main expected benign cause.”

Applied exercise — encoded PowerShell behavior chain

1. Confirm process creation, PowerShell script-block or equivalent, network, DNS, and endpoint identity data for the selected population.
2. Query for encoded or decode-related PowerShell usage; measure normal prevalence and identify common management tools.
3. Join suspicious process events to parent process, signer, user, endpoint, destination, and subsequent file or persistence activity.
4. Review high-context matches against approved change and automation records. Preserve exact raw events and query version for candidates.
5. Create a detection proposal for the stable behavior chain and a telemetry backlog item for any unanswerable part.

Boundary: AI can propose hypotheses, queries, pivots, and summaries, but it cannot assert that a query ran, invent a result, assign a verdict, or replace analyst validation of fields and syntax.

1200km: Threat hunting with AdversaryGraph · Protocol-level network hunting

Confirm alert identifier, rule version, source events, time range, entity, environment, current rule health, duplicates, known test activity, and whether the data is complete. Read the logic and runbook. Determine what matched and which part of the description is interpretation. Assign priority using potential impact, asset and identity context, behavior, confidence, exposure, active scope, and response urgency.

Applied exercise — suspicious administrative login

1. Validate tenant, immutable identity, source IP, device, authentication method, conditional-access outcome, session, target resource, and event timing.
2. Compare recent password, MFA, group, role, device, consent, and sign-in changes. Check whether source reputation applies to a shared provider or exact endpoint.
3. Look for privilege use, mailbox rules, OAuth grants, secret changes, discovery, data access, and persistence in the same session or identity path.
4. Contact the owner through an independent approved channel when required; never rely solely on the potentially compromised account.
5. Escalate or close with explicit evidence, alternative explanation, rule feedback, and any session or credential cleanup.

1200km: SOC Tier 1 complete onboarding guide

Collect process creation and termination, parent and ancestry, command execution, image and module load, signer, file creation and modification, registry or configuration change, service and scheduled task, logon and token activity, script content where approved, network connection, DNS, driver, security control state, removable media, and sensor health. On Linux and macOS, map equivalent process, audit, launch, persistence, package, shell, authorization, and network sources instead of forcing Windows field assumptions.

Applied exercise — Office-to-script-to-network chain

1. Generate a safe lab process chain with a document-like parent, script interpreter, benign encoded content, file write, and controlled destination.
2. Trace original events through collection and normalization. Confirm process GUID or equivalent links survive.
3. Write single-event and correlation variants. Test with common administrative scripts, deployment tools, login scripts, and developer workflows.
4. Verify alert fields allow Tier 1 to see parent, command, signer, user, host, destination, and event references without opening multiple consoles.
5. Test isolation and evidence collection on a lab host; verify authorization, action result, user impact, and rollback.

Evidence gate: report observed process and state behavior. Do not label a binary “malware” solely because it is unsigned, rare, encoded, or launched by a suspicious parent.

Flow records summarize who communicated, when, for how long, and how much. DNS adds requested names and resolution context. Proxy and gateway logs add user, URL, method, policy, and application. Firewall logs add control decisions. Packet capture adds protocol content where collection is lawful and technically available. Endpoint network events add initiating process. Cloud flow and load-balancer logs expose virtual-network paths. No source alone reconstructs every hop.

Applied exercise — protocol-level beacon investigation

1. Select a controlled endpoint and generate a benign periodic HTTPS request to a lab service with known timing and payload.
2. Collect endpoint process/network, DNS, flow, proxy, TLS, and packet evidence where authorized. Align clock and observation points.
3. Measure periodicity, jitter, bytes, request method, path variation, connection reuse, certificate, SNI, and process ancestry.
4. Compare with software update, monitoring, collaboration, and management traffic. Determine which features are stable and discriminating.
5. Create a hunt or analytic proposal that combines network behavior with endpoint and asset context; document environments where it cannot work.

1200km: Protocol-Level Network Threat Hunting · Attack–defense labs

Represent human and service identities, devices, workloads, tenants, directories, groups, roles, permissions, applications, credentials, certificates, sessions, federation, delegation, recovery methods, and resources. Record immutable IDs and point-in-time memberships. High-risk edges include privilege assignment, group control, password or key reset, consent, impersonation, delegation, certificate enrollment, role assumption, session creation, and trust-policy change.

Applied exercise — Kerberoasting detection and response

1. Build a lab domain with a controlled SPN account, test user, endpoint telemetry, domain-controller events, and known time synchronization.
2. Generate normal service-ticket traffic and an authorized Kerberoasting simulation. Compare request encryption type, volume, target SPNs, requesting identity, host, process, and subsequent activity.
3. Test a rule against administrative scanners, service discovery, monitoring, and application behavior. Avoid a blanket “any RC4 ticket is malicious” verdict.
4. Investigate the identity path: credential exposure, privilege, reachable systems, delegation, group control, logons, and persistence.
5. Practice containment order, evidence preservation, service-owner coordination, password rotation, ticket/session invalidation, and verification.

1200km ITDR: Detection framework · Detecting Kerberoasting · Detecting DCSync · Detecting MFA fatigue · Simulation framework

Collect administrative and data-access events for identity, compute, network, storage, database, secrets, keys, logging, security controls, serverless, orchestration, and organization policy. Preserve actor, assumed role or service principal, session, source, user agent, API, resource, region, request parameters with secret filtering, result, error, and request ID. Monitor log disabling, policy changes, snapshot or image creation, public exposure, credential creation, discovery bursts, and cross-account access.

Applied exercise — suspicious Kubernetes secret access

1. Enable an approved audit policy in a lab and verify event stages, user, groups, source IP, verb, resource, namespace, name, response, request ID, and omission of sensitive content.
2. Create normal controller and workload access, then perform an authorized unexpected secret list/get with a test service account.
3. Correlate API audit with RBAC, pod, image, process, node, network, and cloud identity. Distinguish a controller, human administrator, compromised workload, and scanner.
4. Test alert volume and late events. Verify ephemeral pod and service-account context remains available after deletion.
5. Practice token revocation or workload isolation, policy correction, secret rotation, redeployment, and service verification.

1200km: Kubernetes Logging and Monitoring · Primary: Kubernetes auditing

For email, preserve message and trace identifiers, sender and envelope, authentication results, routing, URLs, attachments, sandbox evidence, recipient actions, mailbox rules, forwarding, authentication, session, OAuth grants, and post-delivery remediation. Do not infer sender identity from a display name or single header. Coordinate message purge, URL block, session revocation, password reset, consent removal, endpoint review, and recipient communication.

Applied exercise — unusual repository-to-cloud transfer

1. Create a synthetic repository and data classification. Generate normal developer clones and an approved large export to a lab destination.
2. Collect identity, device, repository audit, endpoint process, file, archive, DNS, proxy, network, and cloud-storage evidence.
3. Test volume-, rarity-, destination-, archive-, off-hours-, and role-aware analytics independently and as a sequence.
4. Review false assumptions: build agents, backups, migrations, incident responders, remote work, shared accounts, and approved transfer tools.
5. Practice a need-to-know escalation with neutral facts, technical containment options, evidence preservation, and legal/HR decision ownership.

1200km: Detecting Malicious Insider Activity

Maintain incident classification and declaration criteria, severity model, on-call roster, incident command roles, service and business contacts, legal and regulatory path, communications plan, evidence procedures, responder access, clean communications, emergency credentials, provider support, forensic capability, backup and restoration evidence, containment patterns, and exercise schedule. Test these dependencies before an incident.

Applied exercise — compromised cloud administrator

1. Run a tabletop using synthetic sign-in, role, token, secret, audit-policy, storage, and endpoint events. Declare assumptions and unavailable evidence.
2. Assign incident command, investigation, cloud, identity, endpoint, communications, legal/privacy, and service-owner roles.
3. Build a timeline and scope graph. Decide whether and when to revoke sessions, disable identity, protect break-glass accounts, rotate secrets, preserve logs, and isolate workloads.
4. Introduce a business dependency that makes immediate account disable risky. Document the decision, compensating control, approval, monitoring, and deadline.
5. Recover, verify, monitor, close, and create tested detection, logging, identity, and runbook improvements.

Evidence gate: each material response action has a named approver, exact target, rationale, expected impact, execution record, success verification, evidence consequence, rollback or recovery plan, and owner.

Primary: NIST SP 800-61 Revision 3 · NIST CSF 2.0

Useful roles include summarizing a bounded evidence set; extracting entities with source spans; proposing hypotheses, queries, correlations, and false-positive checks; explaining rule logic; comparing timelines; drafting case notes; mapping reviewed behavior to ATT&CK; translating a validated analytic between query languages; and identifying missing context. Prohibited or gated roles should include unsupervised verdicts, autonomous containment, uncontrolled external enrichment, secret handling, unsupported attribution, and claims that tools or queries ran when they did not.

Applied exercise — AI-assisted hunt query

1. Create a saved hunt hypothesis with data classification, selected provider policy, telemetry schema, and a reviewed context package.
2. Ask the assistant for Sigma, KQL, SPL, EQL, or YARA-L output using a strict response schema: language, query, required fields, assumptions, expected evidence, false positives, and validation steps.
3. Reject invented fields and syntax. Compile or parse where possible, review against the destination schema, and run only through an approved analyst-controlled workflow.
4. Compare returned rows with the hypothesis; preserve queries and raw event references. Ask the model to summarize only the supplied evidence with citations.
5. Record human edits, final disposition, provider/model/prompt version, retrieval references, token or cost metadata where policy requires, and whether the assistance improved time or quality.

Non-negotiable boundary: model output is a lead, not evidence. Retrieval relevance is not source truth. A tool call is not successful until its authenticated structured result is received, validated, linked to the case, and reviewed.

1200km: AdversaryGraph AI, RAG, MCP, and module guide · AI-assisted threat hunting · Primary: NIST AI Resource Center

Select behavior from a current threat model or intelligence requirement. Define technique and implementation, target, preconditions, expected telemetry, safety limits, allowed effects, cleanup, stop condition, approvals, observers, and rollback. Use isolated lab systems when possible. In production, favor reversible tests with synthetic data and minimal mutation. Never assume an Atomic Red Team, CALDERA, custom script, or commercial simulation is safe merely because it is packaged as a test.

Applied exercise — end-to-end detection validation

1. Select one priority behavior and retrieve the current rule, data contract, runbook, owner, and last validation evidence.
2. Create a safe execution plan with exact command or action, target, test account, observers, time, expected artifacts, stop conditions, and cleanup.
3. Run the test. Capture every layer from action to case without altering timestamps or substituting screenshots for raw evidence.
4. Have an uninformed analyst triage the resulting alert using the production workflow. Record missing context and ambiguous guidance.
5. Fix the narrowest failing layer, rerun, publish evidence, set the next review, and keep limitations visible.

1200km: AdversaryGraph attack simulation · Validation case studies · Validated security telemetry