Надзор върху доставчик на MDR услуги за NIS2, DORA и GDPR

В 02:13 в понеделник сутрин доставчикът на MDR услуги отваря сигнал с висока критичност: невъзможно пътуване, подозрителни правила в пощенска кутия и привилегирован акаунт, използван от неуправлявана крайна точка. SOC анализаторът ескалира през системата за тикети. Вашият ИТ ръководител спи. Финансовият директор получава фишинг предупреждение от банков контакт, преди вътрешният канал за инциденти да се активира. Към 07:30 CISO е изправен пред три неудобни въпроса.

Кой имаше правомощия да обяви инцидент?

Можем ли да докажем, че доставчикът на MDR услуги е разполагал с правилните журнали, съхранявал ги е достатъчно дълго и е запазил доказателствата?

Ако е осъществен достъп до лични данни, може ли правният екип да спази сроковете за оценка на нарушение по GDPR, докато оперативният екип подготвя докладване по NIS2 или DORA?

Месец по-късно външният одитор иска същите доказателства, но с различен тон. PDF докладът на доставчика на MDR услуги е полезен, но не е достатъчен. Одиторът иска сурови данни от сигналите, пълни журнални файлове, проследимост на ескалацията, вътрешния журнал на решенията, записа от прегледа на доставчика и доказателство, че организацията е могла независимо да провери какво се е случило.

Това е проблемът с надзора върху доставчиците на MDR услуги през 2026 г. Организациите възлагат откриването и реагирането на външни доставчици, защото вътрешният SOC капацитет е скъп, наемането е трудно, а активността на заплахите е непрекъсната. Но външно възложеното откриване не означава външно възложена отчетност. Съгласно NIS2 управителните органи остават отговорни за одобряването и надзора на мерките за управление на риска за киберсигурността. Съгласно DORA финансовите субекти остават изцяло отговорни за ИКТ риска от трети страни, включително критични ИКТ услуги, съдействие при инциденти, права на одит, подизпълнители и изход. Съгласно GDPR администраторите трябва да докажат подходяща сигурност на обработването, особено когато обработващи лица боравят с телеметрия, данни от крайни точки, потребителски идентификатори, IP адреси, съдържание на електронна поща, журнали или форензични образи.

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

Защитима програма за надзор върху доставчик на MDR услуги изисква един оперативен модел, който покрива няколко одитни разговора. ISO/IEC 27001:2022 предоставя тази основа.

Надзорът върху MDR започва с отчетност, а не със SOC конзолата

Честа грешка е въвеждането на MDR да се третира като технически проект: внедряване на EDR агенти, препращане на журнали за идентичности, конфигуриране на сигнали, договаряне на канал в Teams или Slack и въвеждане в експлоатация. Това може да подобри откриването, но не доказва управление.

NIS2 прави проблема изричен. Съществените и важните субекти трябва да прилагат подходящи и пропорционални технически, оперативни и организационни мерки за управление на риска за киберсигурността. Article 21 включва анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, киберхигиена, контрол на достъпа, управление на активите, криптография и многофакторно удостоверяване. Article 20 издига това до отчетност на управителния орган, като изисква одобряване и надзор на тези мерки.

Доставчиците на MDR услуги често попадат едновременно в няколко области по NIS2 Article 21:

• Обработване на инциденти, защото доставчикът извършва триаж, ескалира и може да препоръча ограничаване.
• Сигурност на веригата на доставки, защото доставчикът е директен доставчик на услуги с оперативно въздействие върху сигурността.
• Контрол на достъпа, защото доставчикът може да има достъп до конзоли, журнали, инструменти за крайни точки или облачни tenant-и.
• Журналиране и мониторинг, защото откриването зависи от покритието, съхранението и корелацията на журналите.
• Киберхигиена, защото MDR констатациите често разкриват слабости при прилагане на корекции, идентичности или конфигурации.
• Непрекъсваемост на дейността, защото забавената реакция може да наруши критични услуги.

За финансовите субекти DORA прави оперативния модел още по-строг. DORA се прилага от 17 януари 2025 г. и изисква управление на ИКТ риска, докладване на инциденти, тестване на устойчивостта, споделяне на информация и управление на ИКТ риска от трети страни. Той също така уточнява, че за финансови субекти, които са идентифицирани и по NIS2, DORA действа като секторният правен акт на Съюза за припокриващите се задължения за киберсигурност. Регулирана банка, платежна институция, инвестиционен посредник, застраховател или доставчик на услуги за криптоактиви не може просто да каже: „Нашият доставчик на MDR услуги се грижи за това.“ DORA очаква субектът да класифицира ИКТ инциденти, да управлява и наблюдава ИКТ доставчици от трети страни, да поддържа регистри на договореностите за ИКТ услуги, да определя договорни права, да тества устойчивостта, да извършва анализ на първопричините и да докладва съществени инциденти, свързани с ИКТ, поетапно.

GDPR добавя различна перспектива. Ако MDR телеметрията включва потребителски идентификатори, IP адреси, метаданни на електронна поща, записи за автентикация, артефакти от крайни точки или файлове, съдържащи лични данни, се прилагат принципите на GDPR за сигурност и отчетност. Article 5 включва целостта, поверителността и отчетността. Article 32 относно сигурността на обработването става практически въпрос за доказателства: защитени ли са журналите, ограничен ли е достъпът, използвано ли е шифроване, когато е уместно, управлявани ли са обработващите лица и може ли организацията да докаже какво се е случило?

Посланието е последователно и в трите режима: можете да делегирате работата, но не можете да делегирате отговорността.

ISO/IEC 27001:2022 превръща MDR в процес, подлежащ на одит

Добре внедрена система за управление на информационната сигурност, базирана на ISO/IEC 27001:2022, превръща надзора върху доставчик на MDR услуги от обещание в управлението на доставчици в оперативен модел, основан на доказателства. Клауза 8.1 е особено важна, защото изисква организациите да контролират външно предоставени процеси, продукти и услуги, които са относими към СУИС. MDR е точно това: външно предоставен процес, който може да засегне реагирането при инциденти, поверителността, устойчивостта, регулаторното докладване и непрекъсваемостта на дейността.

Най-важните области от Annex A на ISO/IEC 27001:2022 за надзор върху MDR включват взаимоотношения с доставчици, изисквания за сигурност в споразумения с доставчици, управление на риска във веригата за доставки на ИКТ, мониторинг на услугите на доставчици, управление на инциденти, обработване на доказателства, журналиране, мониторинг, контрол на достъпа, привилегирован достъп, криптография и готовност за непрекъсваемост на дейността.

Zenith Controls: The Cross-Compliance Guide на Clarysec Zenith Controls е референтният материал за кръстосано съответствие за тази работа. Той съпоставя контролите по ISO/IEC 27002:2022 с други изисквания, свързани контроли, одитни очаквания и доказателства за внедряване. За надзор върху MDR три контрола по ISO/IEC 27002:2022 са централни: 5.19 за взаимоотношения с доставчици, 5.22 за мониторинг на услугите на доставчици и управление на промените, и 8.15 за журналиране. Те се подкрепят от 5.20 споразумения с доставчици, 5.21 сигурност на веригата за доставки на ИКТ, 5.24 до 5.28 управление на инциденти и обработване на доказателства, 5.34 защита на личните данни и лично идентифициращата информация (PII), 5.36 съответствие, 8.16 дейности по мониторинг, 8.17 синхронизация на системния часовник, 8.18 използване на привилегировани помощни програми и 8.8 управление на технически уязвимости.

Това е важно, защото провалът при MDR одит рядко гласи „няма MDR“. Обикновено гласи едно от следните:

• Доставчикът на MDR услуги не е класифициран като критичен.
• Договорните клаузи не включват уведомяване за инциденти, достъп до доказателства или права на одит.
• Журналите не са съхранявани достатъчно дълго за разследване на докладвано събитие.
• Достъпът на доставчика е бил споделен, постоянен или ненаблюдаван.
• Клиентът не е преглеждал изпълнението на MDR спрямо SLA.
• Подизпълнителите или подизпълнителите по обработване не са одобрени.
• Задълженията за уведомяване при нарушение на сигурността на личните данни не са съгласувани с работните потоци за инциденти.
• Доказателствата не са запазени по форензично полезен начин.
• Ръководството няма показатели, които показват дали MDR услугата намалява риска.

Zenith Controls ясно формулира връзката между очакванията към доставчиците и споразуменията:

„5.19 определя очакванията за сигурност относно начина, по който доставчиците трябва да боравят с информация на организацията. 5.20 формализира тези очаквания, като гарантира, че договорите или споразуменията изрично включват клаузи за сигурност, като изисквания за поверителност, спазване на политики за сигурност и процедури за уведомяване при инциденти. Без 5.20 изискванията, идентифицирани в 5.19, може да не са правно приложими.“

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

Какво трябва да докаже договорът за MDR преди първия сигнал

Добрият договор за MDR не е само търговска поръчка. Той е контролен документ. DORA Articles 28 to 30 изискват ИКТ рискът от трети страни да се управлява през целия жизнен цикъл, включително регистри на ИКТ договори, класификация по критичност, надлежна проверка преди сключване на договор, подходи за одит и инспекция, права за прекратяване, стратегии за изход, ясни описания на услугите, нива на обслужване, местоположения на услугата и обработването на данни, ангажименти за защита на данните, съдействие при инциденти и сътрудничество с органите. NIS2 Article 21 изисква сигурност на веригата на доставки за преки доставчици и доставчици на услуги. GDPR изисква роли на администратор и обработващ, гаранции от обработващия, клаузи за защита на данните и доказателства за сигурност на обработването.

Библиотеката с политики на Clarysec превежда тези задължения в практически договорни и оперативни изисквания. В Enterprise Incident Response Policy Политика за реагиране при инциденти MDR изрично се третира като управлявана способност на трета страна за реагиране при инциденти:

„Интеграцията с услуги на трети страни, включително Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) и доставчици на форензичен анализ, трябва да се управлява чрез ясно определени споразумения за ниво на обслужване (SLA) и клаузи за неразкриване.“

Тази клауза е важна, защото доставчиците на MDR услуги често получават силно чувствителна информация, преди организацията да знае дали инцидентът подлежи на докладване. Телеметрията може да включва потребителски имена, файлови пътища, теми на имейли, вътрешни имена на хостове, IP адреси, мрежови схеми и индикатори за компрометиране. Клаузите за неразкриване защитават организацията по време на разследване и подкрепят отчетността по GDPR.

Enterprise Third party and supplier security policy Политика за сигурност на трети страни и доставчици добавя две клаузи, които одиторите очакват да видят при преглед на надзора върху MDR:

„Права на одит, инспекция и искане на доказателства за сигурност“

и:

„Използването на подизпълнители подлежи на предварително писмено съгласие“

За МСП същият управленски принцип се мащабира надолу, но не отпада. Third-Party and Supplier Security Policy - SME Политика за сигурност на трети страни и доставчици - МСП изисква минимално необходим достъп:

„На доставчиците трябва да се предоставя достъп само до минималните системи и данни, необходими за изпълнение на тяхната функция.“

Тя също изисква:

„Ограничения върху последващо възлагане на подизпълнители без одобрение“

Тези клаузи са особено релевантни за MDR. Много доставчици използват многостепенни SOC екипи, доставчици на платформи, партньори за разузнаване за заплахи, облачни аналитични услуги или регионален персонал за поддръжка. Ако последващи страни могат да имат достъп до клиентски журнали или лични данни, клиентът се нуждае от механизми за видимост и одобрение. В термините на DORA това е част от надзора върху подизпълнителите и риска от концентрация. В термините на GDPR това е управление на подизпълнителите по обработване. В термините на NIS2 това е управление на риска във веригата на доставки.

Основен контролен списък за надзор върху MDR

Защитимото взаимоотношение с доставчик на MDR услуги трябва да може да бъде тествано. Следният контролен списък обединява договорните, оперативните и доказателствените изисквания в един контролен изглед.

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

Седем области на доказателства, които одиторите очакват

За да бъде надзорът върху MDR готов за одит, Clarysec препоръчва изграждане на MDR досие с доказателства, организирано в седем области. Това досие трябва да бъде част от СУИС, а не папка в отдел „Закупуване“, която никой не преглежда.

Тази таблица променя разговора с доставчика. Вместо да пита „Наблюдавате ли ни?“, организацията пита: „Можем ли всеки тримесечен период да докажем, че MDR услугата остава ефективна, съответстваща и съгласувана с нашия апетит към риск?“

Журналирането е мостът между откриването и доказателствата за съответствие

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

Контрол 8.15 от ISO/IEC 27002:2022 обхваща журналирането. Zenith Controls класифицира журналирането като детективен контрол, който подкрепя поверителност, цялостност и наличност, съгласуван с концепцията Detect за киберсигурност и способността за управление на събития по информационна сигурност. Той свързва журналирането пряко с дейности по мониторинг, оценка на събития, реагиране при инциденти, извлечени поуки, привилегирован достъп, синхронизация на системния часовник, контрол на достъпа, поверителност, събиране на доказателства, управление на уязвимости и мониторинг на физическата сигурност.

Затова журналирането е централно за доказателства по NIS2, DORA и GDPR Article 32. Докладването по NIS2 Article 23 за значителни инциденти изисква ранно предупреждение в рамките на 24 часа от узнаването, уведомяване в рамките на 72 часа и окончателен доклад не по-късно от един месец след уведомяването. Докладването на съществени инциденти, свързани с ИКТ, по DORA изисква класификация, ескалация, комуникация, анализ на първопричините и окончателно докладване. Отчетността по GDPR изисква организациите да докажат какво се е случило с личните данни и дали мерките за сигурност са били подходящи.

Logging and Monitoring Policy - SME на Clarysec Политика за журналиране и мониторинг - МСП предоставя прост договорен контрол за по-малки организации, използващи външни доставчици:

„Договорите трябва да изискват от доставчиците да съхраняват журнали поне 12 месеца и да предоставят достъп при поискване“

За корпоративни среди Logging and Monitoring Policy Политика за журналиране и мониторинг добавя изискването за оперативна интеграция:

„Трябва да предоставя журнални данни при поискване или да се интегрира със SIEM/платформата за агрегиране на журнали на организацията.“

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

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

Поддържащите ISO стандарти подсилват този подход. ISO/IEC 27035-1:2023 и ISO/IEC 27035-2:2023 свързват журналирането с откриване на инциденти, триаж и централизиран анализ. ISO/IEC 27701:2021 добавя специфично за поверителността журналиране на дейности по обработване на лично идентифицираща информация (PII). ISO/IEC 27017:2021 и ISO/IEC 27018:2020 добавят очаквания за журналиране в облак и журналиране на PII в облак, особено когато доставчиците обработват клиентски данни в публични облачни среди. ISO/IEC 27005:2024 разглежда недостатъчното журналиране като въпрос на третиране на риска, а не просто като пропуск в инструментариума.

Реагиране при инциденти: MDR може да ескалира, но ръководството трябва да реши

Доставчиците на MDR услуги откриват и консултират. Отчетната организация обявява инциденти, оценява регулаторното въздействие, комуникира с органите и решава дали е необходимо уведомяване за нарушение на сигурността на личните данни.

Това разграничение е важно, защото критичността по MDR не е автоматично равна на значителен инцидент по NIS2, съществен инцидент, свързан с ИКТ, по DORA или нарушение на сигурността на личните данни по GDPR. Доставчикът може да обозначи сигнал като „с висока критичност“, но организацията трябва да реши дали са засегнати критични услуги, дали лични данни са компрометирани, дали клиентите трябва да бъдат уведомени, дали регулаторите трябва да бъдат информирани и дали ръководството трябва да одобри действие по ограничаване с оперативно въздействие.

Incident Response Policy - SME на Clarysec Политика за реагиране при инциденти - МСП е директна:

„Третите страни трябва да действат в съответствие с подписаните споразумения, които трябва да включват клаузи за уведомяване при нарушение на сигурността на личните данни и задължения за съдействие при реагиране.“

Тази клауза е мястото, където доказателствата по GDPR Article 32 се срещат с оперативното реагиране при инциденти. Ако доставчикът на MDR услуги наблюдава предполагаемо извличане на данни от крайна точка, съдържаща лични данни, той трябва да знае колко бързо да уведоми, кого да уведоми, какви доказателства да запази и как да подпомогне оценката на администратора.

Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec Zenith Blueprint дава метода за тестване. Във фазата Controls in Action, Step 19, Zenith Blueprint инструктира екипите да валидират журналирането и мониторинга оперативно:

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

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

„За привилегировани акаунти проверете, че MFA се прилага, администраторските роли са разделени (акаунти в стил admin_john се използват само за администраторски задачи) и съществува актуален списък на привилегированите потребители.“

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

Step 23 от Zenith Blueprint след това дава структурата за тестване на инциденти и доставчици:

„Изберете скорошно събитие или проведете tabletop упражнение, за да валидирате плана си. Запишете и журналирайте всички решения, роли и комуникации (5.26) и актуализирайте плана с извлечени поуки (5.27). Потвърдете, че има процедури за запазване на форензични доказателства (5.28), включително снимки на журнали, резервни копия и сигурна изолация на засегнатите системи.“

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

Изградете MDR пакет за надзор за един сигнал за 90 минути

Бърз начин да се разкрият пропуски е да се избере един скорошен MDR сигнал с висока критичност и да се изгради едностранична доказателствена следа. Това практическо упражнение работи добре преди одити, прегледи от съвета и подновяване на договори.

1. Започнете с тикета за сигнала. Запишете времеви маркер, правило за откриване, засегнат актив, потребител, критичност, бележки на MDR анализатора и път за ескалация.
2. Извадете договорната клауза или SLA, който показва очакваното време за реакция за тази критичност.
3. Извлечете списъка с източници на журнали, който доказва кои системи са захранили сигнала, като EDR, доставчик на идентичност, защитна стена, шлюз за сигурност на електронната поща и облачни одитни журнали.
4. Потвърдете, че журналите се съхраняват съгласно политиката и че историческото събитие все още може да бъде извлечено.
5. Проверете дали MDR анализаторът е имал достъп до клиентска среда. Ако да, запишете именувания акаунт, доказателствата за MFA, журналите на сесията и одобрението.
6. Документирайте решението от страна на клиента: събитието е затворено, обявен е инцидент, задействана е правна оценка, извършено е ограничаване или е приет риск.
7. Ако може да са засегнати лични данни, запишете анализа на ролите по GDPR, собственика на оценката на нарушението и дали са задействани задължения за уведомяване от обработващия.
8. Завършете с извлечени поуки: настройка, ново откриване, промяна в достъпа, актуализация на playbook или проблем със SLA на доставчика.

Тази следа за един сигнал е силна, защото свързва договор, журналиране, достъп, реагиране при инциденти, поверителност и управленски надзор в една верига от доказателства. Ако не можете да я изградите за скорошен сигнал, вероятно няма да можете да я изградите под регулаторен натиск.

Мониторингът на доставчиците е мястото, където повечето MDR програми отслабват

Много организации извършват надлежна проверка преди подписване на договор за MDR и след това спират. Това не е достатъчно за ISO/IEC 27001:2022, NIS2, DORA или GDPR. MDR услугите се променят непрекъснато: нови правила за откриване, нови екипи от анализатори, нови подизпълнители по обработване, нови региони за данни, нови EDR възможности, нови интеграции, нови потоци от разузнаване за заплахи и нови модели за поддръжка.

Контрол 5.22 от ISO/IEC 27002:2022 разглежда мониторинга, прегледа и управлението на промените в услугите на доставчици. Zenith Controls обяснява, че 5.22 надгражда контролите за взаимоотношения и споразумения с доставчици, като осигурява непрекъснат мониторинг и управление след стартиране на услугата. Той се свързва със сигурност по време на прекъсване, управление на уязвимости, съответствие, контрол на достъпа и сигурно инженерство.

DORA Articles 28 to 30 правят това особено важно за финансовите субекти. Те изискват текущ мониторинг, регистри на договореностите с ИКТ трети страни, разграничения по критичност, надлежна проверка, права на одит и инспекция, права за прекратяване, стратегии за изход, нива на обслужване, съдействие при инциденти, сътрудничество с органите и, за критични или важни функции, цели за услугата, тестване на планове при извънредни ситуации и сътрудничество при тестове за проникване, водени от разузнаване за заплахи, когато е приложимо.

Zenith Blueprint, във фазата Controls in Action, Step 23, предоставя структурата на жизнения цикъл на доставчиците:

„Съставете пълен списък на текущите доставчици и доставчици на услуги (5.19) и ги класифицирайте въз основа на достъпа до системи, данни или оперативен контрол.“

Продължава:

„За всеки критичен доставчик идентифицирайте дали използва подизпълнители (подизпълнители по обработване), които могат да имат достъп до вашите данни или системи.“

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

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

Съпоставяне за кръстосано съответствие: един набор MDR контроли, пет одитни разговора

Стойността на ISO/IEC 27001:2022 е, че дава на организациите един последователен цикъл на СУИС за множество разговори за съответствие. Същият MDR пакет от доказателства за надзор може да бъде съпоставен с NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.

NIST CSF 2.0 е полезен за комуникация. Неговата функция GOVERN изисква правните, регулаторните, договорните и свързаните с поверителността задължения да бъдат разбирани и управлявани, ролите и правомощията да бъдат определени, рискът за киберсигурността да бъде интегриран в корпоративното управление на риска, а рисковете, свързани с доставчици, да бъдат комуникирани и наблюдавани.

COBIT 2019 е полезен за управление и уверение. Одиторите, ориентирани към COBIT, често се фокусират по-малко върху един контрол и повече върху това дали управленските цели, управлението на услугите, собствеността върху риска и мониторингът на резултатността работят като система.

Как одиторите ще тестват надзора върху доставчик на MDR услуги

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

Одитор по ISO/IEC 27001:2022 ще започне с обхват, заинтересовани страни, оценка на риска, Декларация за приложимост, план за третиране на риска и оперативни доказателства. Ако MDR е в обхвата, одиторът ще очаква външно предоставените процеси да бъдат контролирани в рамките на СУИС. Той може да извади извадка от взаимоотношения с доставчици, споразумения с доставчици, мониторинг на услугите на доставчици, журналиране, мониторинг, реагиране при инциденти, обработване на доказателства и контрол на достъпа.

Надзорен орган по DORA ще се фокусира върху оперативната устойчивост и системния риск. Той може да разгледа задълбочено оценката на критичността, регистъра на ИКТ услуги, анализа на риска от концентрация, стратегията за изход, класификацията на инциденти, правата на одит и доказателствата, че доставчикът на MDR услуги може да подпомага регулаторно докладване.

Одитор по GDPR или специалист по поверителност ще се фокусира върху управлението на отношенията администратор-обработващ. Той ще поиска DPA, надлежна проверка на обработващия, контроли за подизпълнители по обработване, предпазни мерки за журнали, съдържащи лични данни, контроли за съхранение, записи от оценка на нарушение и доказателства в подкрепа на Article 32.

Одитор по COBIT или ISACA ще инспектира доказателства за управление: собственост върху риска, свързан с доставчици, работен поток по закупуване, протоколи от прегледи на услугите, проследяване на проблеми по SLA, коригиращи действия, качество на доказателствата и дали ръководството получава смислени показатели.

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

Докладване към ръководството: съветът не се нуждае от packet captures

NIS2 и DORA поставят отговорността на ниво управителен орган. Съветите и висшите ръководители не се нуждаят от сурова телеметрия. Те се нуждаят от показатели за надзор върху MDR, релевантни към риска.

Полезно тримесечно MDR информационно табло включва:

• Критични източници на журнали, въведени спрямо очакваните.
• Процент критични активи, покрити от MDR.
• Сигнали с висока критичност по категория и бизнес услуга.
• Средно време от откриване до уведомяване на клиента.
• Средно време от потвърждение от клиента до решение.
• Нарушения на SLA и нерешени действия на доставчика.
• Статус на прегледа на привилегированите акаунти на доставчика.
• Промени при подизпълнители или подизпълнители по обработване.
• Инциденти, изискващи правна, регулаторна или клиентска оценка за уведомяване.
• Внедрени извлечени поуки.

Това информационно табло трябва да захранва прегледа от ръководството на СУИС, актуализациите на третирането на риска и прегледа на доставчика. Съгласно ISO/IEC 27001:2022 ръководството трябва да гарантира, че СУИС е съгласувана със стратегическата посока, ресурсите са налични, отговорностите са възложени, комуникацията работи и се постига непрекъснато подобрение. MDR показателите са практически начин да се покаже, че външно възложените операции по сигурност се управляват от ръководството, а не са оставени на администраторите на инструменти.

Чести пропуски в надзора върху MDR, които трябва да се отстранят преди одитите през 2026 г.

Най-честите пропуски са обичайни управленски неизправности.

Първо, организациите забравят, че доставчиците на MDR услуги могат да обработват лични данни. Журналите за сигурност понякога се третират като „технически данни“, но могат да съдържат лични данни и понякога чувствително съдържание. Анализът на ролите по GDPR и клаузите за обработващи лица трябва да бъдат завършени преди въвеждането, а не по време на нарушение.

Второ, съхранението на журналите се приема за даденост, вместо да бъде договорено. Ако регулаторни, форензични или клиентски задължения изискват доказателства за месеци назад, моделът за съхранение на MDR и SIEM трябва да го поддържа. Изискването на политиката за МСП за 12-месечно съхранение на журналите от доставчика е практическа базова стойност за много среди.

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

Четвърто, праговете за инциденти са неясни. Критичността по MDR не е автоматично равна на правен инцидент, съществен инцидент, свързан с ИКТ, по DORA, значителен инцидент по NIS2 или нарушение на сигурността на личните данни по GDPR. Playbook-ът трябва да определя кой взема всяко решение.

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

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

Следващи стъпки: направете вашия доставчик на MDR услуги готов за одит с Clarysec

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

Clarysec може да ви помогне бързо да превърнете това в работещ процес чрез:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint за поетапно внедряване, включително Step 19 за валидация на журналиране, мониторинг и достъп, и Step 23 за контроли за управление на доставчици и инциденти.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls за съпоставяне на контролите 5.19, 5.22 и 8.15 по ISO/IEC 27002:2022 с одитните очаквания по NIS2, DORA, GDPR, NIST и COBIT.
• Шаблони за политики на Clarysec, включително Политика за реагиране при инциденти, Политика за сигурност на трети страни и доставчици, Политика за журналиране и мониторинг, Политика за реагиране при инциденти - МСП, Политика за сигурност на трети страни и доставчици - МСП, Политика за журналиране и мониторинг - МСП и Политика за защита на данните и поверителност - МСП.

MDR е една от най-ценните инвестиции в сигурност, които една организация може да направи. През 2026 г. тази стойност трябва да бъде доказана чрез управление, доказателства и отчетен надзор. Ако искате практически MDR пакет за надзор, съпоставен с ISO/IEC 27001:2022, NIS2, DORA и GDPR Article 32, Clarysec може да ви помогне да го изградите, преди следващият сигнал да се превърне в следващата одитна констатация.