hashtalk 004: how to look at things through the prism of automation, the theory behind building your first automation lab and why in cybersecurity it is important to do things outside of your level of expertise

Photo by Gabriel Heinzer on Unsplash

By Eva Georgieva

Hi bugs! On today’s menu we have one of my current favorite topics and a thing I find constantly yapping about lately: security automation. Or to be fair, any kind of automation. So in the words of someone famous, somewhere, probably, what you don’t automate, you tolerate. And how to stop doing it.

Hors d’œuvre

In our talks today:

• Automation is your best friend.
• Mini-guide to automation
• The theory behind building a security automation lab
• A jack of all trades is a master of none, but oftentimes better than a master of one

What you don’t automate, you tolerate

Automation is a proactive choice, by not automating, you’re essentially accepting inefficiencies, risks, or unnecessary manual work.

However, automation is not of the most common practices in cyber security teams. It might be due to complexity and lack of resources, fear of unintended consequences or perceived loss of control. Whatever it is, I firmly stand behind the fact that automation offers more benefits than shortcomings and here I’ll try to give you a mini-guide to automation

Mini-guide to automation

When is the right time to automate?

Rule 1: Identify bottlenecks. Listen to your analysts. Look at their worklogs. Which task consumed most of their time? Is there a way to save that time? Which task created a delay in response? If this happens often and there are several of those that can be identified, maybe it is time to befriend automation.

Rule 2: High volume, low complexity. If you have tasks that occur frequently and follow a predictable pattern, such as updating firewall or malware scan or vulnerability scans means it might be due time to open an automation chapter.

Rule 3: Risk reduction. If manual tasks introduce risks (e.g., human error in log analysis or threat hunting), consider automation to reduce vulnerability exposure.

How to Know if a Task Needs Automation

• Assess frequency and effort: Tasks that are high-frequency, repetitive, and time-intensive are prime candidates. For example, are you filling up an excel sheet with metrics from your SOAR system 3 times per week? Solid automation candidate.
• Evaluate pain points: If certain processes consistently create backlogs or frustration, they might benefit from automation. This often includes log review, user activity monitoring, or incident prioritization.
• Quantify impact: Determine how much time or resources would be saved with automation, and measure potential improvements in speed or accuracy.

How to Start Automating (Step-by-Step)

• Map the process: Start by documenting the end-to-end process you want to automate, noting each step and decision point.
• Select automation tools: Choose tools based on compatibility with existing systems and the ability to handle desired workflows (e.g., SOAR platforms like Cortex XSOAR, Phantom, or simple scripting in Python).
• Pilot with low-risk and low-effort tasks: Begin automation with tasks that carry minimal risk, such as data enrichment or report generation. Also tasks that would require the least amount of effort. Gradually scale up as confidence grows.
• Iterate and monitor: Automation is an evolving process. Gather feedback from the team, measure efficiency gains, and adjust workflows to improve outcomes.

Building a Security Automation Lab

Now in this article I will teach you the theory. In some of the next ones I will guide you through my personal automation lab for a real showcase. However, the basics are the same:

• Set up the Environment: Create a sandbox environment to test automation playbooks, scripts, and integrations without risking production.
• Hardware & Software: Use virtual machines or cloud services to mirror your security tools and systems.
• Tool Integration: Incorporate security tools used in production, like SIEM, SOAR, endpoint detection, and network monitoring.
• Simulate Threat Scenarios: Use test datasets and simulated attacks to verify that automation works as intended and check for unintended results. There are plenty of free datasets online for every type of scenario.
• Version Control & Documentation: Track changes to automated processes and playbooks. This is essential for troubleshooting and future scaling.
• Build a Playground: Ensure that analysts and engineers can experiment in the lab. Deploy and document several test scenarios. Encourage them to test and tweak automation that they might later deploy in production.

Automation is an extremely creative process. It requires envisioning how various tasks and systems can be connected in new, efficient ways that were not previously imagined. Designing an automation workflow involves understanding both the technical and logical flow of tasks, which calls for strategic thinking to understand and foresee problems, craft solutions, and optimize the steps involved.

A jack of all trades is a master of none, but oftentimes better than a master of one

When quoting William Sheakspeare, it is of crucial importance to do it right. Oftentimes we only hear the first half of this quote, but it only makes sense if you understand it fully.

Basically what this means is that is extremely important to be a T-shaped person.

A T-shaped person is someone who has specialized knowledge and skills in a particular area, as well as the desire and ability to make connections across different disciplines.

This is extremely important when you work in cybersecurity. The challenges faced in cybersecurity rarely fit neatly into one specialized area; they often require cross-functional insights to address effectively.

Imagine an organization has been hit by a ransomware attack. A specialist with deep knowledge of malware analysis might be able to analyze the ransomware strain and identify its behaviors and encryption methods. However, responding effectively to this incident also requires a broad understanding of other domains:

• Networking: to trace the attack’s path through the network, understand how it spread, and isolate affected systems.
• System Administration: to know how to recover critical data, rebuild systems, and restore functionality with minimal downtime.
• Cloud and Virtualization: if any infected systems or backups are stored in the cloud, the incident responder needs to know how to securely access and recover those resources.

Naturally, in a more mature organization, this can be done by several people, but if the malware analyst has the knowledge for exactly what to ask for, that will absolutely make the whole process more efficient. A T-shaped persona and approach allows people to collaborate well with other teams, communicate technical details in context and quickly adapt to new threats or technologies. Also, makes you quite an MVP for your team!

Let’s keep in touch

I’d always be willing to discuss more, exchange ideas and continue the hash talk.

Reach me at: evaincybersec@gmail.com