Обнаружение и реакция — Информационная безопасность

14.1. Фильтрация трафика на границе сети

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

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

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

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

Фильтрация пакетов (сетевой и транспортный уровни). Решение принимается только по заголовку: адреса, протокол, номер порта. На этом уровне невозможно отличить легальный ответ на свой запрос от сообщения, пришедшего по чьей-то инициативе снаружи.
Контроль состояния соединения (сеансовый уровень). Экран ведет таблицу начатых соединений, и ответный пакет проходит на том основании, что был запрос, привязанный к определенному порту. Разрешение сужается до тех пар, которые система завела сама. При этом таблица конечна и при желании ее можно легко переполнить, инициировав множество не доведенных до конца соединений, в результате прекратится обслуживание всех новых запросов.
Разбор протокола (прикладной уровень). Здесь экран становится стороной обмена. Он принимает соединение на себя, читает метод и адрес запроса HTTP, имя команды, тип вложения, и открывает второе соединение к настоящему получателю. Данных хватает, чтобы выразить, например, запрет загружать исполняемые файлы. Под каждый протокол пишется отдельный анализатор, который первым принимает данные потенциального противника.

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

Место установки от глубины разбора не зависит. Требования ФСТЭК России различают пять типов межсетевых экранов (приказ ФСТЭК России от 9 февраля 2016 г. № 9):

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

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

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

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

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

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

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

14.2. Эшелонированная защита

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

Классическое решение заключается в делении сети на сегменты. Между внешней сетью и внутренней размещают демилитаризованную зону (ДМЗ): в нее выносят серверы, к которым обращаются снаружи, то есть веб-сервер, почтовый сервер и т.д. Снаружи доступна только ДМЗ, а проход из нее во внутреннюю сеть закрыт или сведен к нескольким разрешенным обращениям. Таким образом, захват веб-сервера дает противнику доступ к ДМЗ, но не к базе данных.

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

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

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

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

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

14.3. Модель нулевого доверия

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

По этой причине в последние годы в тренде находится модель нулевого доверия (zero trust) – построение защиты, при котором ни сеть, ни узел, ни ранее выданный доступ сами по себе не дают прав, а решение принимается для каждого обращения отдельно.

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

На практике это дает:

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

Ограничения модели:

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

14.4. Регистрация событий безопасности

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

Состав записи определяется тем, что по ней потребуется восстановить. Без любого из пяти сведений (кто, что сделал, над чем, когда и с каким результатом) не восстанавливается ничего. Полноту записи выбирают между двумя крайностями:

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

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

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

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

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

14.5. Обнаружение вторжений и реакция на инцидент

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

Система обнаружения вторжений (СОВ) – средство, которое анализирует сетевой трафик или события на узле и сообщает о признаках атаки. Требования ФСТЭК России различают СОВ уровня сети и уровня узла и устанавливают шесть классов защиты (приказ ФСТЭК России от 6 декабря 2011 г. № 638). Признаки ищут по сигнатурам и по отклонению от обычного поведения, как и в средствах защиты от вредоносных программ.

СОВ размещается двумя способами:

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

Как и любое распознающее средство, СОВ дает и ложные допуски, и ложные отказы, а баланс между ними (порог обнаружения) настраивается в соответствии с моделью угроз.

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

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

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

Часть этих сроков задана законом. Субъект критической информационной инфраструктуры сообщает о компьютерном инциденте в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА). На это отводится три часа для значимых объектов и сутки для остальных (приказ ФСБ России от 19 июня 2019 г. № 282). Оператор персональных данных уведомляет Роскомнадзор об утечке в течение суток и сообщает результаты внутреннего расследования в течение трех суток (152-ФЗ). Отсчет везде идет от момента обнаружения, поэтому все, что происходило до него, сроком не ограничено.

Обнаружив противника в системе, выбирают между двумя действиями:

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

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

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

14.6. Этапы атаки и жизненный цикл уязвимости

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

Классической моделью служит цепочка поражения (kill chain), предложенная в Lockheed Martin в 2011 году. В ней семь этапов:

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

Порядок этапов не обязателен. Часть пропускается (украденный пароль отменяет первые четыре), часть повторяется на каждом новом узле. Более подробное описание, где вместо семи этапов перечислены сотни приемов, ведет MITRE под именем ATT&CK.

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

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

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

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

Длину этого окна определяет порядок раскрытия. Нашедший уязвимость выбирает между немедленной публикацией и согласованным с разработчиком сроком. Немедленная публикация вынуждает исправлять быстро и одновременно вооружает всякого, кто ее прочитает. Согласованный срок (обычно 90 дней) дает время на исправление, но все это время пользователи не знают, чем рискуют. Принятой практикой стало второе, причем срок объявляют заранее и по его истечении публикуют независимо от того, готово исправление или нет.

Чтобы разработчик, исследователь и службы безопасности могли обсуждать многочисленные уязвимости на одном языке, каждой найденной уязвимости присваивают номер в общем перечне CVE (Common Vulnerabilities and Exposures, перечень известных уязвимостей). Перечень с 1999 года ведет американская организация MITRE, номер имеет вид CVE-2021-44228, где указаны год и порядковый номер, а выдают номера уполномоченные организации, в том числе сами производители программ.

Тяжесть уязвимости оценивают по шкале CVSS (Common Vulnerability Scoring System, общая система оценки уязвимостей), которую ведет международное объединение групп реагирования FIRST. Балл считают от 0 до 10 по свойствам самой уязвимости, то есть по тому, как ее используют, нужен ли для этого доступ в систему, требуется ли участие пользователя и т.д. В России тот же материал собран в банке данных угроз ФСТЭК России, где уязвимости имеют собственные номера, привязаны к записям CVE и снабжены оценкой CVSS. Балл описывает уязвимость, а не систему, в которой она нашлась, поэтому мерой риска он не служит. Риск получается, если добавить ценность того, что стоит за уязвимой программой, и достижимость этой программы для противника. Уязвимость с баллом 9 в системе без внешнего доступа ждет очереди, уязвимость с баллом 5 на общедоступном сервере не ждет.

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

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

14.7. Принципы проектирования защищенных систем

В 1975 году Джером Зальцер и Майкл Шредер собрали требования к конструкции защищенной системы в список из восьми пунктов. Этот список считается настолько универсальным и полным, что не пересматривался с тех пор, хотя появился до персональных компьютеров, сетей общего пользования и облачных служб. Почти со всеми пунктами списка мы уже знакомы.

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

Безопасные умолчания. Доступ выдается перечислением разрешенного, а не запрещенного: ошибка в перечне разрешенного отнимает права у своих и обнаруживается в первый же рабочий день, ошибка в перечне запрещенного отдает права чужим и не обнаруживается никогда.
Полное посредничество. Проверяться должно каждое обращение к объекту, включая повторные. В чистом виде требование дорого, поэтому решение обычно запоминают на время и следующие обращения пропускают по сохраненному ответу. Пока ответ хранится, отозванное право продолжает действовать, и чем длиннее срок хранения, тем дольше система работает по отмененному решению.
Открытость конструкции. Стойкость держится на секретности ключа, а устройство механизма можно опубликовать. Принцип Керкгоффса есть частный случай этого требования, сформулированный для шифров.
Разделение полномочий. Действие с необратимыми последствиями требует согласия двух сторон, и один человек его не выполняет.
Минимум привилегий. Субъект получает права, необходимые для его работы, и на время этой работы. Разрешения приложения на телефоне и разделение обычной учетной записи с административной устроены по этому требованию.
Минимум общего механизма. Все, чем два субъекта пользуются сразу, служит каналом между ними. Общий кэш процессора выдает ключ шифрования, общее время выполнения выдает длину совпавшей части пароля.
Психологическая приемлемость. Механизм должен отвечать представлениям пользователя о задаче, иначе его станут обходить. Правило, которое невозможно соблюсти, порождает обходной путь.

Еще два требования авторы пометили как переносимые на вычислительные системы лишь отчасти:

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

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

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