Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why security and IT Ops need to learn how to share

Gerben Verstraete Chief Technologist, Global Alliances, Micro Focus

Since the dawn of the digital age, IT's overarching operational goal has been built around availability and performance: Keep the systems running fast and with 100% uptime, or close to it, no matter what it takes. The situation looks a bit different today.

Security has become a mandate across the board, as headline-grabbing systems breaches have left enterprises shelling out millions in fines and remediation expenses, not to mention enduring the embarrassment these breaches have caused to their overall brand.

The problem is that while there is a much greater level of attention being paid to security on the whole, in most enterprises security remains locked away in its own bubble. It has its own tools and processes that don't leverage the years of experience and maturity from the broader IT organization, which is more service-oriented, and that's increasingly creating problems.

Here's why security and IT Ops need to play nicely together for a win in cyber resilience and beyond.

Why siloed security is failing

I have worked with several clients whose security departments abruptly found themselves undertaking a full-scale security audit. Why? Their auditor had discovered systems on the network—and even entire network segments—that weren't brought under security controls. So they essentially had spent extra cycles to mitigate, cycles they couldn't afford.

An audit is a good exercise, but IT departments already have comprehensive discovery tools that work well and are focused not only on device discovery, but also on service discovery—in other words, mapping out relationships among the components that make up a service.

Why doesn't security simply use these tools or, better yet, establish a practice by which both IT and security can leverage the same technologies and processes and make decisions jointly? IT's practices have been refined, and have been well established since the early days of service management, and security is missing out by ignoring the discovery framework already in place.

It took time and training to get security and IT working together successfully, but now that they are, both groups are getting a more comprehensive and accurate picture of the application and infrastructure components and the business services they contribute to.

Even co-locating staff became easier. This saved time and money, since not only are processes integrated, but the actual business impact is known—something most security operations centers still struggle with.

How automation can add to the problem

Automation is being leveraged in enterprises as a way to handle security orchestration, automation, and response (SOAR). Qualified security staff are hard to come by, and automation is one of the tools organizations are using to release some of the pressure.

However, comprehensive SOAR tools can raise red flags in some organizations. The security team simply doesn't know what it is automating, and it can quickly become paralyzed out of fear that automation will inadvertently cripple the business. What if the automation tool shut off a critical server farm or isolated it from the network in the name of making it more secure? The possibilities for disaster can seem endless.

The solution lies in tying together the information, technology, and processes of the IT and security teams. IT already has a configuration management system and other operations tools that can be used to make automation decisions based on actual business impact.

These tools can take into account various issues, namely the business's exposure to risk, and can make a more informed decision about how to respond when a security incident is detected. The key is to bring the IT and security teams together and get them to share the knowledge that was readily available in the technologies they had already invested in.

Build a culture of sharing

Why do these silos still exist? The common excuse is that the security team needs to prevent access to certain sensitive records, and therefore needs its own tools. But there is simply no need with today's technology to run separate tools or even separate processes, whether it's to manage incidents, changes, configurations, or any other processes.

That said, it's more important than ever to embed security within the various value streams (such as the IT4IT Reference Architecture) required to deliver services to the business—not as an afterthought, but proactively. As they say, "security by design."

One way to do that is to follow the example of a CISO of a large mobile provider. He decided to embed his staff within various applications and infrastructure teams in a consulting capacity to raise security awareness and knowledge, truly putting the "sec" in DevSecOps.

If the security group understands the attack surface from the time a new product or service is designed (or whenever it is altered), overall security will necessarily be improved. Fewer security surprises will arise later in the game, and the business will be less likely to be taken off guard.

You'll also save money by avoiding costly remediation, not to mention the risk of catastrophe that could come with, say, a breach of customer records. But even today, many enterprises consider security after the fact. Everybody talks about DevSecOps, but not many organizations are really doing it.

Reorganize your IT and security silos

You don't have to rip up your org chart to make this possible—just allow security to develop over time as a more natural part of the cycle. As time goes on and this type of structure proves its worth, you can put a more permanent organizational structure  into place.

However you approach the task, it's critical to get rid of duplicate silos and start streamlining your processes so you can take advantage of the benefits of automation in both IT and security. By embedding security within the IT organization instead of allowing it to live on its own island, you can solve many of the problems that arise later on in the development cycle.

At the end of the day, security really is everyone's problem.

Keep learning

Read more articles about: SecurityInformation Security