ISIby WebGen

Something has happened. Write it down properly.

ISI records an information security incident the way an insurer, an auditor or a regulator will later want to read it. You describe what you know, attach the logs and screenshots, and answer the questions that actually matter for how you were got at. Then the dossier is interrogated for gaps and contradictions before a report is built: what was found, which control measures it implicates, and what to do first.

Create a free account Free to sign up and read the worked example. One payment per incident you raise.
2 Oct 5 Oct 8 Oct 14 Oct 21 Oct corrected withdrawn as at 9 Oct, 14:00 stands superseded retracted dimmed = not yet recorded on the 9th

See it finished before you pay for anything

A full worked example, free with an account

A real-shaped incident — a mail server compromise — carried all the way through: the dossier, the questionnaire, the analysis that told the operator their own evidence contradicted them, and the finished report with 4 findings, the control measures each one implicates and an ordered list of what to do. Every account can read it. Nobody can edit it.

Create a free account Read the example report (PDF)

No card needed to sign up, or to read the example. You pay only when you ask for an analysis of an incident of your own.

  1. Open the incident

    Three dates, not one: when it happened, when you noticed, when it was contained. Collapsing them is how a report ends up claiming a breach lasted an hour.

  2. Build the dossier

    Logs, screenshots, version banners, statements. Evidence can be corrected or withdrawn later without losing what was believed at the time.

  3. Answer the questions

    A common set, then the branch for your avenue of attack. Credential reuse and a software vulnerability are not the same investigation.

  4. Get challenged, then reported

    The analysis names what is missing and where your own evidence disagrees with you — before the report goes to anybody who matters.

Reports adapt to avenues of attack

Credential reuse
Unpatched software
Email lure
Exposed service
Lost device
Supplier or third party

The questions branch on how you were actually got at. Credential reuse and an unpatched service are not the same investigation, and they are not the same report.

“we were running the vulnerable build” your build post-dates the fix fix published 12 Mar your own log 19 Mar

It argues back

The commonest error in these write-ups is a product believed vulnerable that was already patched. If the build number in your own log post-dates the fix, you get told so, with the evidence named and what would settle it.

mail-auth.log · 02:14 screenshot · version banner statement · supplier was breached statement · corrected, our own key ssh-auth.log · 03:02 +1 row. Nothing removed, ever.

Nothing is overwritten

Evidence is append-only. A correction adds a row; a withdrawal adds a retraction. So the report you sent on the 9th can be reproduced exactly as it stood on the 9th, months later, including the things you have since ruled out.

finding control measure control measure patch the build monitor logins revoke the token alert the owner removes it only reduces the damage

Controls, not vibes

Each finding names the control measure it implicates, in plain language that maps onto whatever framework you run, with an ordered remediation path marking which actions actually remove the vulnerability and which only reduce the damage.

PER INCIDENT

$149 AUD, once
  • One incident, for as long as it stays open
  • Unlimited evidence and attachments
  • 10 analysis runs as the dossier changes
  • The report, reproducible as at any date
Start with a free account

No subscription. If you would rather we ran the investigation for you, WebGen does that too.