tinysocs-diagnostics-and-tooling

Verify TinySocs SIEM health, alert pipeline, ledger integrity, and retention with diagnostic tooling.

Updated Oct 12, 2025
One-click install
npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-diagnostics-and-tooling-lukefitzg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tinysocs-diagnostics-and-tooling
Source: https://github.com/lukefitzg/tinysocs/tree/main/.claude/skills/tinysocs-diagnostics-and-tooling
Command: npx skills add https://github.com/lukefitzg/tinysocs --skill tinysocs-diagnostics-and-tooling-lukefitzg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Operators of a TinySocs SIEM install often cannot tell whether the detection pipeline is actually working — health checks show ambiguous WARN/INFO rows, smoke tests have historically shipped broken, and naive OpenSearch queries produce false misses. This Skill provides verified, measurement-only procedures to prove whether event collection, detection, alerting, ledger integrity, and retention purging are genuinely functioning. ## Core Features & Use Cases - Health Check Interpretation: Explains all 16 Test-TinySocsHealth checks, which are structurally INFO/WARN on a minimal install, and why the literal $allPassed value — not the PASS count — is the real verdict. - End-to-End Smoke Test: Documents Invoke-TinySocsSmokeTest, which fires 20 failed logons to trip the TS-001 brute-force rule (threshold 15), including the historical scar where the committed test could never fire. - Direct Pipeline Queries: Provides curl.exe-based OpenSearch query patterns (day-index scoping, detection-floor timestamps, _source projection) that avoid PowerShell 5.1 TLS and ConvertFrom-Json pitfalls. - Coverage, Ledger, and Storage Diagnostics: Covers mitre_coverage.py regeneration, check_ledger.py --verify chain/anchor validation, ISM policy binding checks, purge endpoints, and agent disk-queue inspection. - Use Case: After a fresh install, run the 10-minute prove-the-pipeline runbook to confirm Windows audit events flow through the agent, OpenSearch, and detection engine into a real TS-001 alert document. ## Quick Start Ask the assistant to run the TinySocs health check and smoke test on this install and prove the alert pipeline works end to end.

Frequently Asked Questions about tinysocs-diagnostics-and-tooling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my TinySocs install is working?

Run Test-TinySocsHealth from the TinySocs.Installer.psm1 module in an elevated PowerShell on the host. Read the literal $allPassed return value rather than counting PASS lines, since WARN-severity heartbeat failures still flip the overall result to unhealthy.

How do I test that TinySocs detection fires an alert end to end?

Run Invoke-TinySocsSmokeTest, which generates 20 failed logons for a nonexistent user to trip the TS-001 brute-force rule (threshold 15 in 5 minutes), then confirms the alert count in tinysocs-alerts-* increased after a 30-second detection cycle.

Why does the TinySocs health check show WARN or INFO on a fresh install?

Checks 12-15 report INFO by design when webhook, SMTP, or Sysmon are not configured, so a minimal install never shows 16/16 PASS. Only FAIL-severity checks and the stale/missing heartbeat path indicate real problems.

Why does my OpenSearch alert query return zero results in PowerShell?

PowerShell 5.1's TLS stack silently fails against the bundled OpenSearch self-signed certificate, making Invoke-RestMethod return empty results. Use curl.exe -sk instead, scope queries to today's day index, and project _source to avoid ConvertFrom-Json hangs.

Does the TinySocs MITRE coverage report reflect rules that actually run?

Not entirely. mitre_coverage.py merges the live C# engine rules with a 50-rule Python catalogue that never executes in production, and it counts disabled rules as covered. Disambiguate engine-covered versus catalogue-covered techniques before quoting numbers externally.

When should I not use these TinySocs diagnostics tools?

Use them only to measure state, not to fix failures or judge rule efficacy. Remediation belongs in the debugging playbook, Atomic Red Team validation in the validation toolkit, and installer or retention design questions in the run-and-operate documentation.