ITDR стратегия за ISO 27001, NIS2, DORA и GDPR

В 3:00 ч. сутринта във вторник Сара, CISO на FinScale, се събуди от типа предупреждение, от който съвременните ръководители по сигурността се опасяват все по-често. Активна сесия на старши разработчик, удостоверена чрез MFA само няколко часа по-рано, се използваше от необичаен източник за изброяване на схеми в продукционна база данни.

Нямаше сигнал от зловреден софтуер. Нямаше бележка за ransomware. Нямаше експлойт срещу защитна стена. Само идентичност.

SOC засече дейността, но реакцията беше хаотична. Беше ли това заобикаляне на MFA, откраднат сесиен токен или компрометиране на самия доставчик на идентичност? Кой имаше правомощия да прекрати активната сесия? Достатъчно ли беше нулиране на паролата, или екипът трябваше да обезсили refresh токените, да ротира API удостоверителните данни и да прегледа OAuth разрешенията? Докато дейността беше ограничена, атакуващият беше активен 47 минути.

На следващата сутрин инцидентът по сигурността се превърна в управленски проблем. Управителният орган искаше ясно обяснение дали киберхигиената на FinScale се е провалила по NIS2. Екипът по съответствие искаше да знае дали събитието може да бъде класифицирано като съществен ИКТ инцидент по DORA. Правният екип се нуждаеше от правно обоснован отговор дали е осъществен достъп до лични данни по GDPR Article 32 и дали е необходима оценка на нарушение на сигурността на личните данни. Външният одитор попита дали контролите по ISO/IEC 27001:2022 работят ефективно, а не само дали са документирани в политики.

Проблемът на Сара не беше липса на инструменти. FinScale имаше доставчик на идентичност, MFA, SIEM, контроли за крайни точки, облачни журнали и процес за реагиране при инциденти. Проблемът беше, че управлението на идентичности, журнализирането, мониторингът, реагирането при инциденти, оценката на поверителността и обработването на доказателства работеха в отделни силози.

Това е проблемът на Identity Threat Detection and Response през 2026 г. ITDR вече не е само способност на операциите по сигурността. Той е междурегулаторен механизъм за доказателства за ISO/IEC 27001:2022, NIS2, DORA и GDPR Article 32.

Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec Zenith Blueprint, пакетът от политики и Zenith Controls: The Cross-Compliance Guide Zenith Controls помагат на организациите да превърнат атаките срещу идентичности от хаотични разследвания в повторяеми, одитируеми контролни процеси.

Защо Identity Threat Detection and Response вече е въпрос на ниво управителен орган

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

Това прави ITDR различен от традиционната защита на периметъра. Зрялата програма трябва да може да отговори на следните въпроси:

• Кои човешки, служебни, доставчически и приложни идентичности съществуват?
• Кои идентичности са привилегировани, неактивни, споделени или федеративно свързани с външни среди?
• Кои събития по автентикация са нормални, рискови или невъзможни?
• Кои OAuth разрешения, SaaS токени и API удостоверителни данни могат да осъществяват достъп до чувствителни данни?
• Кои предупреждения задействат класификация на инцидент, форензично запазване на доказателства и регулаторни решения?
• Кои контроли доказват, че достъпът до лични данни е защитен с подходящи технически и организационни мерки?

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

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

GDPR добавя слоя на отчетност за поверителността. Article 5 изисква цялостност, поверителност и отчетност. Article 4 дефинира широко нарушението на сигурността на личните данни, включително неоторизиран достъп до лични данни. Article 32 изисква подходящи технически и организационни мерки за осигуряване на ниво на сигурност, съответстващо на риска. При инциденти, свързани с идентичности, журналите, контролите за достъп, записите за автентикация и доказателствата за инцидента стават ключови за доказване дали личните данни са били защитени.

ISO/IEC 27001:2022 е системата за управление, която може да обедини тези задължения. Clause 4 изисква организацията да разбира своя контекст, заинтересованите страни и правните, регулаторните и договорните изисквания. Clause 6 изисква оценка на риска, третиране на риска, одобрение от собственика на риска и съхранени доказателства. Annex A включва контроли за управление на идентичности, сигурна автентикация, журнализиране, мониторинг, управление на инциденти, събиране на доказателства, взаимоотношения с доставчици, облачни услуги и защита на поверителността.

ITDR принадлежи в ISMS, защото рискът, свързан с идентичности, става одитируем само когато е включен в обхвата, има собственик, оценява се, третира се, наблюдава се и се подобрява.

Сценарият за атака срещу идентичност, който интересува регулаторите

Да разгледаме доставчик на облачно базирани финансови работни потоци, който обслужва клиенти от ЕС. Той използва Microsoft 365, SaaS платформа за клиентска поддръжка, облачна инфраструктура, платежен оператор и няколко API-базирани интеграции. Старши инженер по поддръжката получава убедителна подкана да свърже повторно приложение за продуктивност. Екранът за OAuth съгласие иска достъп за четене до пощенската кутия и offline access. Инженерът го одобрява.

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

Този единствен сценарий пресича няколко области на контролите:

• Жизнен цикъл на идентичностите, защото ролята и разрешенията на потребителя определят радиуса на въздействие.
• Сигурна автентикация, защото MFA сама по себе си не е предотвратила злоупотребата с токен.
• Журнализиране и мониторинг, защото откриването зависи от журнали на доставчика на идентичност, SaaS и приложението.
• Реагиране при инциденти, защото удостоверителни данни, сесии, токени и OAuth разрешения трябва да бъдат отменени бързо.
• Събиране на доказателства, защото може да последва експозиция на лични данни и регулаторно докладване.
• Управление на доставчици и облачни услуги, защото SaaS журналите и одитните API са част от веригата на доказателствата.
• Защита на поверителността, защото достъпът до лични данни трябва да се оцени по GDPR.

По-добрият въпрос не е „Кой инструмент се провали?“ По-добрият въпрос е дали организацията е имала проектирана, тествана и одитируема ITDR контролна верига.

Контролната верига по ISO 27001:2022 зад ефективния ITDR

Най-ефективните ITDR програми свързват превантивни, детективни, коригиращи и доказателствени контроли.

В Zenith Controls ISO/IEC 27001:2022 control 5.16 Identity management се разглежда като превантивен контрол, който подпомага поверителност, цялостност и наличност. Той се свързва пряко с 5.15 Access control, 5.17 Authentication information, 5.18 Access rights, 5.19 Information security in supplier relationships, 5.36 Compliance with policies, rules and standards for information security и 8.2 Privileged access rights.

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

Control 8.5 Secure authentication е друга опорна точка на ITDR. В Zenith Controls той се свързва с управление на идентичности, информация за автентикация, привилегии за достъп, ограничаване на достъпа до информация, дейности по мониторинг, управление на инциденти и защита на поверителността на личните данни (PII). Автентикацията не приключва при вписване. Управлението на сесии, обработването на токени, защитата на удостоверителни данни и проследимостта са част от същата доказателствена картина.

Control 8.16 Monitoring activities е връзката между събирането на журнали и вземането на решения. Той зависи от 8.15 Logging и подпомага 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents и по-широкото управление на инциденти. За ITDR 8.16 е мястото, където подозрителното поведение на идентичност става събитие с триаж, обявен инцидент или документиран фалшиво положителен резултат.

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

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

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

Пакетът от политики на Clarysec предоставя този оперативен модел.

В корпоративната User Account and Privilege Management Policy User Account and Privilege Management Policy, Governance Requirements clause 5.9 посочва:

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

Това превръща инвентара на идентичностите в изрично контролно задължение. То е особено важно, защото служебните акаунти, API ключовете и неактивните удостоверителни данни са чести слепи зони в ITDR.

Същата политика посочва в Governance Requirements clause 5.8:

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

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

За по-малки организации User Account and Privilege Management Policy - SME User Account and Privilege Management Policy - SME задава кратко очакване в Enforcement and Compliance clause 8.1.1:

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

Оттук започват много ITDR програми за SME. Не е необходим голям SOC. Необходими са ясно определена отговорност и редовен преглед на правилните сигнали, свързани с идентичности.

Политиката за журнализиране осигурява доказателствената основа. Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME определя в Governance Requirements clause 5.4.2:

Журнали за автентикация: успешни и неуспешни опити за вписване, продължителност на сесията, използване на MFA

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

Корпоративната Logging and Monitoring Policy Logging and Monitoring Policy разширява изисквания обхват на журналите в Policy Implementation Requirements clause 6.1.1:

Всички обхванати системи трябва да генерират журнали, които записват: 6.1.1.1 Опити за потребителска автентикация и достъп 6.1.1.2 Дейности на привилегировани потребители 6.1.1.3 Промени в конфигурацията 6.1.1.4 Неуспешни опити за достъп или системни събития 6.1.1.5 Откривания на зловреден софтуер и предупреждения по сигурността 6.1.1.6 Външни комуникации и задействания на правила на защитната стена

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

След това политиката за реагиране при инциденти предоставя правомощия на екипите за реагиране. Корпоративната Incident Response Policy Incident Response Policy посочва в Policy Implementation Requirements clause 6.2.1:

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

Политиката Incident Response Policy - SME Incident Response Policy - SME посочва в Roles and Responsibilities clause 4.2.2:

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

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

Обработването на доказателства е разликата между реагиране и доказване. Корпоративната Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy посочва в Governance Requirements clause 5.5:

Всички събрани доказателства трябва да бъдат уникално идентифицирани, етикетирани и съхранявани в защитено хранилище със: 5.5.1 Проверка на целостта, например SHA-256 хеш стойности 5.5.2 Журнали за достъп с времеви маркери 5.5.3 Записи във веригата на съхранение и предаване, подписани от всеки попечител

Политиката Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME посочва в Policy Implementation Requirements clause 6.1.1:

Винаги трябва да се създава форензично копие или експорт; оригиналните доказателства никога не трябва да се редактират директно.

В сценария с FinScale това означава, че SOC експортира журнали от доставчика на идентичност, SaaS одитни журнали, записи за достъп до пощенски кутии, записи за OAuth съгласие, записи за отмяна на сесии и SIEM предупреждения в хранилище за доказателства със защита на целостта и верига на съхранение и предаване.

Изграждане на ITDR пътна карта със Zenith Blueprint

Zenith Blueprint превежда контролната верига в стъпки за внедряване.

Във фазата Controls in Action, Step 19, Technological Controls I, Blueprint е директен относно автентикацията:

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

Същата стъпка надхвърля паролите. Тя изисква сигурно съхранение и предаване на данни за автентикация, сигурно обработване на API токени, идентификатори на сесии и OAuth удостоверителни данни, управление на тайни за автентикация между машини, ротация на токени, контроли върху продължителността на сесиите, защитени cookie флагове и преглед на журналите за автентикация.

Step 22, Organizational Controls, формализира жизнения цикъл на достъпа. Тя насочва екипите да интегрират предоставянето и отнемането на достъп с процесите по човешки ресурси, да извършват документирани тримесечни прегледи на правата за достъп, да дефинират типове идентичности като индивидуални, споделени и служебни акаунти, да налагат MFA за привилегировани акаунти, да премахват неактивни акаунти и да ротират служебни удостоверителни данни.

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

Step 23, Organizational Controls for 5.19 to 5.37, валидира способностите за управление на инциденти. Тя изисква актуален план за реагиране при инциденти, дефинирани събития, подлежащи на докладване, настолни упражнения, документирани решения, записи за комуникации, научени уроци и форензично запазване на доказателства като снимки на журнали, резервни копия и сигурна изолация.

Прагматична ITDR последователност на Clarysec изглежда така:

1. Дефиниране на типове идентичности и собственици.
2. Защита на автентикацията, токените и сесиите.
3. Събиране на журнали за автентикация, привилегии и SaaS.
4. Мониторинг за рисково поведение.
5. Дефиниране на правила за решение от събитие към инцидент.
6. Форензично запазване на доказателства.
7. Докладване, възстановяване и подобрение.

Едноседмичен пакет ITDR доказателства

Фокусиран „пакет доказателства за инцидент с идентичност“ е един от най-бързите начини да се разкрият пропуски. Изберете един високорисков сценарий, например: „Привилегирован SaaS потребител дава съгласие на неоторизирано OAuth приложение и токенът се използва за достъп до клиентски данни.“

След това изградете пакета с доказателства за една седмица.

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

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

Съпоставяне на ITDR с NIS2, DORA и GDPR Article 32

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

NIS2 Article 21 очаква риск-базирани, пропорционални технически, оперативни и организационни мерки. За ITDR това означава контрол на достъпа, управление на активите, киберхигиена, обучение, управление на инциденти, оценка на ефективността на контролите и MFA или непрекъсната автентикация, когато е приложимо. Article 23 създава поетапно докладване за значителни инциденти, включително ранно предупреждение в рамките на 24 часа, уведомяване за инцидент в рамките на 72 часа и окончателен доклад в рамките на един месец.

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

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

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

За SaaS, облачни, управлявани услуги, управлявана сигурност и организации с цифрови платформи обхватът на NIS2 трябва да се провери внимателно. NIS2 обхваща много сектори от Annex I и Annex II, включително цифрова инфраструктура, доставчици на облачни услуги, центрове за данни, доверителни услуги, DNS, TLD регистри, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, онлайн пазари, търсачки и платформи за социални мрежи. Следователно определянето на обхвата по ISO/IEC 27001:2022 clause 4 и анализът на заинтересованите страни не са формалност. Те определят кои задължения трябва да адресира ISMS.

Риск за идентичности при доставчици и SaaS

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

Cloud Usage Policy - SME на Clarysec Cloud Usage Policy - SME включва пряко изискване от Governance Requirements clause 5.2.4:

Услугата предоставя сигурни контроли за достъп, журнализиране и възможности за защита на данните

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

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

В Zenith Controls ISO/IEC 27001:2022 control 8.16 Monitoring activities се свързва с 5.22 Monitoring, review and change management of supplier services. Това отразява оперативната реалност. Предупрежденията от доставчика на идентичност, SaaS одитните журнали, дейността на облачни администратори и акаунтите на доставчици на управлявани услуги са част от повърхността на ITDR.

Как одиторите ще оценяват ITDR

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

Одитор по ISO/IEC 27001:2022 ще попита дали заплахите, свързани с идентичности, са включени в оценката на риска, дали собствениците на риска са одобрили третирането, дали Декларацията за приложимост включва съответните контроли от Annex A, дали политиките са внедрени и дали доказателствата показват, че контролите работят. Той може да избере извадково привилегирован акаунт и да проследи одобрението, настройката на MFA, дейността в журналите, прегледа на достъпа и отнемането на достъп.

Оценител по NIST CSF 2.0 ще прегледа резултатите GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER. ITDR естествено се вписва в профил, ограничен до компрометиране на идентичност, злоупотреба със SaaS токен или неправомерно използване на привилегирован достъп.

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

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

Одитор по COBIT 2019 или в стил ISACA ще прегледа управлението, контролните цели, собствеността, мониторинга на резултатността и увереността.

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

Показатели, които доказват, че ITDR работи

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

• Процент на привилегированите акаунти с устойчива на фишинг MFA.
• Брой неактивни акаунти, по-стари от прага в политиката.
• Брой служебни акаунти без собственик или дата за ротация.
• Процент на критичните SaaS платформи, които изпращат журнали за автентикация към SIEM.
• Средно време до откриване на подозрителна дейност, свързана с идентичност.
• Средно време до отмяна на компрометирани сесии и токени.
• Брой OAuth приложения, които са одобрени, отхвърлени или премахнати.
• Процент на инцидентите, свързани с идентичности, с пълни пакети доказателства.
• Брой просрочени констатации от прегледи на правата за достъп.
• Брой платформи на доставчици, които не предоставят изискваните журнали за идентичности.

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

Чести ITDR одитни констатации и корекции

Clarysec често вижда пет повтарящи се констатации.

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

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

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

Четвърто, доказателствата се променят по време на разследване. Коригирайте това, като следвате правилото на Evidence Collection and Forensics Policy: създавайте форензични копия или експорти, никога не редактирайте оригиналите директно и съхранявайте доказателствата с хешове и записи във веригата на съхранение и предаване.

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

Всяка констатация има отговор чрез контрол, политика и доказателства. Това е практическата стойност на единната ITDR програма: тя дефинира какво трябва да има собственик, да се наблюдава, да се тества, да се доказва и да се подобрява.

Превърнете риска, свързан с идентичности, в готови за одит доказателства

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

Ако отговорът е несигурен, започнете с фокусиран спринт за готовност за ITDR.

Използвайте Zenith Blueprint, за да структурирате пътя за внедряване през автентикация, жизнен цикъл на достъпа, журнализиране, мониторинг, реагиране при инциденти и обработване на доказателства. Използвайте политиките на Clarysec за контрол на достъпа, журнализиране, облачни услуги, реагиране при инциденти и форензика, за да разпределите собственост и правомощия за реагиране. Използвайте Zenith Controls, за да съпоставите управлението на идентичности, сигурната автентикация и дейностите по мониторинг с ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 и одитните очаквания.

Целта е проста: атаките срещу идентичности да станат откриваеми, ограничими, докладваеми и защитими с доказателства.

Clarysec може да ви помогне да изградите ITDR пакет доказателства, да го тествате чрез настолен сценарий и да преобразувате констатациите в план за третиране на риска, разбираем за вашия управителен орган, регулатор и одитор. Започнете с преглед на Logging and Monitoring Policy, User Account and Privilege Management Policy - SME, Zenith Blueprint и Zenith Controls, след което насрочете оценка на готовността за ITDR, за да превърнете риска, свързан с идентичности, в готови за одит доказателства.