I bridged them on purpose
I'm assessing my own computing environment against CIS Controls v8.1, Implementation Group 1. Three sessions in, I haven't filled a single safeguard row.
That bothered me for about a day. Then I looked at what the three sessions actually produced and stopped being bothered.
The plan was simple. IG1 is 56 safeguards, written for small environments with limited staff and commercial tooling, which describes my setup honestly. I narrowed to 18 of them across Controls 3, 4, 5, 6 and 8, because 56 at four per session is 15 minutes each and 15 minutes produces a status column. A status column is the part anyone can generate.
One safeguard per session, 45 minutes, ends in a committed row. That was the unit of work.
Session 1 was supposed to be the easy one. Write the scope, draw the boundary, commit it, go to bed.
Seven assets, not three
I went in thinking I had three things to assess: the VirtualBox lab, the publish pipeline that runs this site, and the workstation I'm typing on.
I came out with seven. The registrar went in, because whoever controls DNS controls the site regardless of what's on the server. The MacBook I've been running as a server went in. The Obsidian vault went in, because it holds personal and family data and pretending otherwise would be convenient.
And the LAN went in, which is the one I want to talk about.
I also wrote down four exclusions with reasons: the work laptop, my daughter's school Chromebook, the dead Hetzner VPS, and Proton services as components. The reasons are the part worth writing, because that's where someone can argue with you.
Then I inventoried the LAN. 14 devices, plus 4 lab guests.
Deliberate, and never reassessed
Here's what I'd written the night before, in my own setup notes, describing the first asset:
1. VirtualBox lab — Kali attacker against Metasploitable 2, Windows 7, Windows 10,
on an isolated host-only network.Every one of those guests was bridged to my LAN.
Metasploitable 2 is a Linux image built to be broken into. It exists to be vulnerable. It ships with accounts you can guess and services nobody should run, and that's the point of it, because I use it as a target for Kali.
Bridged means the VM gets an address from my router and sits on my network like any other device, next to the laptops and the TV and whatever my kids are on. Host-only means it can talk to my workstation and nothing else.
So session 2's opening question was: was that bridge deliberate or default? That's what I'd ask someone else about a firewall rule. A considered risk decision and an unexamined default look identical in a config file, they get written up differently, and one of them means you knew.
It was deliberate. I bridged those adapters because the instructor of the ethical hacking course I was working through said to, so that Kali could reach the targets without my fighting the network layer first. That was the right call for the thing he was teaching. I was learning to attack a box, and the fastest way to learn that is to have the box answer you.
What nobody in that lesson was assessing was my house.
The decision was made to serve a course objective and it kept running after the course ended, on a LAN with my kids' devices on it. I built 4 machines that answer to known exploits, gave them addresses on my home network, and left them there. If someone got onto that network, the easiest targets on it would be the ones I installed on purpose and then stopped thinking about.
The finding I wrote up is that a deliberate decision outlived the reason for it, and went unreassessed the whole time. My own notes had drifted to describing the safer version while the running one stayed put.
I moved all 4 guests to host-only. Kali still reaches them, and now nothing else does.
The device I can't inspect
Sitting under all of this is my T-Mobile Home Internet gateway, and it's the finding I like least, because I can't do anything about it.
I can't inspect it, I can't configure it the way I'd configure a router I bought, and I can't produce evidence about its state. T-Mobile routes everything through their app. It's an unmanaged device carrying my whole network, and no amount of assessment methodology makes that go away.
I should say why I'm on it anyway. My cable provider took my bill from $55 to $95 a month, and T-Mobile Home Internet was the affordable answer at a point when affordable mattered. I'm also getting what I paid for, in both directions: the gateway hands me almost nothing to configure, and video calls are the first thing to degrade when the cell site is busy. I knew about the first half going in and learned the second half by living on it. At that price difference I'd make the same call again, and it goes in the accepted-risk register with the numbers written next to it, so anyone reading the assessment can argue with the trade rather than guess at it.
What I could do was check the compensating control. If the gateway is unmanaged, the thing I want to know is whether there's an inbound path from the internet to anything behind it.
I couldn't get a WAN address out of the gateway. So I went at it from the workstation instead:
$ tracepath -n 1.1.1.1
1?: [LOCALHOST] pmtu 1500
1: 192.168.12.1 3.407ms
1: 192.168.12.1 0.824ms
2: 192.0.0.1 1.828ms
3: 192.0.0.1 1.042ms pmtu 1480
3: no reply
4: no reply
5: no reply
^CIt went no reply from hop 3 onward until I killed it, which is the carrier declining to talk to me. Hop 2 came back 192.0.0.1. That address is the Dual-Stack Lite block, which means my connection sits behind carrier-grade NAT. I share a public address with other customers, and there is no address anyone outside could aim a packet at to reach my network. Inbound is closed by the carrier's architecture, and UPnP on the gateway is moot because there's nothing for it to forward from.
Networking is my weak spot and this closed a piece of it. I learned that private addresses like 192.168.x.x aren't routable on the internet, which I could have told you as a fact before and could not have used as an argument. It took me 3 tries to say it correctly. I'll remember 192.0.0.1 longer than anything a cert module would have taught me on the same topic.
The gateway finding didn't change. I still run a device I can't inspect, configure, or evidence, and that goes in the write-up as is. What changed is that the control underneath it is confirmed instead of assumed, and I can say how I confirmed it when the obvious method was unavailable.
Confirmed instead of assumed is most of the job, and the bridge was the same job from the other end. One decision I'd made and never revisited, one condition I'd never verified, both sitting there for months looking settled.
Three sessions, no rows
Sessions 1 and 3 were the two that landed. Session 2 happened between them, and session 3 got attempted on a Thursday night, abandoned because I couldn't follow my own thread, and restarted from scratch the next morning with the project folder attached from the beginning. The restart is what produced the tracepath.
Zero safeguard rows filled. Session 4 is the account inventory safeguard, and the first job is checking its ID and title against the official v8.1 workbook, which no session has opened yet. I've been working from a summary, and the version matters: v8.1 published in August 2024 and most of my own notes still say v8.
The rows are the deliverable. They're also the part that's easy once the boundary is honest, and the boundary took 3 sessions because the two things I was surest about were the two that needed checking: a lab I'd put on my LAN on purpose, and a gateway I'd never looked behind.
If you want to do this to your own setup, start by opening the config for one thing you're already sure about.