Automation isn’t one-size fits all
It’s no secret that security teams are understaffed despite increased pressure to deliver. Firewall engineers face an additional challenge when it comes to access request denials; more specifically, if they prohibit business, they get noticed – and not in a good way. Conversely, those access request approvals that prohibit security may slip through unnoticed, because in many cases, business productivity trumps security.
All of this pressure to open up access to meet Service Level Agreements (SLAs) combined with limited resources to perform proper security analysis leads to incorrect changes being implemented, negating the work and introducing unnecessary risk to the business. For many organizations, automation would seem like the ideal answer.
Of course, it makes sense to automate when you can speed up workflows and allow more time for analysis of planned changes. However, automation is not a switch you can simply flip on. Each organization, each request maybe, has its own set of workflows, stakeholders and challenges. While automation can help reduce time and increase productivity, it is critical that it doesn’t also introduce more security holes in the network that cyber attackers can take advantage of to gain a foothold within the organization.
Solutions that present themselves as turnkey are missing an important piece of the automation puzzle – the context of the environment it’s automating. After all, automation should fit the organization’s business practices. When done in reverse, process jams and adoption will be low, and you’re left with the same problem as when you started. Therefore, when establishing an automated process and utilizing it in practice, each step should be context-aware – to ensure changes are not simply implemented fast – which tends to be biggest selling point for automation – but correctly.
While the market for policy automation solutions is still in its infancy, as it matures, buyers must demand more control and more customization to ensure safe, efficient change management that actually helps reduce the organization’s risk posture.
Automation recommendations
To help in the meantime, here are a few recommendations for organizations to ensure their policy automation needs are met at each stage of the change management process:
Set Up – Fully flexible workflows ensure organizational requirements and processes are maintained during change automation. More times than not, out-of-the-box functionality won’t fit the bill. Determine where automation should enter the workflow and where it might be better to keep things manual – such as highly complex or potentially risky changes.
Request – Integrate your automation process with existing ticketing systems to enable new requests to filter directly into the change automation platform. Capture all relevant change information upfront to make management easier later and then manage throughout the life of the change ticket using the preferred system.
Design – New changes should be designed using the context of the existing rule base. If a change already exists or an existing rule can be modified to allow the requested access, then a new rule isn’t necessary. Fewer unnecessary rules, means longer device life and less risk.
Analyze – Once a rule is deemed necessary, run a pre-change analysis to determine the impact to security and compliance. Customizable controls ensure that an organization’s established best practices are enforced on every new access request.
Review – Once a rule has been through design and analysis, it can be decided whether or not to automate the rest of the process. It is only recommended to automate low-risk rules. Establish criteria during the analysis phase that, when met, kick off automated review, implementation and verification or a mix of the three.
Implementation – Too often, rules that don’t meet established policy or criteria move through the automated process unnoticed – that is until they are compromised. Herein lies a dilemma of whether to automate every stage of the change management process; however, automating implementation with no awareness of the impact will cause more trouble than it’s worth.
Verification – This too can be automated, but again, the engineer should be in control of which changes are manually verified versus automatically verified. A change that was made outside the bounds of agreed upon processes should require a second look.
Monitoring/Review – Policies need to be reviewed, amended and decommissioned as business needs and threats demand. Integrating the change automation platform with recertification workflows simplifies the decommissioning process. As rules are triggered for review – again this should be customizable by date, event, detected threat, etc. – tickets can be created in the change management workflow to change access accordingly.
There will always be a need for the human behind security; after all, no one knows the business better than the administrators that run the networks behind it. But without automated processes, the change requests will only pile up. That said; if automation is to revolutionize the industry, it must be done in a way that is meaningful, taking into account all the intricacies of an organization and putting them into context. Sure, administrators can push policies more quickly with automation, but it’s the rest of the process, what happens before and after the push – that ensures it’s done correctly.
When the stakes are as high as they are in cybersecurity, organizations should strive higher than risking it all on a one-size-fits all solution. Instead, businesses should combine a good change automation solution with knowledgeable staff that will allow both business and security requirements to be met.