Как приоритизировать защитные меры в госорганах?

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

Это и разработанные каталоги защитных мер в 17-м приказе, и методичка по их трактовке, и модель оценки угроз, и пересмотренные правила аттестации, и требования по безопасной разработке (то есть модный DevSecOps), и многое другое. Но такой прорыв в нормотворчестве повлек за собой и один серьезный недостаток — многие госорганы не привыкли к свободе творчества, которую им предоставила ФСТЭК.

Зачем нужна приоритизация?

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

От «дискретной» безопасности ФСТЭК перешла к концепции безопасности непрерывной, когда мы не просто должны реализовать защитные меры, но и постоянно контролировать их эффективность путем проведения анализа защищенности, тестов на проникновения, киберучений (это, правда, уже больше требование ФСБ), непрерывного и круглосуточного мониторинга состояния ИБ и возникающих инцидентов, а также реагирования на них. И все бы ничего, но основной вопрос, который ФСТЭК оказалась решить не в состоянии: где взять деньги на все это богатство защитных мер? Ведь бюджетами на информатизацию распоряжается не ФСТЭК, и многие госорганы вынуждены реализовывать системы защиты своей инфраструктуры поэтапно, ранжируя защитные механизмы по… А, кстати, как надо ранжировать эти защитные меры?

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

Как эту проблему решают антиподы?

И вот тут впору отвлечься от ФСТЭК и посмотреть на то, что происходит на обратной стороне Земли, у наших антиподов, как часто называют Австралию. Хотя, по правде говоря, у России почти нет антиподов в географическом смысле; разве что якутская Усть-Мая имеет антипода в виде острова Монро в Антарктиде, а антипод Улан-Удэ — город Пуэрто-Наталес в Чили. Но вернемся к Австралии, регулятор в области информационной безопасности которой предложил в 2011 году очень интересную концепцию, схожую с нашей матрешкой. Они предложили Топ-4, Топ-8 и Топ-37 защитных мер, которые позволяют достичь 80%, 90% и 98% результата. Каждый последующий набор включает в себя предыдущий. В условиях нехватки бюджета или времени с каких из 150+ защитных мер из каталога ФСТЭК начать? С сегментации или управления доступом, с внедрения средств защиты от вредоносного кода или межсетевого экранирования, с повышения осведомленности персонала или с регистрации событий безопасности? В австралийских требованиях по ИБ все защитные меры распределяются по пяти приоритетам — Essential (базовые гигиенические), Excellent (отличная эффективность), Very Good (очень хороший результат), Good (неплохо-неплохо) и Limited (а вот это попробуйте, но есть нюансы). Начинать рекомендуется с четыре, а затем и с восьми базовых защитных мер, которые при этом дают не менее 90% эффекта. Реализовав оставшиеся 29 мер (а не 150), мы получим результат на уровне 98% обнаруженных и заблокированных угроз.

В этом документе, который называется «Strategies to mitigate cyber security incidents», нашли отражение все ключевые стратегии обнаружения и пресечения вторжений в киберпространстве. В простой и понятной табличной форме перечислены в порядке приоритета элементарные рекомендации, среди которых:

  • пачьте приложения;

  • минимизируйте число пользователей с административными правами;

  • используйте белые списки приложений (замкнутую программную среду);

  • сегментируйте сеть;

  • усильте защиту пользовательских ОС;

  • контролируйте USB и иные периферийные устройства;

  • используйте сетевые системы обнаружения вторжений и т. д.

Хочу заметить, что стратегии даны в повелительной форме. Не просто «Сегментация сети», а «сегментируйте сеть», то есть дано указание, что делать. Как учат отцы тайм-менеджмента, именно такая форма считается самой правильной при формировании списков дел. Но на этом плюсы австралийского документа не заканчивается. В таблице помимо конкретного указания также дана их оценка по различным критериям:

  • Общая эффективность.

  • Сопротивление со стороны пользователей. Отличный критерий, которого я раньше что-то не встречал при оценке механизмов и средств защиты. А ведь он напрямую влияет на эффективность защитных мероприятий. Одно дело в прозрачном режиме поставить патч на Adobe Reader, и совсем другое — внедрить ограничения на типы вложений, которые могут пересылать пользователи по e-mail. В одном случае сопротивление будет минимальным, а во втором — вполне ожидаемо максимальным. И по каждой из 37 стратегий указаны свои значения данного показателя.

  • Стоимость приобретения и внедрения (CapEx)

  • Стоимость поддержки (OpEx).

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

Переместившись с одного континента на букву А на другой, начинающийся на эту же букву (ну почти),  — в Северную Америку, давайте посмотрим, что делают наши потенциальные противники, чтобы облегчить жизнь своим федеральным структурам при внедрении защитных мер. Надо сказать, что госорганы везде одинаковые, и поэтому американский опыт может помочь нам составить свой план приоритизации защитных мер. Так вот, аналогичная концепция реализована в NIST SP800-53 (а это аналог нашего 17-го приказа) — против каждой защитной меры в поле «Приоритет» стоит значение от 0 до 3, означающее важность реализуемого мероприятия.

Наконец, посмотрим на то, как предлагает выстраивать систему безопасности Center of Internet Security (CIS), который развивает еще один фреймворк с защитными мерами — CIS Controls, иногда по старинке еще называемый SANS Top20. Если у SANS был просто список из 20 защитных мер, то у CIS каждый из пунктов двадцатки (недавно вышла новая версия CIS Controls уже из 18 пунктов) — это уже название блока защитных мер (в приказах ФСТЭК или NIST SP800-53 та же идея), в каждом из которых свой набор мер.

В CIS Controls 18 все защитные меры собраны в так называемые группы внедрения (Implementation Group), которые направлены на компании с разными ресурсами, разной экспертизой в ИБ, разной зрелостью и моделями угроз. Таких групп три, и каждая из них содержит свой перечень защитных мер по нарастающей.

Как чужой опыт реализовать у нас?

А теперь давайте вновь вернемся к нам и посмотрим, насколько такой подход можно реализовать применительно к приказам ФСТЭК. Причем необязательно ждать, чтобы регулятор внес это в свои документы. Почему бы самому не разбить полторы сотни защитных мер на группы в зависимости от того, какой эффект для защиты они дают? Возьму на себя смелость и предложу следующие Топ-10 защитных мер из 17-го приказа, с которых я бы начал построение системы защиты в первую очередь (названия мер даны по тексту приказа):

  • ОПС.3. Установка (инсталляция) только разрешенного к использованию ПО и (или) его компонентов.

  • АНЗ.2. Контроль установки обновлений ПО, включая обновление ПО средств защиты информации. От себя добавлю, что речь идет не только о контроле установки обновлений, но и о самом обновлении.

  • АНЗ.3. Контроль работоспособности, параметров настройки и правильности функционирования ПО и средств защиты информации. В качестве первых кандидатов на ПО, настройки которого стоит не только контролировать, но и улучшать, я бы назвал MS Office, Adobe Acrobat, Adobe Flash (если он еще используется), браузеры.

  • АНЗ.5. Контроль правил генерации и смены паролей пользователей, заведения и удаления учетных записей пользователей, реализация прав разграничения доступа, полномочий пользователей в информационной системе.

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

  • ИАФ.1. Идентификация и аутентификация пользователей, являющихся работниками оператора. От себя добавлю, что речь в первую очередь должна идти о многофакторной аутентификации.

  • ИАФ.2. Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных.

  • ОДТ.1. Периодическое резервное копирование информации на резервные машинные носители информации.

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

  • ЗИС.17. Разбиение информационной системы на сегменты (сегментирование информационной системы) и обеспечение защиты периметров сегментов информационной системы.

Надо отметить, что в приказах ФСТЭК тоже есть определенная приоритизация, но не такая, как в тех же документах австралийского ASD или американского Center of Internet Security. В наших документах состав базового набора защитных мер зависит не от наличия ресурсов, экспертизы или зрелости организации, а от уровня значимости защищаемой информации (в 21-м приказе — от типа и объема обрабатываемых ПДн, в 31-м и 239-м приказах — от критичности АСУ ТП и КИИ), что, может быть, и логично с точки зрения регулятора, но не соответствует логике внедрения в условиях ограниченного бюджета и других ресурсов, которых придерживаются регуляторы в Австралии и в США. Безусловно, они нам не указ, но определенная правда жизни в их подходе есть, что и позволило мне предложить применить эту логику и к нашим требованиям. А уже после реализации этой «горячей десятки» можно перейти и к остальным защитным мерам.

Похожие статьи