If you’ve ever worked within security engineering or as an analyst producing any kind of output in… - SharITSec

Qualifying Stakeholder Requirements for Detection Development

If you’ve ever worked within security engineering or as an analyst producing any kind of output in a business before, you will certainly have dealt with stakeholder requirements.

These requirements might come from a customer, your boss, a coworker, executives, or practically anyone else.

You would also therefore know that stakeholder requirements come in many different shapes and sizes — sometimes hyper-specific and solvable within an hour or two, or even minutes, if the requirement is well-defined.

But all too often, requirements are given under-baked or without much detail (“Can you please generate a report on the state of our cybersecurity by the end of this week”, anyone?). To address these challenges, we need to start at the very beginning: refining inputs and managing our backlog effectively.

For the purposes of this post, we’ll be focusing on the very beginning of a detection development pipeline — the use case intake process, or, inputs and the priority review, which I’ll refer to as true priority.

Alex Teixeira, https://detect.fyi/from-intelligence-to-detection-a-workflow-for-integrating-cti-ir-hunting-red-teams-6c16c48538ab

It’s worth noting as well that software development priority frameworks are a subject of study in and of themselves, with large crossovers into intelligence requirements frameworks.

This post is intended only as a starting point rather than an in-depth method of aligning against a particular set of frameworks, though they should be considered depending on the context of your organisation.

Boiling the Ocean

In a detection engineering environment, refining stakeholder requirements to their purest, most atomic form can be achieved by implementing barriers a requester must pass-through before the requirement ends up on your desk.

In your ITSM or form-filling product of choice, these barriers can be enforced via a stakeholder-facing form they need to fill out in order to generate a ticket in your DevOps system.

This will force the user raising the request to think more heavily about exactly what it is they’re asking of you and your team.

You will find in some situations that requests that would’ve otherwise been emailed or slacked to you may not have been sent at all had the user been forced to clearly articulate what it is they want you to build a detection for.

Avoid Side-Channels

On that topic, It’s absolutely critical that you avoid encouraging requesters to send your team their requirements via email or slack messages, as this can quickly lead to false expectations and frustration on both sides when work isn’t done quickly.

Users should always be redirected to your form or customer service portal to ensure uniformity and proper development scheduling. It’s ITSM 101, but it holds true for detection development and bears repeating.

Building the form

What kind of information should we be expecting of our requesters, then? We need to ensure that we account for a wide array of potential stakeholders and thus avoid asking for highly technical information up front. Consider the broad groups of users in your business that may be raising requests to Detection Engineering. For example:

• Account/Service Delivery Managers (for MSSPs with multiple customer SIEMs)
• Internal Cyber team — SOC analysts, penetration testers, consultants and third-parties
• Cyber Threat Intel — Via a vendor or internal CTI analyst
• Executive leadership (It is worth noting that these requests are often filtered through via managers, and thus won’t be raised directly by an executive themselves. Understanding this is covered below in the ‘Sources and References’ section)

An executive will raise a request from a very different perspective than that of a SOC analyst and vice versa.

You need to account for the possibility of the request being something as simple as “Do we have coverage over the things I read in this news report?”, or as complex as a CTI briefing pertaining to a specific intrusion set or threat actor.

The form you’ll use then to gather these requirements is highly subjective, but you can start by musing on these requirements in order to generate a request.

Stakeholder Requirement

This one might seem obvious, but it’s worth asking the user raising the detection request what it actually is they want you to detect. Is it a TTP from a report they read? Do they want to make sure you have a particular IOC ingested in the SIEM/TIP? Do they wish to validate coverage against a particular group, and therefore receive a report?

It is very important to get this answer from the stakeholder first as it will quickly tell you whether you have a detection on your hands or whether the request needs to be redirected to another team.

Subjective Priority

We’re referring to this as the ‘subjective priority’ because it’s how important the request is to the stakeholder but not necessarily to the detection engineering team. Is this an urgent request that needs to be done by the end of the day, or end of the week? Is it a critical gap from a penetration test or something they read about?

The subjective priority is important to understand as it provides us a key insight we’ll need later to figure out the true priority of the request, which is the priority given to the detection when the request is ready for development. By asking the requester what the priority is, we are gauging how quickly they wish for some kind of outcome.

Sources and References

The source of the request, as given by the stakeholder. This context helps the detection engineers understand and weigh the true priority by letting us know where the information came from.

For example, a critical finding in a penetration test that went undetected or request for information by executive leadership, versus a blog post somebody read on LinkedIn.

How you determine which one to prioritise first is up to your team and organisation’s goals, but broadly speaking, you can assume which one of these requests may be more urgent.

Qualifying the Requirement — Concocting the ‘True Priority’

Now that the request has been generated, how do we qualify these requirements and graduate them into real, actionable engineering requirements?

Re-iterating the disclaimer from above about aligning against priority and intelligence frameworks, you can consider the below aspects when creating your own workflow.

Sanity Check

Is there enough information here? Does the requirement make sense for detection engineering? Would the request be better served by another team? Might this serve better as a threat hunt hypothesis, rather than a repeatable and testable detection? Perhaps the requirement could be better handled as a SOC playbook. Ask yourself these fundamental questions first before proceeding, and don’t hesitate to come back to the requester with a request for more info if there isn’t enough. It’s important that the sanity check weeds these gaps in info out early to prevent friction later on.

Viability

Do we have the data available to us to reproduce the TTPs from the requirement? Can we produce the report or dashboard being requested? If not, is the detection requirement still good? If it is, and the true priority is high, engage with your SIEM engineers to understand whether the data can be onboarded and the potential cost implications of doing so (breaking down departmental silos!).

Relevancy

Employing aspects of Cyber Threat Intelligence, it’s important to gauge the relevancy of the detection being raised. For example, a request for a detection against Russian AI 0-days probably are not worth dwelling upon for very long. You can also use threat-modelling frameworks like MITRE ATT&CK to understand whether the TTPS behind the request are already covered, or whether mitigations and detections in-place earlier in the killchain could sufficiently detect or even prevent the behaviour.

Arriving at True Priority

At this point, you should have enough information to arrive at the true priority of a detection requirement. You should be able to answer all the below questions

• How quickly do we need to develop this detection in context of all the other work currently going on? Does this work need to take priority over something else being worked upon, or can it wait?
• How complex is the detection going to be? Will it require significant time to test and develop, or will it only take a few hours? Particularly important if timesheets and billable work is a KPI.
• Is the data we have consistent enough to detect the activity if we did create the detection?
• And if you’re in an MSSP, can the detection realistically be deployed to multiple environments or even multiple SIEMs?

This will allow you to accurately set the priority of the detection in your backlog and schedule it in for development.

Hopefully this can help others understand how to better prioritise detection development work! Working in an MSSP, it has taken oddly a long time to fully wrap my head around this work, particularly when it comes to many customers across many SIEMs. If you wish to discuss further with me, leave a comment or feel free to DM me on Twitter at @rcegann or chat via LinkedIn. If anyone has any experience building something similar or particularly aligning against Intelligence priority frameworks, I’d love to hear from you!

If you’ve ever worked within security engineering or as an analyst producing any kind of output in… was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Article Link: Qualifying Stakeholder Requirements for Detection Development | by Rcegan | Dec, 2024 | Detect FYI

1 post - 1 participant

Read full topic

Malware Analysis, News and Indicators - Latest topics