Threat Detection Engineering practice seems to be evolving. Not only because of easier log management methods and platforms, but because attackers will easily adapt to OOB security, evading detection and achieving their goals.

Nevertheless access to all this data is only the start. The challenge for Blue Teamers keeps increasing as log availability and other challenges around data polishing such as filtering and normalization are still not solved (never will?).

Here I cover one very strategic aspect related to this practice: once you have gathered enough ideas to start developing custom content, how to manage it?

---

Detection as code

This post is continuation of an idea or an approach I’ve started leveraging a few years ago when I started working as freelancer focused on helping Security Teams build custom detection on Splunk.

The idea is basically to implement an Agile process around new content (Security Use Cases) creation — assuming custom rules and dashboards that aid triage, hunting and reporting cycles.

JIRA Workflows

The screenshots here are based on a quick lab I’ve built in JIRA Cloud and very similar to current workflows I’ve been using in a recent MSSP project.

Atlassian provides many guides and rich documentation on how to create Workflows, below is where to start (“Issues” link from Settings):

JIRA is really powerful when it comes to customization and pretty much everything from the fields, statuses and screens (usual “Story” components) can be integrated into a fully custom workflow.

Development Process

Needless to say, you must define a high-level process before actually implementing a workflow.

That means clearly understanding the project scope as well as the time and resources at disposal (team skill-set and availability).

In the workflow, boxes in green represent finished work (status = closed). The blue ones represent work “In Progress”, whereas the gray ones are in a “To Do” state. The gray dot represents the start, of course.

The proposed workflow below is just a draft, I break it down by main stages further. But remember, you must discuss and define a process first.

You can think about each box as a working ticket or proposal state if that makes it more readable and each gray arrow/line as a transition.

The good thing is those transitions are enforced, avoiding users changing status as they want but strictly following the defined process. When you open a “story”, its status will look like below examples:

The Status is represented by the name defined in your custom workflow. The transition or link between two stages (Status) is also displayed for clarity.

Below is the same workflow but with the transition labels displayed:

Notes on Workflow

• From Backlog to Shortlisted boxes, you may leverage various “rituals” as Agile/Scrum people like to say. The idea is to pick a smaller set to start prototyping based on a rank or priority (JIRA also provides such feature).
• In the Prototyping stage is where one may find an idea not so easy to implement or simply not feasible, hence the link to Discarded. If for instance, a log needs polishing, it can be moved to Blocked state.
• As expected, Development stage is where many incoming flows occur as issues detected will likely demand code changes. One of those can be flagged during SOC Handover process or during a code Review.
• The Documentation process is mainly done by the Detection Engineer and SOC teams: former focusing on rule documentation (high-level goal, core logic, FP, devel highlights), while the latter focus on operational playbooks or instructions on how to handle the alerts generated by a rule.
• The Deployment stage is when test/devel/staging code is finally deployed to production environment (Git/Version Controlled repos).

In case you opt for a Kanban board, it may look like something below:

The columns setup (defaults to: To Do, In Progress, Done) are of course customizable, as well as drag and drop actions/outcome.

Feel free to get in touch to discuss ideas and how your team can leverage that!

Originally posted at Medium on Nov 22, 2019.