JIRA workflow for Detection Engineering teams

Alex Teixeira
Nov 22, 2019 · 4 min read

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.

Custom workflow in JIRA

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:

Status or stage change in JIRA

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:

Custom workflow — with transition labels

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 Controled 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!

Alex Teixeira

Written by

I enable all shades of blue teams extract the value of their investment in Splunk and their security arsenal by offering solid technical advice and expertise.

More From Medium

Related reads

emily
Jan 3, 2019 · 6 min read

79

Also tagged Threat Detection

Related reads

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade