5.1Security operations

Designing information security and running it day to day are different activities. From a service-management viewpoint, you cannot patch every system at once whenever a vulnerability is disclosed; the judgment required is to remediate in order of risk-highest-risk vulnerabilities first-via the change-management procedure, while upholding SLA targets (availability, response time). This section covers the operational controls-prioritizing patch/vulnerability management, log collection and monitoring, the SIEM that cross-references multiple logs, and connecting detected events into incident and problem management-as an operator's judgment. The focus is not deep cryptography but "keeping the service secure without stopping it."

5.1.1Patch management and vulnerability management

• Vulnerability management is the operational process of continuously identifying the vulnerabilities present in your systems and, by weighing their severity (e.g., CVSS score) against how exploitable and exposed they actually are (e.g., internet-facing or not, whether a mitigating control exists), assessing risk and deciding remediation priority. The point is to judge priority on a risk basis, not to "mechanically patch every disclosed vulnerability immediately."
• Patch management is the operation of applying corrective patches to assessed vulnerabilities in a planned way, on the change-management procedure (test, approval, rollback plan). Patches that are hard to apply without downtime are aligned to an SLA-planned maintenance window, while highly urgent vulnerabilities are handled as emergency changes (ECAB)-the timing of application is decided by balancing availability targets against risk.

5.1.2Log collection, monitoring, and SIEM

• Log collection is the operation of centrally gathering, in a tamper-resistant form, the logs emitted by servers, network devices, authentication platforms, applications, and so on. Aligning timelines via time synchronization (NTP) and setting retention periods to match SLA and legal requirements is the prerequisite for later tracing, auditing, and root-cause analysis.
• A SIEM (Security Information and Event Management) centrally ingests logs collected from many devices and systems, performs correlation analysis (cross-referencing multiple logs to detect signs of an attack invisible in any single one), and raises alerts for events matching thresholds or rules. Its value is detecting a "multi-stage chain of attack" that no single device's log would reveal, and detected events are handed off to incident management.

Suppose a service manager operating an internal core service is told Monday morning that "a critical vulnerability allowing remote arbitrary code execution (CVSS 9.8) has been disclosed in the web application framework in use." The service has a 99.9% availability SLA, and its only planned-downtime window is two hours late every Sunday night. Simply judging "it is critical, so patch every host right now" risks an SLA-violating unplanned outage if an in-service patch fails. So the service manager first evaluates, from a vulnerability management viewpoint, "whether an actually exploitable path to this vulnerability exists in our environment." Of the servers using this framework, only a small subset are directly internet-facing, while most are reachable only from inside. For the internet-facing subset, they immediately apply a mitigation that temporarily blocks the attack pattern at the WAF, closing the exploitation window, and then plan to apply the root fix (the patch) as an emergency change (ECAB) with risk and rollback plan approved, staged in priority order: the internet-facing subset first, the internal-only subset at the next planned window. In parallel, they add a rule to the SIEM to detect attempts to exploit this vulnerability, establishing monitoring that can immediately escalate to incident management if signs of attack appear before patching completes. Thus, even for a critical vulnerability, the operational judgment expected of a service manager is not "immediate uniform patching" but to weigh exploitability, exposure, and the SLA availability target, buy time with a mitigation, and remediate the highest-risk systems first on the change-management procedure.

5.1.3Section summary

• Vulnerability management judges priority on a risk basis by weighing severity, exposure, and exploitability; patch management applies patches in a planned way on the change-management procedure, with urgent ones as emergency changes (ECAB)
• Log collection rests on time synchronization and retention design; a SIEM uses correlation analysis across multiple logs to detect attacks invisible in any single one and to alert
• Even for a critical vulnerability, do not patch uniformly at once-buy time with a mitigation and stage-apply to the highest-risk systems first, handing off detected events to incident management