Security Quick Reference | Maelstrom AI Trust Centre

Purpose

Quick reference guide for common security tasks, contacts, and procedures. Bookmark this page for easy access.

Emergency Contacts

Security Incidents: security@maelstrom.au ISMS Owner: [Current holder of role] Security Lead: [Current holder of role]

If you suspect a security issue, report it immediately. No blame for good-faith reports.

Daily Security Checklist

Every Day

✅ Lock screen when away from computer (automatic after 5 minutes)
✅ Check for security notifications (GitHub, Signal)
✅ Update dependencies if Dependabot alerts appear
✅ Use MFA for all logins (GitHub, Cloudflare, etc.)

When Writing Code

✅ Never commit secrets (keys, tokens, passwords)
✅ Run security scans locally before pushing (cargo audit, npm audit)
✅ Request code review for all changes
✅ Use approved cryptographic libraries only

When Reviewing Code

✅ Check for hardcoded secrets
✅ Verify cryptographic operations use approved algorithms
✅ Confirm tests cover security-relevant logic
✅ Review dependency changes for known vulnerabilities

Common Tasks

Responding to Dependabot Alert

Read the alert: Understand the vulnerability (CVE, severity, affected versions)
Check if we’re affected: Are we using the vulnerable function?
Update dependency: cargo update [package] or npm update [package]
Test: Ensure nothing breaks
Commit and push: Security fix goes out immediately
Document: If significant, add to incident log

Timeframe: Critical vulnerabilities patched within 24 hours

Onboarding New Team Member

Within first day:

Provision GitHub access (add to organisation, appropriate teams)
Provision Cloudflare access (if needed for role)
Share ISMS documentation (start with Security Overview)
Ensure password manager setup
Verify MFA enabled on all accounts

Within first week: 6. Complete Security Awareness Training 7. Acknowledge Acceptable Use Policy 8. Review Roles & Responsibilities

Documentation: Add to team roster, update access control records

Offboarding Departing Team Member

Immediately upon departure:

Revoke GitHub access (remove from organisation)
Revoke Cloudflare access (remove from account)
Remove from communication channels (Signal, email lists)
Rotate any shared secrets they had access to (API tokens, HMAC keys)
Update Asset Register (ownership changes)

Within 3 days: 6. Conduct exit interview (security feedback) 7. Document in access review log 8. Update Roles & Responsibilities if role vacant

Rotating Signing Keys

Frequency: Annually (or immediately on compromise)

Process:

Generate new RedJubjub keypair (offline, secure environment)
Store new private key in Cloudflare KV (IS_KEYS)
Publish new public key to JWKS (CDN)
Mark old key status as Deprecated in KV storage
Notify relying parties (30-day grace period)
After grace period, remove old key from KV
Destroy old key backups (cryptographic erasure)
Document in audit log

Authority: Cryptography Specialist (approved by ISMS Owner)

Responding to Security Incident

Phase 1: Detect and Report (Immediate)

Notice something suspicious? Report to security@maelstrom.au
Provide: What, when, where, who, evidence (screenshots, logs)

Phase 2: Assess (Within 1 hour for high severity)

Security Lead determines severity (P0-P3)
Activates incident response team if needed

Phase 3: Contain (Varies by incident)

Stop the bleeding (revoke access, kill malicious process, etc.)
Preserve evidence (log files, screenshots)

Phase 4: Eradicate (After containment)

Remove root cause (patch vulnerability, rotate keys, etc.)

Phase 5: Recover (After eradication)

Restore normal operations
Monitor for recurrence

Phase 6: Learn (Within 1 week)

Postmortem: What happened, why, how to prevent
Update runbooks, policies, controls
Share lessons learned (blameless)

Full details: Incident Response

Approved Tools and Services

Password Management

Approved: 1Password, Bitwarden, or similar reputable password manager Required: All credentials stored in password manager (not browser, not notebook) MFA seeds: Store in password manager or separate authenticator app

Development Tools

IDE: Any (VS Code, IntelliJ, Vim, etc.) Git: GitHub Desktop, CLI, or IDE integration Browser: Chrome, Firefox, Safari (keep updated)

Communication

Work: Signal, email Security reporting: security@maelstrom.au (monitored)

Cloud Services

Approved:

Cloudflare (Workers, KV, Pages, Analytics)
GitHub (code, CI/CD, packages)
Google Workspace (docs, email - if applicable)

Prohibited without approval:

Unapproved cloud storage (Dropbox, OneDrive for work files)
Unapproved AI coding assistants (ensure code not sent to third parties)

Information Classification

Restricted (Highest Protection)

Examples: Signing keys, HMAC secrets, API tokens Handling:

Store in Cloudflare KV or password manager (encrypted)
Never in source code, logs, or email
Access limited to Security Lead and ISMS Owner
Rotate annually or on compromise

Confidential

Examples: Audit logs, incident reports, supplier contracts Handling:

Shared only with authorised team members
Stored in secure location (encrypted cloud storage)
Not posted publicly

Internal

Examples: Internal communications, meeting notes, draft documentation Handling:

For team members only
Not shared publicly
Exercise judgment

Public

Examples: ISMS documentation, source code, API documentation Handling:

Published on GitHub, maelstrom.au/trust
Anyone can view
Maintain accuracy and professionalism

Full details: Asset Management

Security Scanning Commands

Rust (provii-crypto, provii-mobile-sdk)

# Dependency vulnerability scan
cargo audit

# Linting and security checks
cargo clippy -- -D warnings

# Fuzzing (for crypto code)
cargo +nightly fuzz run [target]

# Run all tests
cargo test

TypeScript (provii-agegate)

# Dependency vulnerability scan
npm audit

# Fix automatically if possible
npm audit fix

# Linting
npm run lint

# Run tests
npm test

CI/CD

All security scans run automatically on every PR:

CodeQL (static analysis)
cargo audit / npm audit
SLSA provenance generation
Sigstore signing

Don’t merge if security scans fail.

Access Control Summary

GitHub

MFA. Required for all users
Role. Team members have write access; ISMS Owner has admin
Branch protection. Main branches require code review, passing CI

Cloudflare

MFA. Required for all users
Role. Security Lead and ISMS Owner have access; others as needed
Tokens. Scoped minimally, stored in GitHub Secrets or password manager

Access Review

Frequency. Quarterly
Process. Security Lead reviews all access lists
Action. Revoke unnecessary access, update documentation

Full details: Access Control Policy

Cryptographic Do’s and Don’ts

✅ DO

Use approved algorithms: Groth16, BLS12-381, RedJubjub, BLAKE2, SHA-256, HMAC-SHA256
Use established libraries: bellman, redjubjub, bls12_381
Generate keys with cryptographically secure RNG (OsRng in Rust)
Test cryptographic code (unit tests, known-answer tests, fuzzing)
Consult Cryptography Specialist before implementing crypto

❌ DON’T

Implement cryptography from scratch
Use weak algorithms: MD5, SHA-1 (exception: HMAC-SHA1 for YubiKey officer auth only), single DES
Use weak RNGs: Math.random(), rand::random() without crypto-secure source
Disable crypto for debugging
Skip testing or review of crypto code
Store keys in plaintext

Full details: Cryptography Policy

Change Management Tiers

Standard Changes (Automated)

What: Pre-approved, low-risk changes (dependency updates, documentation, tests) Process: PR -> CI passes -> Merge -> Auto-deploy Approval: Code review sufficient

Normal Changes (Review Required)

What: Feature changes, configuration updates, API changes Process: PR -> Code review -> CI passes -> Manual approval -> Merge -> Deploy Approval: Security Lead or ISMS Owner for security-relevant changes

Emergency Changes (Break Glass)

What: Critical security patches, production outages Process: Implement immediately -> Notify team -> Document post-hoc Approval: ISMS Owner (or on-call if unavailable) Post-implementation: Review in next retrospective

Full details: Change Management

Incident Severity Levels

Severity	Description	Response Time	Example
P0 - Critical	Signing key compromise, data breach	Immediate (24/7)	Production signing key leaked
P1 - High	Service outage, active attack	1 hour (business hours)	DDoS attack ongoing
P2 - Medium	Degraded service, vulnerability	24 hours	Known vulnerability in dependency
P3 - Low	Minor issue, no immediate impact	1 week	Policy documentation out of date