39. Operations and Settings

Operations is a single administrator page for running a module operation against a target you choose, with every parameter shown before it starts. Settings holds the platform-wide configuration.

Settings tabs and where each is described:

39.1 Operations#

Path: Operations (shown to administrators only; others see "Operations are restricted to administrators."). "Run a module operation against a target you choose. Every parameter is shown before the operation starts."

Procedure: run an operation#

1. Open Operations and choose the operation in the Operation list.
2. Fill its fields. The About to run box shows exactly what will be sent; until the fields are complete it says "Choose the values above to enable this."
3. Press the button.
4. Read the result in the Execution log (newest first). Clear empties the log; it only lives in this browser session.

Auto-remediate an incident runs the matching remediation playbooks against the affected host. It asks "Run remediation playbooks for incident <id>? This changes state on the affected hosts." Risk: containment on that host (chapter 36). Rollback: undo each resulting action in Defense (chapter 36). With no open incident there is nothing to act on, and the page says so.

The same operations exist in their modules: chapters 22, 28, 32, 33 and 36.

39.2 Who can open Settings#

The Administration > Settings sidebar entry is shown to administrators. Each tab then checks its own permission; a tab you may not use shows a "permission required" panel.

39.3 Settings > Platform#

Path: Settings (the Platform tab). "Backend health, licence posture, role permissions and sandbox data controls."

Changing the licence and staging an update are critical actions: four-eyes yes by default.

Diagnostics for support#

Diagnostics for support "Builds an archive describing this deployment: version and build id, effective configuration, row counts, migration state, worker health and the end of the application log." Configuration values are reduced to a length and a hash, and tables are reported as counts; collected logs, findings and incidents are not included. Attach it to your message to [email protected].

39.4 Setup#

Path: Settings > Setup. "What this deployment still needs. Recomputed on every visit from the live state, so a step that stops being true comes back."

A blocking step stops the platform serving requests until resolved. An optional step degrades one feature only; its detail line says which.

1. Open Settings > Setup and read each step's state and detail line.
2. Follow a step's link to fix it in the console. Steps without a link are set in .env and read at start-up: edit .env, then run sudo ./lawliet start.
3. Press Re-check to recompute the list.

39.5 What outbound email is used for#

Password-reset links, scheduled report delivery (chapter 25) and notification mail (39.6). Without it, reports are still produced and downloadable, and notifications still reach the bell.

39.6 Settings > Notifications#

Path: Settings > Notifications. "What the bell shows you. Applies to your account only."

1. Under Categories tick what you want:

2. Under Show choose Everything, Warnings and critical or Critical only.
3. Tick Pop up new critical items for a toast while the console is open.
4. Press Save changes. You see "Notification settings saved".

Webhook and email delivery are set for the whole deployment in .env (NOTIFY_WEBHOOK_URL, NOTIFY_EMAIL_RECIPIENTS). Everything they send also appears in the bell.

39.7 Settings > SIEM forwarding#

Sends security events to your SIEM as they happen, in CEF, LEEF, RFC 5424 syslog or JSON.

Permission: Manage SIEM forwarding (also needed to see the page). Four-eyes: adding, editing and removing a destination is the critical action "Change SIEM forwarding", which is off by default; your policy may turn it on. Sending a test event needs no approval. SIEM forwarding is a licensed (enterprise) feature; without it the page says "Not included in this licence".

What you see: Forwarder, Destinations enabled, Queue, Dropped, and the destinations table (Health, Target, Sent, Last delivery, Test, delete).

Procedure: add a destination#

Risk: security events, including user names and host names, leave the platform. Send them only to a collector your organisation controls. Rollback: delete or disable the destination.

1. Press Add destination.
2. Fill the form:

3. Press Create destination (or Save changes when editing). If four-eyes applies, complete the request (20.4).
4. Press Test on the row. You see "Test event delivered to <name>." or the error.

If certificate checking is off, the page warns: "Certificate checking is off. Anyone able to intercept traffic to this collector can read your security events and alter them in transit." The row shows "unverified TLS". Give the collector a certificate your server trusts instead.

If it fails: Test shows the delivery error (connection refused, timeout, TLS failure, HTTP status). Check the address, the port, the network path from the Lawliet server, and the token. A growing Dropped count means events were not delivered; check the destinations' Health.

Procedure: change, pause or delete a destination#

Permission: Manage SIEM forwarding. Four-eyes: only if your policy turns on "Change SIEM forwarding" (off by default). Risk: while a destination is paused or deleted, events are not sent to that SIEM. Rollback: tick Enabled again, or add the destination again.

To change it:

1. Open Settings > SIEM forwarding and click the destination's name. The form opens with its values; the auth header value is not shown ("blank keeps the current one").
2. Change the fields and press Save changes (the button next to it cancels).
3. Press Test on the row to confirm delivery.

To pause it: open it, untick Enabled, press Save changes. Tick it again to resume.

To delete it:

1. Press the bin on the row.
2. Confirm "Delete <name>? Events will stop being forwarded there immediately."
3. What you see: "<name> deleted."

39.8 Settings > Users, Access control, Authentication, API keys, Audit trail#

Described in Users, roles and approvals and Active Directory.

39.9 Settings > Sandbox#

Path: Settings > Sandbox (visible to users with Manage settings, and to sandbox accounts). "Seeds or clears a synthetic dataset across every module for demonstration and local testing." Every sandbox row is flagged as sandbox data and kept apart from real data.

Permission: the controls are shown to users with Manage settings; seeding and clearing also need Manage demo data. Four-eyes: the critical action "Clear or seed demo data" is off by default. A sandbox account can view the dataset but never change it.

1. Read Current contents.
2. Press Seed sandbox data (or Re-seed sandbox - "Re-seeding is idempotent - it refreshes the dataset rather than duplicating it.").
3. To remove it, press Clear sandbox data. Real data, real agents and real users are not touched.

Do not seed sandbox data on a production deployment unless you are demonstrating; it shows on the Overview with the banner "Sandbox data is active".