Home / The Lab

The Lab

Try the ideas behind the work.

Six small experiments in segmentation, firewall rules, monitoring, evidence, recovery, and uptime. About a minute each.

Everything runs in your browser. Nothing you type or pick here is sent to us.

01 / Separate / Blast Radius

How far can one device reach?

Pick a device and watch where it can get to. Then switch the network to zones and pick again.

Experiment 01Illustration

Pick any device to start.

Illustration: twelve devices on one flat network, or in six zonesOn a flat network every device reaches all eleven others through one switch. With zones, guest devices reach nothing, business systems reach each other, payments stay in their own zone, cameras and readers reach only each other, vendor equipment stays in its zone, and the admin PC reaches the recorder and building controls by an approved route, and through them five devices in all.GUEST WI-FIBUSINESSPAYMENTSCAMERAS AND DOORSADMINVENDOR-RUNSWITCHFIREWALLGuest phoneGuest laptopStaff PCFile serverCard terminalPayment serverCameraRecorderBadge readerAdmin PCBuilding controlsKioskIllustration: twelve devices on one flat network, or in six zonesOn a flat network every device reaches all eleven others through one switch. With zones, guest devices reach nothing, business systems reach each other, payments stay in their own zone, cameras and readers reach only each other, vendor equipment stays in its zone, and the admin PC reaches the recorder and building controls by an approved route, and through them five devices in all.GUEST WI-FIBUSINESSPAYMENTSCAMERAS AND DOORSADMINVENDOR-RUNGuest phoneGuest laptopStaff PCFile serverCard terminalPayment serverCameraRecorderBadge readerAdmin PCBuilding controlsKiosk

On a flat network, any device reaches all 11 others. With zones, a guest phone reaches none of them, and the admin PC, the best-connected device, reaches five.

Where this shows up in our work: Network and Physical Security

02 / Control / Rule Order

Can you fix this firewall?

Two of the six test packets do the wrong thing. Reorder the rules until all six behave.

Experiment 02Illustration

Firewall rules read top to bottom

  1. 1AllowWeb from Any to AnyA
  2. 2DenyManagement from Any to CamerasD
  3. 3AllowManagement from Admin PC to CamerasB
  4. 4DenyAny service from Guest Wi-Fi to InternalC

DenyAnything no rule above matches

Test packets what should happen

  • Guest phone opens a websiteGuest Wi-Fi to Internet, webShould be allowedAllowed by rule 1Correct.
  • Guest phone opens the recorder sign-in pageGuest Wi-Fi to Cameras, webShould be blockedAllowed by rule 1Wrong.
  • Admin PC manages the recordersAdmin PC to Cameras, managementShould be allowedBlocked by rule 2Wrong.
  • Staff PC tries to manage the recordersStaff PCs to Cameras, managementShould be blockedBlocked by rule 2Correct.
  • A camera calls out for remote accessCameras to Internet, remote accessShould be blockedBlocked by defaultCorrect.
  • Staff PC opens a websiteStaff PCs to Internet, webShould be allowedAllowed by rule 1Correct.
4 of 6 behave as they should

The firewall reads top to bottom and stops at the first rule that matches. Anything no rule matches is denied.

Show the fix

Move rule C (deny guest traffic to internal systems) above rule A, which allows web traffic from anywhere. Move rule B (allow the admin PC to manage cameras) above rule D, which denies camera management to everyone. Specific rules go above the broad ones they would otherwise lose to.

Where this shows up in our work: Security Assessments

03 / Watch / Signal or Noise

Which alerts matter?

Seven events from an ordinary day. Make the call on each one.

Experiment 03Synthetic events
  • Normal Expected. Note it and move on.
  • Look closer Odd but not urgent. Check before deciding.
  • Escalate Needs a decision now from the people named for it.
  1. Event 1 of 702:10Backup serverNightly jobFinished

    The nightly backup finished at 02:10, the same as every night.

    Our call

    Normal. Expected job, expected time, expected result. Nothing to do.

  2. Event 2 of 707:41Staff account5 failed sign-ins, then successNew location

    Five failed sign-ins on a staff account, then a success from a place this account has never signed in from.

    Our call

    Escalate. Failures followed by a success from somewhere new is a common sign of a guessed or stolen password. Someone should decide now whether to lock the account.

  3. Event 3 of 711:05Guest Wi-Fi device40 camera addresses triedAll blocked

    A guest Wi-Fi device tried 40 camera addresses in a minute. The boundary blocked every attempt.

    Our call

    Look closer. The boundary did its job. It is still worth finding the device and checking that it tried nothing else.

  4. Event 4 of 704:00Point-of-sale serverRestartPatch window

    The point-of-sale server restarted at 04:00, inside its approved patch window.

    Our call

    Normal. A planned restart in a planned window. Confirm it came back, then move on.

  5. Event 5 of 713:22File server3,000 files renamedSame new extension

    On the file server, 3,000 files were renamed with the same new extension within a few minutes.

    Our call

    Escalate. Mass renames at machine speed are what file encryption by an attacker often looks like. This one cannot wait for a full investigation.

  6. Event 6 of 703:12Vendor accountSign-inOutside schedule

    A vendor account signed in at 03:12. That vendor's access is scheduled for Tuesdays, 9 to 11.

    Our call

    Look closer. Not routine, and not yet proof of a problem. Ask the vendor first; escalate if they cannot account for it.

  7. Event 7 of 709:30Business networkNew deviceSmart TV

    A smart TV appeared on the business network this morning.

    Our call

    Look closer. Probably harmless, but it does not belong there. Find its owner and move it to the guest zone.

Where this shows up in our work: Managed Detection and Response

04 / Record / Tamper Test

Can you change a record without a trace?

Edit the drawer log, then try to cover your tracks.

Experiment 04Synthetic records
SampleSynthetic records. A generic hash chain, not a product screen.
Example Resort (fictional)Cash drawer log
TimeWhoEntryAmountFingerprintSeal
08:00SupervisorDrawer opened495c 4474 aa67Matches
10:14Cashier 2Paid out554c c920 ad35Matches
12:30Cashier 2Received8989 b20c c813Matches
15:45SupervisorCount checked54a5 ac87 7412Matches
16:00Shift leadDrawer closedcb6a b733 b1dcMatches
Copied to the shift report at closecb6a b733 b1dcMatches

Each row's fingerprint is a SHA-256 hash of the row and the fingerprint before it. When a row is written, its fingerprint is recorded as its seal.

Change any amount. Try 150.00 to 15.00.

Change one amount and that row no longer matches its seal, and neither does any row after it. Rewrite every seal to cover the change, and the last fingerprint still differs from the copy on the shift report.

Where this shows up in our work: Compliance and Governance

05 / Recover / Recovery Drill

Which bad days would you survive?

Choose your backups, then pick a bad day, or roll the dice.

Experiment 05Illustration

Your backups

How often

Pick a bad day

Choose a bad day to see what survives.

  • Live dataRunning
  • Snapshot on the server
  • Backup in the same building
  • Copy at another site

What survives each bad day
CopyDeleted folderFailed disksEncrypted by an attackerBuilding lost
Snapshot on the serverSurvivesHas the folderLostOn the failed disksLostDeleted by the attackerLostGone with the building
Backup in the same buildingSurvivesHas the folderSurvivesSeparate deviceLostReachable, so encryptedLostGone with the building
Copy at another siteSurvivesHas the folderSurvivesSomewhere elseAt riskReachable with stolen admin accessSurvivesSomewhere else
Locked copy at another siteSurvivesHas the folderSurvivesSomewhere elseSurvivesLocked: cannot be changedSurvivesSomewhere else

Where this shows up in our work: Incident Response and Recovery

06 / Keep running / Downtime Math

What does 99.9 percent really mean?

Set how reliable each part is, pair the weak ones, and watch the year fill in.

Experiment 06Illustration

Everything one service needs in a row

  1. Internet link
  2. Firewall
  3. Switch
  4. Server
  5. Storage
  6. Power

All together

One square per day of the year. Red marks failures; amber, planned work.

Downtime each level allows
AvailableDown per yearDown per month
99%3.7 days7.3 hours
99.9%8.8 hours44 minutes
99.99%53 minutes4 minutes
99.999%5 minutesless than a minute

The math assumes parts fail independently. Real pairs often share power, software, or the person changing them.

Six parts in a row at 99.9% each are up 99.4% together: about 2.2 days down a year. A pair of any part, failing independently, is down only when both are.

Where this shows up in our work: Managed IT and Help Desk

Each experiment is simplified to teach one idea. Devices, people, and events are invented; real networks, logs, and recovery plans have more moving parts.

Questions about your own setup?

Tell us what you run, and what you would like to know.

Confidential briefing. One reply from a senior engineer. No drip campaigns.