СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Оформление модели угроз информационной безопасности в черновиках Из песочницы

Вступление


Приветствую, Хабражители!

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

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

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

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

Типовые проблемы


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

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

План модели угроз


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

Введение
1. Перечень сокращений
2. Перечень нормативных документов
3. Описание ИС
4. Угрозы безопасности
Заключение.
Приложение А.
Приложение Б.
Приложение В.

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

Введение


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

1. Перечень сокращений


Зачем оно тут? — спросите вы. А я вам отвечу:
  • документ может читать не только специалист по информационной безопасности;
  • документ может читать высшее руководство, имеющее некое техническое образование;
  • при описании Информационной системы некоторые термины могут быть неизвестны ни специалистам, ни руководству.

2. Перечень нормативных документов


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

3. Описание ИС


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

Идентификатор
Описание
Примечание
СБД1 Сервер БД (Активный) CentOS 6.3/Ext4
СБД2 Сервер БД (Резервный) CentOS 6.3/Ext4
ТС1 Терминальный сервер 1 Windows 2008 R2 Enterprise/NTFS
ТС2 Терминальный сервер 2 Windows 2008 R2 Enterprise/NTFS

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

Актив Значимость Идентификатор
Коммутационное оборудование Высокая
КО
Внешний канал связи Высокая
КСвнеш
Внутренний канал связи Высокая
КСвнут
Система хранения данных Высокая
СХД

В зависимости от выбранной методики оценки рисков, 3 раздел модели угроз может содержать дополнительную информацию. Например, в случае моделирования угроз для персональных данных, данный раздел дополняется «показателями исходной защищенности ИСПДн», «основными характеристиками ИСПДн».

4. Угрозы безопасности


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

Перечень актуальных угроз удобно оформлять в виде такой таблички:
   №
Угроза
Активы
У-1
Неавторизованное проникновение нарушителя внутрь КЗ
КО, АРМ, ТК АИБ
У-2
Кража носителей информации, содержащих конфиденциальную информацию
БН, АНИ
У-3
Кража отработанных материалов (мусор, уничтоженные документы, списанные носители)
БН, АНИ


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

Заключение


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

1. Защита от несанкционированного подключения незарегистрированных технических средств:
  • серверов СУБД;
  • серверов приложений.

2. Криптографическая защита каналов связи для доступа к Информационной системе (построение VPN сети).


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

Приложение А


В приложении А я обычно описываю модель нарушителя. Как правило оно состоит из:

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


Табличка на выходе:

Тип нарушителя
Категории нарушителей Идентификатор
Внешний нарушитель Криминальные структуры, внешние субъекты (физические лица) N1
Внутренний нарушитель Лица, имеющие санкционированный доступ в КЗ, но не имеющие доступа к ИСПДн (технический и обслуживающий персонал) N2
Зарегистрированные пользователи ИСПДн, имеющие доступ к ПДн N3
Зарегистрированные пользователи ИСПДн с полномочиями администратора безопасности сегмента ИСПДн N4
Зарегистрированные пользователи с полномочиями системного администратора ИСПДн N5
Зарегистрированные пользователи с полномочиями администратора безопасности ИСПДн N6
Программисты-разработчики (поставщики) прикладного программного обеспечения и лица, обеспечивающие его сопровождение на защищаемом объекте N7
Разработчики и лица, обеспечивающие поставку, обслуживание и ремонт технических средств для ИСПДн N8


Приложение Б


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

image

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

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

Приложение В


Приложение В — справочное. В ней расписаны методики расчета актуальности или же методики оценки рисков.

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

Спасибо за внимание.

комментарии (9)

+2
valodik ,  

Хорошие заметки к ГОСТ Р 15408.

0
ystr ,  

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

–1
TheWolf ,  

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

Основой для такой подачи оформления был конечно пакет стандартов ISO 27xxx и СТО БР.

0
dos ,  

Ознакамливались ли Вы с каким-либо софтом для оценки рисков информационной безопасности? Поделитесь экспертным мнением о преимуществах/недостатка существующего софта?

0
TheWolf ,  

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

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

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

0
Spewow ,  

Хорошо когда программа интегрируется со средством автоматической инвентаризации активов, ну или сама проводит такую инвентаризацию.

0
TheWolf ,  

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

0
Didjeru ,  

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

0
TheWolf ,  

Разработки чего? Подхода к оформлению? Или описания угроз? Тут не разрабатывались методики оценки рисков, тут рассматривается только оформление.

В тексте я писал, что подход оформления тех или иных данных брался из зарубежных или отечественных стандартов. Например, таблица с угрозой была взята с РС БР ИББС 2.2. Но так как в этом стандарте идет расчет рисков по правилам данного стандарта, табличка была переделана под ПДн в данном случае.