Melbourne · Open to SOC & junior security roles

Richard Fisher

Security analyst in training.

I build investigation tools that make incident handovers clearer, backed by a software and automation background.

  • ISC2 CC
  • Google Cybersecurity
  • B. IT, Torrens University
  • M. Cyber Security & AI, Griffith (current)
Identity alert · Impossible travelHigh

The alert says

j.tan signed in from Jakarta, nine minutes after Melbourne.

“Jakarta” = geo-IP of 198.51.100.18 · signin.log #214

Provenance

Where did “Jakarta” come from?

  1. 01:57:12signinj.tan203.0.113.24HBR-LT-042
  2. 02:05:58vpn-upj.tan198.51.100.18HBR-LT-042
  3. 02:06:03signinj.tan198.51.100.18HBR-LT-042
  4. 02:06:40signinm.ross203.0.113.61HBR-LT-017

198.51.100.18 → geo-IP → “Jakarta”
The city is a lookup result. The log never recorded a location.

Process

How was each fact produced?

  • Extracted

    Source IP 198.51.100.18, user j.tan, 02:06 UTC

    signin.log #214
  • Verified

    198.51.100.18 is the company’s approved VPN exit

    network register · VPN-EXIT-03
  • Inferred

    VPN routing likely explains the location change

    #213 tunnel up 5 s before · not proof of identity
  • Decided

    Keep open for identity and session checks.

    analyst decision · evidence still incomplete

Utility

What matters, and what happens next?

What matters
The VPN explains the location change. Identity still needs checking.
Next action
Check MFA, device and session activity before closing.
Owner
SOC analyst
Status
Open · validation pending

Synthetic training data. IPs are from documentation ranges.

Open the tool. Follow the reasoning. Explore the code.

01.2

Security / Written analysis

Analyst casebook

Four worked synthetic investigations, each separating the evidence, the decision, and the reasoning the next analyst needs.

Read the casebook ↗
01.3

Backend security / Open source

CarStockApi

A multi-tenant stock API I built in C#. Tenant identity comes only from the signed JWT, every query is scoped to it, and cross-tenant requests return 404 so records can’t be probed.

ASP.NET Core · FastEndpoints · Dapper · SQLite · JWT · BCrypt

Explore the code & setup ↗

Structura

A provenance-first hardware reference. Products, components and standards, with every assertion tied to a source and known gaps left visible.

Python · SQL · Three.js

Explore Structura ↗

LocalCanon

A regional cultural archive for Bandung and Kanazawa, with sourced introductions, credited photography, and clearly marked research gaps.

JavaScript · Vite · Supabase · Node test runner

Explore LocalCanon ↗Source ↗

Make the next
handover clearer.

A reusable analyst template for separating facts, assumptions, unknowns, and the next action. Use it alongside a synthetic Lighthouse case.

Download the template ↓

Plain text · Free download · No signup

  1. Situation and affected asset
  2. Timeline and evidence
  3. Assumptions and unknowns
  4. Actions taken
  5. Next action and owner
Put it into practice in Lighthouse ↗

Trace the claim. Check the evidence. Say what happens next.

I’m a Melbourne-based IT graduate (Bachelor of IT, Torrens University) moving into security operations. I’ve just begun a Master of Cyber Security and Artificial Intelligence at Griffith University.

I hold ISC2 Certified in Cybersecurity and the Google Cybersecurity Certificate, and I’m working toward CompTIA Security+.

My approach comes down to three things. Provenance: trace every claim back to its source. Process: keep what I extracted, verified, inferred and decided clearly separate. Utility: finish with what matters and what someone should do next.

Working with: Linux · Wireshark · Python · SQL · C# / .NET · TypeScript · React · Git · GitHub Actions

Explore my work on GitHub ↗
Screen-printed hands connecting a network cable to a compact patch panel

Good systems depend on clear handovers.

Lighthouse turns that principle into practice: establish what the evidence supports, record what remains unknown, and leave the next analyst a clear starting point.

See the approach in Lighthouse →