OPERATOR GUIDE / EDITION 1
Show the system working.
A repeatable demonstration for students, faculty and external evaluators.
1. Open your laboratory
Open the application and select Start a private lab session. Your browser receives a random access key. It gives access only to this laboratory's evidence. There is no shared administrator password. This is an anonymous research workspace, not institutional sign-in. Keep this browser storage to return to the same session.
Records are saved on the server and remain available for seven days. Each session allows 200 events and 20 canary decoys. Download evidence before starting a new session or clearing browser storage.
2. Demonstrate one event
- Select Routine session and run it.
- Observe Events analysed increase by one.
- Select Repeated failed logins and run it.
- Open the event row. Explain the failed-login feature, anomaly score and the explicit threat-score floor.
- Refresh evidence. The records must remain.
The model may flag some routine synthetic events as anomalies. Anomaly detection is not ground truth; the event inspector distinguishes model output from rule-based severity.
3. Run the evaluator dataset
Download the eight-event sample dataset. Choose it in the application and select Analyse JSON dataset. The event count should increase by eight. The dataset includes routine activity, failed-login bursts, reconnaissance indicators and a long interactive session.
Import accepts a JSON array of 1–50 events, at most 48 KB. Use only documentation addresses under 192.0.2.*, 198.51.100.* or 203.0.113.*. Fields must be non-negative integers within the documented bounds. This public demonstration accepts synthetic data only.
| Field | Meaning / limit |
|---|---|
| command_count | Commands observed; 0–100,000 |
| session_duration_seconds | Session duration; 0–86,400 |
| failed_login_attempts | Failed logins; 0–1,000,000 |
| suspicious_command_count | Commands marked suspicious; 0–100,000 |
| source_ip | Documentation-only address |
4. Demonstrate a canary
- Create a harmless decoy named “Finance planning document”.
- Select Trigger beside that canary.
- Observe its trigger counter and a new Critical event.
- Open the event: it contains the canary identifier and the minimum score of 85.
- Set its status to Investigating, add an observation, and save.
- Refresh and reopen the event to prove the investigation record persists.
The trigger is a controlled button action. No real document has been planted on a network. It demonstrates how a real token interaction would enter the detection workflow.
5. Explain the honeypot correctly
A honeypot is a deliberately instrumented decoy service. It records activity directed at that decoy. This public system simulates its telemetry; it does not expose an SSH server or invite internet attacks. Running a scenario constructs an event, sends it to the API, evaluates it with the trained model, then saves it with its explanation.
For a future authorised Cowrie deployment, place the sensor in an isolated lab. An adapter should read its JSON logs, redact sensitive values, aggregate sessions, and authenticate to a separate sensor-ingest API. That adapter and real sensor deployment are future work; the public demonstration endpoint intentionally refuses real target addresses.
6. Present your findings
Download the evidence JSON and retain it with the project report. State the session date, scenarios run, event count, canary outcome and your interpretation of the rules versus the model. Do not claim detection accuracy from the supplied eight examples. They demonstrate workflow, not independent evaluation.
Troubleshooting
Session expired: start a new session. Concurrent update: refresh and retry. Request throttled: wait a few seconds and retry. Invalid dataset: use the supplied JSON and check the bounds. Session full: download evidence and start another. Data cannot be recovered with a username because this public lab does not create user accounts.