It’s easy to understand the value of SecOps, which refers to having security and operations teams collaborate in order to make applications and infrastructure as secure as possible.
Things get more complicated, however, when it comes time to implement SecOps processes. Translating SecOps principles into on-the-ground practices is challenging, not least because security and operations teams historically have not tended to be closely connected. They have operated with different types of goals, used different sets of tools and relied on wholly separate processes.
But the benefits that SecOps offer are worth the logistical and operational challenges it presents. This article offers tips on how best to overcome those challenges in order to build SecOps processes that are as efficient and effective as possible.
Extend Operations Processes to Support Security (not vice versa)
A first best practice when approaching SecOps is to evaluate the processes that your operations team already has in place; then find ways to integrate security into them.
This may seem unfair to the security team. Why should operations processes form the basis for SecOps, instead of trying to build a new foundation that combines security and operations processes together?
The answer is that the processes performed by the operations team – such as provisioning infrastructure, staging and deploying applications and monitoring application environments – already form the basis for the way the entire IT organization operates. They impact virtually every IT resource and asset at the organization’s disposal, and they take place on a large scale.
In contrast, traditional security processes tend to have a narrower reach. They focus on things like scanning application code for known vulnerabilities, or monitoring environments for anomalies that could signal a breach. They don’t extend into areas such as infrastructure provisioning or application staging.
For this reason, using operations processes as the basis for SecOps is an easier and more practical way to ensure that the security side of SecOps can be extended quickly to the entire organization. The operations team already touches virtually every facet of IT; so by grafting security onto operations processes, you gain a fast and pragmatic way of making sure that security best practices are applied across the organization, too. You also help ensure that security data is actionable, because it can trigger responses using operations processes that are already in place.
Know Which Processes to Automate and Which to Keep Manual
In a large-scale, fast-paced IT environment, automation is critical for successful SecOps. Being able to automate processes such as monitoring, anomaly detection and vulnerability scanning is the only way to perform these processes at scale and in real time. So is the ability to use rule-based automation to remediate many types of security threats automatically, without needing to wait on humans to respond.
At the same time, however, not every process that falls within the realm of SecOps can be fully automated. Certain types of tasks – such as responding to complex security events that aren’t covered by an existing “playbook” within your monitoring and incident remediation tools – require manual effort. So, too, does the creation of response playbooks for handling new types of incidents so that they can be managed automatically in the future, even if they required manual response at first.
The moral here is that it’s important to recognize what can and can’t be automated within the context of SecOps. Sometimes, teams make the mistake of thinking about automation too rigidly, assuming either that everything can and should be automated, or that they need to be prepared for operations that are almost entirely manual. The reality is that you need to strike the right balance between automated and manual response.
Build Holistic, Comprehensive Processes That Work Across the Entire Infrastructure
Because the challenges that modern SecOps teams must address are so broad and dynamic, it’s critical to implement processes that work across the organization’s entire IT infrastructure.
As noted above, the typical operations team already thinks about processes in this way. Operations has historically strived to build processes (and adopt tools to support them) that are comprehensive and can be applied to any server, any application or any cloud that the organization uses. This is why release automation suites usually work with any application written in any language, for example, and why Infrastructure-as-Code tools work with almost any type of on-premises or cloud environment.
In general, security processes haven’t always been so comprehensive. Because security threats can range so widely – depending on which type of operating system you are dealing with, which language your application is written in, which cloud services you use and other factors – security processes in many cases are designed to apply only to specific parts of the organization.
To be most effective, SecOps requires processes (and tools) that are as broad as possible. Although you may not be able to deploy just a single tool and process to deal with every security threat under the sun, SecOps teams should strive to implement solutions that can be used everywhere within their IT organization if at all possible. They may require multiple configurations or multiple tool instances in order to address different types of threats. But having a single, unified process in place will go far to keep SecOps streamlined.
Address the Entire Application Delivery Pipeline
Along similar lines, SecOps processes should be able to mitigate security threats at all stages of the application delivery pipeline.
This is an especially critical point given that security teams have traditionally had a tendency to focus mostly on production environments. They wait until code has already been deployed into production (or until just before it is ready to be pushed) to begin scanning for vulnerabilities.
SecOps teams should instead strive to begin checking for vulnerabilities in their various forms as early in the delivery pipeline as possible. As soon as new code has been written, vulnerability scanning (not just of the code itself, but also of any external dependencies it introduces) should begin. Security testing should continue under different types of configurations before the application is deployed. Security monitoring and analytics remain critical, post-deployment, too; but they should not begin and end there.
Conclusion
As your team goes about designing and implementing processes to support SecOps, focus on strategies that will make SecOps as practical to adopt and as comprehensive in scope as possible. This approach is the best way to build processes that translate SecOps principles into actionable practice and allow organizations to capitalize fully on the speed, visibility and collaboration benefits that SecOps offers.
To learn more about Broadcom’s point of view and AISecOps from Broadcom®, download the white paper: Bridging the Gap Between Security and Operations for Secure, Resilient Infrastructures
