If you’re a developer who lives and breathes code all day, you probably don’t mind having to write complex configuration files to set up an automation tool or configure a management policy.
But the fact is that many of the stakeholders who stand to benefit from security automation are not developers. They’re IT engineers, test engineers, help desk staff, or other types of employees who may have some coding skills, but not enough to generate the hundreds of lines of code necessary to set up the typical automation tool.
Fortunately for non-developers, there are ways to leverage security automation without drowning in manually written code. Here’s a look at five examples of how non-developers can take advantage of security automation while writing little, if any, code.
1. Low-Code Configuration for Detection Rules
Detection rules are the policies that tell security automation tools what to identify as a potential breach. They could configure a tool to detect multiple failed login requests from an unknown host, for instance, or repeated attempts to access non-existent URLs (which could reflect efforts by attackers to discover unprotected URLs that contain sensitive content).
Traditionally, writing rules to detect events like these required writing a lot of custom code, which only developers were good at doing. A faster and easier approach today is to use a low-code technique that allows anyone – not just developers – to specify which types of events security tools should monitor for and then generate the necessary configuration code automatically.
When you take this approach, any engineer can say, “I want to detect repeated login failures” or “I want to detect high rates of 404 responses from a single host,” and then generate the requisite code automatically.
2. Automated Incident Response Playbooks
Along similar lines, you don’t need to be a developer to specify which steps automation tools should take when they detect a security incident.
Instead, non-developers can indicate their intent, which may be something like “I want to block a host’s IP range if the host is previously unknown to the network and more than three failed login attempts originate from the host in under a minute.” Then, automation tools will generate the code necessary to configure security tools to enforce that rule instantly whenever the specified condition is triggered.
3. Automatically Trigger Endpoint Scanning
Whenever a possible security incident arises, automatic scanning of impacted endpoints is a basic best practice for determining the extent of any breach and isolating compromised hosts from the network.
However, performing endpoint scanning across a large number of hosts can be difficult. It has traditionally required either a large amount of manual effort (if you perform each scan by hand) or the authoring of code that will tell your scanning tools to run the scans automatically based on the host and access data you give them. Either way, the process was slow and required collaboration between multiple stakeholders.
However, by using an approach where endpoint scans are configured and executed automatically teams can perform this important step much faster. For instance, if helpdesk staff who are supporting end-users notice the possible presence of malware on a user’s device, they can automatically request scans of all endpoints associated with that user (or with the user’s group or business unit) rather than having to ask developers to configure the scans for them.
4. Automatically Generate Security Testing Code During CI/CD
The testing stage of the CI/CD pipeline has traditionally focused on testing for application performance and reliability rather than security.
That’s not because test engineers deem security unimportant. It’s because most of them aren’t security engineers, and they don’t want to spend lots of time writing code to automate pre-deployment security testing on top of performance testing.
This is another context in which automatically generated code can help integrate security into a process in which it has traditionally played little role due to the complexity of generating the necessary security code. When test engineers can indicate the types of security risks they want to test for within application release candidates (like injection vulnerabilities) and then automatically generate the code they need to run those tests, it becomes much easier to make security testing part and parcel of the broader CI/CD testing process.
5. Update Security Automation Rules for a New Environment
Your business may already have security configuration code in place. That’s great – until you decide to make a change like moving to a new cloud or migrating from VMs to containers, at which point your rules need to be rewritten.
You could update the rules by having security analysts and developers work together tediously to figure out what needs to change and how to change it. Or, you could use low-code security automation tools to generate the new code automatically. There may be some tweaks left for your team to perform manually, but the bulk of the heavy lifting required to secure your new setup can be performed automatically.
Extending Security Automation to Non-Developers
Security automation is a powerful methodology. But given that non-coders are often the stakeholders most in need of security automation, platforms that require stanza upon stanza of manual configuration code to do their job make it difficult – to say the least – for most businesses to leverage security automation to the fullest effect.
That’s why the future of security automation lies in solutions that generate the necessary code and configurations automatically, allowing all stakeholders to implement the security checks and responses they need in order to protect their assets without having to learn to code or lean on developers to write code for them.
