Противодействие реальным угрозам АСУ ТП

Это значит, что специалисты в большинстве случаев либо производственники (с базовыми знаниями в области информационной безопасности), либо "традиционные" безопасники (с базовыми знаниями в области АСУ ТП). В результате мы получаем либо недооценку угроз (слишком АСУ-шный подход), либо ситуацию, когда меры безопасности противоречат задачам нормального функционирования производственных процессов.

В рамках статьи я постараюсь внести дополнительную ясность в понимание реальных угроз ИБ АСУ ТП, раскрыть их природу и рассмотреть основные способы борьбы с ними.

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

Первое, что нужно понимать: на внешние угрозы приходится от 40% до 70% (зависит от отрасли). В среднем для АСУ ТП можно констатировать большее (чем в среднем по отраслям) количество внутренних угроз ввиду большей замкнутости информационных систем. Т.е. в случае АСУ ТП распределение внешних и внутренних угроз примерно одинаковое. Поэтому для АСУ ТП одинаково приоритетна борьба как с внутренними, так и с внешними угрозами ИБ. Да и в других отраслях нельзя пренебрегать ни внешними, ни внутренними угрозами, что должно отражаться в их моделях.

Второе – в силу природы АСУ ТП нам необходимо в первую очередь рассматривать угрозы целостности и доступности.

В-третьих, нужно понять причины реализации угроз АСУ ТП и определить, на чем концентрировать внимание при проектировании и построении систем ИБ АСУ ТП.

На рис. 1 представлено распределение по категориям угроз ИБ АСУ ТП (анализировались открытые источники).

В таблице приведены (более детально) причины реализации угроз АСУ ТП.

Данные причины сгруппированы по категориям, указанным на рис. 1. Категорирование позволяет более точно определить приоритеты в ИБ (нежели помещение в одну статистику разных по природе вещей).

Основные угрозы¹

Под категорию "Иное" можно отнести сценарии реализации социальной инженерии (более интересно в контексте рассмотрения административных мер контроля).

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

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

Непредсказуемые угрозы

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

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

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

Почему данная угроза (конечно, когда Fuzzing используют злоумышленники) – самая непредсказуемая и опасная? Все просто: существует бесконечное количество вариантов воздействия и такое же количество реакций системы. Спрогнозировать их все заранее невозможно. При этом эксплуатация того же Buffer Overflow (как и любой уязвимости другого типа) может также являться результатом Fuzzing (фактически, частный случай). Впрочем, цель атакующего как раз лежит в поле множества конкретных, необходимых ему реакций системы (см. рис. 2).

При этом одним из наиболее распространенных и в то же время опасных последствий реализации Fuzzing являются атаки класса Race Condition.²

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

Один из вариантов Race Condition – подать на вход некорректную (для данного ПО) последовательность данных. В сетевом смысле – это воздействие сетевым трафиком, сгенерированным "не по RFC", как уже описывалось выше.

Что можно в данной ситуации сделать для исключения данной угрозы? Для исключения – ничего. В программировании есть ряд лучших практик (правила работы с переменными, прерываниями и т.д.) для минимизации (но не исключения) уязвимостей рас-синхронизации. Можно ли, как в случае конфигурационных ошибок, контролировать уровень данных угроз? Можно, но в значительно меньшей степени.

Для промышленности, АСУ ТП, критичных систем инфраструктуры, категорированных систем это значит ровным счетом одно: любой межсетевой экран, любое устройство безопасности, маршрутизатор и коммутатор, любое программно-аппаратное средство могут быть взломаны, уязвимости могут быть эксплуатированы. И вариантов – много. Вопрос лишь в том, сможет ли злоумышленник смоделировать данную систему. Казалось бы, это не новость, на уровне подсознания все понимают, что программная реализация ненадежна по своей природе. Но не всегда и очевидна природа данных явлений.

Если вы подумали, что в реальной жизни это все малоосуществимо и из области фантастики, то я советую зайти на любой авторитетный сайт (например, базу уязвимостей CVE³) и ввести в поиске "Race Condition" (рис. 4).

Вы обнаружите огромное количество найденных уязвимостей Race Condition ведущих производителей ПО и сетевого оборудования. Например, каждый месяц публикуются новые уязвимости Race Condition, результатом которых является выключение списков контроля доступа (Access Lists) на популярных межсетевых экранах и маршрутизаторах! Кстати, соотношение Race Condition c Buffer Overflow по статистике – примерно 1 к 15. Почему в сетевом мире уязвимости Race Condition более непредсказуемы (и потенциально более опасны), чем Buffer Overflow? Потому что эксплуатация последних в большей степени предполагает воздействие по конкретным сетевым портам на конкретные сервисы. Race Condition же может произойти при "случайном" воздействии легальным и даже в некоторых случаях "сквозным" сетевым трафиком: активным сервисам устройства необязательно "слушать порты" на данном протоколе, на устройстве в принципе вообще может быть включено правило Deny Any, но Fuzzing и Race Condition будут успешно реализованы.

Кто злоумышленники и как с ними бороться?

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

Что делать? Приведем краткий, но глобальный перечень рекомендаций по защите АСУ ТП:

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