От сигнали до собственост: Защо моделите за сигурност на управляваните услуги се провалят при реални инциденти

От аларми към отговорност
Защо моделите за сигурност на MSP се разпадат при реални инциденти

Повечето модели за сигурност при MSP не се разпадат по време на разговори за продажби. Те се разпадат по време на реални инциденти.

Не защото инструментите се провалят.
А защото отговорността става неясна.

При нормална работа алармите изглеждат управляеми. Таблата показват зелено, генерират се отчети.

Под напрежение обаче се разкрива реалната структура на модела на предоставяне на услугата.

Алармата не е реакция

Много предложения за сигурност от MSP са изградени около препращане на аларми.

Инструмент открива нещо.
Генерира се аларма.
Изпраща се имейл.
Отваря се тикет.

На хартия има откриване на заплахи.

Но при активен инцидент се появяват нови въпроси:

• Кой взема решения за ограничаване на инцидента?

• Кой има правомощия да изолира системи?

• Кой комуникира с клиента?

• Кой носи отговорност, ако щетите се разпространят?

Алармата е сигнал.
Тя не е контрол.

Когато моделът на сигурност е структуриран около уведомяване, а не около правомощия за реакция, ескалацията се превръща в объркване.

Къде изчезва отговорността

В разпокъсани модели отговорността често се размива между няколко слоя:

• доставчикът на инструмента осигурява откриване

• MSP препраща алармите

• бекенд SOC извършва разследване

• клиентът очаква действие

Всяка страна предполага, че някой друг носи отговорността за решаващата стъпка.

Под напрежението на инцидент това води до:

• забавено ограничаване на атаката

• дублиране на действия

• неясна комуникация

• фрустрация на ръководството

От гледна точка на клиента това изглежда като хаос. Дори когато няколко услуги по сигурност са активни.

Не защото никой не работи.
А защото никой не контролира ситуацията ясно.

Защо дори MDR модели могат да изглеждат фрагментирани

Наличието на MDR не решава автоматично проблема с отговорността.

Ако оперативният модел не е ясен:

• Има ли MDR доставчикът право да изолира активи?

• MSP трябва ли да одобрява всяка стъпка за ограничаване?

• Кой комуникира навън?

• Кой документира окончателните решения?

Ако тези граници не са дефинирани преди инцидент, те няма да се изяснят по време на него.

Оперативният стрес усилва структурната неяснота.

Илюзията за покритие

Много MSP вярват, че са решили проблема, след като внедрят 24/7 мониторинг.

Мониторингът е видимост.
Отговорността е правомощие.

Това не е едно и също.

Може да наблюдаваш непрекъснато и пак да се колебаеш при ограничаване на атака.
Може да откриеш заплахата рано и пак да ескалираш твърде късно.

Инцидентите не тестват първо откриването.
Те тестват яснотата на вземането на решения.

Как изглежда контролиран модел

При зрели оперативни модели за сигурност:

• правомощията за реакция са дефинирани предварително

• ескалационните пътища са документирани и упражнявани

• отговорността за комуникацията е ясна

• праговете за ограничаване са предварително съгласувани

• документацията е част от процеса, а не добавена след това

В такива модели инцидентите изглеждат структурирани. Дори когато са сериозни.

Не защото са лесни.
А защото някой ясно носи отговорност.

Разликата не е в инструментите.
Тя е в дизайна на оперативния модел.

Защо това е важно сега

С нарастването на регулаторните изисквания и очакванията на клиентите, въпросът за отговорността при реакция става все по-видим.

Одиторите питат:

• Кой реагира?

• Колко бързо?

• Под чие правомощие?

Клиентите питат:

Кой контролира ситуацията?

Ако MSP не може да отговори ясно на този въпрос, доверието се губи по-бързо, отколкото се провалят системите.

Структурният въпрос пред MSP

Истинската промяна не е от инструменти към по-добри инструменти.

Тя е от аларми към отговорност.

От уведомяване към правомощия.
От мониторинг към контрол.
От покритие към отчетност.

MSP, които изградят оперативния си модел около ясна отговорност преди да започнат да растат, обикновено мащабират спокойно.

Тези, които отлагат, често преживяват инцидентите като структурен стрес тест.

Финална перспектива

Моделите за сигурност рядко се сриват тихо. Те се разпукват под напрежение.

Разликата между хаос и контрол по време на инцидент е дали някой ясно носи отговорност и има правомощия да действа.

Това е преходът от аларми към отговорност.

Вижте MDR в практика

В нашия демо уебинар „MDR 360° in Practice“, проведен съвместно с Acronis, показахме как бекенд SOC операциите могат да помогнат на MSP да мащабират услугите си, без да създават оперативен хаос.