SIEM Configuration and Detection Rules

Step 1: Check Current Log Collection

Before you write any detection rules, check what the monitoring stack can actually see.

Open materials/alloy-config.river or ask Claude to show you the current Alloy configuration:

Show me the current Alloy configuration and tell me which log sources it collects.

The configuration collects only EHR web application logs. SSH and FTP logs are not being collected. This means your network service attacks from Unit 3 -- the brute-force against SSH, the anonymous FTP access -- are invisible to the detection pipeline. You attacked those services, but the monitoring stack cannot see the attacks.

This is a deliberate gap. Adding a log source is a visibility decision with security implications. You choose to collect SSH and FTP logs because you need to detect the attacks you just demonstrated.

Step 2: Add SSH and FTP Log Sources

Direct Claude to modify the Alloy configuration to collect SSH and FTP logs:

Modify the Alloy configuration to also collect SSH server logs and FTP server logs. Follow the pattern used for the EHR web logs. Use descriptive service labels.

AI commonly writes Alloy configuration that assumes standard log formats without checking the actual output of each service. A misconfigured format expectation produces one of two outcomes: either the logs arrive but the fields are wrong, or the logs are silently dropped. After modifying the configuration, verify that logs from all three sources actually appear in Loki.

Step 3: Design Labels

Label design in Loki is a structural decision, not a formatting choice. The labels you assign to log streams determine how the data is indexed, how queries perform, and what detection rules can match.

A flat label scheme like {job="docker"} for all services forces every query to filter by log content. That is slow and makes detection rules complex. A scheme that separates by service -- {service="ssh"}, {service="ftp"}, {service="ehr-web"} -- enables targeted queries. Your SSH brute-force detection rule can query only SSH logs without sifting through web traffic.

Review the labels Claude applied. If they are too generic, refine them:

Update the Alloy labels so each service has a distinct service label. SSH logs should be labeled service="ssh", FTP logs service="ftp", and the EHR web logs service="ehr-web".

Step 4: Verify the Pipeline

After changing the configuration, restart Alloy and verify that all three log sources arrive in Loki with correct labels and field structure.

Restart the Alloy service and verify that SSH, FTP, and EHR web logs are all visible in Loki with their distinct service labels.

Check each source: query {service="ssh"}, {service="ftp"}, and {service="ehr-web"} in Grafana's Explore view. If any source shows no results, the configuration has a problem -- either the file path is wrong, the label is misspelled, or the format expectation does not match the actual log output.

Step 5: Write SSH Brute-Force Detection Rule

Now write a Sigma rule for SSH brute-force detection. No starter template this time. You provide the structure -- logsource specification, field mapping, detection logic, severity level.

Write a Sigma rule that detects SSH brute-force attempts based on the SSH logs we are now collecting in Loki. I need the full rule structure including logsource, detection, and level fields.

AI generates rules from training data patterns. The field names in the rule may not match the actual field names in your Loki SSH logs. A rule that validates syntactically but references auth.user when the actual field is user will never fire. Before trusting the rule, verify that every field name in the detection section exists in the actual log entries.

This is where Dani Okafor might ask a pointed question: did you verify that the field name in the Sigma rule matches the actual Loki label structure for SSH logs?

Step 6: Write FTP Anonymous Access Detection Rule

Write a second Sigma rule, this time for FTP anonymous access. Different logsource, different fields, different pattern.

Write a Sigma rule that detects anonymous FTP connections. Use the FTP logs we configured.

The structure is different from the SSH rule. FTP anonymous access may produce a single connection event rather than a burst of failures. The detection logic must match this different pattern.

Step 7: Write SQL Injection Detection Rule

Write a third Sigma rule for SQL injection in the EHR web application. This revisits familiar ground from previous projects, but without the template structure.

Write a Sigma rule that detects SQL injection attempts in the EHR web application access logs.

Watch for a rule that is too broad. A rule matching "SELECT" in the access log will fire on every legitimate search the EHR application processes. The rule validates -- sigma check passes -- but it generates alerts on normal traffic. A detection rule that fires constantly trains the person monitoring to ignore it. That is worse than having no rule.

Step 8: Test and Tune Rules

Test each rule against the actual attack data from Unit 3. The rules must fire on your real attack traffic and not fire on legitimate application usage.

Convert the Sigma rules to LogQL and test them against the logs in Loki. Check if they fire on the attack patterns from our exploitation phase and whether they also fire on normal traffic.

Tuning is iterative. A rule that is too broad needs narrowing -- specific field values, time windows, threshold counts. A rule that is too narrow might catch only the exact attack you ran and miss variants. The judgment is finding the balance.

Step 9: Create Grafana Security Dashboard

Create a Grafana dashboard with security-relevant panels. This dashboard is a communication artifact, not just a monitoring tool.

Create a Grafana dashboard with three panels: failed SSH login attempts over time, FTP access events, and HTTP error rates by endpoint. Design it to answer security questions, not show generic metrics.

A dashboard for your own analysis and a dashboard you would show in a report are different. The panels should answer specific questions: Is anyone brute-forcing the login page? How many distinct source IPs are accessing FTP? Which web endpoints are seeing unusual error rates?