The Unholy Alliance of SecOps and ITAM

If you have spent any time in large IT departments, you know that the ITAM and SecOps teams are typically treated as outcasts.

Before you judge me for saying that, know that I love these people, they are my people. I have been working with ITAM and Security teams for the better part of my consulting career. That does not change the fact that these teams are seen as roadblocks to progress in Information Technology.

The frustration from the rest of IT that both ITAM and Security are faced with is rooted in the fact that they add additional work to their already full schedule. The Asset administrator is always demanding that all "Configuration Items" and the appropriate "Attributes" be tracked. The security team is demanding aggressive adherence to lofty security goals. I will often side with the asset and security team that these things are necessary, but even I can grow weary of the nagging to "Get it right."

Despite my occasional frustration, for the most part, I'm always looking for ways to promote and support these teams. Our business has consulting practices for both Asset Management and Security Ops or Risk Management. The two teams within ITS Partners collaborate. When these teams collaborate, the customer receives some incredible value. While this happens in our engagements, it strikes me as odd that this does not occur very often within IT organizations without an outside catalyst.

What makes this even odder, is when you consider the power the two teams would have if they teamed up. Think about what the ITAM team needs, enforcement of their policies, or some level of control. The root challenge of ITAM team is, they put policies in place that no one follows. Sure, they can find the data on what is out there, and even report back what the company owns. Over the years, most IT organizations have invested heavily in the deployment of robust inventory and reporting tools. The challenge is they never get to enforce a high maturity of Asset Management. This is because they don’t have the proper control mechanisms to force IT to follow their policies for tracking changes and assigning assets, among many other areas.

While the Security team has the vision for what they want to accomplish, they tend to lack visibility. We have all seen it. How often have you seen rogue VMs, networks, software, and even code? IT Pros will sometimes hide things from Security, so they don't have additional oversight/control until they are ready to "Go Live," and then they'll be ready to "Get some real security." I'm sure that you have never done it, but we all "know someone that has" hidden things from Security. These hidden or shadow projects within IT are typically the areas that are used maliciously by people inside and outside the business. In my own company, I have had to threaten termination to get all the engineers to maintain our corporate level of security on their devices. For the record, they do, but it takes constant oversight and rigor. Because security has been elevated in the past few years, they have the tools to go after / take action on risk and non-compliance with IT. What the security operations team lacks is intelligence. No, not mental intelligence, but the visibility of where the assets, code, software, and networks are. This needed visibility is an area that the Asset team both has and is passionate about.

Before you discount what I'm saying with, "Hey we have Splunk for our Security team," or "Our Asset team could use the tools in System Center to enforce its policies" think about those statements for a minute, keeping in mind the level of success your team has had with the tools.

These tools, while in many cases entirely configured/deployed, can go unused by either team. For that reason, the two teams working together is critical.

Imagine a super-power that modern IT has never seen, the Security and ITAM team together. This super-power would be an unstoppable force for good or evil, depending on your perspective. Either way, they would get both the control and line of sight (visibility) they have never had. The teams compliment each other in so many ways, and share a common desire to "Make IT Better."

The reality, however, is that these two teams will have difficulty getting strong collaboration. This is for many reasons such as trust, the difference in mission, reporting structure, a perceived lack of time for collaboration, and proximity. Despite the challenge of getting the teams together, I would still strongly encourage the managers of both ITAM and SecOps to make their way to each others office for at least an hour a week. I know/have seen that there is a significant value in just this weekly visit. Just the act of the two teams doing a better job of exchanging data about bad actors they both track would get a few people fired in IT. They might not get the respect they crave, but they would get the fear.

One of the main areas of frustration for a CIO regarding these teams is the beating they take from auditors at the end of the year. Your typical Big Four firm (Deloitte, Accenture, KPMG) comes in and brutalizes the Security and ITAM team for compliance issues. Often many exceptions/controls need to be put in place to pass these audits. When the CIO later takes the time to look into why they continually have issues passing these audits, the feedback is similar to what has already been listed, lack of control (ITAM) and lack of visibility (Security). The leadership and technical members of these teams find many reasons why they cannot see the level of success the company needs. The truth is, the Big Four firms can get their findings so easily each audit cycle because they don't separate the two teams. They attack the audit together sharing data and tools.

As a CIO or a manager of these teams, act more like the consulting firms that year after year audit you. Get your ITAM and Security Ops teams together using the same tools and data to create an unholy alliance for good in IT. I would insist on it!

This article was authored by Wade Wyant. You can check more posts from Wade here.