Torq is extremely proud to have Jason Chan on our advisory board. Jason has more than 20 years of experience working in cybersecurity. He’s one of the world’s leading experts in adopting security automation, cloud security, and enhancing security in modern software development practices.

Jason’s most recent career experience was leading the information security organization at Netflix for more than a decade. His Netflix team set the bar extraordinarily high, focusing on cutting edge risk assessment and management, and compliance management strategies and approaches. 

I had the privilege of being able to have a discussion with Jason, exploring the positive impacts security automation is having on organizations of all sizes, worldwide. In the first part of our conversation, “Harnessing Security Automation to Manage the Complexity of Today’s Threat Landscape,” Jason discusses the fact that while cyberthreats are increasing exponentially, it’s becoming increasingly difficult to hire people to address this escalation. As Jason puts it, “The question is how do we get the most out of the resources we have and prioritize the issues we need to address most critically?”

Watch the first part of our conversation in video below and learn all about Jason’s perspective on how security automation addresses these challenges by maximizing the impact of the security systems, processes, and people organizations already have in place, and breaking down security silos:

Take Action Today
Learn how to get started with security automation by reaching out to the professionals at Torq. You’ll learn more about the Torq platform and how we’ve helped myriad organizations achieve and exceed their security goals.

Get Started

Everyone loves automation, and it can be easy to assume that the more you automate, the better. Indeed, falling short of achieving fully autonomous processes can feel like a defeat. If you don’t automate completely, you’re the one falling behind, right?

Well, not exactly. Although automation is, in general, a good thing, there is such a thing as too much automation. And blindly striving to automate everything under the sun is not necessarily the best strategy.

Instead, you should be strategic about what you do and don’t automate. Even if you have the tools and resources to automate certain parts of a process, you may not actually want to automate them.

The Benefits of Automation

To understand the argument for being selective about the processes you automate, let’s go over the key benefits that teams are usually trying to achieve when they automate something. Typically, those benefits include:

• Faster results.
• Less time spent by engineers on manual processes.
• Greater consistency and a lower rate of errors.
• Repeatability.

We could go on, but these bullet points summarize the main goals of most automation projects.

When to Automate and When Not to Automate

Now, if you think critically about how best to pursue the goals we’ve just described, you’ll realize that fully autonomous processes aren’t always the best ways to achieve the goals. Let’s go through each one carefully.

Faster Results

Automation can speed up processes by allowing operations to proceed without waiting on humans to sign off.

The caveat, however, is that if your automation tools run into a situation where they can’t make a decision about how to achieve something – which happens when a variable is introduced that your automation workflow didn’t anticipate – you can end up with more of a delay than you would face if you had a human in the loop to oversee things. You’ll probably get results much more slowly from a fully autonomous process that goes awry than you will from a process where you have a human in the loop to react to unexpected conditions.

Less Engineer Time

By a similar token, the total time that engineers have to invest in operations work may be lower if not all of your processes are completely automated.

The reason why is that if something goes wrong within a fully autonomous process, the response is likely to be highly distracting and time-consuming for your team. But, if you had a human in the loop to begin with, you’d face a lower risk of a disruption that would require an extensive manual response.

Greater Consistency

Automation is a good way to keep processes consistent — so long as those processes are 100 percent predictable and reliable.

But, when there are variables, or when you are dealing with a process where each use case is unique, automation won’t always breed consistency — at least, not the kind of consistency you want. It would be better to keep a human in the loop so that the human could react as needed to special circumstances.

Repeatability

It may be easier to reuse automation tooling, too, when you keep humans plugged into your automated processes.

The reason why is that — once again — each process may be unique, and so you can’t simply lift and shift the automations you’ve created for one process and apply them to a different one. But, if you leave some responsibility to humans, it becomes easier to keep your workflow adaptable enough so that you can use the same automations repeatedly, leaving it to the human to interpret the unique variables within each process and adapt the automations as required.

Using Partial Automation

To illustrate the points above, let’s consider a common process that might seem like a candidate for total automation, but actually is not.

The process is Just In Time (JIT) permissions granting. The goal of JIT permissions is to grant access rights when a user needs them, and revoke them when they are no longer necessary. Having humans configure these permissions each time in a totally manual way is not scalable, so you may think that you would want to automate the process as fully as possible.

But, in reality, it would make more sense to automate only part of your JIT permissions operations. You could automatically collect account and user information, for example, and use these to generate updated access control policies automatically.

But if you actually apply the policies automatically, you run the risk of something unexpected happening with highly negative security consequences. Maybe a user is requesting a JIT permissions update to access a system that was recently moved from testing to production, and that therefore has stricter access requirements. But your automation tooling isn’t aware of that change, so it will grant the permissions without considering the unique circumstances of the request in question.

If you require a human to sign off on the permissions change, however, there is a higher chance that the oversight will be caught. Manual sign-off could delay the process slightly, but the delay should not be significant if the rest of the process is well-automated.

Conclusion: The Limits of Automation

To be clear, we’re not saying automation is a bad thing, by any means.

What we are saying is that there are points within processes where full automation doesn’t always make sense. Although it may seem counterintuitive, there’s value in requiring human participation, even if making processes fully autonomous is a possibility.

Incident response is one of the most challenging tasks that IT teams face. It’s challenging not just because it typically involves many stakeholders and moving pieces, but also because teams usually face pressure to respond as quickly as possible.

That’s why investing in incident response automation is a wise choice. Although it may not be possible to automate every aspect of every incident response workflow, being able to automate at least the major elements of incident response will yield incident management processes that are faster, more reliable, and more consistent.Keep reading to learn about the components of incident response and which incident response activities to start automating.

What Is Incident Response?

In the world of IT, incident response is the process that takes place when teams detect an incident that poses a serious risk to IT operations.Incidents can be cybersecurity problems, like the detection of a software zero-day vulnerability or the existence of malware inside an IT environment.Incidents can also be failures that are not related to security problems. For example, the crash of a mission-critical application or the accidental deletion of important data could trigger incident response operations.

The Components of Incident Response

Each incident is unique, and each incident response needs to be tailored to meet the special requirements of the incident. However, in most cases, incident response hinges on three types of resources.

People

First and foremost, incident management requires some level of intervention by human actors. Humans may need to determine what caused the incident, what the solution is, and how the solution can best be implemented. Humans might also have to manage the sharing of information between the various stakeholders who are affected by an incident or are part of the response operation.

Some of these activities can be automated, so the level of human involvement in incident response may be limited. But, at a bare minimum – even in the context of very simple incidents that can be resolved automatically – humans would at least need to be notified that an incident has occurred and a response has taken place.

Tools

Whether it’s manual or automated, incident response requires tools. Alerting tools tell teams about an incident. Analytics and debugging software can help them investigate the incident and identify its root cause. Collaboration tools help stakeholders share information and plan response activities.

Processes

Incident response also involves a set of processes. These processes define who does what, using which tools, in order to identify, investigate, and resolve the incident. Frameworks like MITRE offer guidance on what processes to take depending on the particular situation.

What Is Incident Response Automation

Incident response automation is the use of tools to automate one or more aspects of your incident response. Depending on the types of incidents you are dealing with, you can likely use automation tools to automate at least one significant part of your incident response operations.

Aspects of incident response that are obvious candidates for automation include:

• Alerting: There’s no good reason to wait on humans to tell you that an incident has occurred. Automate alerts based on your monitoring and analytics data.
• Incident prioritization: In the event that multiple incidents occur at once, automation tools can help to assess the severity of each one, so your team knows which to prioritize.
• Communication: Automation tools can help to ensure that each stakeholder receives the appropriate information during incident response. This is important because different people may need different types of information. C-level executives may want to know what the incident means for the business, for example, while IT engineers need technical information to help them resolve the incident.
• Remediation: In some situations, incidents can be resolved automatically. For example, if a vulnerability scanner detects a zero-day vulnerability in an application, and the vulnerability is fixed in an updated version of the app, you could use automated tools to deploy a new version of the app in order to fix the vulnerability risk.
• Reporting and post-mortems: After a serious incident has been resolved, it’s common to perform a “post-mortem” and prepare a report that explains what went wrong and which steps the team has taken to prevent a similar incident from occurring. Automation tools can help to generate and organize the data inside these reports.

Incident Response Playbooks vs. Automation

In many cases, organizations create incident response playbooks, which define who will do what during incident response operations.

It’s important to note, however, that playbooks alone are not a form of automation. Playbooks are instead a plan for incident response.

Playbooks can certainly be automated by deploying tools that can operationalize the steps within playbooks. But, having a playbook alone doesn’t equate to having automated incident response. Playbooks are more of a first step toward automating incident response processes.

Torq’s Role in Incident Response Automation

With Torq, security teams can deliver improved security without a significant increase in manpower. Automation ensures consistent execution of day to day tasks, and triggered workflows speed incident response and reduce manual effort which, in turn, lets security practitioners do more professionally rewarding work, preventing burnout and attrition. Torq’s ease of use and out of the box integrations mean that security teams no longer need to invest in expensive professional services or middleware development. 

Conclusion

Although there will always be a need for human participation in most incident response operations, many components of incident response can be automated – and they must be automated if you want to reduce incident response time, minimize the risk of error, and keep response processes consistent across different types of incidents.

“Automation” and “orchestration” are terms that frequently appear within the same sentence – which is unsurprising, because they are closely related. In fact, they’re so similar in meaning that it can be easy to confuse them or assume that there is basically no real difference between security automation and orchestration.

But, as with many concepts in the world of IT and security (“observability” vs. “monitoring” is another good example), it would be a mistake to treat automation (or as Torq calls it, hyperautomation) and orchestration as synonymous terms. Understanding the nuanced differences between them is critical for leveraging hyperautomation and orchestration effectively alongside each other within modern IT and security operations.

To that end, let’s compare the definitions of orchestration and automation.

What Is Security Automation?

Security automation is what happens when you use software or other tools to complete a task without intervention by humans. Automation saves time and effort. It can also increase consistency and reduce the risk of mistakes due to human error.

Automation can be partial, meaning that a human plays some role in completing a process, while automation tools handle other parts of the task. This type of automation is known as “human in the loop” automation.

You can also have end-to-end automations, where tasks are completed entirely by automated tools. Humans may configure or deploy those tools, but the tools do their work autonomously once they are running.

What Is Security Hyperautomation?

At Torq, we call it security hyperautomation. Security hyperautomation intelligently integrates and orchestrates multiple security tools so they work in harmony, which empowers enterprise security teams to precisely and autonomously identify, escalate, and remediate security events at dramatic scale, helping them save precious time and money by automating tedious and frustrating manual tasks.

What Is Security Orchestration?

Orchestration is the management of multiple automated workflows.

When you orchestrate something, you are not automating just a single task. Instead, you have multiple related automations running at once, and your orchestration process is what ensures that all of the processes remain in sync.

Orchestration is important because, in many cases, automation processes are interdependent. One automated task may need to complete before another can begin, or data may need to be shared between processes. Orchestration ensures that the various tasks within an automated system proceed smoothly.

Differences Between Automation and Orchestration

The main difference between automation and orchestration is simple: whereas automation focuses on completing a single task with help from an automation tool, orchestration focuses on completing multiple tasks using automation tools across applications.

What this means is, you can have automation without orchestration. In that case, you’d oversee and coordinate each of the automation workflows within your organization by hand.

However, you can’t have orchestration without automation. If you don’t have automations in place, then you’d have nothing to orchestrate.

Orchestration vs. Automation

To contextualize all of the above, let’s consider the automation if tasks such as:

• Collecting data from various sources (logs, metrics, user behavior patterns, and so on) that are relevant for security purposes.
• Analyzing the data to detect anomalies that may be signs of a security issue.
• Generating alerts that tell the security team about a potential risk.

Each of these is a discrete type of process. Each one can be automated separately.

However, because these processes are interdependent, you’d also typically want a way to orchestrate them by ensuring that individual automated tasks take place in a certain order. You need to collect data before you analyze it. And you can’t generate alerts until you have analytics results. Without  security orchestration, then, you’d run the risk that your automation tools would complete tasks in the wrong order, mucking up the whole process.

Orchestration can also help to ensure that humans are plugged into security automation processes at the right times and places. This is important because not every security workflow can be fully automated. For example, while some response operations (like blocking malicious endpoints) could be performed using automation, others (like fixing a vulnerability that requires changing an application’s source code) will require human intervention. Orchestration functionality could help a team identify which security workflows that begin with automation tools need to be handed off to humans to complete.

Conclusion

Security automation allows teams to operate efficiently and at scale. Organizations also benefit from orchestration, which helps to coordinate and manage multiple automation processes to ensure that they proceed as expected. Tools like Torq Hyperautomation bring these together through automated workflows and flexible pre-built templates.