100% found this document useful (4 votes)
2K views13 pages

SOC SLA Template v1 Idc2bp

This document outlines the services and responsibilities for a Security Operations Center (SOC) service level agreement (SLA) between a company and an outsourcing partner or internal department. Key services include log monitoring, security incident management, vulnerability scanning, and security configuration management. The SLA defines roles for individuals managing the SOC services, incidents, and changes from both the company and outsourcing partner perspectives. It also addresses how SLA failures will be handled.

Uploaded by

damola2real
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
100% found this document useful (4 votes)
2K views13 pages

SOC SLA Template v1 Idc2bp

This document outlines the services and responsibilities for a Security Operations Center (SOC) service level agreement (SLA) between a company and an outsourcing partner or internal department. Key services include log monitoring, security incident management, vulnerability scanning, and security configuration management. The SLA defines roles for individuals managing the SOC services, incidents, and changes from both the company and outsourcing partner perspectives. It also addresses how SLA failures will be handled.

Uploaded by

damola2real
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

<Company Name>

SLA for SOC


Provided by <Outsourcing partner name or Internal department name>

<throughout this document <text> indicates something you must change in this template. But
feel free to change anything.
Table of Contents (draft)

1 Document information and history........................................................................... 3


1.1 Version
history....................................................................................................................................... 3
1.2
Distribution...........................................................................................................................
................. 3
1.3 Document
structure.............................................................................................................................. 3
3 Introduction............................................................................................................... 4
4 General........................................................................................................................ 4
4.1 Purpose of this
document...................................................................................................................... 4
4.2 Goals for this
document........................................................................................................................ 4
4.3 Management commitment to information
security.............................................................................. 4
4.4 Scope and target
audience...................................................................................................................... 5
5 Responsibility and formal organization.................................................................... 5
5.1 Conflicting tasks and
responsibilities..................................................................................................... 6
6 Incident Management.................................................................................................. 7
6.1 Incident
Management............................................................................................................................. 7
7 Enterprise Threat modeling........................................................................................ 7
8 Enterprise Risk Management....................................................................................... 7
8.1 Application
Security............................................................................................................................... 8
8.2 Data
Classification.................................................................................................................................
8
8.3 System/Business Application/Infrastructure
Prioritization................................................................. 8
8.4 Business Continuity & Business Recovery
Planning............................................................................... 8
8.5 Continuous
improvement....................................................................................................................... 8
9 Outsourcing and Vendor Management...................................................................... 9
9.1
Policy...................................................................................................................................
................... 9
9.2
Specifics..............................................................................................................................
..................... 9
9.2.1 Outsourcing activities that are not
significant........................................................................... 9
9.2.2 Outsourcing activities that are
significant................................................................................. 9
9.2.3 Outsourcing partner selection and contractual
negotiations................................................... 9
9.2.4 The outsourcing
decision............................................................................................................. 9
10 Empowerment....................................................................................................... 10
11 Definitions and abbreviations.............................................................................. 10
Current Table of Contents
1 Document information and history 5
1.1 Version history 5
1.2 Distribution 5

2 Introduction 6

3 General 6
3.1 Purpose of this document 6

4 Responsibility and formal organization 6


4.1 Conflicting tasks and responsibilities 7

5 Services to be delivered by the SOC 7


5.1 Log monitoring via SIEM 8
5.2 Development and maintenance of SIEM use cases using Threat Modelling 8
5.3 Security device configuration and management 9
5.4 DDoS mitigation 10
5.5 Security Assessment – vulnerability scanning and assessment 10
5.6 Configuration Management 11
5.7 Change Management 11
5.8 Incident management 12
5.9 Forensics and Incident response including malware reversing and analysis 13

6 Handling SLA level failures 13


1 Document information and history

1.1 Version history

Versio Change Approval date Changes and Document Edit


n Date description Tracking

x.x xx.xx.xxxx Not yet Draft version 0.1 <name>


approved

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

<corporate function 1>

<corporate function 2>

<corporate function x>


Specification of third parties to whom distribution of approved versions of this document has
been authorized.
Company & Function

<third party vendor and function 1>

<third party vendor and function 2>

<third party vendor and function x>

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.

4 Responsibility and formal organization


Individuals can perform more than one of the below roles when required.
The following roles need to be appointed within the contracter and the contracted of this SLA:
1. SOC team lead.
a. Responsible for managing the SOC services and reporting to the contracter
2. SOC analysts
a. Responsible for delivering the SOC services to the contracter
3. Incident Manager, contracted
a. Can be the SOC team lead. Manages incidents and escalation of incidents
when required (when manual handling of incidents is needed). Responsible
for communicating to contracted Incident Manager
4. Incident Manager, contracter
a. Responsible for communicating with the contracted and coordinating when
Incidents that need manual handling occur
5. Contract holder, contracted
a. Responsible for the contract at the contracted, document owner. Responsible
for arranging periodic status meetings
6. Contract holder, contracter
a. Responsible for monitoring SOC service delivery and following up.
Responsible for communicating status of SOC services internally at
contracter
7. Change Manager, contracted
a. Responsible for coordinating delivery of services during change management
situations both internally and with contracter
8. Change Manager, contracter
a. Responsible for communicating with contracted when implementation of
changes are required
9. Contract <Approver body>
a. Responsible for the budget behind the contract/SLA

4.1 Conflicting tasks and responsibilities


Assigning conflicting tasks and responsibilities must be avoided when possible.

5 Services to be delivered by the SOC


<Remove any of the services listed below that your SOC does not supply>
5.1 Log monitoring via SIEM

Log management via SIEM includes:

· Ensuring the comprehensiveness of logs added continuously to the SIEM


· Ensuring the uninterrupted addition of logs to the SIEM including end point agent
services

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.

SLA Metrics for reporting:


Average number of days between a new log source becomes operational (term defined as:
From date when contracted has been informed of a new log source being active for collection)
and logfiles are continuously added to the SIEM. The average number of days must be: 0.
Recently added systems have higher risks especially if Internet facing. The number must be
listed per month and reported monthly via email.

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.

SLA Metrics for reporting


The number of minutes total that unique systems were not transmitting logfiles, service windows
not included.
The average number of minutes without service for all devices.
The total number of minutes the SIEM was not actively receiving log files.

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.

5.2 Development and maintenance of SIEM use cases


using Threat Modelling
Contracted must develop and maintain a sufficient number of use cases to detect threats. The
use cases must enable detection of both outsider attacks and internal insider threats.
The number of use cases must be as a minimum <20> for priority 1 assets and <10> for lower
priority systems and the use cases must be optimized per asset type for optimal threat
detection. To ensure that uses cases comply with realistic threat vectors, threat modelling must
be performed and maintained for all assets and established use cases mapped to threat
models. Each established threat model must specify the number of use cases needed to
monitor the threat.

SLA Metrics for reporting


Number of assets that do not have minimum the required number of use cases
Number threat models in total per asset that do not have the required number of SIEM use
cases associated with it

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.

5.3 Security device configuration and management


All security devices must be correctly configured and managed. This includes:

· 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.

SLA Metrics for reporting

1. Number of initial configuration audits performed monthly, indicating audits passed


successfully and failed. The number of failed audits must be less than 1 out of three, seen
over a period of 6 months rolling
2. Number of days per device that signature updates were not received. The number must
be less than 1 day out 10 per device.
3. Number of assets for which new firmware or software versions, including availability
date, exist but no change request has been raised by contracted for this update to be
performed. The number must be less than 1 out 10 and lack of awareness of the availability
of a firmware or software update must be retroactively corrected the following month if this
happens.

The numbers must be listed per month and reported monthly via email. Rolling numbers must
also be reported monthly via email.

5.4 DDoS mitigation


For on-demand DDoS mitigation:

SLA Metrics for reporting


· The number of minutes from the detection of an attack until mitigation was active, per
attack.
· for on-demand DDoS attacks that required extra mitigation to nullify: The number of
minutes from initial mitigations were active until extra mitigations became active, per attack

For always-on DDoS mitigation:


For attacks too large to handle:
· The number of minutes until extra mitigations became active, per attack

The numbers must be listed per month and reported monthly via email listing attack dates, times
on/off and targets.

5.5 Security Assessment – vulnerability scanning and


assessment
Vulnerability scanning must be performed <daily|weekly|monthly> and results must be manually
assessed by competent resources. The results must be communicated to contracter
<daily|weekly|monthly> with impact assessments and remediation advice

SLA Metrics for reporting


1. Vulnerability scan dates and accompanying report dates. Reports must go out less than
<1|2|3> days after a scan has been completed.
2. Scans must take place with the agreed intervals 9 out of 10 times over 6 months rolling
reporting periods.
3. Reports must be completed and sent off within the agreed amount of days 9 out 10
times on average over 6 months rolling reporting periods
4. For critical or high severity vulnerabilities, manual incident handling must be performed.
Reporting must include the number of high or critical vulnerabilities identified, dates
identified, and manual incident handling initiation dates. High or critical impact vulnerabilities
identified must always be reported manually within 24 hours via telephone.

5.6 Configuration Management


Configuration Management means ensuring that the CMDB always contains up to date and
accurate information about all assets and software installed per asset. This means updating the
CMDB during change management and incident management as well.

SLA Metrics for reporting

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.

5.7 Change Management

Change management means handling changes in coordination between contracter and


contracted. Contracted must initiate change requests when new firmware or software updates
are available or when incident management situations require so.

Change Management processes must follow the official change management policy and
contracted will be measured on adherence to this.

SLA Metrics for reporting


1. The number of days for contracted to confirm receipt of a change request or change
notification. The number of days should be less than <1> for priority 1 changes, less than
<3> for priority 2 changes and less than <5> for priority 3 changes.
2. Contracted must work interactively with contracter on change management, which
means that deliverables from contracted regarding a change must always be delivered
within <1 day> for priority 1 changes, less than <3 days> for priority 2 changes and less than
<5 days> for priority 3 changes, given no errors or delays from the side of contracter
The numbers must be listed as changes per month, initiating party, receipt confirmation date,
deliverables delivered date, change priority and reported monthly via email. The numbers
should be maintained as rolling numbers for 6 months rolling.

5.8 Incident management


Incident Management includes:

· Creating, updating and closing incidents


· Escalating incidents manually when required
· Automatic escalation for incidents that do not get solved within the defined
resolution time frames
· Following up on alerts, determining whether or not an alert is a false positive and
updating Incident Management databases with this information
· For alerts that are not false positives, incident management requires a follow up to
verify if an affected system was vulnerable to a potential payload delivered, plus
remediation (in coordination with contracter) if a system was infected
· Major incidents need to be actively managed through their entire lifecycle

SLA Metrics for reporting

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.

5.9 Forensics and Incident response including malware


reversing and analysis
For major incidents, the SOC will handle forensics and incident response. This can also mean
reversing and analysing malware.

SLA Metrics for reporting


1. The number of forensics investigations performed and results

6 Handling SLA level failures


<When the contracted does not live up to agreed SLA levels, fines or consequences must be
agreed upon

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>

You might also like