Information security analysts and engineers often experience the most direct benefits when a company deploys a security orchestration automation and response (SOAR) solution. There is a reduction in repetitive work, fewer false positives to chase down, and the volume of alerts requiring investigation decreases. However, if you work in security operations, convincing your management team to spend time evaluating a new tool isn’t always straightforward. Especially if you’re more used to PCAPs than value props.
In this post, we share a strategy for security operations center analysts and engineers to develop a compelling proposal for a security automation or SOAR tool. We also share a deck based on this methodology that you can use to develop your pitch.
At Tines, we’ve successfully leveraged this methodology when working with customers and prospects on their own security automation proposals.
The security automation pitch deck template is available in Google Slides here. You can export to Powerpoint by clicking
Microsoft Powerpoint. How you use the deck will depend on your requirements, company culture, leadership, etc. The slides provide a foundation you can build on when making your pitch.
Start with a problem statement
First, define the problem that your 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 and your team feel today. Remember, your goal is to convince management to commit to evaluating a platform to solve your SOAR issues.
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 analyzed 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 the next quarter?
How do we increase utilization of our existing threat intelligence 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 organization. In the pitch deck template above, we tackle the following:
How do we reduce the volume of incidents requiring analyst investigation by 50% in the next six months?
Structure the problem
Although there are probably a few different ways to tackle this 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 likely:
We can reduce the volume of incidents requiring analyst investigation by 50% in the next six months by implementing a SOAR solution to automate repetitive analyst workloads.
To test this theory, 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.
Security automation platform return on investment
During analysis, if we prove even a single statement false, we demonstrate the entire hypothesis as incorrect. For example, suppose after performing the analysis (described in the next step) of historical incidents, it emerges that only a tiny percentage are false positives. In that case, 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 an analysis to validate the supporting statements. For each statement, write down the corresponding question(s) you need to answer to prove that statement is true or false. Next, define the analysis you need to perform 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?
Security automation platform return on investment analysis
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.
After answering all the questions through analysis, you should now have a compelling data set. As a next step, synthesize that data into insights that encourage action and buy-in. Related data points are grouped and rolled up into insights that address the governing thought or problem statement.
Security automation platform efficiencies
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 comprehensive evaluation of a security automation platform you think is worth investing in.
Security automation platform proposal
By applying the methodology described in this post, you’ll produce a much more convincing proposal for a new security automation solution. 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.