u/Technical-Tackle-875

Hi everyone. With the moderator team's permission, I wanted to introduce r/FederalCyber, an independent and unofficial community for public-source discussion spanning FedRAMP implementation, RMF and NIST controls, government cloud, ATO evidence, continuous monitoring, zero trust, incident response, and workforce questions.

r/FedRAMP remains the place for FedRAMP-specific discussion. The new community is intended for cross-cutting questions that sit between authorization, engineering, operations, and mission risk. The opening threads focus on evidence that controls actually work, inherited-responsibility gaps, vulnerability prioritization under VDR and VER, and how to share lessons without exposing protected operational details.

The boundaries are strict: no CUI, credentials, customer or agency identifiers, internal architecture, active incident data, nonpublic vulnerabilities, or implied government endorsement. Vendor link drops and low-effort promotion are not welcome.

If that broader scope fits your work, I would value your experience and criticism: https://www.reddit.com/r/FederalCyber/

The awkward part of Microsoft 365 incident response is rarely a single command. It is keeping identity containment, mailbox persistence checks, OAuth review, audit collection, collaboration data, and evidence handling in one coherent case while the clock is running.

I built an MIT-licensed PowerShell console that brings those workflows together without turning the executable into a module tree or deployment project.

It starts in Audit mode. Tenant changes are blocked, reviewed Graph write scopes are replaced with read-only alternatives, and an unknown write scope fails closed. Live operations require ShouldProcess, an operation-specific confirmation phrase, and a durable approval record.

Each case can include raw and normalized exports, a hash-chained JSONL action log, SHA-256 evidence manifests, an HTML report, threat-hunting queries, and a protected archive. It also records query ceilings, repeated pages, retention limits, and partial results instead of quietly presenting incomplete collection as complete.

The release has 68 deterministic offline tests, clean PSScriptAnalyzer results, Windows and Ubuntu CI, secret scanning, and a weekly import test against the current Microsoft module set. None of the automated testing authenticates to a tenant.

I would appreciate criticism from people doing DFIR work, especially on three questions:

1. Which Microsoft 365 artifacts are still missing from the default case?
2. Is the hash-chain and manifest model useful during a real response, or does it create unnecessary ceremony?
3. Where would you draw the boundary between guided collection and guarded containment?

Repository: https://github.com/fusiontechstrategies/M365-Incident-Response-Console

AWS Fault Injection Service is a strong execution engine. The harder operational problem is proving that the caller, account, region, targets, blast radius, stop conditions, recovery path, and evidence all match the experiment that was approved.

AWS Chaos Engineering Framework adds that control plane without trying to replace FIS. It uses FIS whenever AWS provides the fault, then supplies a guarded extension layer for scenarios FIS does not directly expose.

The framework includes:

- 60 executable experiment modes

- Plan mode by default, with no mutating AWS requests

- Exact account, partition, region, suite, and target binding

- Tag-scoped discovery combined with exact target allowlists

- CloudWatch alarm gates and continuous runtime safety checks

- Automatic recovery for reversible actions

- Dual approval for irreversible actions and safety bypasses

- GovCloud-aware region and ARN validation

- Atomic evidence reports with identifiers redacted by default

Reversible actions capture prior state before making changes. Rollback failures are reported as failures instead of being hidden behind a successful experiment status. Live execution requires temporary credentials by default, an exact confirmation token, approved target scope, and working stop conditions.

The runtime remains one Python file with no framework or database. Its release gate runs entirely offline using deterministic AWS clients, exercises every advertised executable mode, and fails if plan mode attempts a write.

This is deliberately disruptive software and should only be used in isolated, explicitly authorized test environments.

I would particularly value criticism of the boundary between FIS-managed actions and guarded service extensions. For teams operating in regulated AWS environments, what additional control would you require before approving a live experiment?

GitHub: https://github.com/fusiontechstrategies/AWS-Chaos-Engineering-Framework

I kept seeing AI safety controls treated as isolated filters, so I built an open-source enforcement layer that evaluates user input, retrieval context, and model output before anything is released.

The production runtime is a single Python file. Offline mode uses only the Python standard library and makes zero AWS calls. Optional integrations add Microsoft Presidio and Amazon Bedrock Guardrails.

A few design goals:

- Privacy-first redaction before optional cloud calls

- Local containment before cloud processing

- Strongest-control-wins decisions

- Metadata-only, hash-chained audit evidence

- Fail-closed production controls

- No implicit AWS clients

- Built-in self-test, red-team, chaos, and audit verification commands

- 163 automated tests with 85 percent branch-aware line coverage

- Windows and Linux support across Python 3.10 through 3.14

GitHub: https://github.com/fusiontechstrategies/Bedrock-Guardrail-Firewall

I would especially value feedback on the threat model, policy design, and deployment ergonomics.