Deploy centralised logging and Sigma-based detections

With the pipeline from Lesson 32 producing a running application, this lesson connects Module 4's observability stack to it. You will ship application and infrastructure logs into a centralised store, structure them into searchable fields, and author a Sigma-based detection rule targeting a realistic malicious pattern, so the capstone system can actually notice when something goes wrong rather than only shipping secure code blindly.

Analogy🏏Cricket

🎬 Think of it like movies: a control room in a heist film lined with monitors, but the screens are worthless until someone wires the cameras in, labels each feed, and briefs a watcher on exactly what a break-in looks like. Shipping logs into a central store is connecting the cameras; structuring fields is labelling each feed clearly; the Sigma rule is the briefing that tells the watcher which movement is the intruder. Without all three, the room streams footage nobody can act on. This reveals why the capstone must notice trouble, not merely ship secure code into the dark.

Step 1 — Ship and structure logs. Configure a lightweight shipper to forward application logs, and, if your infrastructure includes it, cloud API or access logs, into your centralised store following Lesson 19's architecture. Ensure key fields such as timestamp, source IP, user identity, and event outcome are parsed into structured fields rather than left as raw text, since Lesson 21's Sigma rule in the next step depends entirely on those fields existing and being consistently named.

Analogy🏏Cricket

💼 Think of it like business: a finance team that cannot analyse spending until every receipt is entered into consistent columns — date, vendor, amount, category — rather than dumped as a shoebox of loose paper. Parsing logs into structured fields like timestamp, source IP, identity, and outcome is that data-entry discipline, and it exists entirely to serve the reporting that follows. A report written against column names that keep changing simply breaks. This reveals why structuring and consistently naming fields comes first, because the Sigma rule in the next step depends completely on those fields existing as promised.

json

# Example structured event your app should emit after parsing
{
  "@timestamp": "2026-07-04T03:02:11Z",
  "event.action": "login_failed",
  "user.name": "admin",
  "source.ip": "198.51.100.7",
  "app.name": "capstone-web"
}

Step 2 — Write and test the Sigma rule. Author a Sigma rule targeting a realistic pattern for your application, such as the brute-force-then-success pattern from Lesson 20 and Lesson 24, adapted to your app's actual field names. Trace it against a handful of sample log lines, both malicious and benign, exactly as Lesson 21 recommends, confirming it fires only when it genuinely should before converting it into your platform's native query.

Analogy🏏Cricket

♟️ Think of it like chess: studying a known mating pattern by replaying it against sample positions — some where the trap truly exists and some where it does not — until you trust yourself to recognise it only when it is really there. Authoring the Sigma rule for brute-force-then-success is learning that pattern, and tracing it across malicious and benign log lines is rehearsing the recognition. A player who never tests the pattern will see mates that aren't there and miss ones that are. This reveals why the rule is validated on both true and false examples before it becomes a live query.

yaml

title: Capstone App Brute Force Followed by Success
logsource:
  category: authentication
  product: capstone-web
detection:
  failures:
    event.action: 'login_failed'
  success:
    event.action: 'login_success'
  timeframe: 10m
  condition: failures | count(by source.ip) >= 5 and success
level: high
tags:
  - attack.credential_access
  - attack.t1110

Step 3 — Wire the alert to a simple automated response. Following Lesson 22's SOAR pattern at a small scale, configure at minimum a notification action, and if your tooling supports it, an automated enrichment step such as looking up the source IP's reputation, so the alert does not just sit silently in a dashboard. This response layer is what Lesson 34's simulated attack will actually trigger and verify end to end.

Analogy🏏Cricket

⚽ Think of it like sports: a stadium's goal-line technology is useless if the buzz never reaches the referee's watch — the detection has to drive an immediate action on the field, not just light up a screen nobody is watching. Wiring the Sigma alert to a notification, and optionally an IP-reputation enrichment, is that instant signal to the official, turning a passive observation into a played whistle. An alarm that only decorates a dashboard changes nothing at all. This reveals why the response layer is built now, because it is exactly what the next lesson's simulated attack will trigger and verify.

yaml

trigger: sigma_rule == "Capstone App Brute Force Followed by Success"
steps:
  - action: notify(channel="#capstone-alerts", summary=alert.summary)
  - action: enrich_ip_reputation(alert.source_ip)   # optional, if tooling supports it

Step 4 — Confirm visibility end to end. Generate a handful of benign log events and confirm they appear correctly structured in your centralised store, then set the detection aside without yet triggering it for real, since Lesson 34 will do that deliberately as a controlled test. Document your log schema and Sigma rule clearly, since Lesson 35's portfolio submission will reference both as evidence of this working detection layer.

Analogy🏏Cricket

🎮 Think of it like gaming: before a boss fight you run a safe practice lap to confirm your HUD, health bar, and minimap all display correctly, without actually engaging the boss yet. Generating benign log events and checking they appear correctly structured is that practice lap — you verify the instrumentation works while deliberately not springing the real encounter, which the next level handles as a controlled test. Skipping the check means discovering a broken HUD mid-fight. This reveals why you confirm visibility and document the schema now, saving the deliberate trigger for the lesson designed around it.

Connect Module 4's observability stack to the pipeline's running application.
Ship and structure logs first, since detection rules depend on consistent field names.
Write a Sigma rule for a realistic pattern and trace it against sample data before trusting it.
Wire the alert to at least a basic automated notification or enrichment response.
Confirm log visibility end to end before deliberately triggering the rule in Lesson 34.

Analogy🏏Cricket

🎵 Think of it like music: a live sound engineer at a mixing desk who only catches feedback because every microphone is patched in, each channel is labelled, and their trained ear knows the exact squeal to kill. Centralised logging patches in the channels, structured fields label them, and the Sigma rule is the trained ear picking the one dangerous frequency out of the mix. A desk with unplugged inputs hears nothing worth reacting to. This reveals why this whole detection layer only earns its place once shipping, structuring, and alerting are wired together as one responsive system.