Ruslan Rakhmetov, Security Vision
Implementing ITSM practices in cybersecurity allows for the application of strict, predictable process logic to the chaotic flow of information security events. Therefore, in this article, we will discuss the differences between classical approaches to task management in IT and information security, the specifics of integration, and how to build a common platform for effective monitoring and management.
а) Differences between ISSM (Information Security Service Management) and ITSM (Information Technology Service Management)
б) Managing incidents, problems, changes and service requests
в) SLA and OLA
г) Various KPI metrics
д) Conclusion
Differences between ISSM (Information Security Service Management) and ITSM (Information Technology Service Management)
Historically, IT and information security teams have operated in silos, pursuing different, and often conflicting, goals: while IT focused on maximizing availability and service continuity for the business, information security focused on minimizing risks and protecting data confidentiality and integrity, which often resulted in slower business processes.
Global standards and practices, such as ISO/IEC 27001 and ITIL, emphasize that information security should not exist in a vacuum. Instead, it should be inextricably linked to an organization's IT processes. In recent iterations of the ITIL 4 methodology, the concept of processes has been expanded to "practices," emphasizing the need for a holistic approach that considers organizational culture, value streams, partners, and technology. In this context, the service desk ( Service) Desk is no longer just a service center for handling office equipment repair requests. It's being transformed into a single point of contact for all IT and business services, including security incident response, access management, and vulnerability remediation coordination.
Managing incidents, problems, changes and service requests
To ensure seamless collaboration between IT staff and security analysts, it is necessary to clearly delineate areas of responsibility based on a unified process model. Despite the use of a common Service platform Desk, the nature of operational and safety incidents differs:
Incident Management is aimed at restoring normal IT service operation as quickly as possible after an unexpected failure or cyberattack, minimizing damage to business operations. This means quickly isolating the compromised node, removing malware, and restoring data from backups.
The technological elements of this architecture are Security systems Information and Event Management (SIEM), Security Orchestration, Automation, and Response (SOAR), which work symbiotically with ITSM to form a unified threat processing pipeline. We've already discussed the specifics of this process, the incident lifecycle, and frameworks for specialists, so we won't repeat ourselves.
Problem Management, on the other hand, focuses on proactively or retrospectively finding root causes: if the incident is a workstation infected with ransomware, then the problem is a systemic lack of network segmentation and outdated signature databases that allow the attack to be repeated.
In the architecture of the integrated ISSM/SD, the risk-based management approach (for example, vulnerabilities – Risk-Based Vulnerability Management (RBVM) is implemented by programmatically merging VS scanner data with the architectural context from the CMDB asset model (which we also wrote about recently). Modern products also implement sophisticated identification and reconciliation mechanisms ( Identification and Reconciliation Engine, IRE).
Change Management is a critical gateway that ensures that incident response actions (such as emergency operating system updates or blocking network ports) do not result in unplanned downtime of critical business services.
The interaction between IT and information security reaches its highest level of complexity and conflict during the process of making changes to the production environment: any intervention, whether changing traffic filtering rules to block a threat or installing a critical security patch , potentially carries the risk of degrading or completely interrupting business processes. In this context, the ITSM practice Change Management acts as an indispensable balancer, reconciling security's need for speed of response with the business's need for the stability of IT services.
Service Request Management automates routine, pre-approved information security operations, such as granting, modifying, or revoking access rights. This reduces the workload on first-line support and minimizes the risk of human error when granting privileges.
Now our task is to combine these processes and manage them together. Integrating monitoring and response systems (such as SIEM, SOAR, EDR) with IT service management platforms (Service Desk) bridges the conceptual and technological gap. In this architecture, technological alerts from information security tools are transformed into business-oriented tasks with clear service level agreement (SLAs) parameters, assigned IT administrators, and controlled lifecycles.
SLA and OLA
For SecOps to function correctly, it is necessary to clearly separate external obligations to the business and internal technical agreements:
1) SLA (Service Level Agreement) is a high-level, formal agreement between an IT service provider (including security) and a customer (business representatives) that regulates the quality, availability, and deadlines for service delivery and problem resolution. For example, a business requirement (SLA) might stipulate that in the event of a large-scale, high-severity cyberattack, the availability of client transactional services must be restored no later than two hours after the failure is detected. For the business, it doesn't matter who exactly resolves the problem—what matters is the end result and adherence to the agreed-upon deadlines.
2) OLA (Operational Level Agreement) – Unlike an SLA, an OLA is an internal operational agreement between various technical teams within an organization (e.g., between the frontline SOC, network engineers, and database administrators) that, taken together, ensure the global SLA is met. An OLA breaks down the overall task into specific phases with strict timelines for each department. The lack of transparent OLAs is the main reason why incidents get stuck at the intersection of different departments' areas of responsibility.
Imagine a local pizza place promising: "We'll deliver a hot pizza in exactly 45 minutes, or else it's on us." This is the final result that matters to the customer, and it's defined by the SLA. The OLA, however, describes the internal agreements between the pizzeria's departments, which are invisible to you. To meet the promised 45 minutes (SLA), employees agree among themselves: roll out the dough and bake the pizza (chef) within 15 minutes of receiving the receipt; slice it, add napkins, and pack it in a cooler bag (packer) within 5 minutes; get from the kitchen (courier) to your door within 25 minutes; and so on. And if someone violates the OLA, while the other participants perform perfectly, the SLA can still be violated, and a hungry customer will receive their pizza later than expected.
Various KPI metrics
Managing information security processes through the lens of ITSM requires the implementation of a clear, mathematically verified system of metrics and support for the continuous improvement philosophy embodied in ITIL. The service level agreements and external supporting contracts described above (Underpinning Contracts (UC)) set measurable parameters for interaction between the SOC, IT departments, third-party vendors, and the end business:
- MTTD (Mean Time to Detect) determines the time from the actual occurrence of a malicious event to its classification as an information security incident in SIEM/SOAR. It characterizes the quality of correlation rules and the work of monitoring analysts.
- MTTA (Mean Time to Acknowledge, Average response/assignment time) – from ticket creation in Service Desk until a responsible IT engineer or team is assigned. Demonstrates the responsiveness of the dispatching process and the quality of integration work.
- MTT R (Mean Time to Respond) is the average time it takes to fully resolve an incident, clean up systems, and restore the normal functioning of an IT service. Reducing MTTR is the primary economic justification for integrating SIEM/SOAR and ITSM.
These are the main metrics by which the effectiveness of process management is assessed, but there are also more specific ones, for example:
- Compliance with the vulnerability remediation SLA (the percentage of identified vulnerabilities that are resolved within the specified timeframe based on their prioritized criticality) reflects the IT department's actual ability to manage technical debt.
- First-line resolution percentage, which determines the proportion of information security incidents and service requests resolved by the first line of support (L1 SOC or L1 Service Desk) without the need for functional escalation to expensive experts.
- The length of time (usually in days) an attacker can operate undetected within a corporate network before being detected and eliminated. Integrated ITSM and vulnerability management are aimed at minimizing the attack surface, which reduces the likelihood of successful attacker penetration and reduces the metric.
- Detection coverage, the percentage of implemented and tested detections relative to known attacker behavior patterns (e.g., according to the MITRE ATT&CK matrix). Integration of problem management processes with Threat Intelligence data enables SecOps teams to systematically identify gaps in Detection Coverage and initiate IT architectural changes to close blind spots.
End-to-end monitoring provides IT and information security managers with a tool to identify bottlenecks in interdepartmental collaboration. For example, if the MTTA metric is consistently low and the MTTR exceeds the SLA, this may indicate insufficient qualifications of second-line IT engineers in using forensic tools or poorly written instructions (playbooks) transmitted from the SOC to the IT department. This, in turn, serves as a trigger for revising training processes and optimizing internal OLAs.
Conclusion
The transition from disparate system administration processes and isolated threat monitoring to the paradigm of a single system ITSM practices works well together with the integration of information security systems (SOC, SIEM, SOAR, VM, etc.), IT service management systems (Service Desk) and assets (ITAM, CMDB). This creates a transparent, measurable, and manageable technological environment. In this integrated ecosystem, each component multiplies the effectiveness of the others:
1) The CMDB provides vital business context, allowing you to prioritize Cyber threats and vulnerabilities are assessed not by technical metrics that are divorced from reality, but by the degree of their real impact on critical business processes and the company's financial flows.
2) SOAR systems act as high-speed intelligent drivers that translate the language of dry technical alerts and telemetry into the language of clear, regulated IT tasks, automatically enriching them with the information necessary for an investigation.
3) VM is being transformed from endless report generation into a strictly managed work cycle with clearly defined and audited risk acceptance mechanisms at the senior management level.
4) SD provides robust performance monitoring mechanisms through the SLA system, ensures correct routing, escalation, and maintains continuous communication with end users and business owners.
5) Change and problem management processes ensure that urgent security measures are implemented in a manner that is as safe as possible for the continuity of IT services, and that the root causes of recurring incidents are identified and addressed at the architectural level.
Strategic investments in the integration of ITSM practices and information security technology stacks are, rather, investments in the predictability of IT operations, the controllability of infrastructure, and, ultimately, in the fundamental resilience of the entire organization in the face of rapidly evolving digital threats.
.jpg)
