Security Engineer

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.

Uses the account settings pages you already have. Nothing to install. You will likely also improve your own security materially, which is a decent side effect.

1. 1

   Find the account that owns all the others

   Start at your main email. Now list every service that would send a password reset there. That is not a list of accounts — it is a list of things someone gets for free the moment they take that one. Security people call this blast radius, and it is the single most useful concept in identity work.

2. 2

   Check what is actually guarding it

   Look at the security settings of that email account. Is there a second factor? Is it SMS — which is interceptable — or an app or hardware key? Now check the recovery options: an old phone number or a disused backup address is a back door that bypasses everything else you just checked.

3. 3

   Review what you have handed out

   Find the third-party access page on your Google, Microsoft or Apple account — the list of apps you signed in to using it. Most people have twenty to eighty entries and recognise perhaps half. Read what each was granted. Some will have read access to your entire mailbox from a service you used once in 2019.

   Any

   Google:    myaccount.google.com/permissions

   Any

   Microsoft: account.microsoft.com/privacy → apps and services

   Any

   Apple:     appleid.apple.com → Sign in with Apple

4. 4

   Revoke, and notice how that feels

   Remove everything you do not currently use. Notice the hesitation — "what if something breaks?" That exact hesitation, multiplied across ten thousand employees and twenty years, is why organisations accumulate permissions nobody dares remove. You are feeling the central problem of identity engineering firsthand.

5. 5

   Check the sessions still open

   Most services list active sessions and signed-in devices. Look for a device you no longer own or a location you do not recognise. Sign them all out. Note how many services do not offer this at all — that absence is itself a finding.

6. 6

   Write the one-page assessment

   What is your most valuable account? What is the weakest path into it — is it the password, the second factor, the recovery method, or an app you granted access to years ago? What would you fix first if you had one hour? That prioritised write-up is exactly the deliverable an identity or GRC role produces, and doing it for yourself is the cheapest possible practice.

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.

Your own machine’s logs and a command line. Nothing to install, no account.

1. 1

   Pick something that should be rare

   Choose one event that ought to happen occasionally but not constantly on your own machine: a failed login, a service crashing, a scheduled task failing, a USB device connecting. Rare-but-real is the sweet spot — common events make useless alerts and impossible events make rules you can never test.

2. 2

   Count it over thirty days

   Before writing any rule, find out how often it actually happened. This number is your baseline, and skipping this step is the single most common reason real detections get switched off within a fortnight for being too noisy.

   Windows

   Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddDays(-30)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object Count

   Linux

   journalctl --since "30 days ago" | grep -ci "authentication failure"

   macOS

   log show --last 30d --predicate 'eventMessage CONTAINS "Failed"' | wc -l

3. 3

   Write the rule

   Express your detection as something runnable — a filter, a grep, a query. Not pseudocode. It needs to actually execute so it can actually be wrong, which is the only way you will learn anything from it.

   Windows

   Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddHours(-24)} -ErrorAction SilentlyContinue | Group-Object -Property @{e={$_.Properties[5].Value}} | Where-Object Count -ge 3

   Linux

   journalctl --since "24 hours ago" | grep -i "authentication failure" | awk '{print $NF}' | sort | uniq -c | sort -rn | awk '$1>=3'

4. 4

   Deliberately set it off

   Trigger the thing yourself — mistype your own password four times, plug in a USB stick. Does the rule fire? A detection you have never seen fire is not a detection; it is a hypothesis. Astonishing numbers of production rules have never been tested this way.

5. 5

   Now find out how wrong it is

   Run it across the full thirty days. Every hit that was not really an attack is a false positive — and every one of those, in a real SOC, costs a human being fifteen minutes. Calculate your rate. If it is above roughly one a day for one machine, imagine that multiplied by five thousand machines and ask whether anyone would keep it switched on.

6. 6

   Tune it once, and record what you gave up

   Narrow the rule to cut the noise — raise the threshold, exclude a known-good source. Re-run it. Then write down what you can no longer catch as a result. Every tuning decision trades coverage for signal, and being unable to state what you traded away is how organisations end up blind in ways nobody has documented.