Network threat detection: turn three failed logins into a question.
Count failures in fictional logs and build a small detection rule. Learn why an alert is evidence to investigate, not proof of an attacker.
An alert starts an investigation
Network security combines inventory, segmentation, secure transport, updates and useful logs. Detection asks a narrower question: what behaviour deserves a closer look? This exercise counts failed logins in a tiny, invented dataset. It captures no network traffic and collects no household activity.
Run a local detector
Save this as login_demo.py, then run python3 login_demo.py. Python 3 is the only requirement. The addresses below are reserved documentation examples.
from collections import Counter
# Fictional events only; no files or network connections are read.
events = [
{"source": "192.0.2.10", "result": "failed"},
{"source": "192.0.2.10", "result": "failed"},
{"source": "192.0.2.10", "result": "failed"},
{"source": "198.51.100.20", "result": "success"},
]
failures = Counter(e["source"] for e in events if e["result"] == "failed")
for source, count in failures.items():
if count >= 3:
print(f"REVIEW {source}: {count} failed attempts in this sample")
Expected output: REVIEW 192.0.2.10: 3 failed attempts in this sample. Change one failure to success and run again. The threshold no longer fires. That visible change makes a useful video comparison.
Where the simple rule falls short
This example has no timestamps, rolling window, user identity or baseline. It does not detect an actual intrusion. Shared addresses, mistyped passwords and health checks can create false positives; a distributed attack can stay below a per-address threshold.
For a real service you own, preserve original timestamps and investigate the account, result and surrounding events. Do not automatically block an address because this toy script prints it.
Add the defence to the demonstration
Show how MFA, rate limiting, secure session handling and useful audit logs address different parts of the problem. Re-run a controlled test with a dummy account and compare the recorded outcomes. Never publish real tokens, passwords, IP inventories or customer logs.
HTTPS protects content in transit between TLS endpoints; it does not make every application request legitimate. Network visibility also does not automatically reveal end-to-end encrypted messages.
Reference: NIST incident-response guidance, SP 800-61 Rev. 3. Use a documented process to assess alerts and respond. Source checked: 22 October 2026.