1---2name: linux-ngo-cyber-resilience3description: Use when designing or reviewing practical Linux security and incident resilience for NGOs, civil-society organisations, or small mission-led teams; use linux-server-hardening for host controls and linux-disaster-recovery for backup restoration.4---56# Linux NGO Cyber Resilience78Adapt security to the mission, people, data, budget, and threat exposure of a9civil-society organisation. This route coordinates host controls, identity,10communications, evidence, and recovery; it does not claim that a Linux host11alone secures the organisation.1213<!-- dual-compat-start -->14## Distro support1516| Family | Support posture |17|---|---|18| Debian/Ubuntu | Primary examples; verify package and service names on the target release |19| RHEL/Fedora/Rocky/Alma | Supported with family-specific package, SELinux, and service checks |20| Other Linux | Apply the control intent and document the unverified command translation |2122## Use When2324- An NGO needs a proportionate cyber-resilience baseline across Linux hosts and staff workflows.25- A team needs to prepare for phishing, ransomware, spyware, CEO fraud, or information manipulation.26- A security plan must connect prevention, detection, response, recovery, and board accountability.27- A donor, partner, or incident review requires evidence of controls without pretending that policy equals operation.2829## Do Not Use When3031- The task is one host hardening change; use `linux-server-hardening`.32- The task is backup design or restore execution; use `linux-disaster-recovery`.33- The task needs attribution or legal conclusions; preserve evidence and route to the appropriate authority.3435## Required Inputs3637| Artefact | Source | Required? | If absent |38|---|---|---|---|39| Mission, people, systems, data, and dependency map | Programme and technology owners | yes | Build a qualified priority map and mark unknowns |40| Threat and incident history | Incident owner and trusted partners | conditional | Use a conservative threat route and record the gap |41| Host, identity, backup, and communications evidence | Administrators and service owners | yes | Separate designed from operating controls; mark NOT ASSESSED |42| Budget, skills, and partner constraints | Board or change owner | conditional | Produce a staged plan with explicit dependencies |4344## Outputs4546| Artefact | Consumer | Acceptance condition |47|---|---|---|48| Mission-aware cyber-resilience assessment | Board and incident owner | Prioritises harm, dependencies, owners, evidence, and residual risk |49| Linux control checklist | Administrators and service owners | Each selected control has evidence, exception, recovery action, and test |50| Incident response and recovery handoff | Incident owner and communications lead | Preservation, containment, trusted communication, recovery, and learning steps are explicit |5152## Quality Standards5354- Protect people, affected communities, and mission data, not only servers.55- Treat accounts, domains, email, endpoints, and third parties as attack surfaces.56- Use least privilege, MFA where available, patching, tested backups, logging, and safe recovery.57- Preserve incident evidence and avoid destructive cleanup before deciding what must be retained.58- Mark missing monitoring, partner support, or recovery proof as `NOT ASSESSED`.59<!-- dual-compat-end -->6061## Decision Rules6263| Finding | Action | Failure or risk avoided |64|---|---|---|65| A control reduces a likely, high-harm path and fits available capacity | Prioritise it and assign an evidence owner | Spending effort without reducing material mission harm |66| A control exists only in policy | Rate design separately and schedule an operating test | Mistaking written intent for protection |67| A suspected account or domain impersonation is active | Contain safely, preserve evidence, verify trusted channels, and notify the incident owner | Further fraud, unsafe communication, or lost evidence |68| Ransomware or destructive access is suspected | Isolate affected systems, preserve evidence, activate recovery, and do not reconnect from an unverified state | Reinfection and irreversible evidence loss |69| A small NGO cannot operate a control alone | Use a trusted collective, managed provider, or partner and record the dependency | An unowned control failing silently |7071## Workflow72731. **Empower:** assign board-level accountability, staff reporting routes, a74 named incident owner, and a small set of mission-critical priorities.752. **Enable:** secure budget, training, trusted technical help, domain/email76 protection, and a recovery relationship before an incident.773. **Identify:** map assets, identities, data, dependencies, exposed services,78 likely actors, phishing paths, and harm to people or programmes.794. **Protect:** apply host hardening, patching, MFA, least privilege, secret80 handling, encryption, safe admin access, tested backups, and staff practice.815. **Detect:** centralise useful logs, monitor authentication and privileged82 changes, establish reporting for suspicious messages, and retain time-linked83 evidence.846. **Respond and recover:** isolate, preserve, communicate through trusted85 channels, reset and restore in a controlled order, validate integrity, and86 conduct a no-blame learning review.877. Record residual risk, owner, due date, dependency, evidence, and the next88 exercise. Re-test after staff, systems, or threat conditions change. Stop89 the route when evidence, authority, or a safe recovery path is missing.9091## Anti-patterns9293- Buying a tool without assigning an operator. Fix: name the owner, daily action, evidence, and fallback.94- Treating awareness training as the whole security plan. Fix: pair behaviour controls with identity, host, backup, and response controls.95- Wiping a compromised host before preserving evidence. Fix: contain safely and follow the incident evidence route.96- Restoring backups without testing integrity or credentials. Fix: use a staged restore, validation checks, and credential rotation.97- Publishing incident details before confirming affected people and trusted channels. Fix: coordinate facts, safety, and communications.98- Copying enterprise controls that the NGO cannot operate. Fix: choose a smaller control set with real evidence and partner support.99100## Read next101102- `linux-server-hardening` for host-level configuration.103- `linux-access-control` and `linux-secrets` for identity and secret controls.104- `linux-intrusion-detection` and `linux-log-management` for detection evidence.105- `linux-disaster-recovery` for backup and restoration.106- `linux-troubleshooting` for bounded diagnosis and recovery.107108## References109110- [NGO cyber-resilience cycle](references/ngo-cyber-resilience-cycle.md)111112## Capability Contract113114Read and search are required. Execution is limited to approved validation or115administration scope; this skill never authorises destructive response actions by116itself.117118## Degraded Mode119120If host evidence, incident facts, or recovery proof is unavailable, produce a121prioritised plan, preserve the gap, and mark the affected control `NOT ASSESSED`.122123## Evidence Produced124125| Artefact | Acceptance condition |126|---|---|127| Control register | Each priority control has an owner, evidence, exception, and recovery action |128| Incident handoff | Containment, evidence preservation, communication, recovery, and learning steps are named |129130## Worked Example131132An NGO with a shared Linux file server and suspected phishing begins by naming the133programme owner, preserving the suspicious message and authentication logs,134checking recovery access, and isolating only affected accounts or hosts. It then135enforces MFA and least privilege where feasible, tests a clean staged restore,136communicates through a verified channel, and records residual risk rather than137claiming the incident is closed because a password was reset.
peterbamuhigire