Как да изберете SOC услуга и да прочетете нейното SLA

Започнете от нуждите и критичните услуги

Преди да сравнявате доставчици, определете какво трябва да защитава наблюдението. Избройте критичните приложения, системите за идентичност, крайните устройства, облачните акаунти и външните зависимости. Запишете кои услуги не могат да прекъсват, кой ги поддържа и какъв контекст е нужен, за да се оцени инцидент.

Потърсете празнините, които услугата трябва да запълни: нощно и празнично покритие, SIEM инженеринг, анализ на крайни устройства, работа с облачни сигнали или координация при инцидент. Точната нужда помага да се избегне плащане за функции, които не са свързани с приоритетите, и да се открият изключения, които биха били проблем.

SLA трябва да дава проверими обещания

Проверете дефинициите за време за потвърждение, анализ и уведомяване. Това са различни стъпки. Дали часовникът започва при генериране на аларма, при постъпване на лог или след като системата е потвърдила качеството на данните? Как се отчита събитие извън договорения обхват? Измеримото SLA описва началната точка, часовете на покритие, приоритетите, целевите времена и отчетността.

Уточнете ескалационните канали, резервните контакти и как се процедира, ако клиентът не отговори. Разгледайте дали SLA е цел или договорен ангажимент и какво следва при неизпълнение. Изяснете периодичността на отчетите, кои показатели се включват и дали доставчикът отчита пропуски в логването и прекъсванията на интеграциите.

Разпределете отговорностите и правата

Направете матрица кой настройва и поддържа източниците, кой одобрява нови правила, кой потвърждава бизнес въздействие и кой има право да ограничи система или акаунт. Изяснете кои действия са само препоръчителни, кои се извършват с потвърждение и кои са предварително разрешени. Добавете процес за промяна на контактите и за предаване на работа между дежурствата.

Питайте как се управляват данните: къде се съхраняват, кой има достъп, колко време се пазят и как се изнасят или изтриват при прекратяване. Проверете как се уведомявате при инцидент в самата платформа или при прекъсване на услугата. Ако има изисквания за местоположение на данните или обработка, те трябва да бъдат потвърдени в договорните и техническите документи.

Проверете с реалистичен сценарий

Поискайте да преминете през пример: сигнал се появява през нощта, засяга критично приложение, а първият контакт не отговаря. Кой вижда сигнала, каква информация изпраща доставчикът, кой е резервният контакт и какво може да се направи без изрично одобрение? Сценарият разкрива неясноти, които често остават скрити в общо описание на услугата.

Проверете дали доставчикът обяснява как ще изглеждат настройката, първите седмици и текущите промени. Поискайте пример за отчет, процес за коригиране на шумни правила и начин за предаване на инцидент. Реалистичното описание с ограничения е по-полезно от абсолютни обещания за спиране на всички атаки.

Решението трябва да отговаря на капацитета на вашата организация. Ако няма човек, който да получава и изпълнява ескалациите, само денонощното наблюдение няма да доведе до действие. Включете собствениците на системи и бизнес ръководителите при преглед на SLA, така че времевите цели и правомощията да са постижими.

Уточнете как услугата ще започне и как ще се промени. Кой проверява всяка интеграция след активиране? Има ли период за настройка на очакваната активност и как се различава той от договореното оперативно покритие? Как се оценява нов източник, когато организацията придобие компания или премести приложение в облака? Ако включването е „по заявка“, договорът трябва да обяснява сроковете и евентуалните разходи. Планирането на такива промени предотвратява пропуски между техническия проект и дежурния процес.