82 lines
4.5 KiB
Markdown
82 lines
4.5 KiB
Markdown
# IoT PreTester 4.6 Demo — Architecture
|
|
|
|
## Purpose and boundary
|
|
|
|
IoT PreTester 4.6 Demo analyzes existing `.pcap` and `.pcapng` files and turns packet-level observations into prioritized security findings. It is intentionally limited to network-capture analysis. Live capture, streaming, and firmware binary analysis are outside the demo scope.
|
|
|
|
## Runtime components
|
|
|
|
| Component | Responsibility |
|
|
| --- | --- |
|
|
| Next.js frontend | Authentication flow, device administration, capture upload, findings display, report download, and optional deep-analysis controls |
|
|
| Django REST backend | API, validation, persistence, user/device administration, and integration with the analysis core |
|
|
| `analyzer` package | Django-independent capture extraction, detection, scoring, provenance, and report rendering |
|
|
| SQLite | Demo persistence for devices, files, findings, extracted artifacts, and analysis status |
|
|
| tshark/pyshark | Protocol dissection and normalized capture extraction |
|
|
| nmap/hashcat | Optional, explicitly initiated endpoint probing and offline hash recovery |
|
|
|
|
## Analysis flow
|
|
|
|
1. The frontend sends the capture and metadata to the authenticated Django API.
|
|
2. Django validates the upload, stores it in a dedicated volume, and creates the database records.
|
|
3. `extract_pyshark.py` parses the capture once into a normalized `CaptureContext`.
|
|
4. Ten independent detectors evaluate that shared context.
|
|
5. The engine deduplicates and prioritizes findings, then attaches capture, packet, stream, and artifact provenance.
|
|
6. Django persists the result and extracted URL/hash artifacts.
|
|
7. The frontend displays findings and can request Markdown, text, or JSON reports.
|
|
8. Optional URL/hash enrichment runs only for artifacts selected by the user.
|
|
|
|
## Analysis package
|
|
|
|
```text
|
|
django_project/analyzer/
|
|
├── context.py Normalized capture data model
|
|
├── extract_pyshark.py PCAP/PCAPNG extraction
|
|
├── engine.py Detector orchestration and result assembly
|
|
├── findings.py Shared finding taxonomy
|
|
├── provenance.py Packet- and stream-level evidence references
|
|
├── scoring.py Deduplication and prioritization
|
|
├── artifacts.py URL and hash extraction
|
|
├── detectors/ Independent detection rules
|
|
├── enrich/ Optional active enrichment
|
|
├── reporting/ Markdown, text, and JSON output
|
|
└── tests/ Synthetic unit and regression tests
|
|
```
|
|
|
|
The package does not import Django. pyshark and external tools are loaded only at the integration points that need them, so detector tests can run on synthetic contexts without tshark.
|
|
|
|
## Finding model
|
|
|
|
Every detector produces the same core fields: ID, title, category, severity, confidence, affected device, source and destination, protocol, port, time range, evidence, risk description, recommendation, packet references, and stream references.
|
|
|
|
Severity measures the potential impact if a finding is true. Confidence measures how strongly the capture supports it. Keeping these dimensions separate prevents low-confidence indicators from being presented as confirmed critical events.
|
|
|
|
## Detector set
|
|
|
|
1. Plaintext credentials
|
|
2. Password hashes and challenge-response material
|
|
3. Session tokens and secrets
|
|
4. Malware or command-and-control beaconing
|
|
5. Possible data exfiltration
|
|
6. Man-in-the-middle and local network manipulation
|
|
7. Insecure or unexpected protocols
|
|
8. Weak or obsolete TLS
|
|
9. DNS anomalies and tunneling indicators
|
|
10. Brute force, scanning, and suspicious file transfer
|
|
|
|
## Design decisions
|
|
|
|
- Parse each capture once and share normalized records across all detectors.
|
|
- Keep detector logic isolated from persistence, presentation, and external tools.
|
|
- Preserve evidence provenance so every finding can be traced back to the capture.
|
|
- Keep active probing opt-in because authorization can differ from authorization to inspect a capture.
|
|
- Use a small demo wordlist by default to keep distribution compact and behavior predictable.
|
|
- Store complete analysis results as JSON while keeping extracted artifacts and job status queryable.
|
|
|
|
## Known demo limitations
|
|
|
|
- SQLite and in-process background threads are suitable for a controlled demo, not horizontal production scaling.
|
|
- Capture quality and protocol encryption directly limit what can be detected.
|
|
- URL probes observe the endpoint at probe time, which can differ from capture time.
|
|
- The demo does not provide live packet capture, multi-tenant isolation, or production identity-provider integration.
|