open-agreements 0.2.0 → 0.2.2

package/skills/iso-27001-internal-audit/rules/access-control.md

@@ -0,0 +1,191 @@
+# Access Control Rules
+
+Per-control audit guidance for identity, authentication, and authorization controls.
+
+## A.5.15 — Access Control Policy & Enforcement
+
+**Tier**: Critical | **NIST**: AC-1, AC-2, AC-3, AC-6
+
+Ensure access to information and systems is restricted based on business and security requirements. The access control policy should define rules for granting, reviewing, and revoking access based on the principle of least privilege.
+
+**Auditor hints**:
+- Auditors want to see the access control POLICY and evidence it's being FOLLOWED — not just that a policy document exists
+- They'll sample 3-5 joiners and 3-5 leavers to verify access was provisioned/revoked correctly
+- Look for: quarterly access reviews with documented decisions (retain/revoke), not just screenshots of user lists
+- Common gap: policy says "least privilege" but admin accounts are used for daily work
+
+**Evidence collection**:
+```bash
+# GitHub org members and roles
+gh api orgs/{org}/members --paginate | jq '.[] | {login, role: .role}'
+
+# GCP IAM bindings
+gcloud projects get-iam-policy {project} --format=json | jq '.bindings'
+
+# Azure role assignments
+az role assignment list --all --output json
+
+# Google Workspace users
+gam print users fields name,email,orgUnitPath,suspended,isAdmin
+```
+
+**Startup pitfalls**:
+- Using shared accounts ("the deploy key") instead of individual credentials
+- No documented process for access requests — "just Slack the admin" isn't auditable
+- Access reviews never done or done once then abandoned
+
+---
+
+## A.5.16 — Identity Management
+
+**Tier**: Critical | **NIST**: AC-2, IA-2, IA-4, IA-8, IA-12
+
+Manage the full lifecycle of identities — from provisioning through changes to deprovisioning. Each person should have a unique identity; shared/generic accounts should be documented exceptions.
+
+**Auditor hints**:
+- Auditors check for unique user IDs — generic accounts like "admin@" or "deploy@" are flags
+- They'll look for identity lifecycle evidence: joiner provisioning, mover role changes, leaver deprovisioning
+- Service accounts count as identities — they need owners and review cycles too
+
+**Evidence collection**:
+```bash
+# List all identities in IdP
+gam print users fields primaryEmail,name,creationTime,lastLoginTime,suspended
+
+# Service accounts (GCP)
+gcloud iam service-accounts list --format=json | jq '.[] | {email, displayName, disabled}'
+
+# GitHub service/bot accounts
+gh api orgs/{org}/members --paginate | jq '[.[] | select(.type == "Bot")]'
+```
+
+---
+
+## A.5.17 — Authentication Information
+
+**Tier**: Critical | **NIST**: IA-1, IA-5
+
+Manage authentication credentials (passwords, tokens, keys, certificates) through their lifecycle. Define minimum strength requirements and enforce MFA where available.
+
+**Auditor hints**:
+- MFA is the #1 thing auditors check — if it's not enforced on production systems and admin accounts, expect a finding
+- They'll verify password policy in the IdP matches the documented policy
+- API keys and tokens need rotation schedules — "we'll rotate if compromised" is not a policy
+- SSH keys should have expiration dates or documented rotation cadence
+
+**Evidence collection**:
+```bash
+# Google Workspace MFA enforcement
+gam print users fields primaryEmail,isEnrolledIn2Sv,isEnforcedIn2Sv
+
+# GitHub org MFA requirement
+gh api orgs/{org} | jq '{two_factor_requirement_enabled}'
+
+# Azure AD MFA status
+az ad user list --query "[].{name:displayName,mfa:strongAuthenticationDetail}" --output json
+```
+
+---
+
+## A.5.18 — Access Rights
+
+**Tier**: Critical | **NIST**: AC-2, PS-5
+
+Provision, review, modify, and revoke access rights in accordance with the access control policy. Access rights should be reviewed at regular intervals and promptly revoked when no longer needed.
+
+**Auditor hints**:
+- The "48-hour rule": auditors expect access revocation within 24-48 hours of termination, not just at the next quarterly review
+- They'll cross-reference HR termination dates with last-active dates in systems
+- Role changes (promotions, transfers) should trigger access reviews — people accumulate permissions over time
+- Look for orphaned accounts: users who left but still show as active
+
+**Evidence collection**:
+```bash
+# Cross-reference terminated users with active accounts
+# Step 1: Get terminated users from HR system (export CSV)
+# Step 2: Check against active users
+gam print users fields primaryEmail,suspended,lastLoginTime | grep -v "True"
+
+# GitHub: check for stale members
+gh api orgs/{org}/members --paginate | jq '.[] | {login, updated_at}'
+```
+
+---
+
+## A.8.2 — Privileged Access Rights
+
+**Tier**: Critical | **NIST**: AC-6
+
+Restrict and manage the allocation of privileged access rights (admin, root, superuser). Privileged access should be time-limited where possible and subject to enhanced monitoring.
+
+**Auditor hints**:
+- Auditors want a LIST of all privileged users across all systems — if you can't produce this, it's a finding
+- "Everyone is admin" is a common startup pattern and a guaranteed finding
+- Just-in-time (JIT) access is best practice but not required — having a small, documented set of admins is sufficient
+- Privileged access should have separate credentials from daily-use accounts
+
+**Evidence collection**:
+```bash
+# GCP: users with Owner/Editor roles
+gcloud projects get-iam-policy {project} --format=json | \
+  jq '.bindings[] | select(.role == "roles/owner" or .role == "roles/editor")'
+
+# GitHub: org owners
+gh api orgs/{org}/members?role=admin --paginate | jq '.[].login'
+
+# Azure: Global Admins (via MS Graph)
+az rest --method GET \
+  --url "https://graph.microsoft.com/v1.0/directoryRoles/$(az rest --method GET --url 'https://graph.microsoft.com/v1.0/directoryRoles' --query "value[?displayName=='Global Administrator'].id" -o tsv)/members" \
+  --query "value[].{displayName:displayName,upn:userPrincipalName}" -o json
+```
+
+---
+
+## A.8.3 — Information Access Restriction
+
+**Tier**: Critical | **NIST**: AC-3, AC-6
+
+Restrict access to information and application functions based on the access control policy. Systems should enforce access restrictions, not rely on user self-governance.
+
+**Auditor hints**:
+- Auditors test this by checking if users have access they shouldn't — especially cross-environment (dev accessing prod data)
+- Database access is a common gap: developers often have direct production database access "for debugging"
+- API key scoping: keys that grant broad access when narrow scope would suffice
+
+**Evidence collection**:
+```bash
+# GCP: check for overly broad IAM roles
+gcloud projects get-iam-policy {project} --format=json | \
+  jq '.bindings[] | select(.role | test("roles/(owner|editor|viewer)"))'
+
+# GitHub: repo access by team
+gh api orgs/{org}/teams --paginate | jq '.[].slug' | while read team; do
+  echo "=== $team ===" && gh api orgs/{org}/teams/$team/repos --paginate | jq '.[].name'
+done
+```
+
+---
+
+## A.8.5 — Secure Authentication
+
+**Tier**: Critical | **NIST**: AC-7, IA-2, IA-6, IA-8, SC-23
+
+Implement secure authentication mechanisms including MFA, session management, account lockout, and authentication feedback controls.
+
+**Auditor hints**:
+- MFA enforcement is non-negotiable for production and admin access
+- Session timeout should be configured (15-30 min inactive for sensitive systems)
+- Account lockout after failed attempts — check IdP configuration
+- SSO is strongly preferred over individual application passwords
+
+**Evidence collection**:
+```bash
+# Google Workspace: session control and MFA
+gam print users fields primaryEmail,isEnforcedIn2Sv
+
+# GitHub: org settings
+gh api orgs/{org} | jq '{two_factor_requirement_enabled, default_repository_permission}'
+
+# Check session timeout in cloud console (usually screenshot needed)
+# macOS: screencapture -x ~/evidence/session-config_$(date +%Y-%m-%d).png
+```

package/skills/iso-27001-internal-audit/rules/business-continuity.md

@@ -0,0 +1,94 @@
+# Business Continuity Rules
+
+Per-control audit guidance for backup, disaster recovery, and business continuity planning.
+
+## A.5.30 — ICT Readiness for Business Continuity
+
+**Tier**: Critical | **NIST**: CP-1, CP-2, CP-3, CP-4
+
+Ensure ICT systems can be recovered within required timeframes during disruption. Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for critical systems. Test recovery procedures regularly.
+
+**Auditor hints**:
+- Auditors check THREE things: (1) BCP/DR plan exists with defined RTO/RPO, (2) the plan has been TESTED, (3) test results are documented
+- A plan tested > 12 months ago is a finding — annual testing is the minimum
+- "We use cloud so we're resilient" is not a BCP — auditors want to see that YOU tested failover, not just that your provider can
+- RTO/RPO should be defined per system based on business impact analysis, not a blanket number
+- The test should include actual recovery steps, not just "we verified the backup exists"
+
+**Evidence collection**:
+- Business continuity plan (with version date)
+- Business impact analysis (system criticality, RTO/RPO per system)
+- DR test records (date, scope, participants, results, issues found)
+- Recovery time actuals vs. RTO targets
+
+```bash
+# GCP: verify backup configuration
+gcloud sql instances describe {instance} --format="json(settings.backupConfiguration)"
+
+# Azure: check backup policy
+az backup policy list --resource-group {rg} --vault-name {vault} --output json
+
+# AWS: backup plans
+# aws backup list-backup-plans --output json
+```
+
+**Startup pitfalls**:
+- Having backups but never testing restore — a backup you can't restore from is worthless
+- No defined RTO/RPO — "as fast as possible" is not a measurable objective
+- BCP covers infrastructure but not data (database backups, secrets, configuration)
+- Single-region deployment with no failover plan
+
+---
+
+## A.8.13 — Information Backup
+
+**Tier**: Critical | **NIST**: CP-9
+
+Maintain and regularly test backup copies of information, software, and system configurations. Backups should be stored separately from primary systems and encrypted.
+
+**Auditor hints**:
+- Auditors verify: backup frequency matches RPO, backups are encrypted, backups are stored in a different location/region
+- They'll ask for a RECENT RESTORE TEST — "we restored a database in Q2" with evidence
+- Automated backups are good but auditors still want to see that someone verified they completed successfully
+- Backup alerts (failure notifications) should be configured and monitored
+
+**Evidence collection**:
+```bash
+# GCP: Cloud SQL backup history
+gcloud sql backups list --instance={instance} --format=json | jq '.[0:5]'
+
+# GCP: Cloud Storage versioning (for file backups)
+gsutil versioning get gs://{bucket}
+
+# Azure: backup job history
+az backup job list --resource-group {rg} --vault-name {vault} --output json | jq '.[0:5]'
+
+# Verify backup encryption
+gcloud sql instances describe {instance} --format="json(settings.dataDiskEncryptionConfiguration)"
+```
+
+---
+
+## A.8.14 — Redundancy of Information Processing Facilities
+
+**Tier**: Relevant | **NIST**: CP-6, CP-7, CP-10
+
+Implement sufficient redundancy in information processing facilities to meet availability requirements. This includes compute, storage, network, and power redundancy.
+
+**Auditor hints**:
+- For cloud-native startups, this is largely covered by cloud provider SLAs — but auditors want to see you've CHOSEN appropriate service tiers
+- Multi-AZ or multi-region deployment for production is expected for critical systems
+- Database replication configuration should match RTO/RPO requirements
+- Auditors may ask: "What happens if your primary region goes down?" — have an answer
+
+**Evidence collection**:
+```bash
+# GCP: check instance zones/regions
+gcloud compute instances list --format="json(name,zone,status)"
+
+# GCP: Cloud SQL HA configuration
+gcloud sql instances describe {instance} --format="json(settings.availabilityType)"
+
+# Azure: check resource distribution across regions
+az resource list --output json | jq 'group_by(.location) | .[] | {location: .[0].location, count: length}'
+```

package/skills/iso-27001-internal-audit/rules/change-management.md

@@ -0,0 +1,211 @@
+# Change Management Rules
+
+Per-control audit guidance for SDLC, configuration management, and change control.
+
+## A.8.25 — Secure Development Lifecycle
+
+**Tier**: Critical | **NIST**: SA-3, SA-8
+
+Establish rules for secure development of software and systems. Apply security requirements throughout the SDLC — design, development, testing, deployment, and maintenance.
+
+**Auditor hints**:
+- Auditors want to see SDLC DOCUMENTED, not just practiced informally
+- They'll check: threat modeling (even lightweight), secure coding guidelines, pre-deployment security checks
+- For startups: a documented PR review checklist that includes security considerations is sufficient
+- "We do code review" is not enough — show that security is part of the review criteria
+
+**Evidence collection**:
+```bash
+# GitHub: branch protection requires reviews
+gh api repos/{owner}/{repo}/branches/{branch}/protection | jq '{
+  required_pull_request_reviews: .required_pull_request_reviews.required_approving_review_count,
+  enforce_admins: .enforce_admins.enabled,
+  required_status_checks: .required_status_checks.contexts
+}'
+
+# GitHub: recent PRs showing review process
+gh pr list --state merged --limit 10 --json number,title,reviewDecision,mergedAt
+```
+
+---
+
+## A.8.26 — Application Security Requirements
+
+**Tier**: Relevant | **NIST**: SA-3
+
+Define and document security requirements for applications, including authentication, authorization, input validation, and data protection requirements.
+
+**Auditor hints**:
+- Auditors check if security requirements are captured BEFORE development, not added after
+- For web apps: OWASP Top 10 coverage is expected
+- API security requirements should address authentication, rate limiting, and input validation
+- If you use third-party libraries, security requirements should cover dependency management
+
+---
+
+## A.8.27 — Secure System Architecture and Engineering Principles
+
+**Tier**: Checkbox | **NIST**: SA-8
+
+Apply secure engineering principles to system architecture. Design systems with defense in depth, least privilege, and fail-secure defaults.
+
+**Auditor hints**:
+- Auditors look for architecture documentation that shows security considerations
+- Network segmentation (or VPC design) is the most common check
+- Zero trust principles are increasingly expected but not yet required
+- For cloud: show that environments are isolated (dev/staging/prod separation)
+
+---
+
+## A.8.28 — Secure Coding
+
+**Tier**: Relevant | **NIST**: SI-10, SI-11
+
+Apply secure coding practices to minimize vulnerabilities. Address input validation, output encoding, error handling, and cryptographic usage in code.
+
+**Auditor hints**:
+- Auditors may review a recent security-relevant code change to verify practices
+- SAST (static analysis) tool usage is strong evidence — even a free tool like Semgrep or CodeQL
+- Dependency scanning (Dependabot, Snyk) counts as part of secure coding
+- Error messages should not leak internal details (stack traces, SQL queries, file paths)
+
+**Evidence collection**:
+```bash
+# GitHub: code scanning alerts (CodeQL/SAST)
+gh api repos/{owner}/{repo}/code-scanning/alerts --paginate | jq 'length'
+
+# GitHub: Dependabot alerts
+gh api repos/{owner}/{repo}/dependabot/alerts?state=open | jq 'length'
+```
+
+---
+
+## A.8.29 — Security Testing in Development and Acceptance
+
+**Tier**: Checkbox | **NIST**: SA-11
+
+Define and implement security testing processes during development and before production deployment. This includes functional security testing, vulnerability scanning, and penetration testing.
+
+**Auditor hints**:
+- Annual penetration test is expected for SOC 2 and increasingly for ISO
+- For startups: automated security scanning in CI/CD is acceptable evidence between annual pentests
+- Acceptance testing should include security test cases, not just functional tests
+- Bug bounty programs count as continuous security testing
+
+---
+
+## A.8.30 — Outsourced Development
+
+**Tier**: Checkbox | **NIST**: SR-5
+
+When development is outsourced, define and enforce security requirements with the external party. Monitor compliance and ensure secure handover.
+
+**Auditor hints**:
+- If you use contractors for development, auditors check: NDAs, access provisioning/deprovisioning, code ownership
+- Contractor access should be time-limited and revoked at contract end
+- Code review requirements should apply equally to internal and external developers
+
+---
+
+## A.8.31 — Separation of Development, Test, and Production Environments
+
+**Tier**: Checkbox | **NIST**: SA-3
+
+Separate development, testing, and production environments to reduce the risk of unauthorized access or changes to production systems.
+
+**Auditor hints**:
+- Auditors check: can a developer push directly to production? Is prod data used in dev?
+- Environment separation means: different accounts/projects/subscriptions, not just different folders
+- Database access: dev should NOT have production database credentials
+- CI/CD pipeline should be the ONLY path to production
+
+**Evidence collection**:
+```bash
+# GCP: list projects (should show separate dev/staging/prod)
+gcloud projects list --format="json(projectId,name)"
+
+# Azure: list subscriptions
+az account list --output json | jq '.[].{name, id, state}'
+```
+
+---
+
+## A.8.32 — Change Management
+
+**Tier**: Critical | **NIST**: CM-3, SA-10
+
+Manage changes to information processing facilities and systems through a formal change management process. Changes should be requested, assessed, approved, implemented, and reviewed.
+
+**Auditor hints**:
+- Auditors want to see a CHANGE RECORD for every production change — git history is excellent evidence
+- They'll sample 5-10 recent changes and check: was there a request, review, approval, and implementation record?
+- Emergency changes ("hotfixes") must have retroactive review — skipping the process is acceptable if documented
+- Rollback capability should exist — auditors may ask "what happens if this change fails?"
+
+**Evidence collection**:
+```bash
+# GitHub: recent merged PRs (change records)
+gh pr list --state merged --limit 20 --json number,title,author,reviewDecision,mergedAt,mergedBy
+
+# GitHub: branch protection (prevents unreviewed changes)
+gh api repos/{owner}/{repo}/branches/main/protection | jq '{
+  required_reviews: .required_pull_request_reviews.required_approving_review_count,
+  dismiss_stale_reviews: .required_pull_request_reviews.dismiss_stale_reviews
+}'
+
+# GitHub: deployment history
+gh api repos/{owner}/{repo}/deployments --paginate | jq '.[0:10] | .[] | {environment, created_at, sha: .sha[0:8]}'
+```
+
+---
+
+## A.8.33 — Test Information
+
+**Tier**: Checkbox | **NIST**: SA-11
+
+Ensure test data is adequately protected, especially when production data is used for testing. Anonymize or mask production data before use in non-production environments.
+
+**Auditor hints**:
+- If you use production data for testing, it must be masked — this is where many startups fail
+- Synthetic test data is always preferred
+- Test databases should have the same access controls as the environment warrants
+- Automated tests should not contain hardcoded credentials or real PII
+
+---
+
+## A.8.34 — Protection of Information Systems During Audit Testing
+
+**Tier**: Checkbox | **NIST**: CA-2
+
+Protect production systems from disruption during audit testing. Audit activities (vulnerability scans, penetration tests) should be planned and authorized to minimize business impact.
+
+**Auditor hints**:
+- Auditors check that THEIR OWN testing is authorized and scoped — they'll ask you to sign off on the test plan
+- Penetration tests should have written authorization (Rules of Engagement document)
+- Vulnerability scans on production should be scheduled during low-traffic periods
+
+---
+
+## A.8.9 — Configuration Management
+
+**Tier**: Critical | **NIST**: CM-1, CM-2, CM-3, CM-4, CM-6, CM-7, SA-10, SI-7
+
+Define, document, and maintain secure configurations for hardware, software, and network components. Establish baselines and monitor for drift.
+
+**Auditor hints**:
+- Auditors want to see BASELINE CONFIGURATIONS — what is the "known good" state of your systems?
+- For cloud: Infrastructure as Code (Terraform, CloudFormation) IS your configuration baseline
+- Configuration drift detection is increasingly expected — even a weekly diff of IaC vs. deployed state
+- Container images should be built from documented base images with pinned versions
+
+**Evidence collection**:
+```bash
+# Terraform: show current state
+terraform state list | head -20
+
+# GCP: export compute instance configurations
+gcloud compute instances list --format=json | jq '.[] | {name, machineType, status}'
+
+# Docker: list base images
+docker image ls --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"
+```

package/skills/iso-27001-internal-audit/rules/encryption.md

@@ -0,0 +1,93 @@
+# Encryption Rules
+
+Per-control audit guidance for cryptographic controls.
+
+## A.8.24 — Use of Cryptography
+
+**Tier**: Critical | **NIST**: SC-8, SC-12, SC-13, SC-17, SC-28
+
+Define and implement rules for cryptographic controls including key management. Use cryptography to protect data confidentiality, integrity, and authenticity — both in transit and at rest.
+
+**Auditor hints**:
+- Auditors check TWO things: (1) is encryption enabled, (2) is key management documented
+- "Encryption at rest" must cover databases, backups, AND local storage (laptops)
+- "Encryption in transit" means TLS 1.2+ for all external connections — auditors will check with `openssl s_client`
+- Key rotation policy must exist even if rotation is automated — document the cadence
+- Deprecated algorithms are findings: MD5, SHA-1, DES, 3DES, RC4, TLS 1.0/1.1
+
+**Evidence collection**:
+```bash
+# Check TLS configuration on a domain
+openssl s_client -connect example.com:443 -tls1_2 < /dev/null 2>&1 | grep -E "Protocol|Cipher"
+
+# GCP: check encryption at rest (default is Google-managed keys)
+gcloud sql instances describe {instance} --format="json(settings.ipConfiguration,settings.dataDiskEncryptionConfiguration)"
+
+# Azure: check encryption at rest
+az storage account show --name {account} --query "encryption" --output json
+
+# GitHub: check for secrets in repos (Dependabot/secret scanning)
+gh api repos/{owner}/{repo}/secret-scanning/alerts --paginate | jq 'length'
+
+# macOS FileVault status
+fdesetup status
+```
+
+**Startup pitfalls**:
+- Using default cloud encryption (fine) but not documenting the key management approach
+- Storing API keys/secrets in code repositories — use vault/secrets manager
+- No certificate inventory — TLS certs expire and cause outages
+- Assuming HTTPS means all traffic is encrypted — internal service-to-service traffic may not use TLS
+
+---
+
+## A.8.10 — Information Deletion
+
+**Tier**: Relevant | **NIST**: SC-28
+
+Delete information when no longer needed, in accordance with the retention policy. Deletion should be verifiable and cover all copies (backups, replicas, caches).
+
+**Auditor hints**:
+- Auditors check the DATA RETENTION SCHEDULE and verify it's being followed
+- "We keep everything forever" is technically compliant but a GDPR risk if you handle PII
+- Backup retention is often overlooked — if backups contain deleted data, the deletion isn't complete
+- Soft-delete vs. hard-delete: auditors want to know which you use and whether soft-deleted data is eventually purged
+
+---
+
+## A.8.11 — Data Masking
+
+**Tier**: Relevant | **NIST**: SC-28
+
+Use data masking techniques to limit exposure of sensitive data, especially in non-production environments. Masking should maintain data utility while preventing unauthorized access to actual values.
+
+**Auditor hints**:
+- The main question: "Does your staging/dev environment use production data?"
+- If yes, is it masked/anonymized? If no, how do you generate test data?
+- Masking must be irreversible for non-production — tokenization is acceptable if the token store is access-controlled
+- Logs are a common masking gap — sensitive data in debug logs
+
+---
+
+## A.8.12 — Data Leakage Prevention
+
+**Tier**: Relevant | **NIST**: MP-7
+
+Apply measures to prevent unauthorized disclosure of information. Monitor for and block data exfiltration through email, web uploads, USB devices, and other channels.
+
+**Auditor hints**:
+- For startups, DLP usually means: email scanning for attachments with sensitive data, endpoint USB controls, and cloud storage access restrictions
+- Auditors won't expect enterprise DLP software from a startup, but they will ask: "What prevents an employee from emailing the customer database?"
+- GitHub is a DLP vector — check that repos are private by default and secret scanning is enabled
+
+**Evidence collection**:
+```bash
+# GitHub: verify private-by-default repo setting
+gh api orgs/{org} | jq '{default_repository_permission, members_can_create_public_repositories}'
+
+# GitHub: secret scanning alerts
+gh api orgs/{org}/secret-scanning/alerts --paginate | jq 'length'
+
+# macOS: check if USB storage is restricted
+profiles show -type configuration | grep -i "removable"
+```