Selecting the Right Skills for Your SA&O Project (Part 1 of 2)

In my previous entry, I wrote about Selecting Tools for Orchestration. This multi-part article continues on the theme, focused on selecting the right skills for your project.

I’m going to admit something to you: I'm not very good at the Do-It-Yourself home project thing. I have always been more focused on the art of science, not fixing or building things. Originally, my career goal was to be a veterinary surgeon and that meant I had to be good with a scalpel, not a hammer. The reason I bring this up, and you may laugh, but it was only when I was in my late thirties that I suddenly understood that you need the right tools and skills to do something right. Case in point, using the end of a kitchen knife as a screw driver upsets the screw (and my wife).

It’s the same with Security Automation and Orchestration (SA&O). You need the right tools and, just as importantly, access to the right skills. Without both, you might be able to build something that works temporarily, but it will fall over before too long.

This article provides a high-level overview of the skills that you will need to build a great SA&O solution that really helps your security operations people.

At a high level, you need these skills:

• Strategy Development and Delivery
• IT and Business Process Engineering
• Systems Integration
• Operations Experience
• Risk Management
• Data Engineering
• Python coding; and
• Project Management.

Bear in mind that these are skills, not individuals. You could be an army of one or part of a small team—but you need these skills in one or more people to be successful.

Below I explore these skills, as roles, in further detail and give you some tips on what to look for.

The Visionary – Strategy Development and Delivery

Yes, you can rush off and build a phishing investigation playbook, but what’s next? We often see customers who understand the first two or three use cases, but they don’t always see the longer-term vision. How do you measurably improve incident response? How do you make ticket generation and tracking easier? Better leverage your threat intel sources?

Here’s a reality check: The words “Security Automation and Orchestration” sounds like a familiar term, but it is an emerging capability. Only very recently has the security industry matured to a level that makes SA&O feasible.

We’ve found, after working with multiple customers, that regular brainstorming sessions help develop a roadmap of ideas to improve life in the world of security operations and response. These sessions start off with a review of the current state and then we use various tools to explore what can be achieved. There are predefined playbooks, but teams usually need to customize the model to fit their environment. The great thing is that these sessions help to develop a roadmap that can be prioritized and mapped out on a calendar for delivery. And most importantly remember, Rome wasn’t built in a day.

The Architect – IT and Business Process Engineering

Your security team shouldn’t be an isolated island of people and services. It is essential to enlist one or more persons that understand your whole IT infrastructure and services, and not just your security tools. 

For example, they need to understand these things:

• How systems work
• What data systems generate
• What system data is accessible
• System data that is useful to security tools

That last point is important. Not all system data is useful or needs to be ingested into a security tool. It wastes resources in terms of technology, space, and can increase risk (think data retention).

If you don’t have someone who understand all of this (or at least apply the 80/20 rule), then you could be missing opportunities for automation and orchestration.

The Integrator – Systems Integration

Architecture if one thing, but actually understanding what it is going to take to plug everything together is really, really, important.

Considerations such as API authorization, data formats, and access methods can make or break a use case idea. Take for example the access method, do you pull or push, or as we describe in our technical documents, do you use the REST API or Poll? That decision comes down to timing, resource impact, and security controls.

An architect understands the capabilities and implications and can build a model that will work, be robust, and deliver new effective security monitoring and response capabilities.

Operational Empathy – Operations Experience

Operational Empathy is a phrase I like to use to describe the art of understanding how security operations, incident response and threat intelligence teams work on a daily basis. There is no point in building something that increases a team’s workload or generates useless data. Understanding teams’ daily routines, goals, and escalation processes is critical, otherwise the tools will not be used and will lie languishing in the corner, eventually to be dismissed.

I’ve been in situations where the engineering team has no responsibility for ensuring that the solutions they develop are useful to the operations team they’re building for. I’ve also witnessed situations where engineering has no responsibility for ongoing improvements of the solutions. They just throw it over the wall and move on.

Ironically, this approach is damaging for both sides of the wall. There is no feedback loop on the engineered design, so there is no improvement. The value provided to the organization by both teams is diminished and both teams suffer as a result. On the flip side, it’s important for Engineering and SecOps to work hand-in-hand throughout a development project to build camaraderie that is important for success during the rollout of a new solution.

This Article Continues in Part Two.

----------------------------------------------------
Thanks!
Paul Davis