DDoS Belnet 2021: отказоустойчивость общей сети как тест

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

Годовой отчёт Belnet за 2021 год сообщает, что организация подверглась крупной объёмной распределённой атаке типа «отказ в обслуживании» 3 и 4 мая. В записи о текущем состоянии сети задокументированы проблемы со связностью у клиентов, последовательные волны атаки, альтернативные пути трафика, правила смягчения, стабилизационные работы и долгосрочное планирование защиты. [1][2]
Официальная федеральная парламентская стенограмма указывает, что около 200 подключённых организаций, включая университеты, государственные органы и исследовательские учреждения, испытали разную степень нарушения доступа в интернет 4 мая. В ней отмечается, что Belnet активировал кризисную процедуру, связался с Центром кибербезопасности Бельгии и к вечеру взял ситуацию под контроль. [7]
Бельгийская общественная телекомпания VRT сообщила о практических последствиях для правительственных сайтов, работы парламента, удалённого доступа и сервиса записи на вакцинацию. Эти примеры демонстрируют зависимость публичных служб, но не доказывают, что каждое подключённое учреждение пострадало одинаково или столь же долго. [8]
Belnet управляет национальной исследовательской и публичной сервисной сетью с IP- и оптической инфраструктурой, точками присутствия, магистральными соединениями и опциональным резервным доступом. В собственной формулировке миссии сеть названа критически важным элементом федеральных цифровых услуг. [9][10][11]
Открытые источники не называют злоумышленника, политический мотив, точный объём трафика, состав протоколов, размер ботнета, перегруженный канал, использованную уязвимость или полную хронологию по каждому клиенту. Анализ подотчётности должен сохранять эти неизвестные.
Более поздние записи Belnet предоставляют полезные доказательства изменений. Оператор явно увязал ограничение использования адресов «точка-точка» с повышением отказоустойчивости после атаки 2021 года, а в статье, посвящённой мониторингу 2022 года, указано, что внешний облачный центр очистки был задействован в мае 2021 года в ситуации, когда атакующий трафик угрожал магистральным каналам сети. [3][6]
Текущие страницы Belnet «Advanced DDoS Security» описывают фильтрацию на маршрутизаторах, внутренний центр очистки и внешний облачный уровень. Они являются свидетельством более поздних или текущих мер, а не доказательством того, что вся архитектура существовала до инцидента. [4][5]
Документы IETF, посвящённые отказу в обслуживании, входной фильтрации и DDoS Open Threat Signaling, предоставляют терминологию для оценки готовности к смягчению, координации с вышестоящими операторами и телеметрии. Они не доказывают, что Belnet использовал конкретный протокол или конфигурацию в 2021 году. [12][13][14][15][16][17][18][19]
Подотчётность следует за реальным контролем. Belnet контролировал магистральные операции, меры смягчения, перемаршрутизацию, кризисную эскалацию и доказательства на уровне сети. Подключённые учреждения контролировали локальное аварийное переключение, вторичный доступ и непрерывность работы приложений. Вышестоящие провайдеры и провайдеры последней мили контролировали контрактные маршруты и пропускную способность. Государственные органы контролировали требования к непрерывности и надзор.
Заслуживающее доверия завершающее заключение должно показать, в какой момент легитимный трафик стал ограниченным, когда начали действовать меры смягчения и альтернативные пути, какая сопутствующая фильтрация произошла, как измерялось восстановление клиентов и были ли последующие меры проверены на том же классе сбоя.

Отключение превратило общую связность в общий риск для публичных услуг

Распределённую атаку типа «отказ в обслуживании» легко описать плохо. Упрощённая версия гласит, что злоумышленники отправили слишком много трафика, сеть стала недоступной, инженеры отфильтровали трафик, и обслуживание восстановилось. Эта последовательность может быть технически верной, скрывая при этом наиболее важные вопросы подотчётности.

Belnet не просто обслуживал один публичный сайт. Он предоставлял связность, которой пользовались правительственные департаменты, университеты, исследовательские организации и другие государственные учреждения. В миссии Belnet говорится о национальной исследовательской сети и важнейшем компоненте федеральных цифровых услуг. На страницах услуг описывается гибридная IP- и оптическая сеть, соединяющая учреждения с бельгийским и международным интернетом, а также с исследовательскими сетями. [9][11]

Эта роль изменила значение майского инцидента 2021 года.

Атака, ограничившая пропускную способность общей сети, могла затронуть учреждения с не связанными друг с другом приложениями, администраторами и задачами. Парламентской комиссии не нужно было использовать общую базу данных приложений с университетом, чтобы пострадать обоим. Сервису записи на вакцинацию не нужно было работать на том же сервере, что и налоговый сайт. Достаточно было общей достижимости.

В федеральном парламентском отчёте сказано, что около 200 подключённых организаций испытали разную степень нарушения доступа в интернет. [7] VRT описала правительственные сайты, которые работали медленно или были недоступны, отменённую или прерванную парламентскую работу, проблемы с удалённым доступом и период, когда сервис записи на вакцинацию не мог работать нормально. [8]

Об этих последствиях следует сообщать аккуратно. Имеющиеся данные не показывают, что каждая организация полностью лишилась связности на одинаковый промежуток времени. Они не показывают, что все бельгийские государственные службы вышли из строя. Они не доказывают, что сам домен.be стал недоступен. У учреждений были разные схемы доступа, зависимости от приложений, локальные сети и варианты резервирования.

Общий факт менее широк, но более важен: один сетевой инцидент распространился на несколько секторов, потому что эти сектора полагались на общую точку контроля связности.

Это делает концентрацию измеримой.

Сколько критических служб зависело от одного пути доступа Belnet? У скольких учреждений был вторичный путь через другую точку присутствия, волоконно-оптический маршрут или провайдера? Какие службы могли переключиться без изменения DNS, аутентификации, межсетевого экрана или состояния приложения? Какие учреждения знали, что инцидент у общего провайдера может прервать и публичный доступ, и удалённый доступ персонала? Планы каких организаций по непрерывности работы проверялись при недоступности основной исследовательской и публичной сервисной сети?

Ответы на эти вопросы определяют, обеспечивает ли общая инфраструктура эффективную отказоустойчивость или скрытый риск общей причины.

Централизованная сетевая защита может быть ценной. Национальная исследовательская сеть может объединить экспертизу, пропускную способность, мониторинг и закупки. Она может координироваться с вышестоящими провайдерами эффективнее, чем каждое учреждение по отдельности. Она может предоставить резервную оптическую и IP-инфраструктуру и сделать специализированные меры смягчения доступными для организаций, которые не могли бы обеспечить их самостоятельно.

Та же концентрация повышает ставки при недостаточной подготовке мер смягчения, медленной эскалации или неполном аварийном переключении клиентов. Если сотни учреждений зависят от общих магистральных каналов и систем смягчения, технические решения оператора становятся частью непрерывности публичных услуг.

Именно эту границу подотчётности обнажил инцидент. Злоумышленники контролировали вредоносный трафик. Belnet и его партнёры контролировали, как общая инфраструктура обнаруживает, поглощает, перенаправляет и документирует этот трафик. Подключённые учреждения контролировали, насколько их собственная непрерывность услуг зависит от общего пути. Государственные органы контролировали требования к устойчивости, предъявляемые к службам, перерыв в работе которых имел социальные последствия.

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

Что устанавливают открытые источники, а что — нет

Наиболее надёжный анализ начинается с разделения трёх видов записей: обновления операционного статуса Belnet, его последующая годовая отчётность и внешние институциональные или журналистские описания.

Годовой отчёт Belnet относит инцидент к 3 и 4 мая 2021 года и называет его крупной объёмной DDoS-атакой. В нём говорится, что это событие фундаментально изменило подход организации к киберзащите. [2]

Запись о текущем состоянии начинается 4 мая. В ней сообщается, что некоторые клиенты испытывали проблемы со связностью из-за DDoS-атаки. Более поздние обновления описывают последовательные волны, продолжающуюся работу по смягчению, альтернативные пути для трафика, внедрённые правила смягчения, стабилизацию, остаточные инциденты и работу над долгосрочной защитой и цепочками эскалации. [1]

Федеральная парламентская стенограмма даёт официальный правительственный отчёт. Премьер-министр охарактеризовал масштабную DDoS-атаку 4 мая, сказал, что сеть не справилась с нагрузкой, и добавил, что подключённые учреждения пострадали в разной степени. В стенограмме зафиксирована активация кризисной процедуры Belnet и контакт с Центром кибербезопасности Бельгии. Говорится, что к вечеру ситуация была под контролем. [7]

VRT предоставляет независимый современный отчёт о последствиях. В нём упомянуты правительственные сайты, парламентские заседания, удалённая работа или доступ студентов и запись на вакцинацию среди затронутых функций. [8]

Вместе эти источники поддерживают несколько выводов.

Во-первых, это был инцидент с отказом в обслуживании, направленный на общую сетевую инфраструктуру, а не просто компрометация одного приложения.

Во-вторых, воздействие было неравномерным. Официальный отчёт прямо описывает разную степень нарушения.

В-третьих, реакция была итеративной. Belnet не применял одно статичное правило к одному неизменному потоку. Обновления статуса описывают волны, альтернативные пути, правила смягчения, стабилизацию и остаточные проблемы.

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

Открытые источники оставляют существенные пробелы.

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

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

Отсутствие этих фактов не повод заполнять пробелы. Это причина отличать установленные выводы от запросов на доказательства.

Например, входная фильтрация является важным средством сетевого контроля, но источники не устанавливают, что именно поддельные исходные адреса вызвали перегрузку Belnet. Было бы неверно утверждать, что повсеместное внедрение одной практики фильтрации обязательно предотвратило бы это событие.

Внешний центр очистки может поглотить большой поток, но открытые источники не раскрывают точную мощность, доступную до инцидента, или контрактные условия её использования. Более поздние материалы Belnet сообщают, что внешний облачный сервис был внедрён в мае 2021 года. [6] Это свидетельство изменения, а не полная реконструкция архитектуры до инцидента.

В строгой статье следует делать неизвестное видимым, поскольку они определяют остающиеся вопросы подотчётности:

Какая характеристика трафика создала ограничение?
Какие общие каналы или устройства стали узким местом?
Какие меры смягчения были автоматическими, а какие требовали одобрения человека?
Сколько времени занимала каждая эскалация?
Какие клиенты были защищены индивидуально?
У каких учреждений были независимые пути?
Какой легитимный трафик был отфильтрован или задержан?
Как Belnet и клиенты определили, что обслуживание восстановлено?

Эти вопросы полезнее неподтверждённой теории о злоумышленнике.

Belnet был точкой контроля сети, а не обобщённой облачной зависимостью

Предмет данной статьи — сетевая инфраструктура. Это различие важно, потому что инцидент иначе можно свести к общему рассказу о кибербезопасности или государственных ИТ.

Описание публичного сервиса Belnet говорит, что его сеть объединяет IP- и оптические соединения и обеспечивает доступ к коммерческому интернету и исследовательским сетям. [9] Его технические ответы описывают прямые подключения в точках присутствия Belnet, варианты последней мили от сторонних операторов, магистральные интерфейсы и возможность второго подключения через другую точку присутствия и отдельный волоконно-оптический маршрут для критических нужд. [10]

Эти детали выделяют несколько различных областей контроля.

Belnet контролирует магистраль и услуги, предоставляемые в своих точках присутствия. Он может наблюдать трафик, поступающий в его сеть, конфигурировать маршрутизаторы, устанавливать правила смягчения, перенаправлять трафик и координировать общесетевой ответ.

Провайдер последней мили контролирует канал между учреждением и Belnet, когда это учреждение не находится непосредственно в точке присутствия Belnet. Сбой или предел пропускной способности здесь не обязательно находится под единоличным контролем Belnet.

Подключённое учреждение контролирует свою локальную сеть, межсетевой экран, DNS-зависимости, экспозицию приложений и использование вторичной связности. Belnet может предложить резервный доступ, но учреждение всё равно должно приобрести, настроить и протестировать его.

Вышестоящие транзитные и сервисные провайдеры, предоставляющие защиту от DDoS, контролируют пропускную способность и фильтрацию вне административного домена Belnet. Их эффективность зависит от предварительно согласованных полномочий, маршрутизации и операционных контактов.

Эти границы важны при реагировании на DDoS, потому что место, где трафик необходимо фильтровать, часто находится вне прямого контроля владельца приложения.

Если вредоносный трафик насыщает канал доступа, прежде чем достигнет локального межсетевого экрана, фильтрация в учреждении уже запоздала. Если поток угрожает магистральному каналу провайдера, провайдеру может потребоваться перенаправить трафик в центр очистки или запросить помощь у вышестоящей сети. Если для смягчения требуются изменения маршрутизации или клиентских префиксов, участникам нужны полномочия и проверенные процедуры до того, как перегрузка затруднит связь.

Текущие страницы Belnet «Advanced DDoS Security» описывают именно такой многоуровневый сетевой ответ. В них упоминается фильтрация на маршрутизаторах, внутренний центр очистки и внешний облачный центр очистки. В технических ответах говорится, что трафик обычно не пропускается через контур очистки и перенаправляется туда, когда обнаружение указывает на атаку. Также описывается ручное переключение на внешний сервис, когда сеть рискует быть перегруженной. [4][5]

Текущий дизайн нельзя проецировать в прошлое без доказательств. Однако он проясняет практические решения, которыми должен управлять оператор:

Какая аномалия вызывает фильтрацию на маршрутизаторах?
Какой адресат перенаправляется?
Какой легитимный трафик остаётся достижимым?
Когда внутренней мощности недостаточно?
Кто авторизует внешнее перенаправление?
Какие маршруты и сообщества bgp используются?
Как откатить действие?
Какие доказательства подтверждают успешность смягчения?

Это вопросы эксплуатации сети. Они касаются путей трафика, полномочий управления, общих ресурсов и наблюдаемого обслуживания. Инцидент относится к сфере подотчётности сетевой инфраструктуры, потому что публичный вред последовал за поведением этих элементов управления.

Объёмные атаки — это состязание в пропускной способности с неполными решениями

RFC 4732 описывает неудобный архитектурный факт: практически любой интернет-сервис может быть заблокирован, если злоумышленник способен собрать достаточно трафика или использовать достаточно ресурсов для поддержания состояний. [12] Это не делает отказоустойчивость невозможной. Это означает, что заявления о предотвращении должны быть конкретными.

Объёмная атака пытается исчерпать ограниченный ресурс. Ресурсом может быть интернет-канал, производительность маршрутизатора, таблица состояний межсетевого экрана, балансировщик нагрузки, DNS-сервис или приложение. Выбор правильной меры смягчения зависит от того, где возникло ограничение и какой трафик можно отличить.

Если узким местом является магистральный канал, добавление правила на локальном межсетевом экране может не восстановить сервис, потому что атакующие пакеты уже заняли канал. Если узким местом является обработка с учётом состояний, может помочь перенос фильтрации в политику маршрутизатора без учёта состояний. Если трафик распределён по множеству реальных источников и напоминает легитимный спрос, простое блокирование по источнику может быть неэффективным или вредным.

Открытая запись Belnet называет инцидент объёмным и говорит, что волны атаки угрожали связности. [1][2] Она не раскрывает, какой именно ресурс отказал первым.

Эта неопределённость меняет то, как следует оценивать меры контроля.

Пропускная способность — одна из мер. Оператор может заложить резерв и организовать несколько магистральных путей. Одна пропускная способность не может гарантировать выживание при любом мыслимом потоке, но она может поднять порог и дать время на смягчение.

Обнаружение — другая мера. Телеметрия потоков, счётчики маршрутизаторов и сервисные пробы могут выявить необычный трафик, затронутые адресаты и насыщение. Обнаружение должно продолжать работать, когда сеть находится под нагрузкой.

Фильтрация — ещё одна. Списки контроля доступа, спецификации потоков, null-маршруты, ограничения скорости и системы очистки могут удалять вредоносный трафик. Каждый из этих методов может также заблокировать легитимный трафик, если область действия или правила совпадения ошибочны.

Перенаправление — ещё одна. Трафик можно направить через внутренние или внешние мощности очистки. Это требует полномочий на маршрутизацию, принятия префиксов, дизайна обратных путей и достаточной чистой пропускной способности.

Сегментация клиентов — ещё одна. Если поток, направленный на одного клиента, может угрожать общим магистральным каналам, провайдер должен решить, когда и как защитить остальную сеть, даже если атакованный клиент не приобрёл индивидуальную услугу смягчения.

Связь — ещё одна. Оперативным группам нужен канал к клиентам, вышестоящим провайдерам и органам власти, пока основная связность нарушена. Страница статуса Belnet и кризисная процедура были частью этого контура управления. [1][7]

Ни одна из этих мер не является полной сама по себе. В RFC 4948 обсуждаются фильтрация, списки доступа, null-маршрутизация, резервирование и стимулы, которые могут замедлить развёртывание мер, выгода от которых распределена по всему интернету. [14] Следовательно, проблема подотчётности не в том, есть ли у оператора продукт под названием «защита от DDoS», а в том, образуют ли технические, контрактные и человеческие меры проверенную последовательность.

Осмысленное заявление об отказоустойчивости должно было бы указать:

ресурсы, отслеживаемые на предмет исчерпания;
пороговые значения, вызывающие действие;
полномочия на применение смягчения;
доступную внутреннюю и внешнюю мощность;
маршруты, используемые для перенаправления;
обработку легитимного трафика;
запасной план при отказе основного пути смягчения;
сохранённые для анализа доказательства.

Без такой последовательности «у нас есть защита от DDoS» — это описание продукта, а не результат обеспечения отказоустойчивости.

Концентрация может усилить вред, даже если приложения разделены

Учреждения, затронутые через Belnet, не были одной организацией. Среди них были структуры с разными системами управления, технологиями и публичными обязанностями. [7][11]

Общая связность соединила эти различия.

Правительственный департамент мог размещать публичные сайты в одной среде и полагаться на Belnet для доступа персонала. Университет мог использовать сеть для исследовательского трафика, федерации идентификации, удалённого обучения и внешних сервисов. Госпиталь или исследовательский центр могли иметь специализированные потоки данных. Парламентский орган мог зависеть от видео, документов, аутентификации и публичных коммуникаций.

Приложениям не нужно иметь общий код, чтобы сетевой сбой одновременно нарушил их работу.

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

Традиционная карта сервисов может перечислять приложение, базу данных, провайдера идентификации и облачного хостера. Она может опускать путь, по которому пользователи и персонал достигают этих компонентов. Если основное и резервное приложения зависят от одного и того же канала доступа, DNS-резольвера, префикса провайдера или магистрального маршрута, кажущаяся избыточность может исчезнуть при инциденте у провайдера.

Технические ответы Belnet говорят, что учреждения с критическими потребностями в связности могут получить второе подключение через другую точку присутствия и, где возможно, отдельный волоконно-оптический путь. [10] Это важная опция. Она не доказывает, что каждое пострадавшее учреждение имело такое разнообразие или что каждый вторичный путь был независим от того же контура управления DDoS.

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

Пути должны по возможности избегать общих каналов, устройств доступа и электропитания. Они должны заканчиваться в разных точках присутствия. Политика маршрутизации должна позволять трафику переключаться, когда основной путь нарушен. Межсетевые экраны и сервисы идентификации должны принимать альтернативный путь. Публичная DNS и конфигурация удалённого доступа не должны требовать ручных изменений, которые невозможно выполнить во время отключения.

Существует также вопрос закупок.

Резервная связность стоит денег. Государственные учреждения могут оптимизировать расходы, рассчитывая на обычную доступность и предполагая, что национальный сетевой оператор поглотит экстраординарный трафик. Оператор может предлагать базовую связность и опциональное индивидуальное смягчение, сохраняя при этом ответственность за стабильность общей магистрали. Клиенты могут не знать, получают ли они проактивную защиту или только реактивную помощь.

Статья Belnet о мониторинге за 2022 год явно проводит это различие. В ней говорится, что некоторые организации приобрели услугу смягчения с мониторингом, тогда как другие могли получать реактивную помощь. Также упоминается, что внешний облачный центр очистки мог быть задействован, когда атака на клиента угрожала магистральным каналам сети. [6]

Это создаёт по крайней мере три уровня подотчётности:

индивидуальная защита для атакованного клиента;
защита общей инфраструктуры провайдера;
планы непрерывности критических сервисов каждого учреждения.

Эти уровни не следует путать. Провайдер может защитить свою магистраль, заблокировав трафик к цели (blackholing), но сама цель останется недоступной. Клиент может купить очистку, но при этом другая зависимость откажет. Учреждение может содержать второй канал, но оба канала будут зависеть от одного и того же решения вышестоящей системы смягчения.

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

Последовательность реакции показывает, где требовалась власть

Обновления состояния Belnet полезны, потому что они показывают реакцию как последовательность, а не как единое заявление. [1]

В раннем сообщении говорилось о проблемах со связностью и активных мерах смягчения. Более поздние обновления сообщили, что атака продолжалась волнами. Инженеры работали над стабилизацией ситуации и построением альтернативных путей. Они внедряли правила смягчения и мониторили сеть. Ситуация стала более стабильной, но оставались точечные инциденты. Затем Belnet описал механизмы долгосрочной защиты и цепочки эскалации.

Каждый шаг требовал разного рода полномочий.

Мониторинг требовал доступа к сетевой телеметрии и клиентским сообщениям.

Альтернативные пути требовали контроля над маршрутизацией и доступной связностью.

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

Внешняя помощь требовала установленных контактов и разрешения обмениваться информацией о маршрутизации или смягчении.

Восстановление обслуживания клиентов требовало координации с учреждениями, трафик и приложения которых Belnet полностью не контролировал.

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

Федеральный отчёт добавляет координацию кризиса с Центром кибербезопасности Бельгии. [7] Этот шаг важен, потому что сетевой оператор не может самостоятельно определить публично-сервисные последствия каждого клиентского сбоя. Правительственная координация может приоритизировать критические зависимости, обобщить воздействие и поддержать коммуникацию.

Подотчётность должна проверять, были ли эти полномочия ясны до атаки.

Кто мог объявить общесетевой инцидент? Кто мог перенаправлять трафик? Кто мог задействовать внешнюю мощность? Мог ли один инженер выполнить критическое изменение маршрутизации, или требовалось двойное одобрение? Как балансировали скорость и риск изменений? Были ли аварийные контакты доступны внеполосно? Знали ли клиенты, куда сообщать об остаточных сбоях после того, как агрегированные метрики улучшились?

Эти вопросы не подразумевают, что реакция была медленной или некорректной. Открытых данных для такого вывода недостаточно. Они определяют операционные меры, которые должны быть проверяемы после события такого масштаба.

Фраза «под контролем» также требует измеримого определения.

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

Это разные условия.

Процесс подотчётного управления статусом должен связывать публичную фразу с внутренними доказательствами. Он также должен отделять стабилизацию сети от полного восстановления клиентов. Запись статуса Belnet продолжала обсуждать остаточные проблемы и долгосрочную работу после сообщения о стабильности. [1] Эта последовательность поддерживает более точную модель:

сдерживание;
стабилизация сети;
восстановление связности клиентов;
закрытие остаточных инцидентов;
доработка;
проверка.

Объединение их в одну временную метку скрывает операционную истину.

Последующие меры — это свидетельство обучения, а не доказательство предшествовавшей архитектуры

Постинцидентные свидетельства часто слабее записи о самом инциденте. Организации объявляют об инвестициях, не объясняя, какую именно проблему они решают. Более поздние материалы Belnet конкретнее этого, хотя и требуют аккуратной датировки.

Ответы о переходе на адресацию «точка-точка» говорят, что Belnet хотела усилить отказоустойчивость сети после крупной DDoS-атаки 2021 года. Поясняется, что адреса «точка-точка» должны использоваться только для межсоединений и маршрутизации, а конфигурации клиентов должны быть при необходимости приведены в соответствие. [3]

Это осязаемая граница контроля. Дисциплина адресации может упростить защиту, потому что инфраструктурные адреса не рассматриваются как обычные клиентские адреса. Она может уменьшить неоднозначность в маршрутизации и фильтрации. Она может облегчить различение функций межсоединений и адресатов, которые должны получать обычный трафик.

Ответы не доказывают, что неправильное использование адресов вызвало инцидент 2021 года. Корректное утверждение в том, что Belnet связал это изменение с повышением защиты после инцидента.

В статье Belnet о мониторинге за 2022 год говорится, что внешний облачный центр очистки был внедрён в мае 2021 года. Этот уровень используется, когда мощная атака на клиента грозит насыщением остальной сети. [6]

Это тоже конкретно. Защищаемым ресурсом названы магистральные каналы сети, и проводится различие между индивидуальной защитой клиента и общесетевой защитой.

Текущие страницы Belnet «Advanced DDoS Security» описывают трёхуровневую структуру с автоматизированной фильтрацией на маршрутизаторах, внутренним центром очистки и внешним облачным центром очистки. [4][5]

В технических ответах говорится, что детекторы анализируют трафик, входящий в сеть, и могут перенаправить его на внутреннюю очистку. Внешнее перенаправление выполняется вручную, чтобы сохранить контроль при отправке трафика внешней стороне. Также описывается резервированное внутреннее оборудование очистки. [5]

Эти детали показывают, что отказоустойчивость связана с компромиссами.

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

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

Внешняя очистка без постоянного пропускания трафика через неё (out-of-path) позволяет избежать постоянных лишних хопов и снижает риск для обычного сервиса, но она зависит от того, что обнаружение и перенаправление работают в условиях атаки.

Внешняя очистка добавляет мощность и географическое распределение, но вводит ещё одного провайдера, отношения маршрутизации и путь данных.

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

Проверка подотчётности — в том, были ли эти компромиссы протестированы против реального класса сбоя.

Чек о закупке — не тест. Панель продукта — не тест. Успешная демонстрация на низкой нагрузке — не тест.

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

Публичные страницы Belnet описывают механизмы. Полный отчёт о подотчётности связал бы эти механизмы с измеряемыми учениями и результатами инцидентов.

Междоменное смягчение должно быть организовано до того, как канал заполнится

Документы DDoS Open Threat Signaling обеспечивают полезную основу для сравнения, поскольку они адресуют структурную проблему: сеть, страдающая от атаки, может нуждаться в помощи от другого административного домена.

RFC 8612 формулирует требования к сигнализации о смягчении DDoS. RFC 8811 описывает архитектуру, в которой клиент может запросить помощь у провайдера смягчения и получать статус. RFC 8782 определяет сигнальный канал, рассчитанный на враждебные условия. RFC 8903 описывает сценарии использования. RFC 9244 посвящён телеметрии, включая общие каналы связности. [15][16][17][18][19]

Не следует преподносить эти стандарты как доказательство того, что Belnet внедрил DOTS. Их ценность аналитическая.

Они показывают, почему оператор не должен придумывать отношения с сервисной службой во время инцидента.

Сторонам нужны идентификации, аутентификация, авторизация, область действия и контактные пути. Провайдер смягчения должен знать, какие префиксы или услуги контролирует запрашивающая сторона. Изменения в маршрутизации должны приниматься. Телеметрия должна иметь общее значение. Сам сигнальный путь должен выживать в ухудшенных условиях.

Запись статуса Belnet упоминала цепочки эскалации, а более поздние материалы описывают внешнюю облачную очистку. [1][6] Стандарты помогают превратить эти концепции в проверочные вопросы.

Были ли внешние отношения активны до атаки? Были ли клиентские префиксы и политики маршрутизации авторизованы заранее? Мог ли Belnet активировать общесетевую защиту, не дожидаясь каждого клиента? Могли ли отдельные клиенты запрашивать защиту? Какие условия вызывали внешнюю эскалацию? Зависел ли сигнальный и управляющий тракт от перегруженной продакшн-сети? Какой статус возвращался от провайдера смягчения? Какая телеметрия доказывала, что чистый трафик восстановился?

Особенно важна телеметрия общих каналов.

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

Это решение имеет последствия.

Блокировка цели (blackholing) может восстановить общую сеть, но лишить обслуживания саму цель. Очистка может сохранить обслуживание, но добавить задержку или ложноположительные срабатывания. Ограничение скорости может распределить боль между легитимными пользователями. Перемаршрутизация может изменить длину пути и пропускную способность. Ожидание может позволить потоку затронуть не связанных клиентов.

Универсального порога, разрешающего каждый случай, не существует. Порог — это управленческое решение, обусловленное дизайном сети, критичностью клиентов, пропускной способностью и контрактными полномочиями.

Подотчётность означает, что оператор может объяснить это решение с доказательствами постфактум.

Входная фильтрация важна, но не является универсальным объяснением события

RFC 2827 описывает входную фильтрацию сетевого трафика для снижения числа атак, использующих поддельные исходные адреса. RFC 4948 обсуждает ценность и трудности внедрения этого механизма. [13][14]

Эти стандарты уместны в статье о подотчётности DDoS, поскольку атакующий трафик может использовать слабую проверку источников в многих сетях. Операторы, пропускающие поддельные пакеты, перекладывают издержки на жертв и провайдеров смягчения. Широкое внедрение может снизить некоторые классы атак.

Источники по Belnet не сообщают, была ли подмена адресов центральным элементом майской атаки 2021 года.

Эту границу следует сохранять явной.

Если атака использовала скомпрометированные устройства с действительными исходными адресами, входная фильтрация в их сетях могла и не удалить её. Если использовались отражение и усиление с подделанными адресами жертвы, проверка источников могла бы снизить трафик в точке его возникновения. Если были скомбинированы несколько векторов, потребовались бы разные меры.

Открытые источники не позволяют выбрать между этими возможностями.

Корректный анализ подотчётности отделяет политику контроля от причинного утверждения.

Сети должны осуществлять надлежащую проверку источников, потому что это снижает известный класс злоупотреблений и защищает интернет в целом. Это общая обязанность, поддерживаемая стандартами.

Belnet и его партнёры также должны сохранять телеметрию события, достаточную для определения, была ли причиной инцидента подмена, отражение, прямой бот-трафик или прикладные запросы. Это специфическая для события обязанность по доказательствам.

Различие важно, потому что общие рекомендации могут создать ложное чувство завершённости.

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

Выбор мер должен следовать за доказательствами.

Здесь также проявляется экономическая подотчётность. В RFC 4948 отмечается, что некоторые методы фильтрации приносят более заметную пользу другим сетям, чем той, что платит за их развёртывание. [14] Публичные сети и регуляторы могут помочь исправить эту проблему стимулов через закупочные требования, ожидания от пиринга, прозрачность и общие сервисы.

Положение Belnet как оператора публичной сети делает вопрос стимулов особенно актуальным. Он может агрегировать защиту для учреждений, которым было бы трудно купить её по отдельности. Он также может требовать от клиентов и подключённых провайдеров соблюдения дисциплины адресов и маршрутов. Изменение в использовании адресов «точка-точка» — это пример того, как оператор использует правила сервиса для улучшения общей поверхности контроля. [3]

Урок не в том, что одна лучшая практика предотвратила бы отключение. Он в том, что отказоустойчивость общей сети зависит от мер, развёрнутых через организационные границы, и для выбора правильных нужны доказательства.

На подключённых учреждениях тоже лежали обязанности по непрерывности

Belnet контролировал общую сеть. Это не означает, что все обязанности по непрерывности принадлежали Belnet.

Подключённые учреждения контролировали, что происходит после ухудшения связности.

Они могли определять критические приложения, поддерживать альтернативный доступ, разделять публичные и административные каналы, сохранять внеполосные коммуникации, тестировать аварийное переключение удалённой работы и решать, какие сервисы требуют независимых провайдеров.

Практические возможности различались. Небольшая исследовательская организация не могла построить национальную сеть очистки. Министерство не могло переконфигурировать магистраль Belnet. Университет не мог в одностороннем порядке задействовать вышестоящего провайдера смягчения для маршрутов, принадлежащих Belnet.

Ответственность должна соответствовать этой реальности.

Учреждения не должны обвиняться за меры, которые они не могли реализовать. Они несут ответственность за выборы в пределах своих полномочий.

Для сервиса записи на вакцинацию это могло бы включать вторичный публичный путь доступа, проверенную аварийную схему DNS, кешированные информационные страницы, аварийный вариант с колл-центром и ясный статусный канал.

Для парламентской работы это могло бы включать альтернативный путь конференцсвязи или документооборота и способ продолжать важные заседания без основной сети.

Для университетов — независимые аварийные коммуникации, локальный доступ к критическим системам и документированные ограничения на услуги удалённого обучения или исследования.

Для правительственных департаментов — реестр зависимостей, показывающий, какие функции полагаются на Belnet для публичного доступа, доступа персонала, идентификации, межведомственного обмена и коммуникации в ходе инцидента.

Эти меры требуют координации с сетевым провайдером.

Вторая линия полезна, только если учреждение знает, не разделяет ли она с первой точку присутствия, волоконно-оптический маршрут, вышестоящий канал или зависимость от системы смягчения. Аварийная схема DNS полезна, только если авторитетный DNS и доступ к управлению остаются доступными. Резервный сервис удалённого доступа полезен, только если идентификация и конечные точки могут его достичь.

Технические ответы Belnet описывают опции второй точки присутствия и отдельного волоконно-оптического пути. [10] Учреждения должны иметь возможность перевести эти опции в специфичные для сервисов решения о рисках.

Государственные закупки могут поддержать это, задавая вопросы:

Какие физические и административные домены сбоев независимы?
Является ли защита от DDoS проактивной или реактивной?
Какая мощность зарезервирована?
Кто может инициировать смягчение?
Какие цели по восстановлению применяются к общей сети и к отдельным клиентам?
Какая телеметрия и какие постинцидентные доказательства будут предоставлены?
Как авторизуются и проверяются аварийные изменения?

Эти вопросы не позволяют свести отказоустойчивость в контракте к проценту аптайма, который мало говорит о коррелированных атаках.

Публичная коммуникация статуса — часть контура управления восстановлением

Во время сетевого инцидента коммуникация неотделима от операций. Она влияет на решения клиентов, эскалацию и доказательства.

Страница статуса Belnet давала повторные обновления по мере изменения атаки. [1] Сообщения идентифицировали проблемы со связностью, продолжающиеся волны, работу по смягчению, альтернативные пути, стабилизацию и остаточные проблемы.

Такой темп важен для учреждений, решающих, активировать ли локальные планы непрерывности.

Расплывчатое «расследуем» может оставить клиентов в ожидании, пока их собственное окно аварийного переключения закрывается. Излишне уверенное «устранено» может заставить учреждения отключить временные меры до того, как все пути стабильны. Детальное техническое сообщение может создать риск безопасности или запутать неспециалистов.

Правильная публичная запись должна отвечать на операционные вопросы, не раскрывая чувствительную конфигурацию:

Проблема в общей сети?
Какой общий класс сервиса затронут?
Продолжается ли атакующий трафик?
Активно ли смягчение?
Восстанавливаются ли клиенты с разной скоростью?
Следует ли учреждениям сохранять локальное аварийное переключение?
Куда сообщать об остаточных инцидентах?
Когда поступит следующее обновление?

Запись статуса также становится доказательством.

Её можно сопоставить с телеметрией маршрутизаторов, журналами провайдера смягчения, клиентскими заявками и кризисными решениями. Расхождения могут выявить задержку обнаружения, неполную оценку воздействия или пробелы в восстановлении.

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

Федеральная парламентская запись демонстрирует ещё один коммуникационный слой: публичный надзор. [7] Должностным лицам требовалось объяснить масштаб, институциональное воздействие, координацию и превентивные меры. Полезный надзорный процесс должен запрашивать доказательства, не принуждая к раскрытию деталей, пригодных для эксплуатации.

Вопросы должны фокусироваться на контроле и доказательствах:

Какой общий ресурс был ограничен?
Какая мощность смягчения существовала?
Что изменилось в ходе реакции?
Какие учреждения не имели независимых путей?
Какая последующая мера устраняла какой наблюдавшийся сбой?
Как был протестирован ремонт?

Спрашивать только «кто атаковал» — значит оставить урок по инфраструктуре невыученным.

Заявление о восстановлении должно быть специфичным для сервиса и независимо проверяемым

Сетевые операторы нередко сообщают об агрегированной стабильности до того, как восстановился каждый клиент. Это не обязательно вводит в заблуждение. Магистраль может быть стабильна, в то время как локальные сессии, маршруты или приложения остаются нарушенными.

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

Последовательность статуса Belnet двигалась от активных волн и альтернативных путей к правилам смягчения, стабилизации, остаточным инцидентам и долгосрочной работе. [1] Это поддерживает многоступенчатую модель восстановления.

Сдерживание

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

Стабилизация сети

Загрузка магистрали и магистральных каналов остаётся в безопасных границах. Маршрутизация и смягчение перестают осциллировать. Основной мониторинг надёжен.

Восстановление связности клиентов

Подключённые учреждения могут обмениваться трафиком по ожидаемым путям. Исключения выявляются, а не скрываются в средних значениях.

Восстановление сервисов

Публичные сайты, удалённый доступ, идентификация, видео, исследования и другие функции проверяются извне учреждения.

Закрытие остаточных инцидентов

Специфичные для клиентов проблемы с маршрутами, фильтрами, состояниями или последней милей устраняются.

Проверка доработок

Исходный класс сбоя воспроизводится или симулируется при изменённых мерах контроля, с откатом и доказательствами.

Каждая стадия должна иметь критерии выхода.

Для сдерживания критериями могут быть снижение потерь пакетов, доступная чистая пропускная способность и стабильные ресурсы маршрутизаторов.

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

Для восстановления клиентов — репрезентативные пробы по точкам присутствия и классам клиентов.

Для восстановления сервисов учреждениям нужны проверки на уровне приложений. Интерфейс может быть достижим, в то время как аутентификация, транзакции или удалённая работа остаются сломанными.

Независимое тестирование важно, потому что повреждённый или перегруженный контур управления может сообщать о собственном здоровье.

Внешние пробы, клиентские замеры и отдельные пути управления могут оспорить внутреннее представление оператора. Они не заменяют операторскую телеметрию, но снижают риск объявления успеха на основе тех же систем, которые ремонтируются.

Более позднее руководство CISA по DDoS подчёркивает планирование, координацию с провайдерами и многоуровневое реагирование. [20] Оно полезно для сравнения, но не как свидетельство о процедуре Belnet в 2021 году.

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

Пакет доказательств, который подотчётная публичная сеть должна сохранять

Постинцидентный отчёт не обязан публиковать чувствительные конфигурации маршрутизаторов. Однако он должен сохранить достаточно доказательств, чтобы клиенты, органы власти и независимые проверяющие могли понять, что произошло.

Пакет должен начинаться с обеспечения целостности на момент фиксации.

Выборки телеметрии, снимки конфигураций, правила смягчения, изменения маршрутизации и отчёты должны иметь временные метки, принадлежность и криптографические хеши. Если доказательство пересматривается, в пересмотре должна быть указана заменённая версия и причина.

Он должен включать карту зависимостей.

Карта должна идентифицировать магистральные каналы, точки присутствия, вышестоящих провайдеров, провайдеров смягчения, пути управления, статусные каналы и классы клиентов. Она должна показывать общие ёмкости, не раскрывая излишних деталей устройств.

Он должен включать хронологию событий.

Хронология должна различать первый вредоносный трафик, обнаружение, воздействие на клиентов, объявление инцидента, кризисную эскалацию, альтернативные пути, фильтрацию, внутреннюю очистку, внешнюю очистку, стабилизацию, восстановление клиентов и закрытие.

Он должен включать доказательства по ресурсам.

Какие каналы, ресурсы пересылки или сервисы приблизились к пределам? Каков был базовый уровень чистого трафика? Какие классы атак наблюдались? Какая телеметрия оставалась надёжной под нагрузкой?

Он должен включать доказательства по действиям.

Какие правила изменились? Кто их утвердил? Какие маршруты переместились? Какие возникли побочные эффекты? Как изменения были откачены или сохранены?

Он должен включать доказательства по клиентам.

Сколько учреждений было существенно затронуто? Какие классы сервисов отказали? У кого был независимый доступ? Как собирались и закрывались остаточные инциденты?

Он должен включать доказательства по коммуникациям.

Когда выпускались обновления статуса? Какая информация была доступна на каждый момент времени? Были ли критические учреждения оповещены по внеполосным каналам?

Он должен включать доказательства доработок.

Какие последующие меры адресуют какой наблюдавшийся сбой? Как были верифицированы изменения адресации «точка-точка»? Когда стала доступна внешняя очистка? Какие тесты показали, что текущая многоуровневая защита может защитить и цель, и общую сеть?

Он должен включать неопределённости.

Неизвестная атрибуция, отсутствующие детали пакетов, неполные клиентские данные и допущения должны быть перечислены, а не молчаливо разрешены.

Такой пакет превращает подотчётность из риторики в проверяемый процесс.

Он также защищает оператора. Доказательства могут показать, что команды действовали быстро, что атака превысила разумные проектные допущения, что клиенту не хватало приобретённой меры или что действие вышестоящего оператора ограничило ответ. Подотчётность — это не презумпция вины оператора. Это метод распределения ответственности согласно доказательствам и контролю.

Надзор должен связывать доработки с наблюдаемым сбоем

Федеральное парламентское обсуждение спрашивало о предотвращении, технической эволюции, инвестициях и оценке. [7] Это уместные вопросы, но они могут породить общие ответы, если не привязаны к механизму сбоя.

«Мы инвестировали в кибербезопасность» — недостаточно.

Надзорная запись должна связывать каждую затрату с мерой контроля:

дополнительная внутренняя очистка увеличивает мощность в определённой точке сети;
внешняя очистка защищает магистральные каналы сверх локальной мощности;
обнаружение на маршрутизаторах сокращает время до идентификации адресата под атакой;
дисциплина адресов «точка-точка» упрощает фильтрацию и маршрутизацию;
разделённые пути управления сохраняют полномочия на реагирование;
вторичные точки присутствия снижают концентрацию путей доступа;
учения проверяют активацию и восстановление.

FAQ по «точке-точке» и более поздние описания DDoS-сервиса делают такое сопоставление возможным. [3][4][5][6]

Надзор должен также спрашивать о покрытии сервисов.

Если лишь некоторые клиенты приобретают проактивное смягчение, какую защиту предоставляет общая сеть, когда целью становится незащищённый клиент? Когда Belnet может действовать без одобрения клиента, чтобы защитить другие учреждения? Что происходит с целевым сервисом во время такого действия? Подпадают ли критически важные публичные сервисы под более жёсткие базовые требования?

Это в равной мере политические и технические решения.

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

Дизайн должен быть явным.

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

Настоящая проверка подотчётности — готовность до следующей волны

Инцидент Belnet 2021 года был динамичным. Страница статуса описывала последовательные волны и меняющееся смягчение. [1]

Это полезная модель для тестирования отказоустойчивости.

Тест не должен посылать один предсказуемый поток на один защищённый сервис и останавливаться, когда панель загорается зелёным.

Следует варьировать адресаты, протоколы и объёмы в безопасных контролируемых пределах. Следует тестировать защищённого клиента и незащищённого клиента, чей трафик угрожает общей мощности. Следует тестировать внутреннюю и внешнюю очистку. Следует тестировать распространение маршрутов, обратные пути и откат. Следует тестировать ложноположительные срабатывания и легитимные высокообъёмные события.

Следует также тестировать людей.

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

Следует тестировать доказательства.

Выживают ли телеметрия и временные метки? Может ли оператор восстановить, какое правило повлияло на какой трафик? Могут ли клиентские пробы подтвердить восстановление? Может ли независимый проверяющий воспроизвести вывод?

Следует тестировать отказ самой системы смягчения.

Что произойдёт, если внутренний скруббер недоступен? Что, если у облачного провайдера инцидент в управляющем контуре? Что, если перенаправление маршрута задерживается? Что, если фильтр блокирует критический легитимный трафик? Что, если статусная платформа зависит от затронутого пути?

Именно здесь текущие описания архитектуры становятся подотчётными элементами управления. [4][5]

Ценность трёх уровней не в числе три. Она в том, что каждый уровень имеет определённую роль, границу сбоя, триггер и аварийный режим. Если все уровни зависят от одного и того же детектора, управляющего идентификатора или пути маршрутизации, кажущееся разнообразие всё равно может скрывать общую причину отказа.

Поэтому тест должен спрашивать не только, поглощает ли система трафик, но и сохраняет ли организация контроль и доказательства при изменении условий.

Заключение: общие сети создают общую обязанность доказывать отказоустойчивость

Майский инцидент Belnet 2021 года не сделал непрерывность публичных услуг сетевой проблемой. Он показал, что она уже была таковой.

Правительственные, образовательные, исследовательские и другие учреждения зависели от общей сети. Крупная объёмная атака вызвала проблемы со связностью во всех этих организациях. Belnet отреагировал альтернативными путями, правилами смягчения, кризисной координацией и долгосрочной работой. Более поздние записи связывают период инцидента с внедрением внешней очистки, дисциплиной адресации и более многоуровневой архитектурой защиты от DDoS. [1][2][3][4][5][6][7]

Имеющиеся данные не позволяют назвать злоумышленника, точный объём трафика, полный векторный анализ или заключение, что одна отсутствующая мера вызвала отключение.

Они поддерживают ясную основу для подотчётности.

Belnet обладал практическим контролем над магистральными операциями, общесетевым смягчением, перемаршрутизацией, кризисной эскалацией и доказательствами, необходимыми для объяснения восстановления.

Подключённые учреждения обладали практическим контролем над вторичным доступом, непрерывностью приложений, картами критических зависимостей и локальными аварийными планами.

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

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

Ответственность злоумышленника за вредоносный трафик не снимает этих обязанностей. Как и подотчётность инфраструктуры не подразумевает, что любой сбой доказывает халатность.

Надлежащий тест состоит в том, может ли каждая сторона показать, что её контроль был соразмерен вреду, который она могла предотвратить или усилить.

Для общей публичной сети такое доказательство должно охватывать пропускную способность, обнаружение, альтернативные пути, очистку, полномочия на эскалацию, сохранность легитимного трафика, восстановление клиентов и протестированные доработки.

Возвращение сервиса — это операционное достижение. Демонстрация того, почему сеть стала более отказоустойчивой, какие риски остаются и как этот вывод был верифицирован, — это результат подотчётности.

DDoS-атака на сеть Belnet в 2021 году сделала устойчивость общей публичной сети проверкой на подотчётность

Почему это важно