Every day, there seems to be a new headline about the latest ransomware threat, supply chain attack or malware strain.
And, while these are very real risks that organizations need to take seriously, an equally important security issue, albeit a much less publicized one, is the divide between security teams and professionals responsible for IT service management (ITSM).
Craig J. LaCava is a director at Optiv Security, and he sees this disconnect as a recurring pain point in his day-to-day work in the security trenches. We recently spoke to him to shine a spotlight on this issue and find out how organizations can bridge this gap to fortify their cybersecurity posture.
BN: Can you elaborate on the disconnect you’re seeing between information security teams and professionals responsible for ITSM processes?
CL: Back in Information Technology Infrastructure Library’s (ITIL) most popular period, we were using ITIL version (v) 2, where cybersecurity was almost an afterthought. The v2 framework told readers that security was critical and referred to ISO 27001 as a best practice to follow — but this was not prescriptive enough. Many early implementations of ITIL did not properly integrate information security into the foundational processes. This was corrected in ITIL v3, but unfortunately the damage was done. Today, I still see information security management missing in many ITIL process implementations.
BN: Why does this divide exist?
CL: I believe there are two main factors that contribute to the divide between security and ITSM processes. First, owners of ITSM processes often don’t think security needs to be involved, so they exclude them from the start. For example, security team members responsible for Business Continuity Plans (BCPs) and Disaster Recovery (DR) plans often are not invited to discuss complex Requests for Change (RFC) going through the change management process. The problem is that if security isn’t involved, then organizations don’t have a clear understanding of how an RFC might impact BCPs and DR plans — and they won’t realize the repercussions, such as broken procedures or out-of-date documentation, until it’s too late. This disconnect is the reason BCPs and DR plans become outdated, often very quickly, and then don’t work when they are pulled off the shelf, dusted off, and urgently executed during a major incident.
The second reason for this divide, is that security teams within many companies today are grappling with limited resources. So, while they might know participating in ITSM processes is a good idea, they don’t push to be included, because they just don’t have the time. This problem is only getting worse with the Great Resignation and ongoing cybersecurity skills shortage.
BN: Are there other areas where you typically see a significant separation between security and ITSM?
CL: Configuration and asset management is another area where I’d like to see more collaboration. Ensuring there are named owners for every asset, system, application and data set is critical for recovery after a major security incident. Consider the Log4j vulnerability discovered at the end of 2021: security teams everywhere were frantically searching for application owners to get urgent patches applied. In many cases, the vulnerable applications were quite old, and no one could be identified. Therefore, application patches were applied on a best-effort basis and at increased risk. This could have been avoided if these applications were in a configuration management database (CMDB) with named owners.
A related example is associated with ransomware. During the containment phase of response, the incident response team often must disconnect resources from the network. Knowing the impact of removing these resources from production is not always obvious unless the CMDB is accurate and configuration, change, incident and availability management are effectively implemented with the security team’s involvement.
BN: What risks are introduced as a result of this problem?
CL: Of course, you have the security and compliance risks that are introduced when security and ITSM teams operate in silos. But, beyond this, there are other business implications as well, including ROI repercussions and false expectation setting with board members and business leaders.
Keeping with the BCP/DR example above, if time and money is spent creating and testing BCPs/DR plans, but then ongoing plan maintenance is neglected, the initial investment — in dollars, but also in time and resources — will be lost. Worse, business executives and board members will think a company has covered their bases when it comes to BC and DR, because plans are in place, but the reality is that they don’t. When changes are made to the environment but not reflected accordingly in BC and DR strategies, then those plans cannot be executed as efficiently as advertised.
BN: How can organizations address the gap between these two groups?
CL: Sometimes, improvements can be made immediately — for example, simply ensuring information security management has a seat at the table with the change advisory board. Additionally, adding check boxes to the ITSM tool for RFCs that get flagged for having an impact on BC/DR, recovery playbooks, or checking to see if an RFC violates any security policies can be helpful. At the very least, these practices will serve as an early warning system. At best, they can stop RFCs from inadvertently raising risk levels or introducing new vulnerabilities.
For companies that don’t have the skill sets or resources in-house to tackle the integration of security and ITSM, there is always the option of partnering with a third-party provider that conducts assessments, identifies areas for improvement and then provides a prioritized roadmap that improves collaboration between these two groups.
Only when these two groups are working in unison can organizations truly remediate security vulnerabilities and enhance their cybersecurity posture.