Developing a security automation proposal for fun and profit
Information security analysts and engineers often feel the most direct benefits when a company deploys a security orchestration automation and response (SOAR) platform. There’s a reduction in repetitive work, less false positives to chase down, and the volume of alerts requiring investigation decreases. However, if you work in security operations teams, convincing your management team to undertake a SOAR trial isn’t always straightforward. Especially if you’re more used to PCAPs than value props.
In this post we share a methodology security operations center analysts and engineers can use to help them develop a compelling SOAR proposal. We also share a deck based on the methodology, which you can use to develop your pitch.
In Tines, we’ve successfully used this methodology when working with customers and prospects on their own security automation proposals.
Downloading and using the Security Automation Pitch Deck
The template pitch deck is available in Google Slides here. You can export to Powerpoint by clicking File -> Download As. How you use the deck will depend on you, your company culture, your leadership, etc. The slides provide a foundation you can build off when making your pitch.
Developing the SOAR proposal
Start with the problem statement
First we define the problem that our security automation and orchestration initiative will solve. When pitching a multi-purpose platform, like Tines, it’s tempting to compile an exhaustive list of problems the platform will solve. From our experience this will actually dilute the impact of your proposal. Instead, focus on a single problem you/your team feel today. Remember, your goal is to convince management to undertake a SOAR trial.
Problem statements and goals should always be SMART. For example, the following are actual problem statements we’ve seen companies address with Tines:
- How can we ensure 100% of new incident response analysts are on-boarded with the correct access and tool permissions by next quarter?
- What mechanisms can we deploy to ensure every suspicious email reported by employees is analysed for malicious content, in multiple sandboxes, by the end of this year?
- Can we increase coverage of detection and response metrics by 50% in the next 12 months?
- How can we ensure that any potential incidents reported by the executive leadership team are actioned within a strict SLA, by end of next quarter?
- How do we increase utilisation of our existing threat intel investments by 25% in the next three months?
- Can we increase our SOC analysts engagement by 50% in the next six months?
- What steps should we take to ensure all standardized workflow steps in SOPs are being followed in 80% of cases within the next 3 months?
- How do we ensure all analysts have at least 5 hours per week to spend threat hunting new data sources/threat intelligence feeds by this time next year?
Pick the problem which you feel most acutely in your organisation. In the deck we’ve chosen the following:
How do we reduce the volume of incidents requiring analyst investigation by 50% in the next 6 months?
Structure the problem
Although there’s probably a few different ways to tackle that problem, let’s suppose you believe that the best way is by automating incident investigation and response using a security automation platform. Your hypothesis therefore is:
We can reduce the volume of incidents requiring analyst investigation by 50% in the next 6 months by implementing a SOAR platform to automate repetitive analyst workloads.
To test this hypothesis, we’ll use a hypothesis tree. Here we’re defining all the statements which would have to hold true in order for our hypothesis to be valid. We also define how we test those statements.
During analysis, if we prove even a single statement false, we prove the entire hypothesis to be incorrect. For example, if after performing the analysis (described in the next step) of historical incidents it’s revealed that only a tiny percentage are false positives, then a SOAR platform is not the solution to this problem. Of course, that’s not to say that a security automation platform isn’t the solution to another problem you’re experiencing.
Now that we have our completed hypothesis tree, we need to perform analysis to validate the supporting statements. For each statement, write down the corresponding question(s) that you need to answer in order to prove that statement true or false. Next define the type of analysis you need to perform in order to answer that question. The analysis can be quantitative (counting repetitive steps in security processes) and qualitative (speaking to analysts). Finally, what data do you need to support the analysis and where will you find it?
During the analysis step, it’s crucial that we avoid confirmation bias. A biased analysis brings your credibility into question and your pitch will be a lot less impactful.
Synthesise information and insights into action and buy-in
After answering all the questions through analysis, you should now have a compelling data set. As a next step, we’ll synthesis that data into insights that encourage action and buy-in. Related data points are grouped and rolled-up into insights which address the governing thought or problem statement.
Communicate your SOAR-focused solution
When you’ve completed your analysis and established insights that relate directly to the problem you’re aiming to solve, the final step is to package your proposal into a recommended solution. In this case, a trial of a security automation platform.
By applying the methodology described in this post, you’ll produce a much more convincing Security Automation Orchestration and Response trial proposal. Starting with a real problem felt by your security team and rigorously testing your proposed solution will ultimately demonstrate the value-add a SOAR initiative could produce.