Build the read-only checkpoint summary

Aperta
  • Qualcosa non va?
#89 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
bash, powershell
Ambito
security

Direzione di ricerca

The planned module is sustain.health_monitor in phases/sustain/modules/health_monitor/. First read spec design 19 and issue #81, then write bats and Pester acceptance tests for the read-only checkpoint summary. Done when checkpoint runs on the full lab network with identical inventory and shows each accepted finding with its reason.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: probes phase: sustain platform: linux platform: windows type: build

Read first

Read these before starting. If this issue and the spec disagree, the spec wins; say so in the pull request.

Summary

Build checkpoint, one read-only command that sums up the whole network: scored services, integrity, persistence, known flaws and more. A team runs it at regular intervals, so every review covers the same ground. It changes nothing.

Depends on

  • Blocked by #81 (the persistence sweep, which checkpoint re-runs in report mode) and #44 (the login probes).
  • Uses the sealed baseline from #88 and the flaw tracker from #101 for their sections, when they exist; both come after the first usable release, so those sections say they are not built yet.
  • Blocks #91 (the scheduled health monitor, which runs checkpoint on a schedule), #95, #96 and #97 (the service packs), and #102 (service replacement).

Location & Context

  • Branch: phase-6/checkpoint. Module ID: sustain.health_monitor, in phases/sustain/modules/health_monitor/ (new). #91 builds the scheduled job in the same module, so keep checkpoint in its own entry point and helper files.
  • checkpoint is a new action in labyrinth.sh and labyrinth.ps1. Conventions section 3.3 says its name and letter are decided when it is built. Update the manual, docs/manual/labyrinth.md, in the same commit.
  • Tests: tests/phases/sustain/health_monitor/ (new; bats and Pester).

Current Behavior

There is no one-command review of the whole network, so the team cannot see at a glance whether the scored services and findings are in order.

Plan

  1. Build the read-only checkpoint summary. It prints one short summary and saves it to the report log category. Its sections and their sources are the table in design 19, section 5.
  2. Re-run the persistence sweep in report mode for its section.
  3. Build a section only when its source exists. The known-flaw section reads the tracker once #101 builds it.
  4. Run a login probe only when the operator starts checkpoint and a probe account is configured. Use no scoring account.
  5. Add checkpoint to both runners and the manual.

Acceptance tests

Write these first, in bats and Pester:

  • checkpoint completes on the full lab network within the target time and changes nothing (inventory identical before and after).
  • An accepted finding appears at every checkpoint with its reason (this one passes once #101 builds the tracker).
  • With a test mailbox configured, breaking mail logins in the lab makes the checkpoint's login probe fail even though the banner probe still passes (this one needs #44).
  • Negative test: protected accounts and scored services are untouched before and after.

Done when

  • The Linux and Windows versions both pass CI, including the real-host tests on the Ubuntu and Windows Server runners.
  • The manual and the module's help page (about.txt) are written.
  • The module is added to the shipped profiles that use it (profiles/).
  • The tests above pass in the lab (docs/lab/README.md).

Out of scope

  • The scheduled job, state-change alerts, firewall-drift alerts and scheduled checkpoints: #91.
  • The login probe kinds themselves: #44.
  • Seal and reseal: #88. The flaw tracker: #101.
  • The probe from outside the network: #90.
Lingua principale
PowerShell
Stelle
0
Fork
0
Merge medio
2h 7m
PR unite (30g)
53

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnetdork/Labyrinth

Tutte le issue di dotnetdork/Labyrinth

Issue simili

Altre issue su Security

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.