May 3, 2022
Paul-Arthur
Jonville
When talking about network security, people often refer to many manual tasks, such as monitoring your firewalls or IDS/IPS, provisioning and deprovisioning accounts, and updating detection rules.
In yesterday’s world, where organizations were geographically united and the perimeter to defend was unified, it was already a challenging task, implying the use of lots of resources.
In today’s world, companies are increasingly turning from on-premise to hybrid architecture, relying on (multi-)cloud strategy to strengthen their resilience and adapt to the fragmentation of the workforce location. This change in company's architecture brings new concepts of defense, such as the Cybersecurity Mesh Architecture, in which automation and orchestration tools find their place.
Monitoring such network is thus increasingly more complex. As the attack surface is dramatically growing, the processes need to evolve if not to be overwhelmed by alerts.
Network security automation solutions are increasingly sought after to answer these needs, particularly SOARs (Security Orchestration, Automation, and Response), thanks to their automation and orchestration capabilities (as we’ve already shown about Identity Access and Privilege Access here) because of the time-saved and consistency of their processes.
To show why we think that SOARs can bring answers to the network automation issue, we’ll successively show:
How teams usually ensure network security
How it is handled today
Next-generation SOAR, Automation as a Platform
What is network security?
Basics first, let's have a read at what is network security exactly. We define it as a concept that gathers technologies to protect the availability and integrity of your company’s infrastructure. To that end, it prevents the entry or proliferation within your network of potential threats.
Here, we understand the network as the infrastructure itself and its apps. Thus, there are two layers of assets that need to be defended (as said in the introduction, we're voluntarily excluding Network Access Control, NAC, from this post, to keep the subject light and because we've already talked about it).
Your network security stack comprises tools protecting the network itself and the applications to defend this infrastructure. They implement controls at various points to ensure security to provide access control and threat control.
In today's modern stack, we typically find the followings:
Firewall: a barrier between trusted and untrusted areas of your network. It performs access control and segmentation based on IP subnets. Advanced Firewalls also provide granular segmentation.
Load Balancer: to distribute the load based on metrics enabling you to absorb specific attacks (volumetric DDoS attack).
IDS/IPS: deployed behind a firewall to provide protocol analysis and signature matching on various parts of a data packet.
Sandbox: to emulate an end-system environment and determine the behavior of malware.
NTA/NDR: to directly look at traffic and to use machine learning algorithms and statistical techniques to evaluate anomalies and determine if a threat is present.
As you see and as is classical in cybersecurity, teams use in-depth defense strategies. They deploy multiple lines of defense, or layers, that enforce a set of distinct policies that your administrator determines. This strategy, which has proven its benefits over the years, nonetheless implies challenges that we will see below.
Considering its components and the architecture, your network security processes usually consist of:
Network scanning and monitoring: to identify active devices on your network and slow or failing components before they cause problems with the help of WAF, Firewalls, App security module, and compute resources.
Incident and problem management: identify where abnormalities occur on your network and decipher potential threats. You would use threshold indicator, trigger event from existing security gateway device, ASM, WAF.
Threat and vulnerability mitigation: Identify a security gateway policy violated or WAF triggered.
Troubleshooting and remediation: achieve exhaustive visibility of your infrastructure to assess the complete path of a given incident, regardless of vendors or service type.
The current state of network security
Considering the complexity of the network security field and its environment, it's no wonder that your teams are experiencing numerous challenges when confronting the issue. We're going to examine one of the biggest of them, to which we can provide the most radical solution.
Network security is still overly manually managed by teams as of today. More than 65% of enterprise networking activities are performed manually.
This phenomenon is part of a wider one, often known as “ClickOps.” We can define it as people clicking through various menus to select and configure automated computing infrastructure. It's time-consuming, tedious, and thus prone to errors.
Applied to network security, we can define it as performing processes manually, enabled by manual queries on keyboards to enter commands via a command-line interface.
From the analyst's point of view, click-ops materializes itself as repetitive and time-consuming labor. These two factors lead to errors and a high churn rate. Manually updating network devices is slow, inconsistent, and not scalable. This can delay the delivery of services to business units and reduce uptime.
Of course, solutions exist. Indeed, network automation tools have been around for a while now. These tools allow your organization to streamline the configuration, deployment, patching of network devices, maintenance of network infrastructures, etc.
Like the broader network security market described above, where vendors are various, there are many “low friction” network automation tools. These tools are used for specific purposes, not as de facto general solutions.
Also, many analysts are resorting to “DIY” automation via open-source (Ansible) and scripting (python). While this solution can bring temporary relief to your team, it increases your technical debt in the long term. Creating ad hoc automation cases doesn't bring answers to the initial issue, which is the complexity of the environment. Ultimately, you're taking one step back before the jump. It’s more about adding another layer of complexity to already complex architecture.
Furthermore, some companies use embedded automation capabilities provided by network solution vendors on their proprietary management systems. This increases the captivity of your company to your vendor’s solution without regard to its overall quality.
We've named a few solutions that already exist. However, we can see, and you can experience, that network automation adoption in companies remains low. Why?
Most of the time, the reasons are simple and part of a much broader issue about the state of the companies today. We documented this a little while ago as the legacy issue. Your company processes are sclerotic, unadapted to the current environment because the cost of adapting is too great. You can only bring a partial solution to a structural issue that is an inadequacy of the process.
Specifically, about network security, we can list various factors. We have established processes, technical debt, and a lack of confidence in new solutions and skillsets (all linked, as we said here).
As we said there, we believe that a new and radical approach to SecOps and ITOps has the potential to bring answers and accurate and practical benefits to your teams.
Before taking our hands on this, let’s sum up the current state of network security:
Network automation remains low; 65% of enterprise networking activities are performed manually.
Limited network automation implies congestion in although easy tasks but highly repetitive and time-intensive, such as provisioning, updating, and incident resolution.
Open-source, DIY scripts, and embedded capabilities are the most used network security automation tools.
Aiming for network security automation
Network automation at scale needs an accurate and reliable solution, not a pinpoint use-case centric one. We’re circling back to a previous interrogation on our blog, “how can we enable automation at scale?” In this post, we've explored the hyperautomation concept and how it materializes in your company. We believe that hyperautomation is a backbone on which your whole company sits. Specifically, SecOps and ITOps, and the network security automation lack such backbone dedicated explicitly to making broad automation achievable.
We’ve talked about hyperautomation as a process-agnostic tool, i.e., an architecture widening the possibility of automation to potentially every tool and process. Network security automation is where this concept and our approach shine. Few traditional SOARs are tackling this issue simply because their rigid frame and their complexity are blocking them from initiative outside the predetermined paths.
Next-generation SOARs focus on user experience and accessibility via a no-code approach, while maintaining the unique ability of the SOARs to automate. They intend to fulfill the still-vacant backbone place of your company. They develop unique abilities in integrating tools, systems, and applications, from an environmental-agnostic perspective, to replace manual workflows. As a result, automation and orchestration capabilities are multiplicated.
Indeed, thanks to its integrations, the next-generation SOAR tackles the issue of fragmentation between the tools used in network security. On its platform, you can connect and automate the communications between your network security layers, from your EDR to your Firewall, by tagging specific IPs or your Threat intelligence service to your IDS/IPS by typing signatures.
The process agnostic approach enables you to determine your workflows, such as provisioning or de-provisioning accounts according to your specific architecture, or pre-determine automatic updates of your WAF rules, following the discovery of new threats, and much more.
Incident and response wise, an incident should occur; automated communication enables you to collect data about potential security threats from multiple sources (IP, hash, URL, domain, and so on) and infuse it in your incident report to lighten your decision making without multiplying the panes of glass.