Контакты
Подписка
МЕНЮ
Контакты
Подписка

Защита КИИ: от слов к делу

Защита КИИ: от слов к делу

В рубрику "В фокусе" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Защита КИИ: от слов к делу

Федеральный закон “О безопасности критической информационной инфраструктуры Российской Федерации” вступил в силу почти полтора года назад, но до сих пор основной темой обсуждения на профильных круглых столах остается категорирование объектов КИИ. И хотя закон фактически не ограничивает сроки проведения категорирования, наступила пора двигаться дальше – приводить защиту значимых объектов КИИ в соответствие с требованиями ФСТЭК. Попробуем разобраться, как подступиться к этой задаче.
Дмитрий Кузнецов
Директор по методологии и стандартизации Positive Technologies

Формирование требований к системе безопасности значимого объекта КИИ

Трудности поджидают субъекта уже на первом шаге: установить требования к системе защиты принадлежащего ему объекта КИИ он должен самостоятельно. Процедура определения требований выглядит следующим образом.

Порядок создания системы защиты значимого объекта КИИ установлен приказом ФСТЭК от 25 декабря 2017 г. № 239 "Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации" и включает в себя следующие шаги:

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

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

Приказ № 239 устанавливает для каждой категории значимости объектов КИИ т.н. базовый набор мер безопасности. Базовые меры являются необходимыми и должны быть реализованы на всех объектах КИИ данной категории значимости. При этом возможна ситуация, когда реализовать какую-то из базовых мер безопасности на отдельном объекте невозможно в силу технических или иных ограничений (например, производитель оборудования может запрещать установку на него дополнительного программного обеспечения, в том числе антивирусов). В этом случае субъект вправе отказаться от такой меры безопасности, но при этом он должен оценить, реализация каких угроз становится при этом возможна, и принять какие-то иные меры для защиты от них. Приказ называет это адаптацией базового набора мер безопасности.

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

Но это всего лишь перечень мер безопасности, который еще нужно превратить в требования к ним. ФСТЭК уже больше года ведет работу над методическим документом, раскрывающим содержание мер безопасности. Пока вместо него можно использовать другой методический документ, "Меры защиты информации в государственных информационных системах"1, большая часть мер безопасности для государственных информационных систем (ИС) и для значимых объектов КИИ совпадает. Для каждой базовой меры документ содержит 1–2 страницы пояснений, как именно эта мера должны быть реализована, и на основе этих пояснений субъект должен формировать техническое задание на создание или модернизацию системы безопасности. Вот как это работает.

Возьмем для примера такую меру безопасности, как АВЗ.1 “Реализация антивирусной защиты”, которая является базовой для значимых объектов КИИ всех категорий значимости. В соответствии с методическим документом эта мера безопасности включает в себя:

  • применение средств антивирусной защиты на всех компонентах, подверженных заражению вредоносными программами;
  • установку, конфигурирование и управление средствами антивирусной защиты;
  • предоставление средствам антивирусной защиты необходимых прав доступа;
  • проведение периодических проверок компонентов на наличие вирусов;
  • проведение проверок загружаемых, открываемых и запускаемых файлов в режиме реального времени;
  • оповещение администраторов безопасности о выявлении вирусов в режиме реального времени;
  • определение действий, которые должны выполняться при обнаружении вирусов.
На сегодняшний день сложилась порочная практика, когда вместо подробных требований к мерам безопасности в технические задания на ИС включают отсылку типа II должна быть обеспечена безопасность информации в соответствии с требованиями нормативных документов ФСТЭК России”. Еще раз подчеркнем, что в случае объектов КИИ никаких общих требований не существует: субъект обязан самостоятельно определить и ясно сформулировать требования к мерам безопасности, используя методические документы ФСТЭК лишь как справочные материалы.

Эти требования являются общими, т.е. должны быть выполнены при реализации антивирусной защиты на всех объектах КИИ. Кроме них, документ содержит т.н. требования усиления, которые субъект КИИ должен включить в техническое задание, если считает общие требования недостаточными. Таким образом, даже столь очевидная мера безопасности, как реализация антивирусной защиты, должна превратиться в довольно подробный перечень требований, которые необходимо включить в техническое задание на создание или модернизацию системы безопасности. Часть этих мер должна быть реализована техническими средствами, часть – отражена в эксплуатационной и нормативной документации системы безопасности.

К сожалению, на сегодняшний день сложилась порочная практика, когда вместо подробных требований к мерам безопасности в технические задания на ИС включают отсылку типа "должна быть обеспечена безопасность информации в соответствии с требованиями нормативных документов ФСТЭК России". Еще раз подчеркнем, что в случае объектов КИИ никаких общих требований не существует: субъект обязан самостоятельно определить и ясно сформулировать требования к мерам безопасности, используя методические документы ФСТЭК лишь как справочные материалы. Отсутствие в техническом задании подробных требований означает, что субъект не выполнил предписанные приказом № 239 действия по выбору, адаптации и усилению мер защиты, что само по себе является нарушением требований ФСТЭК по обеспечению безопасности значимого объекта КИИ.

Моделирование угроз

Как упоминалось выше, базовый набор мер защиты, установленный приказом № 239, является необходимым, но недостаточным для обеспечения безопасности значимого объекта КИИ. Для того чтобы его дополнить, необходимо провести анализ угроз. В соответствии с требованиями ФСТЭК анализ угроз включает в себя:

  • определение источников угроз и возможностей нарушителей;
  • анализ возможных уязвимостей значимого объекта КИИ;
  • определение возможных способов реализации угроз;
  • оценка возможных последствий реализации угроз.

К сожалению, в нормативных документах ФСТЭК нет указаний на методики проведения анализа угроз. Зато за прошедшие годы накопился богатый опыт примеров недобросовестного проведения такого анализа, поэтому для начала остановимся на них.

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

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

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

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

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

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

Моделировать действия на основе подобных сценариев (сейчас их модно называть Cyber Kill Chain) можно и на основе только описаний угроз из БДУ ФСТЭК, но они не всегда достаточно информативны. Поэтому приходится использовать и другие источники:

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

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

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

Внедрение мер безопасности и приемка системы защиты

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

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

Приказ № 239 требует использовать БДУ в качестве одного из источников исходных данных для анализа угроз. Пытаясь выполнить данное требование, исследователь натыкается, например, на угрозу "УБИ.063: угроза некорректного использования функционала программного и аппаратного обеспечения". В соответствии с описанием "угроза заключается в возможности использования декларированных возможностей программных и аппаратных средств определенным (нестандартным, некорректным) способом с целью деструктивного воздействия на ИС и обрабатываемую ею информацию", а ее реализация может привести к нарушению конфиденциальности, доступности и целостности защищаемой информации. Какие выводы можно сделать из такого описания? Никаких. Подобное описание угрозы никак не помогает нам оценить, актуальна ли она для защищаемого объекта, и если актуальна, то как от нее защититься.

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

Методические документы ФСТЭК определяют две формы сертификации: на соответствие техническим условиям и на соответствие профилю защиты. Профиль защиты – это нормативный документ ФСТЭК, который определяет, какие функции безопасности должны быть реализованы в данном виде средств защиты. Если средство защиты имеет сертификат на соответствие профилю защиты, пользователь может быть уверен, что эти функции безопасности действительно реализованы. На сегодняшний день профили защиты разработаны для функций безопасности операционных систем, межсетевых экранов (включая WAF и специализированные межсетевые экраны для АСУ ТП), средств контроля отчуждаемых носителей, средств доверенной загрузки, средств антивирусной защиты и средств обнаружения вторжений.

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

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

  • испытания механизмов защиты программного продукта проводятся до или в процессе создания, например, для того, чтобы оценить, насколько они пригодны для реализации мер защиты;
  • приемка проводится в целом в порядке, предусмотренном приказом № 239, и включает в себя испытания функций безопасности всех компонентов.
Приказ № 239 не ограничивает выбор системы сертификации, т.е. легитимным подтверждением соответствия средства защиты требованиям безопасности являются как сертификаты системы обязательной сертификации ФСТЭК России, так и сертификаты добровольных систем сертификации, при условии, что сертификация проводилась в соответствии с методическими документами ФСТЭК.

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

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

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

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

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

И как же все это организовать?

Вступление в силу приказа № 239 фактически означает, что для каждого значимого объекта КИИ должна быть проведена модернизация системы защиты. Теоретически возможно, что некоторые объекты изначально будут соответствовать требованиям ФСТЭК, но они будут скорее исключением из общего правила.

Модернизация системы защиты (а для некоторых ИС это будет означать создание системы защиты с нуля) требует серьезных бюджетов и времени. А время ограничено: до 1 сентября 2019 г. субъектам рекомендовано завершить разработку перечня объектов КИИ, соответственно, к 1 сентября 2020 г. ФСТЭК ожидает завершения категорирования объектов КИИ и в 2024 г. можно ожидать масштабные проверки. Получается, что все работы по модернизации систем безопасности значимых объектов КИИ нужно завершить в ближайшую пятилетку.

К счастью, это не так. Кроме приказа № 239 есть приказ ФСТЭК от 21 декабря 2017 г. № 235 “Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования”. Особенность этого приказа в том, что он первым в российской нормативной базе устанавливает необходимость руководствоваться моделью PDCA. В соответствии с этим приказом создание системы безопасности значимого объекта КИИ – не разовая работа, а процесс постоянного совершенствования с годовым циклом PDCA. С момента приемки объекта в эксплуатацию его владелец должен ежегодно планировать мероприятия по обеспечению его безопасности, реализовывать их в течение года, контролировать их реализацию и по итогам контроля планировать на следующий год совершенствование системы безопасности.

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

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

  1. Угрозы, реализация которых может быть продемонстрирована на практике и которые могут привести к таким последствиям, из-за возможного наступления которых объекту и была присвоена категория значимости. Проще говоря, это угрозы, которые действительно могут быть реализованы и которые могут привести как к значительному прямому ущербу, так и к возможности уголовного преследования.
  2. Прочие угрозы, реализация которых может быть продемонстрирована на практике.
  3. Теоретически возможные угрозы, реализацию которых пока не удается продемонстрировать на практике.
  4. Угрозы, которые пока не удается спрогнозировать.

Такое разделение позволяет приоритезировать работы по созданию и модернизации системы защиты. Целью деятельности по обеспечению безопасности значимых объектов КИИ является их защита от угроз первых трех категорий. Для приемки системы безопасности достаточно обеспечить защиту от угроз первых двух категорий. Но для относительного спокойствия владельца значимого объекта достаточно создать систему безопасности, которая обеспечит защиту от угроз первой категории.

Таким образом, приступая к созданию или модернизации системы безопасности, субъекту КИИ стоит разделить меры безопасности на две категории:

  • первостепенные меры безопасности, которые необходимы для защиты от угроз первой категории;
  • второстепенные меры безопасности, которые необходимы для защиты от угроз второй и третьей категорий.
Анализ уязвимостей – едва ли не самая важная часть приемки системы безопасности. Он включает в себя: l выявление архитектурных уязвимостей на основе анализа проектной и рабочей документации; l проверку корректности настройки компонентов ИС, существенных для обеспечения безопасности, включая средства защиты; l проверку наличия известных уязвимостей компонентов с помощью средств контроля защищености (т.е. сканеров уязвимостей); l проведение тестирования на проникновение.

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

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

Таким образом, среди мер безопасности, предусмотренных приказом № 239, можно априори выделить те, которые необходимо реализовать в максимально короткие сроки:

  • анализ и устранение уязвимостей;
  • защита от сетевых атак с применением средств обнаружения вторжений и WAF;
  • антивирусная защита;
  • регистрация и анализ событий безопасности;
  • реагирование на инциденты и фиксация свидетельств, которые должны быть переданы в НКЦК, и т.п.

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

При этом одновременно с первой итерацией целесообразно провести проектирование полноценной системы безопасности, которая позволит обеспечить эффективную защиту от угроз первых трех категорий. Таким образом, станет возможным оценить общий объем финансирования, необходимый для создания полноценной системы безопасности, ожидаемые сроки ее создания, а на их основе – ежегодный объем средств, который может быть выделен на последовательное совершенствование системы безопасности. Итак, после завершения первой итерации и ввода системы безопасности в эксплуатацию можно начать предусмотренный приказом № 235 цикл PDCA. На каждой следующей итерации станут совершенствоваться отдельные меры безопасности, при этом объем усовершенствований будет определяться прежде всего объемом финансирования. Ежегодный контроль будет демонстрировать снижение количества и степени опасности угроз, реализацию которых система безопасности пока не способна предотвратить. Подобное итеративное совершенствование обеспечит постепенное приведение системы безопасности в сбалансированное состояние, при котором затраты на ее создание и эксплуатацию будут адекватны предотвращаемому вреду, и при этом на протяжении всего процесса совершенствования будет обеспечено ее соответствие требованиям нормативных документов ФСТЭК.

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

___________________________________________
1 https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/114-spetsialnye-normativnye-doku- menty/805-metodicheskij-dokument

Опубликовано: Журнал "Information Security/ Информационная безопасность" #3, 2019
Посещений: 1114

Приобрести этот номер или подписаться
  Автор

Дмитрий Кузнецов

Дмитрий Кузнецов

Директор по методологии и стандартизации Positive Technologies

Всего статей:  1

В рубрику "В фокусе" | К списку рубрик  |  К списку авторов  |  К списку публикаций