Hardening the SIEM and Remediation

Step 1: Apply CIS Benchmark to the Wazuh deployment

Open materials/cis-wazuh-benchmark-extract.md. This extract contains benchmark items relevant to hardening a Wazuh deployment in a Docker environment -- default credentials, API access controls, TLS configuration, dashboard authentication, agent registration security, network exposure.

The monitoring system is infrastructure that itself needs hardening. Wazuh stores security events from all three portals. If an attacker compromises the SIEM, they can read the detection rules, understand what is monitored, and modify the evidence. A monitoring system that cannot be trusted undermines every detection decision built on top of it.

Direct AI to assess the Wazuh deployment against the benchmark items. AI applies all items indiscriminately -- it does not distinguish between items critical for a production government deployment and items irrelevant for a Docker lab environment. Your judgment determines which items matter for the Bhutan Tourism Council's context and which are lower priority given the deployment model.

Step 2: Remediate the SQL injection

Address the SQL injection finding from Unit 2. This is prevention-plus-detection pairing -- the fix and the detection rule working together.

Direct AI to implement the fix for the Tourism Services Portal's search endpoint. The injection exists because user input is concatenated directly into the SQL query. The fix replaces string concatenation with parameterized queries.

After the fix is in place, verify it works. Re-run sqlmap against the same endpoint.

The output should show that the previously injectable parameter is no longer vulnerable. Same tool, same target, different result. That is the remediation verification.

Now check the detection rule. Re-run an injection attempt against the patched endpoint. The attack fails -- the parameterized query prevents the injection. But the detection rule should still fire. The attacker's malicious input still appears in the request logs even though the application no longer executes it. Prevention and detection are independent controls.

Verify the detection fires on both Loki and Wazuh. The prevention happens in the application code. The detection happens in the monitoring systems. Both must work.

Step 3: Remediate the API authentication bypass

The API authentication bypass is the most critical finding. The internal APIs between portals allow unauthenticated access to tourist data and guide credentials across system boundaries.

Direct AI to implement authentication for the internal API endpoints. This requires changes across multiple portals -- the tourism portal's API endpoint, the guide system's cross-portal calls, and the operations platform's aggregation endpoints all need authentication added.

Test the fix by attempting the same unauthenticated API calls that worked in Unit 2. They should now fail with authentication errors. Then verify the detection rule fires on attempts to use the API endpoints without credentials.

AI commonly fixes one portal's endpoints without checking that the fix works across the full communication path. The APIs connect three systems -- test the authentication from each direction.

Step 4: Handle the scope creep

Tshering forwards a memo from the Ministry of Information and Communications. The Ministry asks whether the detection capability should also cover a new visa application portal being developed by the Ministry of Foreign Affairs.

This is a different agency's system. It is outside the scope of the Bhutan Tourism Council engagement. The student's job is to set this boundary professionally.

Open the living client interface and respond. Recommend a separate assessment for the visa portal. Note integration points where the two systems might eventually connect. Keep the current engagement focused on the three BTC portals and the directive deadline. Tshering respects clear boundary-setting -- it aligns with how government projects should be managed. She will accept the recommendation and appreciate the integration points being noted for future planning.

Update the scope document to reflect this decision. The out-of-scope section should now explicitly include the visa application portal with a reference to the Ministry memo.

Step 5: Verify portal functionality

The directive requires that all three portals remain operational throughout the assessment. Remediation changes application code -- verify that nothing broke.

Open each portal and test core functionality. The Tourism Services Portal should still serve tourist information and process search queries (without the injection). The Guide Management System should still handle credential lookups. The Internal Operations Platform should still manage documents and staff communications.

Run the environment verification script.

bash materials/scripts/verify-environment.sh

If a portal is broken, the remediation introduced a regression. Fix it before proceeding. A remediation that patches a vulnerability but breaks the service is not a complete fix -- especially when the client explicitly constrained operational continuity.