Управление на висящи DNS записи за NIS2, DORA и GDPR

Главният директор по информационна сигурност получава съобщението в 07:12 в понеделник.

Изследовател по сигурността е установил, че promo.company.com сочи към изоставено облачно приложение. DNS записът все още е активен. Облачният ресурс вече не съществува. SaaS тенантът, който някога е обслужвал кампанията, е изтрит преди шест месеца, малко след като маркетингът е преминал към друга платформа. Никой не е премахнал CNAME записа.

В 08:30 въпросът вече не е „Може ли някой да превземе поддомейна?“. Въпросът е „Защо никой не знаеше, че този актив съществува?“

В 09:15 е включен правният отдел, защото поддомейнът някога е събирал имейл адреси за списък с чакащи за продукт. Включено е снабдяването, защото платформата за кампанията е била управлявана от агенция. Включена е функцията по съответствие, защото дружеството се подготвя за надзорен одит по ISO/IEC 27001:2022, готовност за NIS2 и клиентски въпросници за увереност. Длъжностното лице по защита на данните (DPO) пита дали експозицията може да се превърне в нарушение на сигурността на личните данни по GDPR, ако поддомейнът бъде използван злонамерено. Финансовият директор пита дали същата слабост може да засегне платежен портал в регулираната среда за финансови услуги на групата.

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

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

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

Какво всъщност означава висящ DNS запис

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

Чести примери включват:

• CNAME запис, който сочи към незаявен облачен app service.
• Персонализирано SaaS хост име, оставено в DNS след прекратяване на абонамента.
• CDN дистрибуция, премахната от конзолата на доставчика, но все още реферирана в публичния DNS.
• Маркетингов микросайт, изведен от употреба от агенция без премахване на DNS записите.
• Крайна точка за съхранение или съпоставяне към статичен уебсайт, което може да бъде регистрирано повторно.
• Развоен поддомейн, изложен чрез забравен проект от тип platform-as-a-service.

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

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

Затова Clarysec съпоставя този въпрос с очакванията за одит по ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.

Защо ISO 27001:2022 е практическата основа

Най-силният подход за управление на висящи DNS записи не е създаване на отделни програми за NIS2, DORA и GDPR. Подходът е ISO/IEC 27001:2022 да се използва като гръбнак на системата за управление, а доказателствата да се генерират веднъж за множество потребности от увереност.

Релевантните изисквания започват още преди Annex A. Клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, изискванията на заинтересованите страни, обхвата на СУИС и зависимостите с други организации. За управление на висящи DNS записи обхватът следва да включва външен DNS, домейни, регистратори, облачни услуги, SaaS платформи, агенции, управляван хостинг, CDN и всяка трета страна, която може да създава или извежда от употреба интернет-достъпни услуги.

Клаузи 5.1 до 5.3 превръщат това във въпрос на лидерство и отчетност. Ръководството трябва да съгласува СУИС с бизнес посоката, да осигури ресурси, да комуникира значението на информационната сигурност и да възложи отговорности. Ако маркетингът може да стартира микросайт, инженерните екипи могат да създават облачни крайни точки, а снабдяването може да прекратява SaaS договори, организацията се нуждае от модел на управление, който ясно разпределя собствеността върху DNS и услугите между всички тях.

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

Клаузи 7.5, 8.1, 8.2 и 8.3 превръщат управлението в доказателства. Те изискват контролирана документирана информация, планирани и контролирани оперативни процеси, отчитане на непреднамерени промени, контрол на външно предоставяни процеси, периодични оценки на риска и документирани резултати от третирането.

След това Annex A предоставя каталога с контроли. В проектите на Clarysec основните връзки с ISO/IEC 27002:2022 обикновено изглеждат така:

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

Погледът на Zenith Controls: един риск, три опорни контрола

В Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec използва релевантни контроли по ISO/IEC 27002:2022 като опорни точки за съответствие между рамки. За управление на висящи DNS записи и превземане на поддомейни три контрола са централни.

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

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

Контрол 8.8, Управление на технически уязвимости, се класифицира като превантивен, поддържа поверителност, целост и наличност, съгласува се с Identify и Protect и попада в управлението на заплахи и уязвимости като оперативна способност, с управление, екосистема, защита и отбрана като области на сигурност.

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

Clarysec често добавя поддържащи практики около тези опорни контроли: ISO/IEC 27005 за дисциплина при оценка и третиране на риска, ISO/IEC 27017 за управление на сигурността на облачни услуги, ISO/IEC 27018, когато облачни услуги обработват PII, ISO/IEC 27701 за управление на неприкосновеността на личната информация и ISO 22301, когато непрекъсваемостта и кризисното реагиране са релевантни.

Доказателствата от политики, които вече изискват контрол на жизнения цикъл на DNS

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

Политика за управление на активите за МСП на Clarysec Политика за управление на активите за МСП, Изисквания за прилагане на политиката, клауза 6.6.1 гласи:

Облачно базираните активи (напр. акаунти за съхранение, SaaS платформи, уеб домейни) също трябва да бъдат включени в инвентара.

Същата политика добавя в клауза 6.6.2:

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

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

Най-важното е, че клауза 6.6.3 гласи:

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

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

Корпоративната версия подсилва тази по-широка концепция за активите. Политика за управление на активите на Clarysec Политика за управление на активите, Обхват, клауза 2.2.5 гласи:

Логически активи: имена на домейни, лицензи, потребителски акаунти, базови конфигурации

Имената на домейни и конфигурациите не са административни подробности. Те са активи, носещи доверие, които могат да се превърнат в пътища за атака.

Връзката с контрола на промените е също толкова важна. Политика за управление на промените на Clarysec Политика за управление на промените, Цел, клауза 1.1 гласи:

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

Следователно премахване на DNS запис, прекратяване на SaaS услуга, изтриване на облачно приложение, CDN миграция или извеждане от употреба на маркетингов микросайт следва да генерира доказателства за промяна. Липсата на заявка за промяна често е първият сигнал за одитен риск.

Управлението на облачните услуги също трябва да бъде свързано. Политика за използване на облачни услуги на Clarysec Политика за използване на облачни услуги, Изисквания за управление, клауза 5.5 гласи:

Екипът по информационна сигурност трябва рутинно да оценява мрежовия трафик, DNS дейността и журналите, за да открива неоторизирано използване на облачни услуги (shadow IT). Откритите нарушения трябва да се разследват своевременно.

За предотвратяване на превземане на поддомейни мониторингът на DNS дейността не е само за shadow IT. Той е и за „остаряло ИТ“ — активи, които някога са били одобрени, но вече не се контролират.

Практически работен поток на Clarysec за управление на висящи DNS записи

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

За малки и средни предприятия това може да започне като лек регистър. За големи организации обикновено се интегрират DNS експорти, управление на външната атакуваема повърхност, инвентари на облачни активи, CMDB записи, скенери за уязвимости, SIEM аларми и системи за билети.

Управленският въпрос остава същият: можете ли да докажете, че всеки външно достижим поддомейн е известен, има собственик, наблюдава се и може да бъде премахнат чрез контролиран процес?

Изоставеният поддомейн за кампания, обработен правилно

Да се върнем към инцидента от понеделник. promo.company.com сочи към изоставен SaaS сайт за кампания.

Първо, ръководителят по сигурността създава запис за уязвимост, защото активът е публично достъпен. Политика за управление на уязвимости и корекции на Clarysec Политика за управление на уязвимости и корекции, Изисквания за прилагане на политиката, клауза 6.1.1 гласи:

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

За малки и средни предприятия еквивалентната политика изостря приоритизацията. Политика за управление на уязвимости и корекции за МСП Политика за управление на уязвимости и корекции за МСП, Изисквания за прилагане на политиката, клауза 6.5.1 гласи:

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

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

Трето, ИТ проверява облачната или SaaS платформата. Ако облачният акаунт е бил изтрит, Политика за използване на облачни услуги за МСП на Clarysec Политика за използване на облачни услуги за МСП, Изисквания за прилагане на политиката, клауза 6.3.6 е пряко релевантна:

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

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

Пето, ръководителят по поверителността оценява дали поддомейнът е обработвал или е могъл да изложи лични данни. PII Security and Access Control Policy на Clarysec PII Security and Access Control Policy, Сигурна конфигурация и управление на уязвимостите, клауза 4.7.4 гласи:

[Both] Собственикът на система / собственикът на приложение MUST записва покритието на оценките на уязвимостите за системи, обработващи PII, в REG12 поне на тримесечна база и след съществена техническа промяна.

Клауза 4.7.5 добавя:

[Both] Ръководителят по информационна сигурност MUST записва неотстранените високорискови уязвимости, засягащи PII, в REG12 в рамките на пет работни дни от валидирането.

Тези клаузи се прилагат независимо дали организацията действа като администратор или обработващ лични данни, защото са маркирани с [Both]. При проблем с висящ DNS запис, включващ PII, доказателствата не трябва да остават само в технически билет. Те трябва да бъдат отразени в регистъра на доказателствата за уязвимости, свързани с PII.

Шесто, ако агенция или SaaS доставчик е хоствал кампанията, снабдяването проверява записите за трети страни. Processor, Subprocessor and Third-Party Privacy Management Policy на Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy, Идентифициране и класификация на взаимоотношенията, клауза 4.1.2 гласи:

[All] Собственикът на процес / собственикът на бизнеса MUST идентифицира всяко предложено взаимоотношение с трета страна, която ще обработва, достъпва, получава, съхранява, предава, поддържа или по друг начин ще засяга PII, в REG08 преди снабдяване, въвеждане, подновяване или съществена промяна във взаимоотношение с трета страна във връзка с поверителността.

Клауза 4.5.5 изисква:

[Both] Собственикът по доставчици / снабдяване MUST записва местата на обработване, местата на хостинг и индикаторите за международно предаване в REG08 и да свързва приложимите доказателства за предаване с REG09 преди одобряване на обработващ лични данни, подизпълнител по обработване, промяна на местоположение или промяна на услуга, релевантна за предаванията.

Накрая, ръководителят по съответствието пакетира доказателствата. Политика за одит и мониторинг на съответствието на Clarysec Политика за одит и мониторинг на съответствието, Цели, клауза 3.4 посочва, че една от целите е:

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

Това е резултатът, от който главният директор по информационна сигурност се нуждае, когато клиент, регулатор или одитор попита: „Как знаете, че това няма да се случи отново?“

Къде се вписва Zenith Blueprint

Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec Zenith Blueprint превръща контролите в оперативни практики, готови за одит. Висящите DNS записи се съпоставят силно с четири области.

Във фазата Controls in Action, стъпка 22 обхваща организационни контроли 5.1 до 5.18, включително контрол 5.9 по ISO/IEC 27002:2022. Zenith Blueprint посочва:

Никоя организация не може да защити това, за което не знае, че притежава. Контрол 5.9 формализира този основополагащ принцип, като изисква създаване и поддържане на актуален инвентар на цялата информация и свързаните активи, релевантни за СУИС.

Той продължава:

В най-стратегическата си форма инвентарът на активите служи като централната нервна система на вашата СУИС.

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

В стъпка 20 Zenith Blueprint обхваща технологични контроли 8.18 до 8.26. За контрол 8.21, Сигурност на мрежовите услуги, той инструктира организациите да валидират сигурността на мрежовите услуги:

Избройте всички вътрешни и външни мрежови услуги (DNS, VPN, SMTP, DHCP, API gateways и др.).

Затова DNS доставчиците, регистраторите, cloud DNS, CDN платформите и функциите за персонализирани домейни в SaaS принадлежат в регистъра на услугите.

В стъпка 19 Zenith Blueprint обхваща технологични контроли 8.1 до 8.17. За контрол 8.8 той посочва:

Управлението на уязвимостите е една от най-критичните области на съвременната киберхигиена. Макар защитните стени и антивирусните инструменти да осигуряват защита, тя може да бъде подкопана, ако некоригирани системи или неправилно конфигурирани услуги останат изложени.

Висящ DNS запис е неправилно конфигуриран път към външна услуга. Дори когато няма CVE, той следва да се обработва чрез управление на уязвимостите: валидиране, оценка, възлагане, отстраняване, повторно тестване и закриване.

В стъпка 23 Zenith Blueprint разглежда организационни контроли 5.19 до 5.37. За контрол 5.23 той препоръчва:

Избройте всички облачни услуги, които се използват в момента (5.23), включително shadow IT, когато е известно. Идентифицирайте кой ги е одобрил и дали е извършена надлежна проверка. Разработете лек контролен списък за оценка, който обхваща местонахождение на данните, модел на достъп, регистриране и шифроване.

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

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

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

Програмата за висящи DNS записи се съпоставя пряко с тези области. Article 21(3) също изисква сигурността на веригата на доставки да отчита уязвимостите, специфични за всеки пряк доставчик или доставчик на услуги. Ако маркетингова агенция, SaaS доставчик, доставчик на управляван хостинг или облачна платформа управлява персонализирани домейни, специфичните за доставчика контроли следва да обхващат DNS собственост, изход от услуга, съдействие при инцидент и предаване на доказателства.

Article 23 е релевантен, ако превземане настъпи или е способно да причини сериозно оперативно прекъсване, финансова загуба или значителна материална или нематериална вреда. NIS2 използва поетапно докладване: ранно предупреждение в рамките на 24 часа от узнаване за значителен инцидент, уведомление в рамките на 72 часа, междинни доклади при поискване и окончателен доклад в рамките на един месец от уведомлението за инцидента.

За финансовите субекти DORA е секторният режим за цифрова оперативна устойчивост. Articles 5 и 6 изискват вътрешна рамка за управление и контрол на ИКТ риска, с крайна отговорност на ръководния орган, ясни ИКТ роли, политики за наличност, автентичност, цялост и поверителност на данните, планове за одит, ресурси, политика за услуги от трети страни и документирана рамка за управление на ИКТ риска.

Articles 8 до 14 формират оперативното ядро. Article 8 изисква идентифициране, класификация и документиране на бизнес функции, поддържани от ИКТ, информационни активи, ИКТ активи, зависимости, свързаности с външни доставчици на ИКТ услуги, инвентари, рискови сценарии и наследени системи. Висящ CNAME запис често е пропусната зависимост. Article 9 изисква защита и превенция. Article 10 изисква откриване на аномална дейност, ИКТ инциденти и потенциални единични точки на отказ. Articles 11 и 12 разглеждат непрекъсваемост, възстановяване, архивиране и възстановяване от резервни копия. Article 13 изисква извличане на поуки от уязвимости, заплахи, инциденти и тестове.

Articles 17 до 19 формализират управлението на инциденти, класификацията и докладването. Articles 28 до 30 правят риска от ИКТ трети страни базиран на жизнения цикъл. Финансовите субекти остават изцяло отговорни при използване на доставчици на ИКТ услуги. За готовност за DORA Clarysec препоръчва добавяне на четири полета към всеки DNS регистър и регистър на облачни услуги: поддръжка на критична или важна функция, външен доставчик на ИКТ услуги, договорна препратка или препратка към регистър и статус на тест за изход.

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

PII Incident and Breach Management Policy на Clarysec PII Incident and Breach Management Policy, Класификация и оценка на нарушението, клауза 4.2.6 подкрепя този анализ на критерии за задействане в няколко режима:

[Conditional] Ръководителят по поверителността / PIMS Manager MUST оцени приложимите правни, секторни, финансово-секторни, киберсигурностни, договорни, клиентски и свързани с получатели на услуги критерии за докладване за всеки инцидент с лични данни с високо въздействие и да запише резултата за приложимостта в REG01, REG08 и REG10.

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

Как одиторите ще тестват вашите доказателства

Интегрираната СУИС следва да ви позволява да отговаряте на различни одитори със същата доказателствена основа. Формулировката на въпроса се променя, но доказателството често е същото.

По-широката перспектива за увереност често включва NIST CSF 2.0 и COBIT 2019. NIST CSF 2.0 помага целевото състояние да се изрази чрез резултати GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER. Current Profile може да показва ръчни тримесечни DNS прегледи и непоследователно извеждане на SaaS. Target Profile може да изисква автоматизирани ежеседмични проверки за превземане, задължително възлагане на собственик, доказателства при изход от доставчик и интеграция с управлението на промените.

Одитор, ориентиран към COBIT 2019 или ISACA, обикновено ще попита кой притежава процеса, как рискът се оценява и насочва, дали промените се контролират, дали доставчиците се управляват, дали конфигурацията и активите са надеждни и дали доказателствата за увереност поддържат управленското докладване. Той може да не поиска първо списък с CNAME записи. Може да попита как ръководството знае, че външните цифрови услуги се контролират през целия им жизнен цикъл.

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

Пакетът за одит на висящи DNS записи следва да бъде достатъчно малък за поддържане, но достатъчно пълен за защита. Clarysec обикновено препоръчва следния набор от доказателства:

• Инвентар на DNS зони с източник, дата, тип запис, цел и собственик.
• Резултати от сканиране на външната атакуваема повърхност, показващи проверки за превземане.
• Записи в регистъра на активите за домейни, поддомейни, облачни услуги, SaaS приложения и CDN.
• Регистър на услугите, показващ вътрешна отговорност или отговорност на доставчик.
• Заявки за промяна за създаване, изменение и изтриване на DNS записи.
• Контролни списъци за въвеждане на облачни и SaaS услуги, включително преглед на персонализирани домейни и DNS.
• Договори с доставчици или клаузи за сигурност, обхващащи DNS, хостинг, съдействие при инцидент и изход.
• Билети за уязвимости със степен на сериозност, собственик, дата на отстраняване и доказателства от повторно тестване.
• Оценка на PII, когато поддомейнът обработва или преди е обработвал лични данни.
• Записи за класификация на инциденти при подозирано или потвърдено превземане.
• Поуки и актуализирани процедури след констатации.

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

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

Чести модели на отказ, които Clarysec установява

При клиенти в SaaS, fintech, здравни технологии, управлявани услуги и електронна търговия се повтарят едни и същи модели.

Първо, собствеността върху DNS е разделена между екипи. Инженерните екипи притежават облака. Маркетингът притежава кампаниите. ИТ притежава достъпа до DNS доставчика. Снабдяването притежава прекратяването на SaaS. Никой не притежава целия жизнен цикъл.

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

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

Четвърто, процедурите за изход от доставчик се фокусират върху фактури и връщане на данни, но не върху персонализирани домейни, DNS записи и промени в подизпълнители по обработване.

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

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

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

30-дневен план за действие за управление на DNS

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

Започнете с този 30-дневен план:

1. Експортирайте всички официални DNS зони.
2. Идентифицирайте CNAME, ALIAS, A и AAAA записи, сочещи към облачни услуги, SaaS, CDN и услуги, управлявани от агенции.
3. Назначете собственици и бизнес цели.
4. Изпълнете проверки за превземане и валидирайте подозрителните записи ръчно.
5. Създайте билети за уязвимости за потвърдените рискове.
6. Премахнете или повторно заявете изложените записи чрез контрол на промените.
7. Актуализирайте регистъра на активите, регистъра на облачните услуги и регистъра на доставчиците.
8. Прегледайте дали засегнат поддомейн е обработвал PII.
9. Добавете проверки на жизнения цикъл на DNS към въвеждането на облачни услуги, снабдяването със SaaS и изхода от доставчици.
10. Докладвайте показатели на ръководството.

Техническото отстраняване на висящ DNS запис често е просто. Управленското отстраняване е това, което предотвратява следващото превземане.

Clarysec може да ви помогне да въведете това в оперативен режим чрез Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls и нашия инструментариум от политики за управление на активите, използване на облачни услуги, управление на уязвимостите, управление на доставчици, сигурност на PII, реагиране при инциденти и одитни доказателства.

Ако искате подход, готов за одит, Clarysec може да ви помогне да изградите пакет с доказателства за DNS и облачна експозиция, да го съпоставите с ISO/IEC 27001:2022, NIS2, DORA и GDPR и да превърнете забравените поддомейни в контролирани, притежавани и наблюдавани активи. Изтеглете релевантния инструментариум на Clarysec, поискайте демонстрация или насрочете оценка на управлението на DNS, преди тестер за проникване, одитор или нападател да открие следващия забравен указател.