JIRA workflow for Detection Engineering teams

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…