IT Operations: How SecOps Saves the Day

Few messages strike fear in the hearts of IT operations staff like the dreaded scan results from your security team. These messages often appear in your inbox early on Monday morning, which means it’s sitting there waiting for you. You’re not even into your second cup of coffee when you open the message: Good morning, Your servers have 14,000 vulnerabilities that must be resolved in 14 days. See the attached spreadsheet for a wall of text that’s entirely useless and requires a few hours to manipulate into actionable information. Love, Security Sure, I’m exaggerating a bit. But only a bit. The relationship between operations and security is fraught with tension and calamity. Often, communications from the security team indicate a lack of understanding of patching and change management processes. And equally often, communications from the operations team indicates a lack of exigency regarding addressing the vulnerabilities. But ironically, you’ll hear the same observations from both teams: “We’re just trying to do our jobs.” For operations, the job is managing server lifecycles, handling tickets, responding to alerts, ensuring backups run, and generally juggling flaming chainsaws. For security, the job is scanning networked hosts for known vulnerabilities and missing patches, compiling reports for the executives, and disseminating scan results to the cognizant technical teams for resolution. The problem inherent in these teams’ goals is this: there’s no clear accountability for the security of the network and its systems. Without this clarity, you’ll end up with an IT shop that is more focused on placating the other teams than it is on security. This is where SecOps can save the day.

What Is SecOps, Anyway?

At this point, you might be thinking, “SecOps… sounds like DevOps. And that is a meaningless buzzword that belongs in the garbage heap of forgotten IT trends.” I hear you. These terms are certainly overused, and that’s a shame. Both DevOps and SecOps can solve organizational problems that are the result of a generation of siloed org charts and team assignments. And just like DevOps brings together your application and infrastructure teams, SecOps brings together security and infrastructure. In both cases, “bringing teams together” means that the existing battle lines get erased. For example, you maybe have a security team that uses a patch scanning tool to identify systems with missing patches. That tool likely has a built-in database that can track vulnerabilities for hosts over time. It might even include a reporting function that can extract recent scan results for a subset of hosts and place that information in a PDF or spreadsheet. This are all standard, reasonable expectations from a security team’s internal tools. On the other side of the aisle is your operations team, with their own patch management solution that has been configured to act primarily as a patch and software deployment tool. The tool can determine missing patches for managed system and act as a central repository for vendor patches. It likely has its own built-in database for keeping track of patch deployments. And it might include a reporting function. Again, these are all basic tools and capabilities of the ops staff. What’s the problem with this approach? You’ve got valuable data sequestered from staff who could put this information to good use. And the organization as a whole can’t turn that data into knowledge. And most importantly, the focus of these two teams’ interactions will be on finding fault in each other’s data as a means to discredit the team as a whole. I’ve seen this happen. You have, too. It’s not good.

How Can SecOps Help?

A SecOps approach would open up these two datasets to both teams. Security gets a view into your ops team’s patching process, and operations gets firsthand access to scan results for the systems they maintain. And something remarkable happens: instead of the conflict that is manufactured when two teams are each working with non-shared information, you get transparency. The conflict starts to ease. The focus shifts from appeasement to collaboration. And the distrust between the teams starts to fade. OK, that might be expecting a little much from a simple change. Because these battle lines are ingrained in the minds of IT staff, you’ll want to be patient with your new SecOps practitioners. The next step to bring about SecOps culture change is to align the goals of each team with the organization’s goals and vision. Before SecOps, your security team’s effectiveness may have been measured by the raw number of vulnerabilities it identifies each month, or quarter, or year. And your operations team may be measured by how many tickets it closed each month, or quarter, or year. But these measurements fail to put the focus where it belongs: on the shared responsibility to create and maintain a secure IT environment. These measures are also trailing indicators, and generally suggest a fundamental problem with patching or scanning or both. Like all trends in IT, SecOps is no panacea for all of IT’s woes. And it requires buy-in from your technical staff who are likely suspicious of yet another “great idea” from the execs in the Ivory Tower. But with the right coaching, and the focus on SecOps as an iterative journey and not a point-in-time change, your organization will certainly benefit from bring these teams together.