Library / Knowledge Hub

The playbooks for when the pressure is on.

Checklists and cheat sheets built for the worst hour of someone's week. Most evidence is destroyed in the first sixty minutes by well-meaning people trying to help — these exist so that doesn't happen.

The first hour of an incident

On-call engineers and technical leads

What to do — and specifically what not to do — in the first sixty minutes. Most evidence is destroyed in this window by well-meaning people trying to help.

Stabilise

Start a timestamped log. Every action, who took it, and when. This becomes your legal record.
Do not power off affected machines. Memory contents are often the only evidence of what happened.
Isolate at the network layer rather than the host: pull the VLAN, not the plug.
Nominate one incident lead. Everyone else reports to them and does not act independently.
Move coordination to an out-of-band channel. Assume the corporate one is being read.

Preserve

Capture volatile memory before disk imaging on any host you plan to investigate.
Snapshot cloud instances rather than terminating them; export the relevant audit logs immediately.
Extend log retention now — default windows will expire mid-investigation and you cannot get them back.
Preserve authentication logs, EDR telemetry and mail gateway logs as a priority. They answer 'how did they get in'.
Record hashes for anything you copy, so chain of custody survives scrutiny later.

Assess

Establish the earliest confirmed evidence of compromise, then look earlier still.
Identify which credentials and keys were reachable from the compromised systems.
Determine whether personal data was in scope — this starts your regulatory clock.
Check whether backups are intact and, critically, whether they are reachable from the compromised network.
Do not begin remediation until scope is understood. Partial eviction teaches an attacker to hide better.

Communicate

Brief leadership with facts and explicit unknowns. Resist pressure to estimate impact early.
Engage legal counsel before external communication, and confirm notification deadlines under GDPR or local law.
Notify your cyber insurer — many policies require it within a fixed window or coverage lapses.
Prepare holding statements for customers before anyone asks, not after.

Preparing for a penetration test

Engineering leads commissioning an assessment

Preparation determines how much value you get. Teams that do this get findings that matter; teams that do not pay for a list of missing headers.

Before scoping

Decide what a successful engagement would tell you. 'Find vulnerabilities' is not an objective.
Inventory what is actually in scope, including the APIs and third-party integrations you forgot about.
Identify your crown jewels: the data or capability whose compromise would genuinely hurt.
Check contractual constraints with cloud providers and SaaS vendors before agreeing scope.

Before testing starts

Provision test accounts at every privilege level, and verify they work before day one.
Whitelist the tester's traffic identifier in your WAF, or accept that you are testing the WAF instead.
Tell your SOC. Either they know and you test the application, or they do not and you test detection — decide deliberately.
Agree an escalation path with names and phone numbers for critical findings.
Snapshot and confirm the restorability of any environment being tested.

During

Read the daily updates. Questions raised on day two are cheaper than surprises in the report.
Do not fix findings silently mid-test without telling the tester — it invalidates their retest baseline.
Escalate anything that looks like a real incident rather than test traffic, immediately.

After

Triage findings against your own risk context, not just the CVSS number.
Fix the root cause rather than the instance. One IDOR usually means the authorization pattern is wrong everywhere.
Book the retest while the context is fresh.
Feed the findings into your engineering backlog with owners and dates, or nothing will change.

Secure defaults for a new product

Founding engineers and first security hires

What to get right before you have a security team. Ordered by return on effort — the top five prevent most of what we find in early-stage assessments.

Identity

Enforce MFA on every administrative interface, including your cloud provider and DNS registrar.
Use SSO for internal tooling from the start. Retrofitting it later is painful and expensive.
Deny by default in authorization. Every endpoint should require an explicit permission check.
Enforce tenant scoping in shared middleware, not per handler — new endpoints must inherit it.

Secrets

No secrets in source control, ever. Add scanning to pre-commit hooks and CI on day one.
Use a secret manager. Environment variables in a dashboard are not a secret manager.
Give every environment its own credentials. Shared staging and production keys defeat the separation.
Rotate on personnel change, and make sure you know how long rotation takes before you need it.

Infrastructure

Private by default. Databases and internal services should not have public endpoints.
Separate accounts or projects per environment, with no trust relationship between them.
Enable audit logging everywhere and ship it somewhere the production account cannot delete.
Least-privilege CI/CD roles scoped by OIDC rather than long-lived access keys.

Application

Parameterised queries only. No string-built SQL anywhere in the codebase.
Validate on the server. Client-side validation is a user experience feature, not a control.
Set a Content-Security-Policy early — it is far harder to retrofit onto a mature front end.
Rate-limit authentication, password reset and any endpoint that costs you money to serve.
Keep dependencies current with automated updates and a human reviewing the diff.

Triaging an inbound vulnerability report

Security contacts and product owners

Someone has emailed you claiming a vulnerability. How you respond in the first 48 hours determines whether this becomes a coordinated fix or a public disclosure.

Acknowledge

Reply within one working day, even if only to confirm receipt. Silence is what pushes researchers to publish.
Thank them genuinely. They chose to tell you rather than sell it.
Never threaten legal action against a good-faith reporter. It ends well for no one and guarantees escalation.
Ask clarifying questions rather than demanding a full proof of concept up front.

Verify

Reproduce in a controlled environment before assessing severity.
Check your logs for prior exploitation of the same issue — if it was found once, assume it may have been found before.
Assess real impact in your context, not the generic CVSS score.
Look for the same pattern elsewhere in the codebase. Reports are samples, not inventories.

Resolve

Give the reporter a realistic timeline and then keep them updated against it.
Fix the class of issue, not only the reported instance.
Agree disclosure timing openly. 90 days is the widely accepted norm.
Credit the reporter publicly if they want it. It costs nothing and buys enormous goodwill.

Cheat sheets

Severity, in practice

How we score findings. The number is a starting point; the business context adjusts it.

Critical: Unauthenticated access to sensitive data, remote code execution, or full authentication bypass. Escalated the moment it is confirmed, not saved for the report.
High: Authenticated escalation across tenants or roles, or a chain that reliably reaches sensitive data. Fix inside the current sprint.
Medium: Requires a precondition or user interaction, or exposes information useful to an attacker. Schedule within the quarter.
Low: Defence-in-depth weakness with no direct path to impact. Batch these with other work.
Informational: Hardening opportunities and observations. Useful context; not a vulnerability.

Common ports worth knowing cold

The services you will meet on nearly every internal engagement.

21 / 22 / 23: FTP (cleartext) · SSH · Telnet (disable it)
25 / 587 / 465: SMTP relay · submission · implicit TLS
53: DNS — check zone transfer and dangling records
80 / 443: HTTP · HTTPS
88 / 389 / 636: Kerberos · LDAP · LDAPS
445: SMB — signing, SMBv1, relay exposure
1433 / 3306 / 5432: MSSQL · MySQL · PostgreSQL
3389: RDP — never expose it directly
5985 / 5986: WinRM HTTP · HTTPS
6379 / 27017 / 9200: Redis · MongoDB · Elasticsearch — frequently unauthenticated

Regulatory clocks

Deadlines that start the moment you become aware of a breach. ⚠️ Confirm against current counsel — this is orientation, not legal advice.

GDPR (EU/EEA): 72 hours to notify the supervisory authority from becoming aware; affected individuals without undue delay where risk is high.
Israel Privacy Protection Regulations: Severe security incidents must be reported to the Privacy Protection Authority immediately upon discovery.
NIS2 (EU): Early warning within 24 hours, incident notification within 72 hours, final report within one month, for in-scope entities.
PCI DSS: Notify your acquirer and the card brands immediately on suspected cardholder data compromise.
Cyber insurance: Policy-specific, often 24–72 hours. Check yours before you need it, not during.