docs: add security guides

foomo/blog/authors.yml

@@ -5,7 +5,7 @@ jan:
   image_url: https://github.com/janhalfar.png
 philipp:
   name: Philipp Mieden
-  title: MSc
+  title: Security & Network Engineer
   url: https://github.com/dreadl0ck
   image_url: https://github.com/dreadl0ck.png
 marko:

foomo/docs/general/security.md

@@ -1,12 +0,0 @@
-# Security
-
-TODO: @dreadl0ck knock yourself out
-
-## OS / Application setup
-
-- disable telemetry whereever possible
-
-## Keep your data safe
-
-- encrypt your file system to make sure so that if your computer gets stolen at least your data remain secure
-- make sure to have multiple backups in different places i.e. one backup disk at home and one in the office

foomo/docs/security/containers.md

@@ -0,0 +1,202 @@
+---
+title: Container Security
+slug: /security/containers
+---
+
+This document outlines best practices for securing Docker containers, from building images to running them in production. The information is largely based on the excellent [container-security-checklist by krol3](https://github.com/krol3/container-security-checklist).
+
+## Table of Contents
+
+- [Secure the Build](#secure-the-build)
+  - [Image Hardening](#image-hardening)
+  - [Image Scanning](#image-scanning)
+  - [Image Signing](#image-signing)
+- [Secure the Container Registry](#secure-the-container-registry)
+- [Secure the Container Runtime (Docker)](#secure-the-container-runtime-docker)
+- [Secure the Infrastructure](#secure-the-infrastructure)
+- [Secure the Data](#secure-the-data)
+- [Secure the Workloads (Running Containers)](#secure-the-workloads-running-containers)
+
+## Secure the Build
+
+The security of a container begins with the image from which it is built. A compromised or poorly constructed image can introduce vulnerabilities into every container that uses it.
+
+### Image Hardening
+
+Hardening an image involves minimizing its attack surface. The fewer components an image contains, the fewer potential vulnerabilities it has.
+
+*   **Use minimal base images**: Always start with the smallest possible base image that your application can run on.
+    *   [**Distroless**](https://github.com/GoogleContainerTools/distroless) images from Google are a great choice as they contain only your application and its runtime dependencies, without package managers, shells, or other utilities.
+    *   [**Alpine Linux**](https://alpinelinux.org/) is a popular choice due to its small size (around 5MB).
+    *   Many official images have a `slim` or `alpine` tag (e.g., `python:3.9-slim`, `node:16-alpine`) that provides a smaller version of the image.
+
+*   **Remove unnecessary tools**: Do not include debugging tools (like `curl`, `netcat`), shells, or any utilities not strictly required by your application in a production image. An attacker who gains access to a container can use these tools for malicious activities.
+
+*   **Run as a non-root user**: By default, containers run as the `root` user. This is a significant risk. If an attacker compromises the container, they will have root privileges inside it. Use the `USER` instruction in your `Dockerfile` to specify a non-root user for the application to run as.
+
+    ```dockerfile
+    FROM alpine:latest
+
+    # Create a non-root user and group
+    RUN addgroup -S appgroup && adduser -S appuser -G appgroup
+
+    # Switch to the non-root user
+    USER appuser
+
+    WORKDIR /app
+    COPY . .
+    CMD ["./my-app"]
+    ```
+
+*   **Use multi-stage builds**: [Multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/) are a powerful feature that allows you to use multiple `FROM` instructions in a single `Dockerfile`. This lets you compile your code or build assets in a "build" stage with all the necessary dependencies and tools, and then copy only the final artifacts into a clean, minimal "runtime" stage. This prevents build tools and dependencies from being included in the final production image.
+
+    ```dockerfile
+    # ---- Build Stage ----
+    FROM golang:1.19-alpine AS builder
+    WORKDIR /src
+    COPY . .
+    # Build the application
+    RUN CGO_ENABLED=0 go build -o /out/my-app .
+
+    # ---- Runtime Stage ----
+    FROM gcr.io/distroless/static-debian11
+    # Copy the built application from the builder stage
+    COPY --from=builder /out/my-app /
+    # Set the entrypoint
+    ENTRYPOINT ["/my-app"]
+    ```
+
+### Image Scanning
+
+Automated scanning is crucial for identifying known vulnerabilities and secrets before they reach production.
+
+*   **Scan for vulnerabilities**: Integrate image scanning into your CI/CD pipeline. This will check your image's components against databases of known Common Vulnerabilities and Exposures (CVEs).
+    *   [**Trivy**](https://github.com/aquasecurity/trivy) by Aqua Security
+    *   [**Clair**](https://github.com/quay/clair) by Quay
+    *   [**Anchore**](https://anchore.com/)
+
+    Example with Trivy:
+    ```bash
+    # Scan an image for vulnerabilities
+    trivy image my-app:latest
+    ```
+
+*   **Scan for secrets**: Never hardcode secrets like API keys, passwords, or tokens in your `Dockerfile` or image layers. Use tools to scan for secrets that may have been committed by accident.
+    *   [**GitGuardian Shield**](https://www.gitguardian.com/gitguardian-shield)
+    *   [**detect-secrets**](https://github.com/Yelp/detect-secrets) by Yelp
+
+### Image Signing
+
+Image signing provides a level of trust by ensuring the integrity and authenticity of an image. It verifies that the image you are running is the one that the publisher intended to release and has not been tampered with.
+
+*   **Use Docker Content Trust**: Enable [Docker Content Trust](https://docs.docker.com/engine/security/trust/) by setting the environment variable `DOCKER_CONTENT_TRUST=1`. This uses cryptographic signing to verify that images have been signed and are from a trusted source. It implements [The Update Framework (TUF)](https://theupdateframework.io/), a security framework to protect against various types of supply chain attacks.
+
+    ```bash
+    # Enable content trust for the current shell session
+    export DOCKER_CONTENT_TRUST=1
+
+    # With content trust enabled, 'docker pull' will only fetch signed images
+    docker pull my-app:latest
+
+    # Push an image with a signature
+    docker push my-registry/my-app:latest
+    ```
+
+## Secure the Container Registry
+
+The registry is where your images are stored. Securing it is as important as securing the images themselves.
+
+*   **Control access**: Use Role-Based Access Control (RBAC) to enforce the principle of least privilege. Only grant permissions to push images to specific users or service accounts that are part of your CI/CD pipeline. Similarly, restrict pull access to only those hosts and services that need to run the container.
+
+*   **Use a private registry**: For non-public images, always use a private registry (like Docker Hub private repos, Amazon ECR, Google Artifact Registry, or a self-hosted one like Harbor) that is protected behind your firewall. This reduces the risk of image tampering and unauthorized access.
+
+## Secure the Container Runtime (Docker)
+
+Securing the Docker daemon and its configuration is critical to prevent a container compromise from escalating to a host compromise.
+
+*   **Secure the Docker daemon**:
+    *   The Docker daemon socket (`/var/run/docker.sock`) is a Unix socket that the Docker CLI and other tools use to communicate with the daemon. **Access to this socket is equivalent to root access on the host.**
+    *   Never expose it over an unencrypted TCP socket. If you need remote access, use [TLS to encrypt the connection](https://docs.docker.com/engine/security/protect-access/).
+    *   Avoid mounting the socket inside containers. If a container needs to interact with the Docker API, consider using a secure proxy instead.
+
+*   **Use rootless mode**: Running the Docker daemon in [rootless mode](https://docs.docker.com/engine/security/rootless/) executes the daemon and containers as a non-root user. This significantly mitigates the impact of a potential container breakout vulnerability, as the attacker would only gain the privileges of that unprivileged user on the host.
+
+*   **Enable user namespaces**: [User namespaces](https://docs.docker.com/engine/security/userns-remap/) isolate containers by mapping the `root` user in a container to a non-privileged user on the host. This means that even if a process breaks out of the container as root, it will have very limited permissions on the host system.
+
+*   **Don't disable security profiles**: Docker uses several Linux security features by default to protect the host. Do not disable them unless absolutely necessary.
+    *   [**seccomp**](https://docs.docker.com/engine/security/seccomp/): Restricts the system calls a container can make. Docker applies a default profile that blocks about 44 syscalls out of 300+. Running with `--security-opt seccomp=unconfined` disables this protection.
+    *   [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) / [**SELinux**](https://docs.docker.com/engine/security/selinux/): Linux Security Modules that provide mandatory access control (MAC) to further confine container processes.
+
+## Secure the Infrastructure
+
+Because containers share the host's kernel, a vulnerability in the host can compromise all containers running on it.
+
+*   **Keep the host patched**: This is one of the most critical aspects of container security. Regularly apply security patches to the host operating system and kernel to protect against known vulnerabilities that could lead to container escapes.
+
+*   **Use CIS Benchmarks**: The Center for Internet Security (CIS) provides benchmarks for hardening various operating systems and container platforms, including Docker and Kubernetes. Follow the [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker) to secure your host configuration.
+
+*   **Isolate containers**: In addition to Docker's built-in isolation, using security modules like SELinux or AppArmor provides a robust second layer of defense, making it much harder for a compromised container to affect the host or other containers.
+
+## Secure the Data
+
+Protecting sensitive data, especially secrets, is paramount.
+
+*   **Manage secrets carefully**:
+    *   Never store secrets in image layers (e.g., in the `Dockerfile`) or pass them via environment variables, as they can be easily inspected.
+    *   Use a dedicated secrets management solution. The best approach is to mount secrets into the container at runtime.
+        *   [**Docker Secrets**](https://docs.docker.com/engine/swarm/secrets/) (for Swarm) and Kubernetes Secrets mount secrets as files in an in-memory `tmpfs` volume.
+        *   External tools like [**HashiCorp Vault**](https://www.vaultproject.io/) or cloud provider services (AWS Secrets Manager, Azure Key Vault) provide centralized and secure secret storage with fine-grained access control.
+
+*   **Apply least privilege**: Follow the principle of least privilege. A container should only be given access to the specific secrets it needs to function, and nothing more.
+
+*   **Rotate secrets regularly**: Regularly rotate all credentials to reduce the window of opportunity for an attacker if a secret is compromised.
+
+## Secure the Workloads (Running Containers)
+
+These practices focus on securing the containers while they are running.
+
+*   **Avoid privileged containers**: Never run containers with the `--privileged` flag. A privileged container has all the capabilities of the host machine, effectively disabling all isolation. It can load kernel modules, access all devices, and can easily take over the entire host.
+
+    ```bash
+    # Example of a dangerous command (DO NOT RUN in production)
+    docker run --privileged my-app:latest
+    ```
+
+*   **Limit resources**: A compromised container could be used to launch a denial-of-service (DoS) attack or a cryptojacking campaign. Mitigate this by setting resource limits.
+    *   Use `--memory` and `--cpus` to constrain memory and CPU usage.
+    *   Use `--pids-limit` to prevent "fork bomb" attacks where a process rapidly replicates itself to exhaust system resources.
+
+    ```bash
+    docker run \
+      --memory="512m" \
+      --cpus="0.5" \
+      --pids-limit=100 \
+      my-app:latest
+    ```
+
+*   **Read-only root filesystem**: Run containers with a `--read-only` root filesystem. This prevents an attacker from overwriting application code, modifying configuration, or downloading malicious tools into the container. If the application needs to write files, mount a dedicated volume or a `tmpfs` for temporary data.
+
+    ```bash
+    docker run \
+      --read-only \
+      --tmpfs /tmp \ # Mount a temporary in-memory filesystem for temporary files
+      my-app:latest
+    ```
+
+*   **Network segregation**: By default, all containers on the same host can communicate with each other over the default bridge network. This increases the "blast radius" of a compromise.
+    *   Avoid the default `bridge` network for production workloads.
+    *   Create custom [bridge networks](https://docs.docker.com/network/bridge/) to segment containers. This allows you to control which containers can communicate with each other, creating isolated groups.
+    *   Only expose the necessary container ports to the host and the outside world.
+
+    ```bash
+    # Create a custom bridge network
+    docker network create my-app-net
+
+    # Run containers on the custom network
+    docker run --network=my-app-net --name db ...
+    docker run --network=my-app-net --name api ...
+    ```
+
+---
+
+Source: [krol3/container-security-checklist on GitHub](https://github.com/krol3/container-security-checklist)

foomo/docs/security/linux.md

@@ -0,0 +1,111 @@
+---
+title: Linux Security
+slug: /security/linux
+---
+
+## Overview
+
+This document provides a baseline for hardening Linux servers and workstations. It focuses on practical, enforceable security controls that protect against common threats. The recommendations are distribution-agnostic where possible, but may include examples for Debian-based and RHEL-based systems.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [Linux Security Foundations](#linux-security-foundations)
+- [Opinionated Baseline](#opinionated-baseline-what-we-enforce)
+  - [User and Access Management](#user-and-access-management)
+  - [System and Software Updates](#system-and-software-updates)
+  - [Filesystem and Data Encryption](#filesystem-and-data-encryption)
+  - [Network Security](#network-security)
+  - [Secure Configurations](#secure-configurations)
+  - [Logging and Monitoring](#logging-and-monitoring)
+- [Quick Reference Checklists](#quick-reference-checklists)
+
+## Linux Security Foundations
+
+Linux's security model is built on a mature, multi-user architecture with robust permissions and process isolation. Key foundations include:
+- **Open-Source Transparency**: The source code for the kernel and most system components is publicly available for scrutiny, enabling rapid discovery and patching of vulnerabilities by a global community.
+- **Principle of Least Privilege**: The user/group/other permission model for files and the distinction between user and root (`sudo`) privileges are core to limiting the impact of a compromise.
+- **Security Modules (LSM)**: Frameworks like [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) and [AppArmor](https://en.wikipedia.org/wiki/AppArmor) provide Mandatory Access Control (MAC) to enforce fine-grained restrictions on what processes are allowed to do, even if running as root.
+- **Namespaces and Cgroups**: These kernel features are the foundation of containerization technologies like Docker, providing process, network, and filesystem isolation.
+
+## Opinionated Baseline (what we enforce)
+
+Harden in layers: identity, system state, data, network, and logging. Use configuration management tools (e.g., Ansible, Puppet) to apply and verify settings at scale.
+
+### User and Access Management
+
+- [ ] **Enforce Least Privilege**: Users should operate as non-root accounts. Use `sudo` for administrative tasks with a restrictive `sudoers` configuration.
+- [ ] **Centralized Authentication**: Use a system like OpenLDAP or an identity provider (IdP) integration via SSSD/PAM to manage user accounts and enforce consistent policies.
+- [ ] **Strong Password Policies**: Enforce password complexity, length, and history requirements using `pam_pwquality` or similar modules.
+- [ ] **Multi-Factor Authentication (MFA)**: Require MFA for SSH and console logins, especially for privileged accounts. Use tools like `libpam-google-authenticator` or commercial solutions.
+- [ ] **Monitor User Activity**: Log all login attempts, `sudo` usage, and significant commands. Forward these logs to a central SIEM.
+- [ ] **Disable Guest Account**: Ensure no default or guest accounts are active.
+- [ ] **SSH Hardening**:
+  - [ ] Disable root login (`PermitRootLogin no`).
+  - [ ] Use key-based authentication; disable password authentication (`PasswordAuthentication no`).
+  - [ ] Use a non-standard port if security-through-obscurity is part of the strategy.
+  - [ ] Configure `AllowUsers` or `AllowGroups` to restrict who can log in.
+
+### System and Software Updates
+
+- [ ] **Automate Patching**: Configure the system to automatically install critical security updates.
+  - Debian/Ubuntu: `unattended-upgrades`
+  - RHEL/CentOS: `dnf-automatic`
+- [ ] **Regularly Review Updates**: While automated, have a process to review applied patches and manually handle updates that require service restarts or further configuration.
+- [ ] **Minimize Software Installation**: Only install necessary packages. A smaller footprint reduces the attack surface.
+
+### Filesystem and Data Encryption
+
+- [ ] **Full-Disk Encryption (FDE)**: Use LUKS (Linux Unified Key Setup) during installation to encrypt the entire disk for physical security, especially on laptops.
+- [ ] **Encrypt Backups**: Ensure all backup data is encrypted both in transit and at rest. Use tools with built-in encryption like BorgBackup or Duplicity.
+- [ ] **Strict File Permissions**:
+  - [ ] Set restrictive default permissions with `umask` (e.g., `027`).
+  - [ ] Regularly audit for world-writable files or incorrect ownership.
+  - [ ] Use `chattr` to make critical files immutable (`+i`) where appropriate.
+- [ ] **Use Access Control Lists (ACLs)**: For complex permissions scenarios, use filesystem ACLs (`getfacl`, `setfacl`) to grant specific users/groups access without altering base permissions.
+
+### Network Security
+
+- [ ] **Implement a Host-Based Firewall**: Configure `iptables`, `nftables`, or `firewalld` to block all incoming traffic by default and only allow required services.
+- [ ] **Secure Network Services**:
+  - [ ] Ensure services are bound only to necessary network interfaces.
+  - [ ] Disable or uninstall unused network services (e.g., `telnetd`, `rshd`).
+- [ ] **Monitor Network Connections**: Use tools like `netstat` or `ss` to regularly check for unexpected listening ports or active connections.
+- [ ] **Use VPNs**: For remote access or communication over untrusted networks, use a VPN like OpenVPN or WireGuard.
+
+### Secure Configurations
+
+- [ ] **Implement Mandatory Access Control (MAC)**:
+  - [ ] Use SELinux (on RHEL-based systems) or AppArmor (on Debian/SUSE-based systems) in `enforcing` mode.
+  - [ ] Use or develop policies to confine critical services, especially those exposed to the network.
+- [ ] **Harden System Configurations**:
+  - [ ] Apply security settings to the kernel via `/etc/sysctl.conf` (e.g., disable IP forwarding if not a router, enable TCP SYN cookies).
+  - [ ] Secure shared memory (`/dev/shm`).
+- [ ] **Leverage Configuration Management**: Use tools like Ansible to apply a consistent, secure baseline to all systems and prevent configuration drift.
+
+### Logging and Monitoring
+
+- [ ] **Enable Comprehensive Logging**: Configure `rsyslog` or `journald` to capture logs from all relevant services.
+- [ ] **Centralize Logs**: Forward logs from all systems to a central SIEM for aggregation, correlation, and alerting.
+- [ ] **Use `auditd`**: The Linux Audit Daemon can be configured to log specific events required for compliance or threat hunting, such as file access, use of specific system calls, or security attribute modifications.
+- [ ] **Deploy an EDR Agent**: For critical systems, deploy an Endpoint Detection and Response agent that can detect and respond to threats in real-time.
+
+## Quick Reference Checklists
+
+### Minimum Baseline (must-have)
+
+- [ ] SSH hardened (keys only, no root login)
+- [ ] Automated security updates enabled
+- [ ] Host-based firewall active (default deny)
+- [ ] Strong password policy enforced, with MFA for privileged access
+- [ ] Unnecessary services and software removed
+- [ ] Centralized logging configured
+- [ ] Users operate as non-root with `sudo`
+
+### Nice-to-Have (should-have)
+
+- [ ] Full-disk encryption (especially for laptops)
+- [ ] MAC enabled (SELinux/AppArmor in enforcing mode)
+- [ ] `auditd` configured for critical event logging
+- [ ] EDR agent deployed
+- [ ] Regular vulnerability scanning

foomo/docs/security/macos.md

@@ -0,0 +1,213 @@
+---
+title: macOS Security
+slug: /security/macos
+---
+
+## Overview
+
+This document distills the macOS security model and recommended hardening practices into an actionable baseline for corporate Macs. It synthesizes Apple’s platform assurances with practical configuration guidance you can enforce via MDM.
+
+- Sources referenced:
+  - [Apple Platform Security Guide (macOS)](https://support.apple.com/guide/security/welcome/web)
+  - [macOS Security and Privacy Guide](https://github.com/drduh/macOS-Security-and-Privacy-Guide)
+
+## How to use this document
+
+- Skim the Table of Contents to jump to what you need.
+- Start with the Opinionated Baseline and apply via your MDM. Layer on role‑specific items.
+- New to macOS security? Follow the inline links and short explanations next to key terms.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [How to use this document](#how-to-use-this-document)
+- [Objectives and Scope](#objectives-and-scope)
+- [Apple Platform Foundations](#apple-platform-foundations-what-macos-gives-you)
+- [Opinionated Baseline](#opinionated-baseline-what-we-enforce)
+  - [Baseline for All Corporate Macs](#baseline-for-all-corporate-macs)
+  - [Additional Hardening for Admins and Developers](#additional-hardening-for-admins-and-developers)
+  - [High-Risk or Data-Critical Roles](#high-risk-or-data-critical-roles)
+- [Operational Playbooks](#operational-playbooks-condensed)
+- [Implementation Notes](#implementation-notes-mdm-first)
+- [Quick Reference Checklists](#quick-reference-checklists)
+- [References](#references)
+
+## Objectives and Scope
+
+- Protect corporate and user data by securing devices at rest and in transit, restricting lateral movement on the network, and preventing malware execution.
+- Preserve user privacy while enabling essential productivity, IT support, and security observability.
+- Prefer native, built-in macOS security controls. Use a Mobile Device Management (MDM) solution to enforce a secure-by-default posture that is centrally managed and auditable.
+
+## Apple Platform Foundations (what macOS gives you)
+
+- Hardware Root of Trust and [Secure Boot](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_Boot): The system validates that only legitimate, Apple-signed code runs at startup, preventing boot-level malware from taking hold.
+- [Secure Enclave](https://en.wikipedia.org/wiki/Apple_Silicon#Security_and_privacy) (SEP) and keybags: A dedicated hardware security processor that handles cryptographic operations for sensitive data like FileVault keys, Keychain items, and Touch ID, isolating them from the main OS.
+- [System Integrity Protection](https://en.wikipedia.org/wiki/System_Integrity_Protection) (SIP) and code signing enforcement: Protects critical system files, processes, and kernel extensions from modification, even by the root user, and blocks unauthorized low-level code.
+  ```bash
+  # Check if SIP is enabled (System Integrity Protection)
+  csrutil status
+  # Expected output: System Integrity Protection status: enabled.
+  ```
+- [Gatekeeper](https://en.wikipedia.org/wiki/Gatekeeper_(macOS)) and [Notarization](https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution): Before a downloaded app runs for the first time, Gatekeeper verifies that it’s from an identified developer and has been notarized by Apple—an automated check for malicious content.
+- [App Sandbox](https://developer.apple.com/documentation/security/app_sandbox) and entitlements: Applications from the App Store are sandboxed, meaning they are restricted in their access to system resources and user data. They must declare required permissions (entitlements), limiting the potential damage if compromised.
+- [Transparency, Consent, and Control](https://en.wikipedia.org/wiki/Transparency,_Consent,_and_Control) (TCC): The system prompts the user for explicit permission before an app can access sensitive data or services, such as the camera, microphone, location, contacts, or screen recording.
+- [XProtect](https://en.wikipedia.org/wiki/XProtect) and Apple malware removal: macOS includes built-in, signature-based antivirus capabilities that silently check for and block/remove known malware in the background. Apple pushes updates to it automatically.
+- Full‑disk encryption ([FileVault](https://en.wikipedia.org/wiki/FileVault)): Provides strong, hardware-accelerated AES-XTS 256-bit encryption for the entire startup disk, protecting all data at rest. If a device is lost or stolen, the data is unreadable without the user's password or a secure recovery key.
+
+## Opinionated Baseline (what we enforce)
+
+Harden in layers: identity, device state, data protections, network posture, app controls, and telemetry. Use MDM to apply and verify settings at scale.
+
+### Baseline for All Corporate Macs
+
+- Identity and Enrollment
+  - [ ] Device enrolled in [MDM](https://en.wikipedia.org/wiki/Mobile_device_management) via Automated Device Enrollment ([ABM](https://www.apple.com/business/it/)/[ASM](https://www.apple.com/education/schools/)) with supervision. This non-removable management profile ensures devices are corporate-owned and configured securely from their very first boot (zero-touch deployment).
+  - [ ] Enforce compliant posture to access corporate resources (SSO, MFA, device compliance). For example, access to cloud apps can require that the device is managed, has FileVault enabled, and is running a recent OS version.
+
+- Disk and Data Protection
+  - [ ] Enable [FileVault](https://en.wikipedia.org/wiki/FileVault) (FV2) on all Macs; escrow recovery key to MDM/key escrow service. This ensures data at rest is encrypted. Escrowing the key allows IT to perform data recovery if a user forgets their password.
+    ```bash
+    # Check FileVault status
+    fdesetup status
+    # Expected output: FileVault is On.
+    ```
+  - [ ] Enforce strong passcode/password policy; disable automatic login. Example policy: require at least 12 characters, including mixed case, numbers, and symbols.
+  - [ ] Require screen lock with password after sleep/screensaver (≤ 5 minutes). This minimizes the window for unauthorized access when a device is left unattended.
+  - [ ] Encrypt [Time Machine](https://support.apple.com/en-us/HT201250) backups; restrict to approved destinations only, such as a designated, encrypted network share, to prevent data leakage via backups.
+
+- Software Update and Patching
+  - [ ] Enable automatic OS updates, app updates, background updates, and Rapid Security Responses. Timely patching is one of the most effective security measures.
+    ```bash
+    # Manually check for available software updates
+    softwareupdate -l
+    ```
+  - [ ] Define maximum deferral windows and install deadlines via MDM. For example, allow users to defer a critical update for 3 days, after which installation is forced. This balances convenience with security.
+
+- Account Model
+  - [ ] Users operate as Standard accounts; use JIT elevation or a separate, dormant Admin account. This enforces the principle of least privilege. Administrative tasks should require temporary, auditable privilege elevation.
+  - [ ] Block local account creation outside IT workflows; disable Guest account. This prevents users from creating unauthorized accounts to bypass controls. The Guest account provides an unmanaged access vector and should be disabled.
+    ```bash
+    # Disable the guest account from the command line
+    sudo dscl . -create /Users/guest UserShell /usr/bin/false
+    sudo dscl . -create /Users/guest Password '*'
+    ```
+
+- Network and Sharing
+  - [ ] Enable Application Firewall and Stealth Mode; block incoming connections by default. Stealth Mode prevents the Mac from responding to network probes (like pings), making it less visible.
+    ```bash
+    # Check Firewall status
+    sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
+    # Check Stealth Mode status
+    sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
+    ```
+  - [ ] Disable Internet Sharing, Printer Sharing, Screen Sharing, Remote Apple Events by default. These services can create security holes if misconfigured and should only be enabled when explicitly required.
+    ```bash
+    # Example: Disable Screen Sharing
+    sudo launchctl disable system/com.apple.screensharing
+    ```
+  - [ ] AirDrop set to Contacts Only (or Disabled for high-risk roles) to prevent receiving unsolicited, potentially malicious files from unknown sources.
+  - [ ] Bluetooth restricted to approved peripherals; auto-disconnect when unused. Consider disabling discoverability when not actively pairing.
+
+- Application Controls
+  - [ ] [Gatekeeper](https://en.wikipedia.org/wiki/Gatekeeper_(macOS)) set to “App Store and identified developers”; require notarization. This should be enforced by MDM to prevent users from downgrading the setting.
+    ```bash
+    # Check Gatekeeper status
+    spctl --status
+    # Expected output: assessments enabled
+    ```
+  - [ ] Block legacy kernel extensions; prefer [System Extensions](https://developer.apple.com/documentation/systemextensions); approve only vetted Team IDs. Legacy kernel extensions (kexts) are being phased out. Modern System Extensions run in a more restricted userspace environment.
+  - [ ] PPPC/TCC: grant Full Disk Access, Accessibility, Screen Recording only to required tools (e.g., EDR). Manage Privacy Preferences Policy Control (PPPC) centrally to grant powerful permissions sparingly and only to vetted security or IT support tools.
+  - [ ] Application allow/deny lists managed by MDM for sensitive roles. For high-risk roles, an allow-list that only permits approved applications to run provides a very strong defense against untrusted code.
+
+- Browser and Content Protections
+  - [ ] Phishing/malware site warnings enabled; pop-ups and insecure plug-ins blocked. These are standard features in modern browsers (e.g., Google Safe Browsing) and should be enforced.
+  - [ ] Enforce safe defaults via managed browser policies (Safari/Chrome/Firefox). For example, use MDM to block risky browser extensions, disable automatic downloads, and configure privacy settings.
+
+- Privacy Protections (TCC)
+  - [ ] Location, camera, microphone, screen recording, calendar/contacts: deny by default; allow per role via MDM profiles where possible.
+  - [ ] Limit analytics/diagnostics sharing to minimum necessary; disable ad personalization.
+
+- Telemetry, Detection, and Response
+  - [ ] Deploy managed EDR/XDR (endpoint detection/response) using Apple’s [Endpoint Security](https://developer.apple.com/documentation/endpointsecurity) framework; verify coverage. An EDR agent is crucial for detecting and responding to advanced threats that bypass preventative controls.
+  - [ ] Enable unified logging collection for security‑relevant events; forward to a [SIEM](https://en.wikipedia.org/wiki/Security_information_and_event_management). Centralize macOS logs in a SIEM to enable threat hunting, incident investigation, and compliance monitoring.
+    ```bash
+    # Example: stream logs in real-time to view security-related events
+    log stream --predicate 'subsystem == "com.apple.security"'
+    ```
+  - [ ] Enable audit policy ([auditd](https://en.wikipedia.org/wiki/Auditd)) with a minimal, targeted ruleset where required by compliance. `auditd` provides detailed event logging but can be verbose; use it to meet specific requirements (e.g., PCI-DSS) rather than for general monitoring.
+
+### Additional Hardening for Admins and Developers
+
+- [ ] Stronger password policy and shorter screen-lock timers (e.g., 1 minute).
+- [ ] Restrict developer tool entitlements (e.g., debugging, task_for_pid) to approved workflows. For example, the `get-task-allow` entitlement, which allows other processes to attach to an app, must be disabled for all production-signed software.
+- [ ] Isolate build chains and package managers; verify signatures; prefer reproducible builds. Use tools like Docker or Nix to create isolated build environments. Always verify dependency signatures (e.g., using `npm audit` or checking GPG signatures).
+- [ ] Limit container/VM networking and host mounts; disable privileged containers. By default, containers should not have access to the host network or sensitive file system locations. Always run containers as a non-root user.
+- [ ] Rosetta installation only if required; remove when no longer needed. Rosetta 2, which enables Intel-based apps to run on Apple Silicon, increases the attack surface and should only be installed if absolutely necessary.
+  ```bash
+  # Check if Rosetta 2 is installed
+  /usr/bin/pgrep -q oahd && echo "Rosetta 2 is installed" || echo "Rosetta 2 is not installed"
+  ```
+
+### High-Risk or Data-Critical Roles
+
+- [ ] AirDrop disabled; external storage blocked or read-only; enforce USB device policy. Use MDM to control USB devices, for example by only allowing approved, encrypted storage.
+- [ ] Network egress filtering/DNS filtering; VPN required; per-app VPN for sensitive tools. Use a network filter to block connections to known malicious domains. A per-app VPN can ensure that only specific, approved applications can access sensitive internal resources.
+- [ ] Screen recording disabled except for approved collaboration tools.
+- [ ] Camera/microphone disabled unless explicitly needed.
+
+## Operational Playbooks (condensed)
+
+- Lost or Stolen Mac
+  - [ ] Immediately mark device lost in MDM; enable Activation Lock and Lost Mode; attempt remote lock/wipe
+  - [ ] Revoke tokens and sessions; monitor for access attempts; rotate keys if needed
+
+- Malware Detection
+  - [ ] EDR should isolate the host from the network. Collect triage artifacts (e.g., running processes, network connections) via MDM/EDR tooling. Eradicate the threat and reimage the machine if persistence is suspected.
+  - [ ] Validate Gatekeeper/Notarization settings; review recent downloads and quarantine flags.
+
+- Major OS Upgrade
+  - [ ] Preflight compatibility checks (apps, drivers, security tools)
+  - [ ] Staged rollout with telemetry gates; enforce install by deadline
+
+- Offboarding
+  - [ ] Disable accounts/tokens; revoke device compliance; remote wipe or reassign after backup/escrow.
+
+## Implementation Notes (MDM-first)
+
+- Use Automated Device Enrollment and supervision to lock down Setup Assistant and require MDM profiles at first boot. This prevents users from bypassing enrollment.
+- Enforce FileVault with personal recovery key escrow and, if policy requires, an institutional key held in a secure [HSM](https://en.wikipedia.org/wiki/Hardware_security_module)-backed secret manager.
+- Manage TCC via Privacy Preferences Policy Control (PPPC) profiles; scope highly privileged grants *only* to tools that absolutely require them (like EDR).
+- Prefer System Extensions and Network/System Content Filters; block and avoid legacy kernel extensions.
+- Use Configuration Profiles for Firewall, Gatekeeper, Restrictions, and Software Updates; verify with compliance rules and periodic audits.
+
+## Quick Reference Checklists
+
+### Minimum Baseline (must-have)
+
+- [ ] MDM enrollment and supervision
+- [ ] FileVault enabled with escrowed recovery key
+- [ ] Automatic OS/app/RSR updates
+- [ ] Standard user accounts; no auto-login; Guest disabled
+- [ ] Firewall + Stealth Mode enabled; sharing services off
+- [ ] Gatekeeper/Notarization enforced; no legacy kexts
+- [ ] EDR deployed and reporting; logs forwarded
+
+### Nice-to-Have (should-have)
+
+- [ ] DNS/content filtering for phishing/malware
+- [ ] Encrypted Time Machine backups to approved targets
+- [ ] PPPC minimized; periodic review of Full Disk Access
+- [ ] Browser hardening via managed policies
+
+### Team-Specific (as-needed)
+
+- [ ] Developer entitlements and tools managed; signed artifacts; SBOMs
+- [ ] High-risk roles: removable media controls, stricter TCC, per-app VPN
+
+## References
+
+- [Apple Platform Security Guide](https://support.apple.com/guide/security/welcome/web)
+- [macOS Security and Privacy Guide (GitHub)](https://github.com/drduh/macOS-Security-and-Privacy-Guide)
+- [Jamf Pro Security Documentation](https://www.jamf.com/resources/product-documentation/jamf-pro-security-overview/)
+
+

foomo/docs/security/operating-system.md

@@ -0,0 +1,14 @@
+---
+title: Operating System Security
+slug: /security/operating-system
+---
+
+# Operating System Security
+
+This section provides detailed security hardening guides for various operating systems. Choose an operating system below to view the recommended security baseline and configuration practices.
+
+- [macOS Security](./macos.md)
+- [Linux Security](./linux.md)
+- [Windows Security](./windows.md)
+
+

foomo/docs/security/organization.md

@@ -0,0 +1,354 @@
+---
+title: Organizational Security Operations
+slug: /security/organization
+---
+
+## Overview
+
+This document distills practical, organization-wide security operations guidance into clear priorities, roles, processes, and controls. It focuses on prevention first, rapid detection and response second, and continuous improvement throughout. It is intended as a living document to be adapted to our evolving security posture.
+
+## How to use this document
+
+- Use the Table of Contents to jump to areas like Identity, AppSec, or Incident Response.
+- Start with Core Pillars and Maturity Milestones to set priorities.
+- Checklists can be copied into quarterly plans and audits.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [How to use this document](#how-to-use-this-document)
+- [Security Objectives](#security-objectives)
+- [Governance and Roles](#governance-and-roles)
+- [Core Pillars](#core-pillars)
+- [Maturity Milestones](#maturity-milestones-crawl--walk--run)
+- [Checklists](#checklists)
+- [Metrics and Reporting](#metrics-and-reporting)
+- [Incident Response Workflow](#incident-response-workflow-high-level)
+- [Continuous Improvement](#continuous-improvement)
+- [Incident Playbooks](#incident-playbooks-examples)
+- [Severity and Response SLAs](#severity-and-response-slas)
+- [Practical Templates](#practical-templates)
+- [Logging and Detection Baseline](#logging-and-detection-baseline)
+- [CI/CD Security Gates](#cicd-security-gates-examples)
+- [Vendor and Third-Party Checklist](#vendor-and-third-party-checklist)
+- [People Processes](#people-processes)
+- [Example Artifacts](#example-artifacts)
+
+## Security Objectives
+
+- **Protect** people, data, systems, and business continuity.
+- **Reduce** the likelihood and impact of security incidents.
+- **Comply** with legal, regulatory, and contractual obligations.
+- **Build** a culture of secure-by-default engineering and operations.
+
+## Governance and Roles
+
+- **Executive Sponsor**: Accountable for the security program's success, direction, and funding. This role champions security at the highest levels and ensures it aligns with business objectives.
+- **Security Leadership**: Defines and directs the security strategy. This includes creating policies, managing risk, selecting tools, and reporting on the program's effectiveness to the executive sponsor.
+- **Engineering Leads**: Implement secure development lifecycle (SDLC) practices, secure infrastructure, and developer-focused security tooling.
+- **IT Operations**: Manages identity, access, device, and network security controls.
+- **Incident Response (IR) Team**: A designated team responsible for preparing for and responding to security incidents, including detection, containment, eradication, and recovery.
+- **Data Owners**: Responsible for classifying data, approving access requests, and defining retention policies for the data they own.
+- **All Employees**: Have a responsibility to follow security policies, complete training, and report incidents or suspicious activity promptly.
+
+## Core Pillars
+
+### 1) Identity and Access Management (IAM)
+
+- **Single Sign-On (SSO) with Multi-Factor Authentication (MFA)**: Mandate SSO with [MFA](https://en.wikipedia.org/wiki/Multi-factor_authentication) for all accounts. SSO simplifies access and reduces password fatigue, while MFA adds a critical layer of protection against credential theft. For example, even if a password is stolen, an attacker cannot log in without the second factor (e.g., a code from a phone app).
+- **Least-Privilege Access (RBAC)**: Grant access based on roles, providing only the minimum permissions necessary for a job function. A developer, for instance, should not have access to financial records. This principle, known as Role-Based Access Control (RBAC), limits the potential damage from a compromised account.
+- **Just-in-Time (JIT) Privileged Access**: Provide temporary, auto-expiring access for sensitive tasks. Instead of permanent admin rights, an engineer can request elevated permissions for a specific database task, which are automatically revoked after a short, pre-defined period. This is logged and requires approval.
+- **Access Reviews and Automated Deprovisioning**: Conduct regular (e.g., quarterly) reviews of who has access to what. This process, combined with automated workflows to remove access immediately when someone leaves or changes roles, prevents the accumulation of unnecessary privileges.
+
+### 2) Endpoint and Device Security
+
+- **Managed Device Baseline**: Enforce a security baseline for all corporate devices, including full-disk encryption to protect data if a device is lost, an automatic screen lock to prevent unauthorized access, and OS auto-updates to patch vulnerabilities promptly.
+- **Endpoint Detection and Response (EDR/XDR)**: Deploy and monitor an EDR (or XDR) solution on all endpoints. These tools provide deep visibility into system activity, helping to detect, investigate, and respond to threats like malware and unauthorized access. Where feasible, block unauthorized USB device usage.
+- **Mobile Device Management (MDM)**: Use standard device images and MDM to enforce policies. For high-risk roles, implement application allowlists to restrict software to only approved, necessary applications.
+
+### 3) Network and Cloud Security
+
+- **Zero Trust Networking**: Operate on a "never trust, always verify" principle. Restrict all inbound exposure by default and prefer private, authenticated, and encrypted links over public internet access.
+- **Segmentation**: Isolate networks to limit lateral movement. For example, the production environment should be strictly segregated from development and staging environments.
+- **Secure Cloud Foundations**: Implement preventative guardrails (e.g., AWS SCPs, Azure Policy), enforce detailed logging, use secure defaults like [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) in AWS, and use hardened, minimal machine images.
+- **Edge Protection**: Deploy a Web Application Firewall (WAF) and DDoS protection for all public-facing services. Automate certificate management to ensure universal and up-to-date TLS encryption.
+
+### 4) Application Security
+
+- **Secure SDLC**: Integrate security into every phase of the software development lifecycle, starting with threat modeling and defining security requirements during the design phase.
+- **Dependency Management**: Pin dependency versions to prevent unexpected changes. Use Software Composition Analysis (SCA) tools to find known vulnerabilities in libraries, and employ bots (like Renovate or Dependabot) to automate updates.
+- **Automated Scanning**: Integrate security scanning directly into the CI/CD pipeline. This includes [SAST](https://en.wikipedia.org/wiki/Static_application_security_testing) for static code analysis, secret scanning to find leaked credentials, and [IaC](https://en.wikipedia.org/wiki/Infrastructure_as_code) scanning to detect cloud misconfigurations before deployment.
+- **Dynamic and Manual Testing**: Use Dynamic Application Security Testing (DAST) tools to scan running applications for vulnerabilities. Conduct manual security reviews and penetration tests for critical services and major changes.
+
+### 5) Data Security and Privacy
+
+- **Data Classification and Handling**: Establish a data classification policy (e.g., Public, Internal, Confidential) and handling standards for each level. Practice data minimization by collecting and retaining only what is necessary.
+- **Encryption**: Encrypt all data in transit (e.g., with TLS 1.2+) and at rest (e.g., AES-256). Use a managed Key Management Service ([KMS](https://cloud.google.com/kms)) or Hardware Security Module ([HSM](https://en.wikipedia.org/wiki/Hardware_security_module)) to protect encryption keys.
+- **Backups and Recovery**: Maintain regular, automated backups of critical data. Crucially, conduct periodic restore tests to ensure the backups are viable. For the most critical data, use immutable storage to protect against ransomware.
+- **Privacy by Design**: Embed privacy controls and considerations into the design of new systems and processes, including clear retention and deletion schedules.
+
+### 6) Detection and Response
+
+- **Centralized Logging and Alerting**: Aggregate logs, telemetry, and alerts from all systems (endpoints, cloud, apps) into a central platform ([SIEM](https://en.wikipedia.org/wiki/Security_information_and_event_management)) to enable comprehensive threat hunting and investigation.
+- **Incident Playbooks and Exercises**: Develop defined, step-by-step playbooks for the most common incident types (e.g., phishing, malware). Conduct regular table-top exercises to practice and refine the response process.
+- **On-Call and SLAs**: Establish a clear on-call rotation for the security/IR team, with well-defined severity levels and Service Level Agreements (SLAs) for response times.
+- **Blameless Post-Incident Reviews**: After every incident, conduct a review focused on process and technology improvement, not on blaming individuals. The outcome should be a list of actionable remediation items with clear owners.
+
+### 7) Third Parties and Supply Chain
+
+- **Vendor Risk Management**: Assess the security posture of all vendors before engagement. Ensure contracts include security requirements, Data Processing Agreements (DPAs), and breach notification clauses. Request attestations like SOC2 or ISO 27001 where relevant.
+- **Software Supply Chain Security**: Monitor package registries for malicious packages. Digitally sign all build artifacts to ensure their integrity and track their provenance from code to deployment.
+- **Software Bill of Materials (SBOM)**: Maintain [SBOMs](https://www.cisa.gov/sbom) for all critical services to have a clear inventory of all software components and dependencies, which is invaluable for responding to new vulnerabilities.
+- **Secure CI/CD**: Grant CI/CD pipelines and deployment keys the least-privilege access they need to function.
+
+### 8) Security Culture and Training
+
+- **Role-Based Training**: Provide security training tailored to different roles. For example, engineers receive secure coding training, while the finance team receives training on preventing invoice fraud.
+- **Phishing Simulations**: Conduct regular, managed phishing simulations and provide immediate, constructive coaching to those who click, helping to build resilience.
+- **Blameless Reporting and Communication**: Maintain clear, well-known channels for reporting suspicious activity, and foster a blameless culture that encourages reporting. Provide regular communications to the organization on top risks and security improvements.
+
+## Maturity Milestones (crawl → walk → run)
+
+- **Crawl: Foundational Controls.** The goal here is to establish basic visibility and preventative measures. Think of it as locking the doors and installing an alarm system. Key controls include MFA, EDR, central logging, backups, and basic CI scanning (SAST/secrets).
+- **Walk: Proactive Defense.** The focus shifts to proactive measures, automating controls, and maturing detection capabilities. This is about building higher walls and having guards patrol them. Key controls include SSO everywhere, RBAC/JIT, IaC policies, SIEM alerts, tabletop exercises, and Data Loss Prevention (DLP).
+- **Run: Advanced Resilience.** At this stage, security is deeply integrated and automated. The organization can withstand sophisticated attacks and recover quickly. This is a fortress with automated defenses and a well-drilled army. Key controls include zero trust networking, automated incident response, signed builds/SBOMs, and continuous penetration testing.
+
+## Checklists
+
+Use these checklists to plan and audit security efforts on a recurring basis.
+
+### Executive and Governance
+
+- [ ] Board/executive security sponsor named and active
+- [ ] Security policy set approved, communicated, and versioned
+- [ ] Security roadmap with quarterly objectives and KPIs exists
+- [ ] Risk register is maintained with owners and due dates
+- [ ] Budget is allocated for tools, headcount, and training
+
+### Identity and Access Management
+
+- [ ] SSO and MFA are mandated for all users and admins
+- [ ] RBAC roles are defined; least privilege is enforced; no shared accounts
+- [ ] Break-glass accounts are secured, tested, and monitored
+- [ ] Access reviews are scheduled and completed quarterly
+- [ ] Automated joiner/mover/leaver process is in place
+
+### Endpoint and Device Security
+
+- [ ] All corporate devices are enrolled in MDM with encrypted disks
+- [ ] EDR/XDR is active and reporting for 100% of endpoints
+- [ ] OS and browser auto-updates are enabled; patch SLA is defined
+- [ ] High-risk roles use hardened profiles and app allowlists
+- [ ] Device inventory is accurate and reconciled monthly
+
+### Network and Cloud Security
+
+- [ ] Internet exposure is minimized; WAF/CDN enabled on public services
+- [ ] Segmentation between prod, staging, and dev is enforced
+- [ ] Cloud guardrails are in place: SCPs/policies, least-privilege service roles, KMS
+- [ ] Centralized VPC/VNet egress with filtering is used where possible
+- [ ] Certificate automation (ACME) and TLS 1.2+ are used everywhere
+
+### Application Security
+
+- [ ] Security requirements and threat models exist for critical services
+- [ ] CI runs SAST, secrets, SCA, IaC scanning with quality gates
+- [ ] Dependencies are updated routinely; vulnerable packages are triaged quickly
+- [ ] DAST is run against internet-facing apps; pentest cadence is defined for critical apps
+- [ ] Secure code review is required for sensitive changes
+
+### Data Security and Privacy
+
+- [ ] Data is classified; handling rules are documented and enforced
+- [ ] Encryption is used at rest and in transit; keys are rotated and access is logged
+- [ ] Backups are verified by periodic restore tests; RPO/RTO is defined
+- [ ] Data retention and deletion policies are implemented in systems
+- [ ] Privacy impact assessments are conducted for new/changed data processing
+
+### Detection and Response
+
+- [ ] Logging is centralized for endpoints, apps, cloud, and network
+- [ ] Alerts are monitored with an on-call rotation and escalation paths
+- [ ] Incident runbooks exist for common scenarios (phishing, ransomware, key leak)
+- [ ] Tabletop exercises are conducted at least twice per year
+- [ ] Post-incident reviews produce tracked, owned actions
+
+### Third Parties and Supply Chain
+
+- [ ] Vendor intake includes security questionnaires and contractual controls
+- [ ] Artifact integrity is verified: signed builds, image scanning, provenance checks
+- [ ] SBOMs are maintained for critical services; dependencies are monitored
+- [ ] CI/CD pipelines use least-privilege, rotated, and scoped secrets
+- [ ] Continuous monitoring is in place for third-party breaches
+
+### Security Culture and Training
+
+- [ ] Onboarding and annual role-based training is completed by all staff
+- [ ] Regular phishing simulations are run with feedback and trend tracking
+- [ ] An easy, well-known channel exists to report security issues
+- [ ] Quarterly security updates are shared with the organization
+- [ ] Positive security behaviors are recognized and rewarded
+
+## Metrics and Reporting
+
+### Leading Indicators
+*Measure preventative activities and preparedness. These metrics help predict future success.*
+- **Patch Latency**: Average time to patch critical vulnerabilities (e.g., goal: < 14 days).
+- **MFA Coverage**: Percentage of users with MFA enabled (e.g., goal: 100%).
+- **EDR Coverage**: Percentage of endpoints with EDR installed and reporting.
+- **Training Completion**: Percentage of employees who have completed required security training.
+
+### Lagging Indicators
+*Measure the effectiveness of the program after an event. These reflect past performance.*
+- **Incident Mean Time to Remediate (MTTR)**: Average time to fix a critical vulnerability after detection.
+- **High/Critical Vulnerabilities Time-to-Remediate**: The median time it takes to fix vulnerabilities, grouped by severity.
+
+### Program Indicators
+- **Access Review Completion**: Percentage of required quarterly access reviews completed on time.
+- **Backup Restore Success Rate**: Percentage of backup restore tests that completed successfully.
+- **Tabletop Cadence**: Frequency of incident response tabletop exercises.
+
+## Incident Response Workflow (high level)
+
+- **Detect**: An alert fires or a report is received. The first step is to confirm the incident's validity and assign an initial severity.
+- **Contain**: Isolate the affected systems to prevent further damage. This could mean taking a server offline, blocking an IP address, or disabling a user account.
+- **Eradicate**: Remove the threat from the environment. This involves eliminating malware, revoking stolen credentials, and fixing the underlying vulnerability.
+- **Recover**: Restore services to normal operation. This may involve deploying clean systems, restoring data from backups, and validating system integrity before bringing it back online.
+- **Learn**: Document the incident in a post-mortem report. This blameless review should identify the root cause and assign actionable remediation items with owners and deadlines to prevent recurrence.
+
+## Continuous Improvement
+
+- **Quarterly Risk Review**: Re-evaluate the risk register and update the security roadmap quarterly.
+- **Service Ownership**: Ensure every service has a clear owner, defined SLOs, and a documented security posture.
+- **Automate Everything**: Automate any manual, recurring security task. Always prefer preventative controls that stop issues from happening over detective controls that find them later.
+
+## Incident Playbooks (examples)
+
+### Phishing Report (employee-reported)
+
+- **Triage**: Verify sender domain, links, and headers; detonate suspicious links/attachments in a sandbox environment.
+- **Contain**: Block sender, domains, and URLs at the email gateway and DNS level.
+- **Hunt**: Search mailboxes and endpoints for indicators of compromise; auto-quarantine suspicious emails.
+- **Notify**: Communicate with targeted users and support teams with clear next steps.
+- **Eradicate**: Force-delete delivered messages; revoke tokens or sessions if a user clicked a malicious link.
+- **Recover**: Mandate password resets and session revocation for impacted users.
+- **Learn**: Update detection rules; share patterns with staff in a weekly security brief.
+
+### Ransomware on Endpoint
+
+- **Detect**: EDR alert triggers; confirm file encryption activity and the presence of a ransom note.
+- **Contain**: Immediately isolate the host from the network; disable all associated user sessions.
+- **Eradicate**: Remove malware, persistence mechanisms, and any scheduled tasks it created.
+- **Recover**: Reimage the machine from a known-good golden image; restore user data from backups.
+- **Notify**: Inform leadership; engage legal and cyber insurance as required by policy.
+- **Learn**: Identify the initial access vector; patch the vulnerability and harden systems to prevent recurrence.
+
+### Credential/Token Leak (e.g., key pushed to repo)
+
+- **Detect**: A secret scanner alert fires in the CI pipeline or repository provider.
+- **Contain**: Revoke and rotate the exposed key immediately. Remove the sensitive data from commit history (e.g., using tools like BFG Repo-Cleaner, which should be done with extreme care as it rewrites history).
+- **Hunt**: Analyze logs for any use of the leaked credential; monitor for anomalous access patterns.
+- **Recover**: Redeploy services with the new credentials. Review the credential's permissions and tighten its scope and Time-To-Live (TTL).
+- **Learn**: Implement pre-commit hooks and stricter CI quality gates to prevent secrets from being committed in the future.
+
+### Cloud Resource Exposure (public S3 bucket or open port)
+
+- **Detect**: A Cloud Security Posture Management (CSPM) or IaC scan alert triggers, or an external party reports it.
+- **Contain**: Immediately restrict public access; apply a least-privilege policy to the resource.
+- **Eradicate**: Fix the Infrastructure as Code (IaC) module that created the misconfiguration and add guardrails to prevent regression.
+- **Recover**: Validate the integrity of the exposed data; evaluate any data disclosure obligations.
+- **Learn**: Add unit tests and policy-as-code checks to the CI pipeline to enforce that specific security control.
+
+## Severity and Response SLAs
+
+- **Sev 1 (Critical)**: Active customer or business impact.
+  - **Acknowledge**: 5 min; **Contain**: 30 min; **Comms**: 30 min; **RCA**: 5 days
+- **Sev 2 (High)**: Degraded service or high risk of imminent impact.
+  - **Acknowledge**: 15 min; **Contain**: 2 h; **Comms**: 2 h; **RCA**: 7 days
+- **Sev 3 (Moderate)**: Limited scope or a potential, non-imminent issue.
+  - **Acknowledge**: 4 h; **Contain**: 1 day; **RCA**: 10 days
+- **Sev 4 (Low)**: Informational or minor issue.
+  - **Acknowledge**: 1 day; **Contain**: Best effort; **RCA**: As needed
+
+**Escalation**: If an SLA is at risk, the on-call engineer pages the incident commander and executive sponsor.
+
+## Practical Templates
+
+### Risk Register
+*A central document for tracking identified risks.* It should contain:
+- ID, Title, Description, Business Impact, Likelihood, Severity (calculated)
+- Owner, Mitigation Plan, Target Date, Status, Last Reviewed Date
+
+### Access Review Record
+*A log to prove that access rights are being regularly reviewed.* It should contain:
+- System/Group, Data Classification, Reviewer, Scope, Date
+- Changes Made: users removed, rights reduced, exceptions and justifications
+- Evidence: exported list or screenshot stored in a secure repository
+
+### Data Classification
+*A framework for categorizing data based on sensitivity to inform security controls.* Example levels:
+- **Public**: Information intended for public consumption (e.g., marketing materials).
+- **Internal**: Data accessible to all employees but not for public disclosure (e.g., internal wikis).
+- **Confidential**: Sensitive customer or business data that could cause medium/high impact if leaked (e.g., PII, financial records).
+- **Restricted**: Highly regulated or sensitive data requiring the highest level of controls and logging (e.g., production secrets, health data).
+
+## Logging and Detection Baseline
+
+- **Endpoints**: Process execution, network connections, authentication events, EDR detections.
+- **Cloud**: Control plane audit logs (e.g., CloudTrail), authentication logs, configuration changes, network flow logs, object storage access logs.
+- **Applications**: Authentication events (success and failure), administrative actions, errors, permission changes, key operations.
+- **Network/Edge**: WAF blocks/alerts, CDN logs, VPN connections, DNS queries, firewall accepts/denies.
+- **Retention Targets**: 30–90 days in hot (fast-query) storage, 365+ days in cold (archival) storage for critical sources.
+
+## CI/CD Security Gates (examples)
+
+- **Pre-commit**: Run lightweight secrets and linting hooks on developer machines before code is committed.
+- **CI (Pull Request)**: Run SAST, SCA, and IaC scans. Fail the build if new critical vulnerabilities are found.
+- **Build**: Generate a signed, reproducible build artifact and an SBOM.
+- **Deploy**: Scan the container image for vulnerabilities, run policy-as-code checks (e.g., OPA Gatekeeper), and require manual approvals for production deployments.
+
+## Vendor and Third-Party Checklist
+
+- **Contract**: Ensure a security addendum, breach notification SLA, and data processing terms are in place.
+- **Assurance**: Obtain independent attestations (e.g., SOC2 Type II, ISO 27001) or a completed security questionnaire.
+- **Technical**: Mandate SSO with MFA, ensure audit log export is available, and confirm data location and backup policies.
+- **Exit**: Clarify data return/deletion terms and support for migration off the platform.
+
+## People Processes
+
+### Onboarding
+
+- Role-based access profiles are applied via groups.
+- Device is enrolled in MDM before first login; MFA is set up.
+- Security training is completed within the first week.
+
+### Offboarding
+
+- All accounts are immediately disabled; tokens and sessions are revoked.
+- Device is returned and wiped; recovery keys are verified.
+- Access is removed from all groups and third-party services; removal is documented in a ticket.
+
+### Security Champions Program
+
+- A program to embed security experts within engineering teams.
+- One champion per team; they sync monthly with the security team.
+- Champions help maintain a backlog of security tasks aligned to their team's roadmap.
+- Success is measured by metrics like vulnerabilities resolved, time-to-fix, and training completed by their team.
+
+## Example Artifacts
+
+### Minimal Incident Report
+
+- **Summary**: What happened, when it was detected, and by whom.
+- **Impact**: Customers, data types, and systems affected.
+- **Timeline**: A log of key events, decisions, and actions.
+- **Containment/Eradication/Recovery Actions**: What was done to fix the issue.
+- **Root Cause**: The underlying reason(s) the incident was possible.
+- **Remediations**: Actionable tasks with owners and due dates to prevent recurrence.
+
+### Quarterly Security Metrics (sample)
+
+- **Coverage**: MFA %, EDR %, Logging %, Backup Test Pass %
+- **Velocity**: Critical Vulnerability Median Time-to-Fix, Patch Latency
+- **Readiness**: Tabletop Cadence, Incident SLA Adherence
+- **Risk**: Count of open high-impact risks, aged risks (> 90 days)

foomo/docs/security/pentests.md

@@ -0,0 +1,218 @@
+---
+title: Penetration Testing
+slug: /security/pentests
+---
+
+## Pentesting: summary and checklists
+
+This document summarizes a pragmatic, end‑to‑end penetration testing approach and provides ready‑to‑use checklists. It is aligned with the [OWASP Web Security Testing Guide (WSTG v4.2)](https://owasp.org/www-project-web-security-testing-guide/), common [OSCP](https://www.offsec.com/certifications/pen200-oscpexam/) methodology, and practical guidance from the included PDFs. Use the checklists to plan, execute, evidence, and report engagements consistently.
+
+## How to use this document
+
+- Skim the Table of Contents and pick the scope you are testing (web, API, network, OS).
+- Use the methodology as a sequence, and the checklists as quick run sheets.
+- Inline links and acronym expansions help non‑specialists follow along.
+
+## Table of Contents
+
+- [Pentesting: summary and checklists](#pentesting-summary-and-checklists)
+- [How to use this document](#how-to-use-this-document)
+- [Purpose and scope](#purpose-and-scope)
+- [Methodology overview](#methodology-overview)
+- [Web application testing](#web-application-testing-owasp-wstg-aligned)
+- [API testing focus](#api-testing-focus)
+- [Network and infrastructure](#network-and-infrastructure)
+- [Operating system and platform notes (macOS)](#operating-system-and-platform-notes-macos)
+- [Evidence, safety, and ethics](#evidence-safety-and-ethics)
+- [Reporting and risk rating](#reporting-and-risk-rating)
+- [Deliverables](#deliverables)
+- [Checklists](#checklists)
+- [Sources](#sources)
+
+## Purpose and scope
+
+- **Goal**: The primary objective is to identify, validate, and demonstrate the impact of security weaknesses. The engagement must deliver actionable remediation guidance to improve the target's security posture. It's not just about finding flaws, but about showing how they can be fixed.
+- **Scope**: A well-defined scope is critical for a successful engagement. It must clearly delineate targets, techniques, and timelines.
+  - **Targets**: Specify what is in-scope (e.g., `api.example.com`, iOS app v2.1) and what is explicitly out-of-scope (e.g., corporate infrastructure, third-party integrations).
+  - **Techniques**: Define allowed and disallowed testing methods. For instance, are denial-of-service (DoS) tests permitted? Is social engineering of employees allowed?
+  - **Time Window**: Testing should be confined to an agreed-upon timeframe (e.g., "Mon-Fri, 9am-5pm PST") to minimize disruption and align with monitoring capabilities.
+- **Rules of Engagement (ROE)**: These are the ground rules for the test.
+  - **Authorization**: Obtain explicit, written permission from the asset owner.
+  - **Safe Harbor**: Legal protection for the testing team for actions performed within the agreed scope.
+  - **Contact Points**: Establish primary points of contact for both the testing team and the client for escalations and emergencies.
+  - **Data Handling**: Specify how sensitive data discovered during the test should be handled, stored, and ultimately purged.
+
+## Methodology overview
+
+A structured methodology ensures comprehensive and repeatable testing. This process follows a standard lifecycle from planning to validation.
+
+1.  **Pre‑engagement**: This foundational phase aligns the testing team and the client. It involves defining the scope, rules of engagement (ROE), provisioning test accounts, setting success criteria, and establishing communication and incident handling plans. Clear expectations are key.
+2.  **Reconnaissance**: Gathering information about the target.
+    -   **Passive**: Collecting information from public sources without directly engaging the target (e.g., DNS records, search engine hacking, social media).
+    -   **Active**: Directly probing the target to discover hosts, open ports, and services (e.g., using tools like `nmap`, `gobuster`). The goal is to map the attack surface, enumerate the technology stack, and identify API surfaces.
+3.  **Threat Modeling**: This phase involves thinking like an attacker. Identify high-value assets (e.g., user data, payment info), analyze trust boundaries (e.g., between a public API and an internal service), and map out potential attacker paths and abuse cases.
+4.  **Vulnerability Analysis**: With a map of the target, begin searching for flaws. This is a mix of automated scanning (e.g., with Nessus, Burp Suite Pro) and manual testing to find misconfigurations, weak controls (e.g., lack of rate limiting), and insecure defaults.
+5.  **Exploitation**: The goal here is to safely validate identified vulnerabilities and demonstrate their real-world impact. This must be done with extreme care to minimize the "blast radius" and avoid disrupting production systems. For example, instead of dropping a table, an SQL injection could be proven by extracting the database version.
+6.  **Post‑exploitation**: After gaining an initial foothold, this phase explores what an attacker could do next. This might involve controlled attempts at lateral movement (moving to other systems) or privilege escalation (gaining higher-level access). All actions must be carefully documented.
+7.  **Reporting**: A critical deliverable. The report should detail findings, assign risk ratings (e.g., using CVSS), explain the business impact, and provide clear, step-by-step instructions for reproduction and remediation.
+8.  **Remediation Validation**: After the client has implemented fixes, the tester re-tests the specific vulnerabilities to verify that the mitigations are effective. This closes the feedback loop and confirms risk reduction.
+
+## Web application testing (OWASP WSTG‑aligned)
+
+This section aligns with the OWASP Web Security Testing Guide, covering common vulnerability categories.
+
+-   **Information Gathering**: Map the application's attack surface. Enumerate subdomains (`subfinder`, `amass`), discover directories and files (`gobuster`, `dirb`), identify parameters, and map out client-side routes and API endpoints. Analyze third-party scripts for supply chain risks.
+-   **Configuration and Deployment Management**: Look for misconfigurations. Examples include enabled directory listing, exposed default files (e.g., `.env`), debug flags left on in production, and verbose error messages that leak internal state. Check for proper implementation of security headers like `Content-Security-Policy` ([CSP](https://developer.mozilla.org/docs/Web/HTTP/CSP)) and `Strict-Transport-Security`.
+-   **Identity and Authentication**: Test the gates of the application. Does it enforce a strong password policy? Is [MFA](https://en.wikipedia.org/wiki/Multi-factor_authentication) implemented correctly? Are account recovery flows secure? Can you brute-force logins or stuff stolen credentials without being blocked?
+-   **Authorization**: Once authenticated, what can a user do?
+    -   **Horizontal access control**: Can User A access User B's data by changing an ID in a URL (e.g., `/orders/123` to `/orders/124`)? This is an Insecure Direct Object Reference (IDOR).
+    -   **Vertical access control**: Can a regular user access an admin panel (e.g., `/admin`)?
+-   **Session Management**: Test how the application handles sessions. Are cookies flagged as `HttpOnly` and `Secure`? Does the session token rotate upon login or privilege change? Does logging out actually invalidate the session on the server?
+-   **Input Validation and Injection**: Test how the application handles user-supplied data.
+    -   **SQL Injection (SQLi)**: If a query is built like `SELECT * FROM products WHERE id = '` + product_id + `'`, an attacker could use `1' OR '1'='1` to dump all products.
+    -   **Cross-Site Scripting (XSS)**: If a search term is reflected on the page without encoding, an input like `<script>alert('XSS')</script>` could execute in a user's browser. We test for Reflected, Stored, and DOM-based XSS.
+    -   Also test for Server-Side Request Forgery (SSRF), XML External Entity (XXE) injection, and insecure deserialization.
+-   **Business Logic**: Abuse the intended functionality of the application. Can you manipulate a price in a checkout flow? Can you submit a form multiple times in a race condition to get a double discount?
+-   **Data Protection**: Check for sensitive data exposure. Is personally identifiable information (PII) encrypted at rest and in transit? Are API keys or tokens accidentally leaked in URLs, logs, or client-side code?
+-   **Client‑Side Security**: Analyze risks that manifest in the browser. This includes DOM-based XSS, insecure JavaScript dependencies (supply chain attacks), and misuse of web storage (e.g., storing sensitive data in `localStorage`).
+
+## API testing focus
+
+Modern applications heavily rely on APIs. Testing them requires a focus on their unique characteristics.
+
+-   **Discovery**: Identify all API endpoints and supported methods. This often involves finding OpenAPI/Swagger or GraphQL schema definitions, which can reveal undocumented or hidden endpoints. Watch for different versions, like `/api/v1/users` vs `/api/v2/users`.
+-   **Authentication and Authorization (AuthN/AuthZ)**:
+    -   **Broken Object Level Authorization (BOLA)**: The most common API flaw. Similar to IDOR, can an authenticated user access resources they don't own? For example, accessing `/api/v1/users/another_user_id/profile` should be forbidden.
+    -   **Broken Function Level Authorization (BFLA)**: Can a non-admin user call an admin-only endpoint, like `POST /api/v1/admin/users`?
+    -   **Token Security**: Are JSON Web Tokens (JWTs) properly validated (checking the signature and expiration)? Are token scopes enforced?
+-   **Input and Serialization**:
+    -   **Mass Assignment**: If an API endpoint automatically binds incoming JSON to object properties, an attacker might be able to overwrite sensitive fields. For example, sending `{"isAdmin": true}` when updating their user profile.
+    -   **Data Handling**: Test for proper content-type validation (e.g., rejecting `application/xml` if only `application/json` is expected) and secure file upload handling.
+-   **Rate‑Limiting and Quotas**: Test for the absence of rate-limiting on sensitive functions like login or password reset, which could allow for brute-force attacks. Check if reasonable quotas are enforced to prevent resource exhaustion.
+-   **Data Handling**: Look for excessive data exposure, where an API returns more data than the client UI displays. For instance, an endpoint might return a user object with a `passwordHash` field that is simply ignored by the frontend, but available to an attacker.
+
+## Network and infrastructure
+
+-   **External Footprint**: Map the perimeter. This includes DNS enumeration (`dig`, `dnsrecon`), checking for TLS/SSL misconfigurations (`testssl.sh`), and scanning for exposed services (`nmap`, `masscan`). Look for default credentials on management interfaces (e.g., routers, firewalls), CI/CD platforms, and artifact registries (e.g., Docker Hub, npm).
+-   **Internal Network**: Once inside, explore the local network. Enumerate hosts and services, and probe for weak protocols like SMB, NFS, and RPC. Test for network segmentation gaps—can a host in a lower-trust zone communicate with a high-trust zone?
+-   **Active Directory (AD)**: In corporate environments, AD is often a primary target. Look for common misconfigurations, attempt Kerberoasting (extracting service account hashes) or AS-REP Roasting (extracting hashes for users without Kerberos pre-authentication).
+-   **Privilege Escalation (Linux/Windows)**: Once on a host, the goal is to gain higher privileges. Search for kernel or driver vulnerabilities, misconfigured services running as root/SYSTEM, PATH variable hijacking (on Linux), or DLL hijacking (on Windows). Tools like `LinPEAS` and `WinPEAS` can automate enumeration.
+-   **Cloud Environments (Conceptual)**: Cloud security testing focuses on configuration. Look for IAM policies that violate the principle of least privilege, exposed secrets in code or environment variables, publicly accessible storage buckets (e.g., AWS S3), and unprotected instance metadata services.
+
+## Operating system and platform notes (macOS)
+
+For engagements involving macOS endpoints, consider the platform's specific security controls.
+
+-   **Platform Controls**: Assess the effectiveness of built-in security features.
+    -   **Gatekeeper and Notarization**: Ensures that only trusted software runs on the machine. Can it be bypassed?
+    -   **System Integrity Protection (SIP)**: Protects core system files and processes. Is it enabled?
+    -   **Transparency, Consent, and Control (TCC)**: Manages permissions for apps to access sensitive user data (e.g., location, contacts). Are there ways to trick a user into granting excessive permissions?
+-   **Hardening**: Verify standard security hygiene.
+    -   **Software Sources**: Is the system configured to only allow apps from the App Store and identified developers?
+    -   **FileVault**: Is full-disk encryption enabled?
+    -   **Firewall**: Is the application firewall enabled and configured correctly?
+    -   **Login Items / Launch Agents**: Review for persistence mechanisms that could be used by malware.
+-   **Telemetry and Logging**: macOS has a Unified Logging system. Ensure that sensitive data (e.g., passwords, API keys) is not inadvertently being written to logs where it could be collected by an attacker or endpoint security agent.
+
+## Evidence, safety, and ethics
+
+Professional penetration testing requires a strong ethical framework and safety controls to prevent unintended harm.
+
+-   **Data Minimization**: Collect only the minimum evidence necessary to prove a vulnerability's impact. For example, query for a user count (`SELECT COUNT(id) FROM users`) instead of dumping the entire users table. Sanitize personally identifiable information (PII) from screenshots and logs wherever possible.
+-   **Chain of Custody**: Maintain a clear record of your actions. Keep timestamped notes, take hashes of any downloaded artifacts, and clearly map your actions to the findings in your report. This ensures the integrity of your evidence.
+-   **Safety Controls**: Adhere strictly to the agreed-upon scope and rules of engagement. Use non-destructive payloads (e.g., `id` or `hostname` commands for OS injection instead of `rm -rf /`). Obtain explicit written approval before conducting any potentially disruptive tests, such as those for Denial of Service.
+-   **Cleanup**: At the end of the engagement, be a good guest. Remove any test accounts, backdoors, or payloads you introduced. Revert any configuration changes to their original state. Provide a checklist of cleanup actions to the system owners.
+
+## Reporting and risk rating
+
+The report is the primary deliverable of the engagement and must be clear, actionable, and professional.
+
+-   **Content**: A standard report includes an executive summary (high-level overview for management), a detailed breakdown of the scope and methodology, and then the core findings. Each finding should include:
+    -   A description of the vulnerability and affected assets.
+    -   Reproducible, step-by-step instructions.
+    -   Supporting evidence (e.g., screenshots, code snippets).
+    -   An assessment of the impact and likelihood.
+    -   A final risk rating.
+    -   Actionable remediation guidance.
+-   **Risk Rating**: Use a consistent and defensible rating scheme, like the [Common Vulnerability Scoring System (CVSS) v3.1](https://www.first.org/cvss/). A rating might look like: `8.8 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`. Clearly document any assumptions made during the rating process.
+-   **Remediation**: Focus on practical advice. Prioritize high-impact, systemic fixes. Propose defense-in-depth controls (e.g., not just fixing the XSS, but also implementing a strong CSP) and suggest opportunities for improved detection and monitoring.
+
+## Deliverables
+
+-   **Formal Report**: A human-readable report (typically PDF) with a sanitized version for wider distribution if needed.
+-   **Technical Annex**: An appendix with detailed reproduction steps, proof-of-concept scripts, and environment notes that may be too verbose for the main report.
+-   **Evidence Archive**: A securely shared archive (e.g., encrypted zip file) containing all evidence, with hashes to ensure integrity.
+-   **Remediation Validation Memo**: A short document confirming the results of the re-test after fixes have been applied.
+
+## Checklists
+
+### Pre‑engagement
+
+- [ ] Defined scope, ROE, test window, and contacts
+- [ ] Written authorization and safe‑harbor language
+- [ ] Test data and seeded accounts provisioned; MFA paths defined
+- [ ] Logging and detection teams informed with expected activity patterns
+- [ ] Data handling requirements (PII, secrets, retention) agreed
+- [ ] Communications cadence, incident handling, and escalation mapped
+
+### Web application (WSTG mapping)
+
+- [ ] Enumerated hosts, routes, parameters, and client‑side assets
+- [ ] Baseline security headers and TLS posture evaluated
+- [ ] Authn: MFA, password policy, recovery flows, lockout/ratelimiting
+- [ ] Authz: IDOR/horizontal/vertical checks across key objects
+- [ ] Sessions: cookie flags, rotation, invalidation, fixation
+- [ ] Injection: SQL/NoSQL/OS/LDAP/XXE/template/deserialization tested
+- [ ] XSS: reflected/stored/DOM; CSP effectiveness and bypasses
+- [ ] Business logic: workflow abuse, race conditions, replay
+- [ ] Sensitive data exposure and secrets in code, repos, or responses
+- [ ] File upload and serialization handling with content‑type validation
+
+### API
+
+- [ ] Collected and validated OpenAPI/GraphQL schemas
+- [ ] Checked BOLA/BFLA, object filtering, field‑level authorization
+- [ ] Verified token scopes, audience/issuer validation, key rotation
+- [ ] Enforced rate limits/quotas per token/user/IP/resource
+- [ ] Mass assignment/type confusion and pagination boundary tests
+
+### Network and internal
+
+- [ ] External recon: DNS/TLS, exposed services, management interfaces
+- [ ] Internal enum: SMB/NFS/RPC/LDAP/WinRM; weak segmentation paths
+- [ ] Credential hygiene: default creds, password reuse, secrets in shares
+- [ ] AD: roasting/delegation/ACL misconfigs and lateral paths
+
+### Privilege escalation and post‑exploitation
+
+- [ ] Enumerated local privilege escalation vectors (Linux/Windows)
+- [ ] Verified least‑privilege for services/agents and scheduled tasks
+- [ ] Collected minimal evidences; documented commands and timestamps
+- [ ] Cleaned up payloads, reverted configs, removed accounts/keys
+
+### Reporting and validation
+
+- [ ] Findings have clear repro, impact, and asset mapping
+- [ ] Risk ratings consistent; assumptions documented
+- [ ] Actionable remediation and detection recommendations provided
+- [ ] Re‑test plan agreed; validation results captured and signed off
+
+## Sources
+
+Repository documents referenced:
+
+- `Security/pentests/wstg-v4.2.pdf` (OWASP Web Security Testing Guide v4.2)
+- `Security/pentests/OSCP_Notes_1651671402.pdf` (OSCP methodology notes)
+- `Security/pentests/SySS_PenTest_Paper_Deutsch.pdf`
+- `Security/org/Security_Operations_Concept.pdf`
+- `Security/org/The Hacker’s Guide to Securing Your Organization_V2.pdf`
+- `Security/os security/apple-platform-security-guide.pdf`
+- `Security/os security/macOS-Security-and-Privacy-Guide.pdf`
+
+Canonical references:
+
+- OWASP WSTG v4.2: <https://owasp.org/www-project-web-security-testing-guide/>
+- OWASP API Security Top‑10: <https://owasp.org/API-Security/>
+- CVSS v3.1: <https://www.first.org/cvss/>
+
+

foomo/docs/security/web-development.md

@@ -0,0 +1,275 @@
+---
+title: Secure Web Application Development
+slug: /security/web-development
+---
+
+## Overview
+
+This guide distills practical, engineering-focused best practices for building and operating secure web applications. It emphasizes preventative controls, defense-in-depth, and testable requirements you can wire into your SDLC and CI/CD pipeline.
+
+Primary sources: the [OWASP Web Security Testing Guide v4.2 (WSTG)](https://owasp.org/www-project-web-security-testing-guide/), [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/), and [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/). Controls are mapped to these standards to keep implementation and testing aligned.
+
+## How to use this document
+
+- Skim the Table of Contents to jump to a topic.
+- For each section, use the checklist-style bullets during design, coding, and review.
+- New to some terms? Inline links and short explanations are provided.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [How to use this document](#how-to-use-this-document)
+- [Security Principles](#security-principles)
+- [Secure SDLC](#secure-sdlc)
+- [Quick Engineering Checklist (build-time)](#quick-engineering-checklist-build-time)
+- [Runtime and Configuration Hardening](#runtime-and-configuration-hardening)
+- [Area-by-Area Best Practices](#area-by-area-best-practices)
+- [Pre-Release Test Checklist](#pre-release-test-checklist-mapping-to-wstg)
+- [References](#references)
+
+## Security Principles
+
+These core principles should guide every engineering decision. They are ordered from most to least impactful.
+
+- **Secure by default**: Systems should be secure out-of-the-box. This means enabling minimal features and privileges and using deny-by-default policies.
+  - *Example*: A new firewall should block all traffic by default, requiring explicit rules to allow specific ports. User accounts should start with the lowest possible permissions.
+- **Least privilege**: Grant only the minimum permissions necessary for an identity (user, service, or system) to perform its intended function.
+  - *Example*: An application's database user should only have `SELECT`, `INSERT`, `UPDATE` permissions, not `DROP` or `ALTER`. An admin API token should be scoped to specific actions, not given full admin rights.
+- **Defense in depth**: Implement multiple, layered, and independent security controls. If one control fails, others are in place to stop an attack.
+  - *Example*: To prevent SQL injection, you might have: 1) a Web Application Firewall (WAF), 2) strict input validation, and 3) parameterized database queries. A failure in one layer is caught by the next.
+- **Trust boundaries**: A trust boundary is any point where data crosses from a less-trusted area to a more-trusted area. Always validate and sanitize data crossing these boundaries. Never trust client-controlled input.
+  - *Example*: In a client-server application, the API endpoint is a trust boundary. Validate all incoming data from the client, even if client-side validation already occurred.
+- **Fail securely**: Applications should fail in a way that denies access and does not leak sensitive information.
+  - *Example*: If a database connection is lost during an authorization check, the system must deny access, not grant it. Error pages should show a generic message and a correlation ID, not a full stack trace.
+- **Privacy by design**: Build privacy considerations into the system from the start. Collect only the data you need, limit its purpose, and retain it for the shortest time necessary.
+  - *Example*: Instead of storing a user's date of birth, store only their age or a boolean indicating if they are over 18, if that's all you need. Redact sensitive data like passwords and credit card numbers from logs.
+- **Automate guardrails**: Encode security requirements into automated tests, CI/CD pipelines, and infrastructure templates. This makes security consistent and scalable.
+  - *Example*: A CI pipeline could automatically run a Static Application Security Testing (SAST) tool and fail the build if any high-severity vulnerabilities are found.
+
+## Secure SDLC
+
+Integrating security into every phase of the Software Development Lifecycle (SDLC) is more effective and cheaper than trying to add it at the end.
+
+- **Requirements & Threat Modeling**: Before writing code, define security requirements using a standard like OWASP ASVS. For any new feature or service, conduct threat modeling to identify potential abuse cases and data flow vulnerabilities.
+  - *Example*: For a file upload feature, threats include uploading malware, oversized files (DoS), or a web shell. Controls would include file type validation, size limits, and malware scanning.
+- **Standards & Reuse**: Codify security standards for your organization. Create reusable libraries and services for critical operations like authentication, authorization, and encryption. Enforce standards with linters and code review checklists.
+- **Dependencies**: Use a dependency scanner ([SCA](https://en.wikipedia.org/wiki/Software_composition_analysis)) like Dependabot or Snyk to find and fix known vulnerabilities in your third-party packages. Use lockfiles (`package-lock.json`, `yarn.lock`, `go.sum`) to ensure builds are reproducible and verified.
+- **Coding**: Write code with security in mind. Use frameworks with built-in security features (like auto-escaping to prevent XSS). Implement centralized authentication and authorization checks. Use contextual encoding for all output.
+- **Reviews**: Perform security-focused code reviews, especially for sensitive changes (e.g., in auth logic, payment flows). A two-person review rule for critical components is a good practice.
+- **Testing**:
+  - **SAST** ([Static Application Security Testing](https://en.wikipedia.org/wiki/Static_application_security_testing)): Scan source code for vulnerabilities like SQL injection or insecure configurations. Tools: Snyk Code, SonarQube.
+  - **SCA** ([Software Composition Analysis](https://en.wikipedia.org/wiki/Software_composition_analysis)): Find known vulnerabilities in open-source dependencies.
+  - **Secrets Scanning**: Scan code and git history for accidentally committed secrets. Tools: git-secrets, TruffleHog.
+  - **IaC Scan** ([Infrastructure as Code](https://en.wikipedia.org/wiki/Infrastructure_as_code)): Scan Terraform, CloudFormation, or Kubernetes manifests for misconfigurations. Tools: tfsec, checkov.
+  - **DAST** ([Dynamic Application Security Testing](https://en.wikipedia.org/wiki/Dynamic_application_security_testing)): Test the running application for vulnerabilities by simulating attacks. Tools: OWASP ZAP, Burp Suite.
+- **Pre-release**: Triage and fix all high and critical vulnerabilities before release. For significant new features, perform targeted manual penetration tests based on the WSTG.
+- **Release & Config**: Use Infrastructure as Code (IaC) to manage and version your infrastructure. Fetch secrets at runtime from a secure vault (e.g., HashiCorp Vault, AWS Secrets Manager). Deploy applications with least-privilege service accounts and roles.
+- **Operate**: Monitor application and infrastructure logs for security events. Use a WAF with rate limiting to protect against automated attacks. Have runbooks and playbooks ready for incident response.
+
+## Quick Engineering Checklist (build-time)
+
+A quick-reference list for engineers during development.
+
+- **Choose a baseline**: Adopt an OWASP ASVS level (e.g., Level 1 for low-risk apps, Level 2 for most apps) and link to it in user stories.
+- **Threat model new/changed flows**: Whiteboard potential attacks on new authentication flows, payment integrations, file uploads, admin panels, etc.
+- **Secrets management**: Use a secrets vault. Never hardcode secrets in code, config files, or CI/CD variables. Rotate keys and scope permissions tightly.
+- **Dependency hygiene**: Integrate SCA into your CI pipeline. Block builds with known critical vulnerabilities. Pin dependencies and update them regularly.
+- **Static analysis**: Run SAST and secrets scanning on every commit. Enforce quality gates on main branches to prevent merging vulnerable code.
+- **Authz tests**: Write automated tests that verify both positive and negative access control cases (e.g., "user A *can* access their own data," "user A *cannot* access user B's data").
+- **Input validation & encoding**: Use centralized validation libraries. Rely on your framework's auto-escaping features for output.
+- **Security headers**: Set strong security headers.
+  - *Example*: `Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none';`
+  - `Strict-Transport-Security: max-age=31536000; includeSubDomains`
+  - `X-Content-Type-Options: nosniff`
+- **CORS**: Use an explicit allowlist of origins. Never use `*` with `Access-Control-Allow-Credentials: true`.
+  - *Example*: `Access-Control-Allow-Origin: https://trusted.example.com`
+- **Release gates**: Ensure no high or critical vulnerabilities are outstanding before release. Perform quick WSTG-based spot checks for new features.
+
+## Runtime and Configuration Hardening
+
+Securing the environment where your application runs.
+
+- **TLS**: Enforce TLS 1.2 or higher. Use a tool like [SSL Labs Server Test](https://www.ssllabs.com/ssltest/) to check your configuration. Enable HSTS with preload for high-security sites.
+- **Cookies & Sessions**: Set secure flags on cookies. Rotate session IDs on login or privilege changes.
+  - *Example*: `Set-Cookie: sessionId=abc; HttpOnly; Secure; SameSite=Strict; Path=/;`
+- **Headers**:
+  - `Content-Security-Policy`: A strong CSP is one of the most effective ways to prevent XSS. Use nonces or hashes for inline scripts.
+  - `X-Content-Type-Options: nosniff`: Prevents the browser from MIME-sniffing a response away from the declared content type.
+  - `Permissions-Policy`: Restrict which browser features (e.g., camera, microphone, geolocation) the page can use.
+  - `Referrer-Policy`: Control how much referrer information is sent with requests.
+- **CORS**: Only allow trusted origins. Preflight requests should be enforced by the browser for non-simple requests.
+- **Rate limiting & DoS**: Protect against brute-force and denial-of-service attacks by implementing rate limits on sensitive endpoints like login, password reset, and expensive API calls.
+- **WAF/CDN**: Use a Web Application Firewall (WAF) to filter malicious traffic. A CDN can provide DDoS protection and performance benefits.
+- **Egress control**: Restrict outbound network connections from your servers to only what is absolutely necessary. This can prevent data exfiltration and limit the impact of an SSRF vulnerability.
+- **Secrets**: Fetch secrets at runtime from a vault. Use short-lived credentials and tokens where possible (e.g., AWS IAM roles, short-lived database credentials).
+- **Observability**: Use structured logging (e.g., JSON) and forward logs to a centralized security monitoring system (SIEM). Alert on security-relevant events like authentication failures, privilege escalations, and spikes in 4xx/5xx errors.
+
+## Area-by-Area Best Practices
+
+### Authentication ([WSTG-ATHN](https://owasp.org/www-project-web-security-testing-guide/))
+- **Centralize identity**: Use a dedicated, well-tested identity provider or library. Implement multi-factor authentication (MFA). Ensure password reset and account recovery flows are secure (e.g., using time-limited tokens sent to a verified email or phone).
+- **Password storage**: Store password hashes using a memory-hard algorithm like [Argon2id](https://www.rfc-editor.org/rfc/rfc9106) (preferred) or bcrypt.
+  ```go
+  // Example using Go's bcrypt library
+  hashedPassword, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
+  ```
+- **Throttling**: Throttle login attempts by IP address and username to slow down brute-force attacks. Implement account lockouts after a certain number of failed attempts.
+- **Re-authentication**: Require users to re-enter their password before performing sensitive actions like changing their email address or deleting their account.
+
+### Session Management ([WSTG-SESS](https://owasp.org/www-project-web-security-testing-guide/))
+- **Session tokens**: Use high-entropy, randomly generated session IDs. Store them on the server-side (e.g., in a database or Redis cache). Avoid long-lived stateless tokens (like JWTs) for sessions unless you have a robust revocation strategy.
+- **Cookie flags**:
+  - `HttpOnly`: Prevents JavaScript from accessing the cookie, mitigating XSS.
+  - `Secure`: Ensures the cookie is only sent over HTTPS.
+  - `SameSite=Lax` or `Strict`: A primary defense against CSRF. `Lax` is a good default.
+- **Lifecycle**: Invalidate session tokens on the server-side immediately upon logout or a password change. Consider expiring idle sessions after a reasonable period (e.g., 15-30 minutes for sensitive applications).
+
+### Authorization & Access Control ([WSTG-ATHZ](https://owasp.org/www-project-web-security-testing-guide/), IDOR)
+- **Server-side enforcement**: Authorization checks *must* be performed on the server. Never rely on hiding UI elements on the client, as an attacker can always craft their own requests.
+- **Object-level checks (IDOR)**: Insecure Direct Object References (IDOR) are a common and severe vulnerability. On every request that accesses a resource by an ID, verify that the current user is authorized to access that specific resource.
+  ```go
+  // Vulnerable:
+  func GetOrder(c *gin.Context) {
+    orderID := c.Param("id")
+    order := db.FindByID(orderID) // Attacker can request any order ID
+    c.JSON(200, order)
+  }
+
+  // Secure:
+  func GetOrder(c *gin.Context) {
+    currentUser := c.MustGet("user").(User)
+    orderID := c.Param("id")
+    order := db.FindByID(orderID)
+    if order.UserID != currentUser.ID { // Check ownership
+      c.JSON(403, "Forbidden")
+      return
+    }
+    c.JSON(200, order)
+  }
+  ```
+- **Function-level checks**: Verify that the user's role permits them to perform the requested action (e.g., a `viewer` cannot `edit`).
+- **Multi-tenant isolation**: In multi-tenant systems, ensure all database queries are strictly scoped to the current tenant ID to prevent data leakage between tenants.
+
+### Input Validation & Output Encoding ([WSTG-INPV](https://owasp.org/www-project-web-security-testing-guide/), XSS)
+- **Input validation**: Validate all incoming data on the server. Use an allowlist approach (i.e., accept only known-good values) and enforce strict types, formats, and length limits.
+- **Output encoding**: Encode all data before it is rendered in a template to prevent Cross-Site Scripting (XSS). Rely on the automatic contextual encoding provided by modern templating frameworks.
+  ```html
+  <!-- Go's html/template automatically escapes data -->
+  <!-- If userInput is "<script>alert(1)</script>", it will be rendered as text, not executed. -->
+  <div>{{ .userInput }}</div>
+
+  <!-- React also auto-escapes -->
+  <div>{userInput}</div>
+  ```
+- **Untrusted HTML**: If you must render user-supplied HTML, sanitize it with a robust library like DOMPurify. Never use `innerHTML` or similar functions with unsanitized data.
+
+### Injection: SQL/NoSQL/Command/Template/LDAP ([WSTG-INPV](https://owasp.org/www-project-web-security-testing-guide/), [WSTG-INJ](https://owasp.org/www-project-web-security-testing-guide/))
+- **Parameterized queries**: The single most effective defense against SQL injection is to use parameterized queries (also called prepared statements). Never build queries by concatenating strings.
+  ```go
+  // Vulnerable to SQL Injection
+  query := "SELECT * FROM users WHERE username = '" + username + "'"
+  db.Query(query)
+
+  // Secure using parameterized query
+  db.Query("SELECT * FROM users WHERE username = ?", username)
+  ```
+- **Command injection**: Avoid calling shell commands with user input. If you must, use functions that handle argument escaping properly and avoid parsing the command as a single string.
+- **ORM/DB Libraries**: Use Object-Relational Mapping (ORM) libraries or database drivers that provide safe, parameterized APIs by default.
+
+### Cross-Site Request Forgery ([WSTG-CRS](https://owasp.org/www-project-web-security-testing-guide/))
+- **Synchronizer tokens**: The most robust defense is the synchronizer token pattern. A unique, unpredictable token is embedded in each form, and the server validates this token upon submission.
+- **SameSite cookies**: Use `SameSite=Strict` or `SameSite=Lax` on your session cookies. This is a powerful defense that instructs the browser not to send cookies on cross-origin requests. It should be used in addition to synchronizer tokens for defense-in-depth.
+- **Check HTTP method**: Always ensure that state-changing actions are performed only via `POST`, `PUT`, `PATCH`, or `DELETE` requests, never `GET`.
+
+### Deserialization and Data Parsing ([WSTG-DV](https://owasp.org/www-project-web-security-testing-guide/), XXE)
+- **Avoid unsafe deserialization**: In languages like Java, C#, and PHP, deserializing untrusted data can lead to remote code execution. Avoid generic deserialization of objects. Use simple data formats like JSON and parse them into strongly-typed objects.
+- **XML External Entities (XXE)**: If you must parse XML, configure your parser to disable resolution of external entities (XXE) and DTDs to prevent information disclosure and SSRF.
+
+### File Uploads & Downloads ([WSTG-BUSL](https://owasp.org/www-project-web-security-testing-guide/))
+- **Upload validation**:
+  - Validate the file type on the server using its content (magic bytes), not just the `Content-Type` header or file extension.
+  - Enforce strict size limits.
+  - Scan uploaded files for malware.
+- **Storage**:
+  - Store uploaded files in a location outside the web root (e.g., an S3 bucket or a dedicated directory).
+  - Assign a new, randomized filename to the stored file to prevent path traversal or execution attacks.
+- **Downloads**: For file downloads, set the `Content-Disposition: attachment; filename="user-facing-name.ext"` header to prevent the browser from rendering the file inline, which can lead to XSS.
+
+### SSRF and Server-Side Fetches ([WSTG-SSR](https://owasp.org/www-project-web-security-testing-guide/))
+- **Server-Side Request Forgery (SSRF)**: Occurs when an attacker can trick the server into making a request to an arbitrary destination.
+  ```go
+  // Vulnerable: fetches any URL provided by the user
+  url := c.Query("imageUrl")
+  http.Get(url)
+  ```
+- **Mitigation**:
+  - **Allowlist**: Maintain a strict allowlist of permitted domains, IPs, and ports the server can connect to. Deny by default.
+  - **Block internal networks**: Explicitly block requests to private IP ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) and cloud metadata endpoints (e.g., `169.254.169.254`).
+
+### Path Traversal & Resource Access ([WSTG-ATHZ](https://owasp.org/www-project-web-security-testing-guide/), [WSTG-ATHN](https://owasp.org/www-project-web-security-testing-guide/))
+- **Path normalization**: If accessing files based on user input, normalize the path to resolve sequences like `../` and ensure it is still within the intended directory.
+  - *Example Attack*: `?filename=../../../etc/passwd`
+
+### Error Handling, Logging, and Privacy ([WSTG-INFO](https://owasp.org/www-project-web-security-testing-guide/), [WSTG-CONF](https://owasp.org/www-project-web-security-testing-guide/))
+- **Generic errors**: Show generic, non-technical error messages to the user.
+  - **Bad**: `FATAL: connection to database "prod_db" failed: password authentication failed for user "webapp"`
+  - **Good**: `An unexpected error occurred. Please try again. (Error ID: 9f4e1a2b)`
+- **Structured logging**: Log security-relevant events in a structured format like JSON. Redact all sensitive data (passwords, PII, API keys) from logs.
+
+### Cryptography & Data Protection ([WSTG-CRYP](https://owasp.org/www-project-web-security-testing-guide/))
+- **Use standard libraries**: Use well-vetted, standard cryptographic libraries for your language. Do not invent your own crypto.
+- **Modern algorithms**: Use modern, authenticated encryption (AEAD) ciphers like AES-256-GCM or ChaCha20-Poly1305.
+- **Key management**: Encrypt sensitive data both in transit (TLS) and at rest (database/disk encryption). Use a dedicated Key Management Service (KMS) or Hardware Security Module (HSM) to manage encryption keys.
+
+### Browser and Platform Security ([WSTG-CLNT](https://owasp.org/www-project-web-security-testing-guide/))
+- **Content Security Policy (CSP)**: A strong CSP is a critical defense against XSS. Start with a strict policy and use nonces or `strict-dynamic` for scripts.
+- **Clickjacking defense**: Use the `Content-Security-Policy: frame-ancestors 'self'` header (or the older `X-Frame-Options: SAMEORIGIN`) to prevent your site from being embedded in an iframe on a malicious site.
+- **Subresource Integrity (SRI)**: When loading scripts or styles from a third-party CDN, use SRI to ensure the file has not been tampered with.
+  `<script src="https://example.com/library.js" integrity="sha384-..." crossorigin="anonymous"></script>`
+
+### CORS ([WSTG-CONF](https://owasp.org/www-project-web-security-testing-guide/))
+- **Explicit allowlist**: Your server should respond with an `Access-Control-Allow-Origin` header that specifies the exact origin(s) allowed.
+- **Credentials**: If you must set `Access-Control-Allow-Credentials: true`, the `Access-Control-Allow-Origin` header *cannot* be a wildcard (`*`). It must be an explicit origin.
+
+### API (REST/GraphQL) Specifics ([WSTG-API](https://owasp.org/www-project-web-security-testing-guide/))
+- **Schema validation**: Strictly validate all incoming requests against a defined schema. Reject any requests with unknown or malformed parameters.
+- **Resource limiting**: Implement pagination on all endpoints that return lists of data. Limit the size and complexity of API requests to prevent denial-of-service.
+- **GraphQL security**:
+  - **Query depth/complexity limiting**: Prevent expensive, deeply nested queries that could overwhelm your database.
+  - **Disable introspection**: Turn off GraphQL introspection in production environments to avoid leaking schema information.
+  - **Authorization**: Implement authorization checks at the resolver level for each field.
+
+### Secrets and Supply Chain ([WSTG-CONF](https://owasp.org/www-project-web-security-testing-guide/))
+- **Central secret store**: Use a vault for all secrets. Your CI/CD pipeline, infrastructure, and applications should all fetch secrets from this central store at runtime.
+- **Supply chain**:
+  - **Signed builds**: Sign your build artifacts to ensure their integrity.
+  - **SBOM**: Generate a Software Bill of Materials (SBOM) for your applications to inventory all dependencies.
+  - **Image scanning**: Scan container images for known vulnerabilities before deploying them.
+
+### CI/CD & Infrastructure
+- **Least-privilege CI/CD**: CI/CD jobs should run with the minimum permissions needed. Use short-lived, scoped tokens for deployments.
+- **Branch protections**: Enforce branch protection rules on your main branch, requiring mandatory code reviews and passing CI checks before merging.
+- **Container security**:
+  - **Minimal images**: Use minimal base images (e.g., `distroless`, `alpine`).
+  - **Non-root user**: Run your application as a non-root user inside the container.
+  - **Read-only rootfs**: Configure the container's root filesystem to be read-only where possible.
+- **Network policies**: Use Kubernetes network policies or cloud security groups to restrict traffic between services (east-west) and from the internet (north-south).
+
+## Pre-Release Test Checklist (mapping to WSTG)
+
+- **Recon & Info**: review exposed endpoints, metadata, headers (WSTG-INFO)
+- **Authn/Authz**: test login flows, MFA, password reset, IDOR, function-level authz (WSTG-ATHN/ATHZ)
+- **Session**: cookie flags, rotation, invalidation (WSTG-SESS)
+- **Input/Output**: XSS (reflected/stored/DOM), template injection, encoding (WSTG-INPV/CLNT)
+- **Injection**: SQL/NoSQL/command/LDAP/ORM; path traversal (WSTG-INJ)
+- **CSRF**: token presence/validation; method safety; SameSite (WSTG-CRS)
+- **Files**: upload/download handling; MIME/extension; storage location (WSTG-BUSL)
+- **SSRF/XXE**: deny internal targets; parser hardening (WSTG-SSR/XXE)
+- **Config**: headers, CORS, TLS, error messages, directory listing (WSTG-CONF)
+- **API**: schema validation, rate limiting, error handling, GraphQL limits (WSTG-API)
+
+## References
+
+- OWASP Web Security Testing Guide v4.2 — Detailed test cases for every category listed above ([OWASP WSTG](https://owasp.org/www-project-web-security-testing-guide/))
+- OWASP Application Security Verification Standard — A catalog of security requirements to build into your development process ([OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/))
+- OWASP Cheat Sheet Series — Concise, actionable guidance on specific security topics ([OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/))

foomo/docs/security/windows.md

@@ -0,0 +1,61 @@
+---
+title: Windows Security
+slug: /security/windows
+---
+
+## Overview
+
+This document provides a high-level overview of Windows security hardening, with a focus on leveraging community-driven configurations. Unlike macOS and Linux, which are often hardened from a minimal baseline, Windows security can be significantly improved by applying comprehensive security templates and scripts.
+
+This guide is primarily based on the principles and tools provided by the [Harden-Windows-Security](https://github.com/HotCakeX/Harden-Windows-Security) project. It is recommended to thoroughly read and understand the project's documentation before applying any configurations.
+
+## Core Principles
+
+- **Reduce Attack Surface**: Disable unnecessary features, services, and applications that could serve as entry points for attackers.
+- **Enforce Strong Policies**: Use Group Policy, AppLocker, and other Windows features to enforce strict rules about what users and applications can do.
+- **Leverage Built-in Security Features**: Maximize the use of Windows Defender, BitLocker, Controlled Folder Access, and other native security controls.
+- **Automate and Standardize**: Use scripts and configuration management to apply a consistent and repeatable security baseline to all Windows systems.
+
+## Recommended Implementation
+
+The `Harden-Windows-Security` repository provides a collection of PowerShell scripts, Group Policy templates, and configuration files to automate the hardening process.
+
+### Key Features from the Project:
+
+- **Comprehensive Security Policies**: Hundreds of settings covering Group Policy, PowerShell configurations, and Windows Defender hardening.
+- **Threat Mitigation**: Includes rules and settings to block common attack vectors, malware, and potentially unwanted programs (PUPs).
+- **Usability vs. Security Profiles**: The project offers different levels of hardening, allowing administrators to choose a balance between maximum security and user convenience.
+- **Regular Updates**: The project is actively maintained to adapt to new threats and changes in the Windows operating system.
+
+### How to Use
+
+1.  **Read the Documentation**: Start by reading the `README.md` and associated documentation in the [Harden-Windows-Security GitHub repository](https://github.com/HotCakeX/Harden-Windows-Security). Understand the different profiles and what each setting does.
+2.  **Test in a Non-Production Environment**: **Do not** apply these settings directly to production machines. Test them thoroughly on a virtual machine or a dedicated test computer to ensure they do not break critical applications or workflows.
+3.  **Choose a Profile**: Select a hardening profile from the repository that matches your organization's security requirements.
+4.  **Deploy Systematically**: Use a phased approach to roll out the changes. Start with a small group of users and gradually expand the deployment.
+5.  **Monitor and Audit**: After deployment, continuously monitor system logs and use security auditing tools to verify that the policies are being enforced correctly and are not causing unintended side effects.
+
+## Quick Reference Checklist
+
+This checklist summarizes the areas covered by the `Harden-Windows-Security` project. Refer to the project for detailed implementation steps.
+
+- [ ] **System Hardening**:
+  - [ ] Apply security-focused Group Policies.
+  - [ ] Disable legacy protocols and features (e.g., SMBv1, PowerShell v2).
+  - [ ] Harden Task Scheduler and other system components.
+- [ ] **Application Control**:
+  - [ ] Use AppLocker or Windows Defender Application Control (WDAC) to restrict application execution.
+  - [ ] Block commonly exploited applications (e.g., legacy script hosts).
+- [ ] **Data Protection**:
+  - [ ] Enable BitLocker full-disk encryption.
+  - [ ] Enable Controlled Folder Access to protect against ransomware.
+- [ ] **Microsoft Defender Suite**:
+  - [ ] Maximize Defender Antivirus protection levels.
+  - [ ] Enable Attack Surface Reduction (ASR) rules.
+  - [ ] Configure Defender Firewall with a default-deny policy.
+- [ ] **Privacy**:
+  - [ ] Disable non-essential telemetry and data collection.
+
+## References
+
+- [Harden-Windows-Security GitHub Repository](https://github.com/HotCakeX/Harden-Windows-Security)

foomo/sidebars.js

@@ -20,6 +20,7 @@ const sidebars = {
   frontendSidebar: [{type: 'autogenerated', dirName: 'frontend'}],
   devopsSidebar: [{type: 'autogenerated', dirName: 'devops'}],
   projectsSidebar: [{type: 'autogenerated', dirName: 'projects'}],
+  securitySidebar: [{type: 'autogenerated', dirName: 'security'}],
   //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
   //backendSidebar: [{type: 'autogenerated', dirName: './backend'}],