About
A small practice.
Kiln has been run out of Tallinn since 2019. We take on around nine engagements a year, which is about as much as seven people can do carefully.
- 2019 Founded, Tallinn
- 9 Engagements a year
- 19 Advisories published
- 31% Open at retest
What each side gets
Three ways to read a report.
The same engagement, written up for three different readers, so nobody has to translate for anyone else.
They handed us the timeline before they handed us the report. We had detections written for two of the routes while the operation was still running.
The narrative, not the score.
The operation written down in order and timestamped against your own logs, including the routes that dead-ended. Those are often the more useful half.
-
Full attack narrative, in order, with timestamps you can match against your logs.
-
Detection rules for every technique we used, and whether they fired.
-
The routes that failed, which is usually the more useful half.
The first finding arrived as a pull request. Four vendors before them sent a PDF and an invoice, and we did the translation ourselves both times.
Something to reproduce.
Every finding comes with steps that reproduce it and, where the fix is ours to write, a patch. We also describe the pattern behind it, so the repair is not limited to one place.
-
A working proof for every finding, not a screenshot of a scanner.
-
A patch that compiles, or a pull request, where the fix is ours to write.
-
The pattern behind the finding, so you fix four places rather than one.
One page, and I knew what to do with it. The ninety-day retest is now the first thing I ask any vendor whether they will commit to.
One page, plainly written.
What was reachable, what that would have meant, and a short note ninety days later saying whether the fixes held.
-
One page, no jargon, written for a board rather than a SOC.
-
Risk in business terms: what was reachable, and what it would have cost.
-
Written confirmation, ninety days later, that the fixes held.
Method
How an engagement runs.
The shape is fixed so you can plan around it. What happens inside each block is not, and it varies by estate.
-
kiln@engagement:~$ scope
We map what you actually run rather than what the asset register says. The gap between the two is usually where the work is.
-
kiln@engagement:~$ breach
Live operation against production, under rules you write. You get a channel we post to daily rather than a monthly summary.
-
kiln@engagement:~$ report
Findings ordered by what they lead to rather than by score. Each one has steps to reproduce it and a suggested fix.
-
kiln@engagement:~$ retest
We come back and try the same routes ninety days later, and record what held and what did not.
The team
Who you would be working with.
Four of us are below. Three work under client agreements that do not allow a public profile.
-
Principal
Eleni Sarris
Founded Kiln after eleven years of red team work for two banks and a shipping group. Writes the rules of engagement for each job and leads the longer ones.
- Adversary simulation
-
Head of research
Marcus Bramwell
Most of our published advisories came out of his research. Spends roughly a third of the year looking at software nobody asked him to look at.
- Vulnerability research
-
Cloud and identity lead
Nadia Okonjo
Came from platform engineering rather than security, which is why her findings arrive as pull requests. Argues that identity is where the boundaries actually are.
- AWS and Azure
-
Detection engineering
Tomas Reinholt
Sits on the defensive side of an engagement. Turns what the team did into detection rules, then tries the same routes again to see whether they fire.
- Detection rules