Detective controls are an important part of any security process. Put simply, they’re the rules that spot bad things happening, and let us know about them.
As we’ve grown, we’ve changed how we write the code for these rules. And now it’s all written in a language called Sigma - which is specifically meant for this kind of thing.
We ended up building quite a few tools to help this transition. And now we’ve made the tools we built open-source so anyone can use them. (The actual rules themselves are still secret, of course! )
Author here (both of the post, and a lot of the tools we used) so I’m happy to answer any questions you might have about this
I found that an interesting read, especially as my computer language is pretty much limited to 1980’s BASIC and self taught HTML from the 90s
I find coding fascinating, yet attempts to try and learn any of them have been pretty fruitless as I can never see an end-use for any skill learned tbh.
Anyway, back to the article, it was interesting to see how the team rose from around a dozen to the fifty odd mark.
How does this work in the real world, having so many on staff. Does each person have a set task, or is everyone part of a group/mini-group project to come up with the coding required to keep the rules effective?
Are there weekly meetings where suggestions can be made to tinker with the code, and who has the final say on what goes in to the system, and what stays on the cutting room floor?
50 would definitely be too many to have in one single team @PaulUK
Even as 12 engineers we were unofficially split into two teams: Infrastructure Security (e.g. securing our servers) and Application Security (securing the code that runs on the servers) but as we’ve grown we’ve further subdivided those teams and added entirely new ones.
We’re now 10 different “squads” each with their own focus area (which mostly avoids needing to do cross-team work). Within that it kinda runs how you say: every week or two we have a planning meeting to decide what we’re going to work on. Then we’ll break off and do the work, often collaborating in pairs.
Leadership is pretty fluid (tends to rotate round by project) but, if it came to it, I guess the engineering manager for a squad would have the final say on what work had to be done vs dropped.
Interesting read, always wish I learnt to code!My daughter seems a natural at it! It just looks like the matrix in my old eyes. Just wondering if other banks do security the same way? Or is Monzo unique with bank security?
To to avoid the risk of a bad rule being deployed and swamping us with spurious alerts, we had to first deploy rules in a test mode to evaluate their performance before upgrading them to “real” alerts.
How is this managed differently with the new Sigma solution?
We’ve definitely got some different challenges because of how we run our software (we’re mostly deployed on “public” clouds like Amazon’s AWS or Google’s GCP whereas many older banks are running on their own private servers) but the underlying principles are pretty much the same.
Certainly if you look at other new banks, I’d think we look very similar.
Ah yes! This is a great bit about Sigma: we can compile our rules differently depending on how we want to use them.
For running rules in real-time against live data, we use sigma-go, but for testing out new rules we can use sigmac to convert it into a query that can be run over all our historical data.
So you can easily see what would have been alerted on if this rule had been live months ago and tweak it until the results are what you want.
)
Author here (both of the post, and a lot of the tools we used) so I’m happy to answer any questions you might have about this 
