Detection Engineer

A spreadsheet is enough — Excel, Numbers, or free LibreOffice. There is an optional SQL path at the end if you want it. No account needed.

1. 1

   Get something real and unhelpful

   Download a CSV from a public data portal — data.gov.uk, data.gov, or your national statistics office. Pick a subject you actually care about: crime near you, rainfall, energy prices, hospital waiting times. Deliberately do not pick a tutorial dataset. Real data is messy, and the mess is the job.

2. 2

   Write your question down before you look

   One sentence, on paper, before you open the file. "Has burglary in my area gone up or down over five years?" Doing this first is what stops you finding whatever the data happens to show and calling it a finding afterwards.

3. 3

   Meet the mess

   Open it. Find the problems: blank cells, dates in three formats, a total row hiding at the bottom that will corrupt every average you take, categories renamed halfway through the period. Write a list of every defect you find before you fix any of them.

4. 4

   Clean it, and keep a record of what you changed

   Fix the defects — but write down each decision as you go. "Dropped 214 rows with no date." "Treated blank as zero." Those decisions change the answer, and being unable to say what you did to the data is the difference between analysis and guessing.

5. 5

   Answer the question

   Pivot table, chart, or a formula. Get to a number. Then do the part almost everyone skips: try to disprove it. Is the trend just one anomalous year? Did the collection method change? Would a different but equally reasonable cleaning decision have flipped the result?

   Any

   Optional SQL path — sqlite3 ships with macOS and Linux:
   
   sqlite3 data.db
   .mode csv
   .import yourfile.csv t
   SELECT year, COUNT(*) FROM t GROUP BY year ORDER BY year;

6. 6

   Say it in three sentences

   What you found, how confident you are, and what it does not tell you. Show it to someone who has not seen the data. If they ask a question you cannot answer, that is not a failure — that is you discovering the limit of your own finding, which is the most valuable output of the whole exercise.

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.

A text editor and a browser. No install, no server, no account — the page runs from a file on your desktop.

1. 1

   Build something that works

   Save this as a file called app.html and open it in your browser. It is a greeting page that takes a name. Use it normally first — type your own name, see it work. Everything you build starts here: correct, for the input you imagined.

   Any

   <!doctype html>
   <input id="n" placeholder="your name">
   <button onclick="go()">Greet</button>
   <div id="out"></div>
   <script>
   function go() {
     const name = document.getElementById("n").value;
     document.getElementById("out").innerHTML = "Hello, " + name + "!";
   }
   </script>

2. 2

   Type something that is not a name

   Now put this in the box instead and press the button. Something will happen that the author did not intend and did not anticipate. You have just done the fundamental move of application security: supplying input the designer never pictured.

   Any

   <img src=x onerror="alert('this is now my page')">

3. 3

   Work out precisely why it worked

   The code never asked for code — it asked for a name. But it glued your text into the page as markup rather than as text, so the browser did what browsers do and executed it. Sit with that: the flaw is not the alert box, it is that data and instructions were allowed to occupy the same channel. Nearly every major vulnerability class is a variation of that one sentence.

4. 4

   Escalate it

   An alert box proves nothing to anyone. Change your payload so it reads something real from the page instead — the document title, a cookie you set yourself, the contents of another element. Proving actual impact rather than mere possibility is the difference between a finding a developer fixes and one they close as noise.

   Any

   <img src=x onerror="document.getElementById('out').textContent = document.title">

5. 5

   Fix it — the right way and the wrong way

   First fix it badly: filter out the word "script". Then defeat your own filter — the payload above never used that word. Now fix it properly by changing innerHTML to textContent, so the input is treated as text and can never be instructions. Try every payload again. This contrast, blocklist versus correct handling, is the single most useful lesson in the whole trial.

   Any

   document.getElementById("out").textContent = "Hello, " + name + "!";

6. 6

   Go looking for the same shape elsewhere

   Where else does something you have written take input and put it somewhere with meaning — a filename, a database query, a shell command, a URL? Write down three. You now have the pattern-recognition that application security work actually consists of, and it transfers to every language you will ever use.