When an organization detects a security event, the response typically involves several specialists. The security team usually kicks things off, but other parties invariably join in. Especially during a large-scale incident, IT operations, product engineering, support, and others often join the remediation team.
Unfortunately, these teams usually operate in separately managed silos, and each uses tools that overlap in functionality. To see why this is the case, it's important to understand how we got to the current state of things, beginning with a split in the way security tools have evolved, with security and operations teams gravitating toward separate, overlapping sets of tools. That needs to change.
Protecting your IT infrastructure doesn't mean just safeguarding the perimeter; it also means securing your data, applications, and identities. Protecting the enterprise is no longer a matter solely of protecting the network, but of protecting everything inside it.
Security tools that help with this generally fall into two categories, and each tends to be used by a separate group within the enterprise:
- Protective controls, typically used by the IT operations group, include things such as authentication and authorization enforcement, a least-privilege access model, entitlement management, and security policies compliance.
- Detective controls, typically used by the security team, include things such as monitoring network activity and behavior, correlating events, and searching for anomalous activity.
Up to now, some people have felt that just one of these was sufficient to implement an effective security program. But you need both: the former to block or slow down the progress of the attack, and the latter to quickly detect an attack and trigger a response to minimize damage. They complement and reinforce each other.
That's why IT Ops and security tools need to converge—and they will take the first steps in that direction over the next year or so.
Two tool sets, two silos
Today, security is largely a subset of IT. Some IT professionals focus on operations, while others focus on security. Unfortunately, in many organizations, these teams are managed separately, and each uses different tools.
The SOAR (security orchestration, automation, and remediation) software stack was tailored to the needs of IT security professionals, and was largely developed in isolation from the IT department. SOAR's development was driven largely because of divergent access requirements between the security and IT operations teams.
Meanwhile, IT operations management professionals have their own permissions and orchestration tools that they use for incident management and forensics when an incident arises—tools to which the security team is not privy.
But these two sets of tools aren't destined to live apart for much longer. With the emergence of advanced logging, analytics, and machine learning, the two worlds will soon converge.
This is not to cast aspersions on SOAR, which offers a thoughtfully designed approach to security that uses the NIST Cybersecurity Framework appropriately.
The problem isn’t SOAR's approach to cybersecurity. It's that some vendors are creating SOAR solutions that completely ignore the infrastructure and operations tools that already exist.
The evolution begins
Current IT operations tools will soon begin to evolve in such a way that you can apply them to security use cases instead of reinventing them from scratch as separate tools for security teams.
The pattern for responding to a security incident is not different from the service assurance incident: Both need to be detected or observed, both need to be logged, and both will trigger remediation and forensic actions.
For example, if you use runbook automation for IT incident management in the data center, you might be able to apply those runbooks to security incidents as well with minimal effort. Can they be additive and complementary?
The alternative—a security tool that has been created from the ground up—isn't automatically a bad thing, but it ignores years of best practices developed by IT operations.
The counterargument to this is that a security incident implies that IT Ops has failed, that the IT process hasn’t worked. But as every security and IT professional knows, no network is perfectly secure, and you will always have incidents no matter how hardened your security is.
Some level of remediation will always be necessary, so we should strive to build resilience into our environments as well, with the understanding that security incidents are nearly impossible to fully prevent.
Wouldn't it be more productive and lead to better security if IT and security teams worked together on these solutions, using a common set of tools, instead of each working with its own tools in isolation?
Do you really need two parallel tool sets?
Consider a few examples. When a security event arises, there are certain actions you need to take, mostly in the data center, such as shutting down a port. That action is no different from a security perspective than it is from an IT monitoring and remediation perspective.
The situation is the same for patch automation. Why should security rely on a different tool to push patches to users when IT already has one? They may be designed with different policies, but the technical implementation of these tools is really the same. So why should the security and IT Ops groups use different systems?
Part of the rationale historically has been that the two groups have different goals in mind and that each requires different tools to achieve those goals. Security's goal may be to stop an attack from occurring, while IT's goal may be to rescue a crashed server.
While you could detect and manage these issues using a common platform, the professionals using the tools typically need different analytics and forensic tools, and may require different permissions on the network.
Again, the traditional way to manage this has been to create two sets of completely separate tools that operate on a parallel track. Security and IT both have access to separate auditing systems, incident management systems, knowledge management systems, and service management systems. An enterprise service management system often sits on top of that, to orchestrate where to route an incident once it is detected.
That's a complex undertaking—and a needless one. Why do you need multiple sets of tools to detect an issue, orchestrate the remediation, and then track the activity? Up to now that's where the industry has been heading.
The coming convergence
Customers, however, are increasingly looking for a unified approach. The typical CISO manages as many as 100 different products to deploy an effective cybersecurity framework or environment.
That's a massive undertaking that not only adds a gargantuan level of complexity and cost to the organization, but ignores 30 years of history and best practices developed by IT in the enterprise.
The good news is that some security vendors are starting to come around to the idea of automating remediation. And even if some vendors don't fully consolidate security and IT tools in the next year, they will likely begin to more tightly interconnect them.
Security remediation and IT operations remediation tools may not immediately merge. But in the medium term, both groups will soon be able to use tools initially designed for either purpose—because users are asking for it.
Digital enterprise organizations are not waiting for the vendors, and you shouldn't either. They're reviewing internal best practices and aligning to industry standards such as SOAR and IT4IT.
They are driving people and process alignments against the automated detection and remediation of security and service quality incidents. That's a small step forward you can take, but an efficient one in the constant race with the bad guys.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
