Vulnerability Management Analyst

Needs one other person who is not technical, and a real problem they actually have. That is the only requirement, and it is the hard part.

1. 1

   Find a real complaint

   Ask a family member, housemate or friend what annoys them about their computer or phone. Do not accept a technical description — you want the raw version. "It's slow." "The printer never works." "It keeps logging me out." That vagueness is the actual starting condition of the job.

2. 2

   Resist fixing it for ten minutes

   This is the discipline the whole trial is built around. Ask questions instead. When did it start? What changed around then? Does it happen every time, or sometimes? Show me. Watch them do it — you will almost always see something they did not mention, because they did not know it mattered.

3. 3

   Reproduce it yourself

   Make the problem happen on demand, with your own hands. If you cannot reproduce it, you cannot know you have fixed it — you can only know it has stopped happening for now, which is not the same thing and will come back.

4. 4

   Halve the problem, repeatedly

   Is it that app or all apps? That network or all networks? That account or all accounts? Each answer eliminates half of what it could be. Keep going until only one thing is left. Notice how few questions this actually takes when you choose them well.

5. 5

   Fix it — then explain it without jargon

   Make the fix. Then tell them what was wrong in language they understand, without being condescending and without pretending it was harder than it was. Watch their face. This skill is worth more to an early IT career than any certification, and almost nobody practises it deliberately.

6. 6

   Write the runbook

   Five lines: the symptom, how to confirm it is this and not something else, the fix, and how to tell it worked. Written so someone else could follow it at 3am without ringing you. This is the artefact that turns a fix into an asset.

Nmap is free and open source. One install, no account, available for every platform.

1. 1

   Establish what your own network is

   Find your own address and the range your network occupies. You need to know precisely what you own before you touch anything, and getting this wrong is how people accidentally scan their neighbour or their ISP.

   Windows

   ipconfig

   macOS

   ifconfig | grep "inet "

   Linux

   ip addr

2. 2

   Find out what is actually on it

   A ping sweep of your own range. Count the results. Almost everyone finds more than they expected — a thermostat, a TV, a printer they thought was off, a doorbell, a device they cannot identify at all. That last category is the interesting one.

   Any

   nmap -sn 192.168.1.0/24        # adjust to YOUR range from step 1

3. 3

   Identify the one you cannot name

   Pick the device you could not identify. Ask what it is — services, guessed operating system, vendor from its hardware address. Then go and physically find it in your home. This is device profiling, and it is precisely what a network access control system does automatically, all day, at enterprise scale.

   Any

   nmap -A 192.168.1.42          # the unknown device on YOUR network

4. 4

   Practise against the one legal target

   The Nmap Project runs scanme.nmap.org for exactly this purpose. Scan it once or twice — not repeatedly — and compare what a deliberately exposed host looks like against your own devices. Read the open ports and ask what each one is for.

   Any

   nmap -A scanme.nmap.org

5. 5

   Ask the question that actually matters

   You now have a list of open ports. A scanner will tell you what is open; it will never tell you whether it matters. For each finding ask: is it reachable from outside my house, what would someone get if they took it, and is there a reason it is on at all? That reasoning — exposure and impact, not severity scores — is the whole difference between running a tool and doing the job.

6. 6

   Write it up as if for someone else

   Three findings, ranked by what you would fix first, with a sentence each on why. Include one you decided NOT to worry about, and say why. Being able to justify what you deliberately ignored is what separates a useful report from a wall of noise nobody acts on.

Paper and a pen. Deliberately no tools — the constraint is the point, because architecture is thinking, not diagramming software.

1. 1

   Draw what you actually have

   Your home network, on one sheet. Router, every device, how each connects. If you did the exposure trial you already have the inventory; if not, list them from memory and then check — the gap between what you remembered and what is really there is itself the first finding, and it is the same gap every organisation has.

2. 2

   Draw the lines nothing crosses

   Now mark what can reach what. On a normal home network the honest answer is everything reaches everything — your work laptop, your smart bulb, a guest's phone, the doorbell camera all sit in one flat space. Draw that reality, not the reality you would prefer.

3. 3

   Name the thing that actually matters

   Of everything on that page, what would genuinely hurt to lose or have taken? Usually one or two things: the machine with your work on it, the drive with the family photos. Circle them. Everything else on the diagram exists, in security terms, mainly as a route toward those.

4. 4

   Pick the worst device and follow it

   Choose the least trustworthy thing on the network — the cheapest smart device, the one that has not had a firmware update in three years. Trace, on the diagram, exactly what it can reach if someone takes it. That path is your blast radius, and drawing it is more persuasive than any risk score you could write down.

5. 5

   Redesign it, on a second sheet

   Draw the version where that cannot happen. A separate network for untrusted devices. The important machine somewhere the doorbell cannot reach. Guest access that is genuinely separate. You do not have to build it — you have to be able to justify it.

6. 6

   Now write down what your design costs

   This is the step that separates architecture from wishful thinking. What breaks? Casting to the TV probably stops working. Someone has to maintain two networks. A guest cannot print. Write the honest list, then decide which trade-offs you would actually accept and which you would not. If you cannot articulate the cost of your own design, you will lose every real architecture argument you ever have.