In cloud security, automation does *not* mean automatic

Technology terms often mean different things to different people. For example, to someone in DevOps, the cloud is a fantastic environment for deploying applications with unprecedented speed and agility. To a security pro, the cloud might be a quagmire of risk that can grow exponentially in a matter of hours -- thanks in no small part to those DevOps guys. To end-users, cloud is an easy way to access applications and data … and who cares about all the plumbing?

Which brings us to automation. 

Automation is one of the most loaded terms in technology today. Even when referring strictly to cybersecurity, it means different things to different people. To chief information security officers, it means headcount reduction or a way to reduce the cybersecurity skills gap. To a security operations engineer, however, it could mean “a machine making device changes instead of me.” This can be a frightening prospect to someone who is accustomed to manually implementing security rules across devices and IT assets and, more importantly, responsible for cleaning up the mess when things go wrong.

Yet automation is the only way that security can keep pace with the breakneck speed of DevOps and mission demands. The key is to automate security functions in a way that still gives security pros a degree of control, so they can be comfortable with the automated process. In other words, automation can’t just be automatic -- it must be a hybrid process where humans set the guardrails for the machine.

Automated, not automatic

There is a long and storied history of disconnect between application development and security teams based on their often-conflicting priorities. Developers are under pressure to enable the mission, so they push to get their applications in production as quickly as possible. Security, on the other hand, is in the business of reducing risk -- so speed is not as important as diligence. This conflict has created many situations where application security becomes an afterthought or, even worse, avoided completely. It puts security pros in a position where they must discover and secure applications and systems after they’ve been built and deployed, which would qualify as a “worst practice” for enterprise security.

This situation was problematic when most applications and systems were deployed on-premise. It has become inflamed with the emergence of DevOps and cloud computing, because together these two trends have dramatically increased the velocity of change across the new, hybrid enterprise IT infrastructure. Applications that once underwent six-month release cycles are now being constantly updated and changed, and deploying systems in the cloud is as easy as a few mouse clicks.

The cloud has also created new security accountability issues. According to the FireMon 2018 State of the Firewall report, which surveyed more than 300 security professionals, nearly 40 percent of respondents indicated that the IT/cloud team or the application owner is responsible for network security in the cloud. Nearly one-fifth of respondents did not know who was responsible.

These survey results indicate people outside of the security organization are often responsible for cloud security. And, with all of the pressure on today’s thinly staffed security organizations, security pros are often in no hurry to change this situation because the cloud adds a massive new security management component to their already overworked staffs.  If ever there were a use case for security automation, this is it.

Automation with control

The idea of automating cloud network security is often alarming to security professionals. They are accustomed to manually creating and deploying security rules to keep IT assets compliant with enterprise security policy. To suddenly ask these pros to relinquish this job to automation is like telling someone to take their hands off the steering wheel for the first time with a self-driving car. It might make life easier, but it’s hard to let go.

However, there are technologies available today that provide cloud security automation in a way that also lets security pros sleep at night. One particularly ripe area for this type of automation is in change management. Security organizations often have a long checklist for change management, so they can fully understand the ramifications of any change to a cloud asset and ensure that the asset stays within the organization’s compliance structure. It is possible, however, to codify this change management process into automated workflows that include:

Change planning: Knowing what to change, obviously, is a critical first step to change management. For example, if the staff is managing 2,000 firewalls and needs to create an access path from one cloud asset to another, what device changes do they need to make? Using manual approaches, it can take weeks of tracing routes and understanding traffic flows to figure this out. Today, however, there is technology that can automatically identify the devices to be changed and then automate the architecture for the required changes, without having to go through those manual steps.

Risk assessment: Conducting risk assessment traditionally requires vulnerability scans and then a manual review of the results to understand if any particular change is going to open vulnerabilities. Today, this job can be done automatically with change management tools that provide a pre-change and post-change view of cloud assets to validate that changes stay within policy compliance guidelines.

Compliance testing: Maintaining compliance in the cloud is another daunting proposition for security pros. However, automated compliance testing tools can dramatically reduce risk and effort by ensuring that any changes do not cause assets to move beyond their established guardrails.

Rules cleanup and maintenance: Most organizations have firewalls and other devices with outdated configurations and mountains of useless rules. These legacy rules can lead to configuration issues that cause conflicts and vulnerabilities, so they must be cleaned up. For many organizations, manually cleaning up rules is simply not viable, because there are so many that need to be changed or eliminated and there simply are not enough manpower cycles to get it done. This is another area where available automation tools can eliminate useless rules across heterogeneous devices based on the parameters set by the security organization.

Beyond these automation capabilities, the next step in change management is to enable DevOps to self-implement security in a way that is always compliant with agency policy. This sounds like a “take the hands off the wheel” moment for security pros, but it isn’t, due to the emerging “intent-based security” trend. This approach to security enables security pros to establish the intent for any application or system, which is tied to a set of rules that ensure the intent is met. This sets specific guardrails for rules implementation, which then enables security to hand over implementation tasks to DevOps. With this approach, security can move as quickly as DevOps needs it to, because DevOps is automatically implementing the correct rules set.

We live in a time where automation is changing the security game, and this will only grow as intent-based security gains more prominence. This does not have to be a scary process for security pros. With the examples mentioned above, it is easy to see how automation is not automatic with machines running the show. More importantly, it is easy to see how security can achieve automation that eliminates untold hours of mundane manual labor, while giving security pros the confidence and control they need. This makes it practical for organizations to put cloud security where it belongs -- under the control of the security organization, but aligned with the needs of DevOps and the agency -- and that should let everyone sleep at night.