SOC SLA Template v1 Idc2bp
SOC SLA Template v1 Idc2bp
<throughout this document <text> indicates something you must change in this template. But
feel free to change anything.
Table of Contents (draft)
2 Introduction 6
3 General 6
3.1 Purpose of this document 6
1.2 Distribution
New approved versions of this document must be distributed to the functions listed below. It is
the responsibility of the document owner to initiate (re)approval processes and thereafter the
responsibility of the <approver> to approve the changes to the SLA.
Permanent <approver body> members: (<delete this whole table if handled in a separate
policy>)
Function
…
…
Specification of third parties to whom distribution of approved versions of this document has
been authorized.
Company & Function
2 Introduction
This document will describe the services delivered to <Company> name by the Security
Operations Center at <Vendor or Internal department>.
3 General
3.1 Purpose of this document
The purpose of this SLA is to establish the service levels agreed upon between the parties.
The SLA must describe which services the SLA include, how they must be delivered and how
reporting of the delivery must be performed.
Contracter must initially specify the logs to be included in the SIEM log collection, and the
contracted must assess the initial specification and point out shortcomings to ensure
comprehensiveness. Comprehensiveness must proactively be maintained in Change
Management situations, i.e. ensuring that newly added systems have their logfiles added to the
SIEM as well.
The contracted must ensure the uninterrupted addition of logs to the SIEM, which includes
ensuring that end point log forwarding agents are running and that the SIEM receivers are
listening and functional.
The numbers must be listed per month and reported monthly via email. The average time logfile
collection is inactive must be less than 1 hour per asset per month, approved service windows
not included.
The numbers must be listed per month and reported monthly via email. The number of priority 1
assets that have threat models with less than the required number of use cases associated with
it must be 0 within 1 month of this asset going active. The number of priority 1 assets that have
threat models with less than the required number of use cases associated with it must be 0
within 3 months of this asset going active.
· Daily verification that devices or applications that need signature updates receive
these i.e. IDS devices receive new signatures
· Monitoring for new firmware or software version availability
· Changing default passwords and community strings
· Documenting passwords in password managers
· Documenting asset configurations in the CMDB with the agreed upon level of
configuration item detail.
· Ensuring separation of duties between production systems and backup systems
holding backup data
All security devices must pass an initial configuration audit after contracted has configured
them. This audit will be perfomed by contracter (or a third party employed for this purpose by
contracter) and the audit must be performed within 1 month of the device going active.
The numbers must be listed per month and reported monthly via email. Rolling numbers must
also be reported monthly via email.
The numbers must be listed per month and reported monthly via email listing attack dates, times
on/off and targets.
1. Contracter will perform bi-annual CMDB accuracy and comprehensiveness audits. The
number of errors including omissions per asset/software must be less than 1 per asset or
software package
Reporting of audit results must take place via email within 1 week of audit completion.
Change Management processes must follow the official change management policy and
contracted will be measured on adherence to this.
1. Numbers of incidents created, their creation date, and their closing date
2. Number of incidents automatically escalated, their escalation from/to, escalation
time/date. Incidents must automatically escalate from priority <5> to <4> after <3> days,
from <4> to <3> after <2> days, from <3> to <2> after <1> days, from <2> to <1> after <3>
hours and unclosed priority 1 incidents not closed 3 hours after contracter reporting these or
contracted creating these must be escalating to major incident handling
3. Number of major incidents, their reporting/creation time, their closing time/day and
whether or not a major incident was escalated automatically and if yes, from which initial
priority
4. Average contracter satisfaction with major incident handling. Following the closing of a
major incident, contracter will always perform a satisfaction survey internally, and the
satisfaction in percent must always stay above 80% over 6 months rolling
5. Number and percentage of incidents manually escalated and reasons for this
6. Number and percentage of alerts followed up, number and percentage of alerts
determined as false positives, number and percentage of alerts without potential impact,
number and percentage of alerts with potential impact plus actions taken.
7. For any alert that could mean a potential breach, this will be handled like a major
incident and reporting should be done according to the major incident handling process
described above
The numbers must be listed per month and reported monthly via email. Rolling numbers must
also be reported monthly via email.
For a third party SOC vendor, the fine structure should be in % of monthly payments up to 100%
maximum plus a liability for major breaches happening that should have been prevented.
For an internally provided SOC, this is not doable and you will have to come up with something
else that makes sense to your organization to incentivize the SOC – carrots better than sticks>