Ласкер пообещал одному из своих противников не обкуривать его во время игры своими сигарами. После нескольких первых ходов Ласкер вытащил из кармана большую сигару и засунул ее в рот. Противник Ласкера вскочил со стула и побежал к судье:
– Ласкер обещал, что не будет курить во время нашей партии!
– Но он же не курит, – удивился судья. – Он даже не зажег сигару.
– Да, но он же угрожает закурить! – возразил на это шахматист. – А вы же
знаете, какое значение он придает угрозе!
В феврале на ТБ-Форуме 2022 ФСТЭК в лице Гефнер И.С. представил доклад на тему «Практика реализации методики оценки угроз безопасности информации (УБИ)» (далее – Доклад), посвященный разработке модели угроз (МУ) в соответствии с методическим документом, утвержденным 05.02.2021 (далее – Методика). В частности, было сказано о том, что 67% присылаемых на проверку МУ возвращаются на доработку. Разработанная мной МУ оказалась в списке оставшихся 33%. В связи с эти решил поделиться своим видением процесса моделирования угроз.
В Приложении 3 Методики приведена рекомендуемая структура МУ, которой стоит придерживаться. Раздел «Общие положение» пропустим и рассмотрим раздел «Описание систем и сетей и их характеристика, как объектов защиты». Далее будем пользоваться понятием «Объект защиты» (ОЗ), включающим в себя все компоненты защищаемой системы и/или сети. Прямых замечаний у регулятора к этому разделу не было, но некоторые замечания к другим разделам прямо связаны с качественным описанием ОЗ.
Целью данного раздела является описание ОЗ, позволяющее определять возможные негативные последствия, объекты воздействия, источники УБИ (модель нарушителя), способы реализации (возникновения) УБИ, и выполнить построение сценариев реализации УБИ. Кому интересно, прошу под кат.
В виду особенностей отдельных ОЗ (особенно это касается АСУ ТП) материал не является исчерпывающим пособием, но в тоже время содержит вполне определенные направления описания ОЗ и отдельные примеры.
Далее по пунктам будет указано содержание раздела описания ОЗ (согласно Методики) и сразу же приведены комментарии по наполнению.
В соответствии с Методикой рассматриваемый раздел содержит:
1. Наименование систем и сетей, для которых разработана модель угроз безопасности информации
Указывается наименование ОЗ. Если ОЗ имеет название, закрепленное в каких-то документах, то с целью единообразия лучше его придерживаться.
2. Класс защищенности, категория значимости систем и сетей, уровень защищенности персональных данных
Приводится ссылка на акт классификации информационной (автоматизированной) системы, в котором указаны класс защищенности, категория значимости и/или уровень защищенности персональных данных (ПД). Указываем какой класс защищенности, категорию значимости и/или уровень защищенности персональных данных в соответствии с актом.
Класс защищенности определяется в соответствии с приказом ФСТЭК № 17 от 11.02.2013 (Приказ № 17) для государственных информационных систем (ГИС), а также ОЗ, не являющихся ГИС, но для которых по решению обладателя информации или оператора принято решение о применении Приказа № 17.
Категория значимости определяется в соответствии с Постановлением № 127 от 08.02.2018 для ОЗ, которые отнесены к объектам критической информационной инфраструктуре (ОКИИ).
Уровень защищенности персональных данных определяется в соответствии с Постановлением № 1119 от 01.11.2012 для ОЗ, являющихся системами персональных данных (СПД).
К слову, даже если ОЗ не планируется аттестовать, рекомендую использовать форму акта классификации, приведенную приложении № 3 к Порядку организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации, не составляющей государственную тайну, утвержденному Приказом ФСТЭК № 77 от 29.04.2021. Шаблон акта сделан для определения класса защищенности в соответствии с Приказом № 17. В случае, если ОЗ одновременно является ГИС, ОКИИ и/или СПД, то в указанную форму можно добавить разделы, в которых описываем критерии определения категории и/или уровня защищенности.
3. Нормативные правовые акты Российской Федерации, в соответствии с которыми создаются и (или) функционируют системы и сети
Если ОЗ, создан в соответствии с какими-то нормативными правовыми актами, указываем их. Как правило, актуально для ГИС. Если таких документов нет, то опускаем данный момент. Впрочем, приказ о создании ОЗ есть почти всегда.
4. Назначение, задачи (функции) систем и сетей, состав обрабатываемой информации и ее правовой режим
В части назначения, задач (функций) можно взять сведения из имеющихся на ОЗ документов. Это могут быть документы о создании, упомянутые выше, техническое задание на создание ОЗ и т.п. В случае отсутствия такого формализованного описания необходимо на основе собранных данных подготовить его.
Относительно состава обрабатываемой информации необходимо привести характеристику сведений, обрабатываемых ОЗ. В части ПД указывается перечень всех субъектов, чьи ПД обрабатываются, а также состав ПД для каждого субъекта.
После этого указываем установленный правовой режим для обрабатываемой информации, а также основание его установления. Это может быть ссылка на нормативный документ, в соответствии с которым для данной информации установлен режим ограниченного доступа (персональные данные, банковская тайна и т.д.), или внутренний документ организации (заказчика) в соответствии с которым доступ к информации ограничен. Владелец информации имеет право сам устанавливать для нее такой статус (за исключением сведений, ограничение доступа, к которым запрещается законодательством).
В случае, если часть данных относится к конфиденциальным, а часть нет, можно явно сказать об этом. Но это имеет смысл, если как-то повлияет в дальнейшем на моделирование угроз. Если весь объем данных хранится в единой базе данных (БД), и доступ к ним осуществляется с использованием одних и тех же механизмов, необходимость явно выделять сведения ограниченного доступа отсутствует. Достаточно указать, что в ОЗ обрабатывается информация ограниченного доступа.
5. Основные процессы (бизнес-процессы) обладателя информации, оператора, для обеспечения которых создаются (функционируют) системы и сети
Вообще процессный подход может быть эффективен. После определения процессов, реализация которых обеспечивается различными компонентами инфраструктуры, можно выполнить разделение инфраструктуры на объекты защиты (с привязкой к процессам), для которых в дальнейшем будет выполняться моделирование угроз и последующее построение систем защиты информации. Т.е. определить границы моделирования угроз.
В тоже время наличие формализованный список процессов, как правило, встречается в крупных организациях. В ситуации отсутствия описания процессов на уровне внутренней документации организации можно указать процессы в соответствии с функциями ОЗ, формально выполнив данный пункт (например, процесс электронного документооборота). С замечаниями регулятора при таком подходе сталкиваться не приходилось.
6. Состав и архитектуру систем и сетей, в том числе интерфейсы и взаимосвязи компонентов систем и сетей
Описанные выше пункты были в каком-то смысле преамбулой. На мой взгляд, этот и следующие пункты являются наиболее важными в части описания ОЗ и содержащие основную информацию для дальнейшего моделирования угроз.
Здесь приводим описание ОЗ в части используемых сред виртуализации, указываем, где и для чего они применяются. Если ОЗ развернут в кластере, указываем состав и характеристики кластера в части железа, общесистемного ПО, сведения о системе хранения данных и иные значимые характеристики.
Указываем данные о серверах: тип (физический или виртуальный), роль сервера в составе ОЗ (сервер приложений, сервер БД и т.п.), ОС и другие характеристики. В части прикладного ПО приводим информацию об установленном ПО, используемом в составе ОЗ. Это могут быть системы управления базами данных (СУБД), веб-серверы и т.д. Описываем функции, выполняемые каждой программой.
Если в программной части ОЗ является программным комплексом (ПК), то нужно также прояснить состав входящего в ПК прикладного ПО и его назначение.
Далее нужно определить массив АРМ пользователей, полностью охватывающий все возможные их варианты. В данном случае под вариантами имеется в виду АРМ под управлением различных ОС, а также использующие различные технологии подключения к серверам ОЗ.
Реализация УБИ через АРМ администратора будет отличаться от реализации через АРМ обычных пользователей. В связи с этим его стоит выделить отдельно и указать соответствующие характеристики.
При наличии в составе ОЗ мобильных устройств, нужно указать их характеристики, включающие описание, что из себя представляет мобильное устройство (планшет, ноутбук и т.д.), а также ОС и прикладное ПО, связанное с ОЗ.
Для каждого компонента ОЗ указываем адрес расположения.
После того, как все компоненты ОЗ определены, нужно подготовить описание их взаимодействия между собой, в том числе указать используемые протоколы. Наличие схем в Методике носит рекомендательный характер. В тоже время наличие схемы позволяет наглядно отразить взаимодействие компонентов ОЗ между собой и будет полезно, в том числе для разработчика МУ, особенно когда придется вернуться к документу, например, при актуализации. Также схема снимает необходимость подготовки объемного описания взаимодействия. Важно учитывать расположение компонентов ОЗ относительно контролируемой зоны (КЗ). Это также можно отразить на схеме. Вот пример схемы.
При необходимости к схеме можно дать пояснения, содержащие уточнение о характере взаимодействия. Если в рамках ОЗ данные передаются посредством внешних носителей, это также нужно отразить на схеме.
7. Описание групп внешних и внутренних пользователей систем и сетей, уровней их полномочий и типов доступа (в состав групп пользователей включаются все пользователи, для которых требуется авторизация при доступе к информационным ресурсам, и пользователи, для которых не требуется авторизация (например, предоставлен доступ к сайту без прохождения авторизации)
Классическим примером разделения пользователей на группы является разделение на:
привилегированных пользователей (администраторы);
пользователей, не имеющих привилегированных прав доступа;
неавторизованные пользователи (при наличии).
Далее необходимо привести описание системы разграничения доступа ОЗ. В случае ролевой модели разграничения доступа приводится список ролей и их права доступа. При наличии доступа к ОЗ для неавторизованных пользователей нужно сказать об этом, указав, какими возможностями обладают неавторизованные пользователи и откуда они получаются доступ к ОЗ (это также должно быть на схеме, пример которой приведен выше).
В случае, если в ОЗ доступно создание ролей и присвоение им прав доступ, т.е. окончательный список ролей привести невозможно, то стоит сказать об этом. Также нужно привести список прав доступа, которые могут быть назначены ролям. Это может быть «чтение», «запись» и/или какие-то специфические права доступа. Если возможные права доступа отличаются для разных объектов доступа нужно привести описания прав доступа с привязкой к объектам доступа.
Отдельно стоит остановиться на описании прав доступа администратор, в том числе в части настроек информационной безопасности.
В итоге должно быть целостное понимания о возможностях системы разграничения доступа и пользователях ОЗ.
8. Описание внешних интерфейсов и взаимодействий систем и сетей с пользователями (в том числе посредством машинных носителей информации, средств ввода-вывода, веб-приложений), иными системами и сетями, обеспечивающими системами, в том числе с сетью «Интернет»
Про взаимодействие с пользователями уже было сказано выше. В части внешних взаимодействий также рекомендуется подготовка схемы. Если ОЗ является небольшой системой, его взаимодействия с другими системами, можно отразить на приведенной выше схеме взаимосвязи компонентов ОЗ, но рекомендую, даже для небольших ОЗ схему внешних взаимодействий сделать отдельно.
В качестве исходных данных для данной схемы нужно определить список систем, с которыми выполняется взаимодействие, интерфейсы передачи данных, а также механизм передачи данных, состав передаваемых данных и направление передачи данных.
Состав передаваемых данных, а также направление передачи определяются и описываются для каждого интерфейса. Под направлением подразумевается передача данных из ОЗ или в ОЗ.
Очень часто взаимодействий с внешними системами осуществляется посредством API-интерфейсов. Для них также нужно привести описание в части направления передачи, механизма работы и состава передаваемых данных.
Все это влияет на определение доступных нарушителям интерфейсов и возможности реализации УБИ. В качестве примера. Посредством какого-то интерфейса в ОЗ поступает информация, не относящаяся к сведениям ограниченного доступа. При этом интерфейс доступен потенциальному нарушителю. В этом случае нужно будет оценивать УБИ, связанные с нарушением целостности и доступности данных при передаче посредством данного интерфейса.
Схема может выглядеть так.
В качестве пояснения к данной схеме нужно привести содержание информации, которая передается в рамках каждого взаимодействия. Здесь нужно учитывать состав обрабатываемых сведений, приведенный в соответствии с пунктом 4. Также нужно указать расположение компонентов смежных систем, с которым выполняется взаимодействие. Основной мыслью здесь является понимание, выполняется ли передача данных за пределы КЗ. Или получение данных происходит из системы за пределами КЗ или в пределах КЗ.
Описать нужно все взаимодействия, в том числе, при которых выполняется отправка и/или получение данных посредством электронной почты (внешняя система № 4 на рисунке). При наличии необходимо отразить передачу данных с использованием съемных носителей информации (внешняя система № 1 на рисунке), также указав, выносятся ли носители за пределы КЗ.
В конечном итоге должно быть полное понимание внешних и внутренних связей ОЗ, которые могут быть использованы для реализации УБИ.
9. Информацию о функционировании систем и сетей на базе информационно-телекоммуникационной инфраструктуры центра обработки данных или облачной инфраструктуры, о модели предоставления вычислительных услуг, о распределении ответственности за защиту информации между обладателем информации, оператором и поставщиком вычислительных услуг, об условиях использования информационно-телекоммуникационной инфраструктуры центра обработки данных или облачной инфраструктуры поставщика услуг (при наличии)
При разработке МУ не сталкивался с развертыванием ОЗ (или части ОЗ) на базе ЦОД. Если данный факт имеет место быть в целом смысл тот же. Нужно привести описание в какой части ОЗ завязан на инфраструктуру ЦОД, указать модель предоставления услуг и т.д. Это позволит определить границы при оценке УБИ между владельцем ОЗ и поставщиком услуг. Об этом говорится в пункте 4.8 Методики, где приведен такой рисунок.
Также все это нужно учесть и отразить на схемах, примеры которых приведены выше.
Вместо выводов
Несмотря на появляющуюся то тут, то там информацию о внесении изменений в Методику, применять ее приходится здесь и сейчас. Также, несмотря на то, что в Докладе было заявлено о подготовке сервиса, автоматизирующего процесс формирования перечня возможных угроз, описание ОЗ будет необходимо, т.к. содержит сведения, на основе которых будет формироваться данный перечень.
Вот интересный график, отражающий результаты опроса, проведенного ЦЗИ «Конфидент» по поводу оценки применения Методики.
Склонен согласится с приведенным графиком. На мой взгляд, зря убрали такую вещь, как вероятность реализации УБИ. Бывает так, что с учетом всех особенностей самого ОЗ и его окружения реализация некоторых УБИ выглядит весьма фантастичной. В тоже время прямых оснований для ее исключения нет. В связи с этим для таких УБИ приходится проходить все этапы моделирования, включаю написание сценариев реализации, что связано с существенными трудозатратами.
Впрочем, в Методике есть и положительные стороны, но она однозначно требует доработки, которая, надеюсь, скоро произойдет.
