MSP Insights

Проблемът с правомощията при реакция на MSP

Защо да знаеш какво да направиш не означава, че можеш да го направиш

Системите за мониторинг в MSP среда се развиха значително.

Детекцията е по-бърза. Видимостта е по-широка. Алармите са по-точни. В много случаи екипите разбират какво се случва достатъчно рано. И въпреки това реакцията се забавя. Причината не е в липсата на яснота. А в липсата на право за действие.

Когато реакцията спира въпреки ясната ситуация

В процеса на реакция има моменти, в които следващата стъпка е очевидна. Устройство показва признаци на компрометиране. Потребителско поведение е необичайно. Налице са признаци за странично придвижване. Необходимото действие е ясно. Но не се изпълнява веднага. В този момент реакцията зависи от нещо извън техническия слой. Тя зависи от правомощията.

Пропускът в правото за действие

В много MSP модели детекцията и анализът са ясно дефинирани.

Действията не са.

Това създава разминаване между:

• това какво трябва да се направи
• възможността да бъде направено

Екипите често идентифицират правилното действие, но изчакват. Забавянето не идва от анализа, а от неяснотата кой има право да действа.

Защо се случва това

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

Сигурността се управлява от:

• SOC екипи
• MSP екипи
• представители на клиента

В момента на реакция това разпределение създава напрежение.

Появяват се въпроси:

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

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

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

Този проблем се проявява в реални ситуации:

• компрометирано устройство не се изолира веднага
• подозрителен достъп не се прекратява навреме
• ранни признаци на ransomware не водят до незабавна реакция

Във всички случаи сигналът е достатъчен. Забавянето идва от слоя на вземане на решения.

Правомощията не се подразбират

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

Така се създава модел, при който:

детекцията е бърза
реакцията е условна

Как се решава този проблем

Намаляването на забавянето изисква ясно дефиниране на правомощията предварително.

Това включва:

• предварително одобрени действия за конкретни сценарии
• ясно разпределение на решенията според критичност
• съобразяване с бизнес риска
• договорна яснота какви действия могат да се предприемат без одобрение

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

Позицията на DIAMATIX

В MSP среда реакцията не се забавя заради липса на видимост или технически възможности. Забавя се, защото правото за действие не е ясно дефинирано. В практиката виждаме, че детекцията и ескалацията често са добре структурирани, докато вземането на решения остава зависимо от координация между различни страни. Това води до колебание точно в момента, в който скоростта е най-важна.

В нашия подход правомощията са част от оперативния модел, а не предположение.

Това означава:

• предварително дефинирани действия според критичност
• ясно разпределение на отговорността за решения
• процеси, които не зависят от одобрение в реално време
• съобразяване на техническите действия с бизнес ефекта

Така реакцията преминава от анализ към действие без излишно забавяне, като същевременно се запазва контролът.

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

Определя се от това доколко последователно и уверено се предприемат действия

Заключение

Детекцията и ескалацията дават структура. Правомощията определят дали ще има действие навреме.

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

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

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

Гледайте запис от уебинара