Пример сценария реализации угрозы безопасности информации

BDU:W01 — Уязвимости, связанные с недостатками проверки вводимых данных

Описание:

Уязвимости данного типа связаны с ошибками, позволяющими нарушителю осуществить
несанкционированное внедрение кода в различные элементы, используемые в составе
веб-приложений:

— веб-страницы;

— запросы;

— заголовки;

— команды;

— сообщения;

— электронные документы.

Типы ошибок:

CWE-79 («Непринятие мер по защите структуры веб-страницы»)

CWE-20 («Недостаточная проверка вводимых данных»)

CWE-89 («Непринятие мер по защите структуры запроса SQL»)

CWE-78 («Непринятие мер по нейтрализации специальных элементов, используемых в
команде операционной системы»)

CWE-611 («Неверное ограничение XML-ссылок на внешние объекты»)

CWE-77 («Непринятие мер по чистке данных на управляющем уровне»)

CWE-601 («Переадресация URL на ненадежный сайт («Открытая переадресация»)»)

CWE-80 («Непринятие мер по нейтрализации script-related тэгов HTML на веб-странице
(основной XSS)»)

CWE-94 («Неверное управление генерацией кода (Внедрение кода)»)

CWE-434 («Неограниченная загрузка файлов опасного типа»)

CWE-74 («Неверная нейтрализация особых элементов в выходных данных, используемых
входящим компонентом («инъекция»)»)

CWE-83 («Непринятие мер по нейтрализации сценария в атрибутах на веб-странице»)

CWE-427 («Неконтролируемый элемент пути поиска»)

CWE-98 («Некорректное управление именем файла для оператора Include/Require в
программе PHP (Удаленное включение файла PHP)»)

CWE-626 («Ошибка взаимодействия нулевых байтов (Poison Null Byte)»)

CWE-91 («Внедрение XML (Blind XPath Injection)»)

CWE-96 («Непринятие мер по нейтрализации инструкций в статически сохраненном коде
(Внедрение статического кода)»)

CWE-90 («Непринятие мер по нейтрализации специальных элементов в запросе LDAP
(Внедрение LDAP)»)

CWE-116 («Некорректное кодирование или сокрытие выходных данных»)

CWE-444 («Передача скрытых HTTP-запросов»)

CWE-22 («Обход пути»)

CWE-35 («Обход пути: …/…//»)

Способы эксплуатации:

Общие

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

Известные способы эксплуатации для различных типов ошибок CWE:

1) CWE-20:

— выполнение произвольного кода путем отправки специально сформированного запроса;

— выполнение произвольного кода путем отправки специально сформированного
сериализованного
объекта Java;

— выполнение произвольного кода путем отправки специально сформированного flash-файла
(в
формате .swf);

— внесение несанкционированных изменений в файловую систему путем загрузки и
выполнения
вредоносного файла;

— повышение привилегий путем загрузки и выполнения вредоносного файла;

— выполнение произвольных команд путем отправки вредоносных запросов;

2) CWE-22:

— раскрытие защищаемой информации путем отправки специально созданных HTTP-запросов;

— получение содержимого каталога с ограниченным доступом путем отправки специально
сформированного HTTP-запроса;

— вызов отказа в обслуживании путем манипулирования параметрами запросов;

3) CWE-78:

— выполнение произвольного кода путем отправки специально сформированного запроса;

4) CWE-79:

— получение несанкционированного доступа к защищаемой информации путем отправки
специально
сформированного GET-запроса;

— осуществление межсайтовой сценарной атаки путем отправки специально сформированного
запроса;

— выполнение произвольного кода или осуществление межсайтовой сценарной атаки путем
загрузки на сервер вредоносных файлов с не запрещенным списком расширений (.pht, .php7,
.php5, .php3, .php4, .phtml, .pht и др.);

— отправка специально сформированного электронного письма;

5) CWE-89:

— получение содержимого базы данных путем манипулирования параметром GET-запроса;

— выполнение произвольных SQL-запросов, путем отправки специально сформированных
HTTP-запросов;

6) CWE-91:

— нарушение конфиденциальности, целостности и доступности защищаемой информации путем
отправки специально сформированных TCP и XML запросов;

7) CWE-434:

— выполнение произвольного кода путем загрузки вредоносного файла на сервер;

— выполнение произвольного кода путем загрузки вредоносного файла на сервер при
помощи
специально сформированного POST-запроса;

CWE-611:

— чтение произвольных файлов на сервере путем объявления внешней ссылки;

— вызов отказа в обслуживании путем объявления внешней ссылки

Примеры сценариев реализации угроз:

Пример сценария реализации угрозы несанкционированного доступа к автоматизированному
рабочему месту пользователя с использованием уязвимости системы управления содержимым
сайта, связанной с ошибкой CWE-79

Сбор информации о системах и сетях

1) Сканирование сетевых служб с целью определения уязвимостей, имеющих эксплойты
или иные техники использования уязвимостей;

Получение первоначального доступа к компонентам систем и сетей

2) Осуществление межсайтовой сценарной атаки путем отправки специально
сформированного запроса (CWE-79);

Внедрение и исполнение вредоносного программного обеспечения в системах и
сетях

4) Выполнение кода через различного рода загрузчики («drive-by» атака);

Закрепление (сохранение доступа) в системе или сети

5) Скрытая установка и запуск средств удаленного доступа

Сбор и вывод из системы или сети информации, необходимой для дальнейших действий
при реализации угроз безопасности информации или реализации новых угроз

6) Вывод информации через разрешённые на периметровых средствах защиты стандартные
tcp/udp-порты (например, tcp/80)

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W02 — Уязвимости, связанные с недостатками управления доступом и защиты данных

Описание:

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

Типы ошибок:

CWE-284 («Неправильный контроль доступа»)

CWE-264 («Разрешения, привилегии и средства управления доступом»)

CWE-285 («Неправильная авторизация»)

CWE-863 («Неправильная авторизация»)

CWE-269 («Небезопасное управление привилегиями»)

CWE-862 («Отсутствие авторизации»)

CWE-59 («Неверное определение ссылки перед доступом к файлу»)

CWE-276 («Неправильные стандартные разрешения»)

CWE-639 («Обход авторизации посредством использования ключа, контролируемого
пользователем»)

CWE-73 («Внешнее управление именем или путем файла»)

CWE-668 («Раскрытие ресурса для ошибочной области»)

CWE-913 («Недостаточный контроль ресурсов кода с динамическим управлением»)

CWE-338 («Использование криптографически слабого генератора псевдослучайных чисел»)

CWE-693 («Нарушение механизма защиты данных»)

CWE-200 («Раскрытие информации»)

CWE-598 («Раскрытие информации посредством строки запросов»)

CWE-319 («Передача секретной информации в виде открытого текста»)

CWE-256 («Хранение пароля в незашифрованном виде»)

CWE-312 («Незашифрованное хранение критичной информации»)

CWE-326 («Слабое шифрование»)

CWE-310 («Проблемы использования криптографии»)

CWE-331 («Недостаточная энтропия»)

CWE-325 («Отсутствие необходимого этапа шифрования»)

CWE-327 («Использование криптографических алгоритмов, содержащих дефекты или
риски»)

CWE-311 («Непринятие мер по шифрованию секретных данных»)

CWE-538 («Утечка информации о файлах и каталогах»)

CWE-257 («Хранение паролей в восстанавливаемом формате»)

CWE-12 («Ошибка в конфигурации ASP.NET: отсутствие пользовательской страницы
ошибки»)

CWE-16 («Конфигурация»)

Способы эксплуатации:

Общие

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

Известные способы эксплуатации для различных типов ошибок CWE:

1) CWE-12:

— раскрытие защищаемой информации о системе с помощью вызова необработанного
исключения путем выполнения запросов с измененными значениями пользовательских
переменных;

2) CWE-16:

— раскрытие защищаемой информации с помощью специально созданного запроса;

3) CWE-200:

— получение доступа к защищаемой информации Java Content Repository с помощью
специально сформированного запроса;

— получение доступа к защищаемой информации об учетных данных и Cookie путем чтения
аутентификационных заголовков;

— раскрытие защищаемой информации с помощью специально сформированных запросов;

— раскрытие защищаемой информации с помощью специально сформированного SNMP-запроса;

— получение информации о внутренней сети путем сканирования портов;

— получение доступа к конфиденциальным данным с помощью отправки специально
созданного JSON-сообщения;

4) CWE-264:

— обход существующих ограничений доступа с помощью специально сформированного
запроса;

— получение доступа к аутентификационным данным интерфейса REST API с помощью
специально сформированных HTTP-запросов;

— получение доступа на изменение, добавление или удаление данных с помощью
HTTP-протокола;

— повышение своих привилегий с помощью специально созданного URI-запроса;

— получение полного контроля над приложением с помощью сетевого протокола T3;

5) CWE-284:

— получение доступа к защищаемой информации с помощью специально сформированного
HTTP-запроса;

— получение доступа к защищаемой информации о конфигурации устройства с помощью
специально сформированных запросов;

— получение несанкционированного доступа к защищаемым данным с помощью протокола
HTTP;

— повышение своих привилегий с помощью специально сформированного HTTP-запроса;

— получение доступа на изменение, добавление или удаление данных с помощью
HTTP-протокола;

— выполнение произвольных действий на уязвимом устройстве с привилегиями
администратора с помощью специально сформированноых HTTP-запросов;

6) CWE-285:

— повышение своих привилегий с помощью специально сформированного HTTP-запроса;

7) CWE-598:

— выполнение произвольного кода с помощью специально сформированого GET-запроса;

CWE-639:

— раскрытие информации путем манипулирования параметром;

9) CWE-863:

— повышение привилегий с помощью специально созданного запроса

Примеры сценариев реализации угроз:

Пример сценария реализации угрозы подмены информации, обрабатываемой программным
средством для реализации гипертекстовой среды путем эксплуатации уязвимости, связанной с
ошибкой CWE-284

Сбор информации о системах и сетях

Повышение привилегий по доступу компонентам систем и сетей

2) Повышение своих привилегий с помощью специально сформированного HTTP-запроса
(CWE-284);

Неправомерный доступ и (или) воздействие на информационные ресурсы или
компоненты систем и сетей, приводящее к негативным последствиям

3) Подмена информации

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W03 — Уязвимости, связанные с недостатками работы со структурами данных

Описание:

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

Типы ошибок:

CWE-119 («Выход операции за границы буфера в памяти»)

CWE-502 («Восстановление в памяти недостоверных данных»)

CWE-787 («Запись за границами буфера»)

CWE-121 («Переполнение буфера в стеке»)

CWE-704 («Неправильное преобразование типов»)

CWE-415 («Повторное освобождение»)

CWE-122 («Переполнение буфера в куче»)

CWE-189 («Ошибки, возникающие при обработке чисел»)

CWE-476 («Разыменование указателя NULL»)

CWE-822 («Ненадежное разыменование указателя»)

CWE-416 («Использование после освобождения»)

CWE-120 («Копирование буфера без проверки размера входных данных (классическое
переполнение буфера)»)

CWE-125 («Чтение за границами буфера»)

Способы эксплуатации:

Общие

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

Известные способы эксплуатации для различных типов ошибок CWE:

1) CWE-119:

— вызов отказа в обслуживании с помощью специально сформированного RPC-запроса;

— выполнение произвольного кода с повышенными привилегиями с помощью специально
сформированной веб-страницы;

— выполнение произвольного кода с помощью специально сформированных запросов;

— вызов отказа в обслуживании с помощью специально сформированных запросов;

— выполнение произвольного кода с помощью специально сформированных файлов формата
Advanced Recording Format (ARF) или Webex Recording Format (WRF);

2) CWE-120:

— выполнить произвольный код с помощью специально сформированного сообщения RPC;

3) CWE-189:

— вызов отказа в обслуживании с помощью специально сформированного RPC-запроса;

4) CWE-415:

— перезагрузка устройства с помощью специально сформированных HTTP-запросов;

— отказ в обслуживании с помощью специально сформированных HTTP-запросов;

5) CWE-502:

— выполнение произвольного кода с помощью специально сформированных данных;

— манипулирование файлами в целевой системе с помощью специально сформированных
данных;

— выполнение произвольного кода с помощью специально созданного запроса;

— выполнение произвольного кода, путем отправки специально сформированного
сериализованного объекта Java;

6) CWE-787:

— выполнение произвольного кода в целевой системе с помощью специально созданных
вредоносных файлов формата MCR;

— выполнение произвольного кода в целевой системе с помощью специально сформированной
веб-страницы

Примеры сценариев реализации угроз:

Пример сценария реализации угрозы переведения в состояние «отказ в обслуживании»
маршрутизатора путем эксплуатации уязвимости, связанной с ошибкой CWE-119

Сбор информации о системах и сетях

2) Вызов отказа в обслуживании с помощью специально сформированных запросов
(CWE-119)

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W04 — Уязвимости, связанные с недостатками проверки подлинности

Описание:

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

Типы ошибок:

CWE-352 («Межсайтовая фальсификация запросов»)

CWE-287 («Неправильная аутентификация»)

CWE-918 («Серверная фальсификация запросов»)

CWE-306 («Отсутствие аутентификации для критичной функции»)

CWE-798 («Жесткое кодирование регистрационных данных»)

CWE-384 («Фиксация сеанса»)

CWE-307 («Недостаточное ограничение попыток аутентификации»)

CWE-295 («Неправильное подтверждение подлинности сертификата»)

CWE-613 («Неверный срок действия сеанса»)

CWE-255 («Управление регистрационными данными»)

CWE-522 («Недостаточная защита регистрационных данных»)

CWE-288 («Обход аутентификации посредством использования альтернативного пути или
канала»)

CWE-640 («Слабый механизм восстановления забытых паролей»)

CWE-305 («Обход аутентификации в силу исходной ошибки»)

CWE-494 («Загрузка кода без проверки целостности»)

CWE-521 («Слабые требования к паролям»)

CWE-345 («Недостаточная проверка подлинности данных»)

CWE-308 («Применение однофакторной аутентификации»)

CWE-354 («Неправильное подтверждение значения проверки целостности»)

Способы эксплуатации:

Общие

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

Известные способы эксплуатации для различных типов ошибок CWE:

1) CWE-287:

— выполнить произвольный код с помощью специально созданных запросов;

— выполнить произвольный код с помощью специально сформированнного URI;

— получение несанкционированного доступа к защищаемой информации с использованием
метода полного перебора;

— выполнение произвольных действий на уязвимом устройстве с помощью отправки
специально сформированного HTTP-запроса;

2) CWE-295:

— выполнение произвольного кода с помощью специально созданной веб-страницы;

3) CWE-306:

— раскрытие защищаемой информации с помощью специально созданного HTTP-запроса;

— получение несанкционированного доступа к защищаемой информации путем отправки
специально созданного запроса и использования утилиты сетевого анализа Tcpdump;

4) CWE-352:

— получение доступа к аутентификационным данным произвольных пользователей с помощью
запросов, изменяющих настройки;

— выполнение произвольных действий на уязвимом устройстве с помощью специально
сформированной ссылки;

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

— выполнение произвольного кода с помощью специально сформированной ссылки;

5) CWE-494:

— получение полного контроля над приложением с помощью HTTP протокола;

6) CWE-798

— повышение своих привилегий с помощью статического ключа шифрования;

7) CWE-918:

— осуществление управления приложением с помощью специально сформированных запросов;

— оказание воздействия на целостность защищаемой информации с помощью специально
созданного HTTP-запроса

Примеры сценариев реализации угроз:

Пример сценария реализации угрозы нарушения функционирования средства защиты информации
с использованием уязвимости, связанной с ошибкой CWE-352

Сбор информации о системах и сетях

1) Сканирование сетевых служб с целью определения уязвимостей, имеющих эксплойты или
иные техники использования уязвимостей;

Получение первоначального доступа к компонентам систем и сетей

2) Использование методов социальной инженерии

3) Выполнение произвольных действий на уязвимом устройстве с помощью специально
сформированной ссылки (CWE-352);

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W05 — Уязвимости, связанные с недостатками управления ресурсами

Описание:

Уязвимости данного типа связаны с некорректным управлением ресурсами, доступными
веб-приложению. Эксплуатация уязвимостей данного типа приводит, преимущественно, к
отказу в обслуживании веб-приложения или узла, под управлением которого оно
функционирует

Типы ошибок:

CWE-399 («Ошибки управления ресурсом»)

CWE-400 («Неконтролируемый расход ресурса («Истощение ресурса»)»)

CWE-770 («Неограниченное распределение ресурсов или дросселирование»)

Способы эксплуатации:

Общие

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

Известные способы эксплуатации для различных типов ошибок CWE:

1) CWE-399:

— вызов отказа в обслуживании путем задания определенного имени файла;

— вызов отказа в обслуживании путем отправки специально сформированных запросов;

— перезаписать файлы в файловой системе уязвимого устройства с помощью специально
созданного файла

2) CWE-400:

— вызвать отказ в обслуживании с помощью специально сформированного HTTP-запроса

Примеры сценариев реализации угроз:

Пример сценария реализации угрозы несанкционированного доступа к СУБД путем переведения
в состояние «отказ в обслуживании» программное обеспечение управления событиями и
политиками безопасности сетевых устройств путем эксплуатации уязвимости, связанной с
ошибкой CWE-399

Сбор информации о системах и сетях

2) Вызов отказа в обслуживании с помощью специально сформированных запросов
(CWE-399)

Получение доступа (распространение доступа) к другим компонентам систем и сетей
или смежным системам и сетям

3) Использование средств и интерфейсов удаленного управления

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

Источник

Моделирование угроз на основе сценариев или Как Cyber Kill Chain и ATT&CK помогают анализировать угрозы ИБ

Введение

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

Одним из наиболее эффективных приемов анализа угроз является моделирование сценариев реализации угроз с построением графов атак, который в англоязычных источниках получил название «Cyber Kill Chain».

Регламентирование в российской нормативной базе деятельности по анализу угроз

На сегодняшний день в

нормативных документах ФСТЭК России

Приказ ФСТЭК России от 11.02.2013 N 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».

Приказ ФСТЭК России от 18.02.2013 N 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».

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

Приказ ФСТЭК России от 25.12.2017 N 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации».

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

методические документы,

Методический документ «Меры защиты информации в государственных информационных системах» для приказов ФСТЭК №17 и №21. Аналогичный документ разрабатывается для приказов ФСТЭК №31 и №239.

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

Так, например, одной из мер безопасности, направленной на защиту от компьютерных атак, является мера безопасности СОВ.1

«Обнаружение вторжений»,

Определена как базовая мера защиты во всех четырех упомянутых выше приказах ФСТЭК.

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

Возникает вопрос: как именно следует проводить анализ угроз? Наиболее подробно процедура описана в приказе №239, но даже это описание не дает прямого ответа. Так, в соответствии с требованиями данного документа анализ угроз безопасности информации должен включать:

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

При этом в качестве исходных данных для анализа угроз следует использовать банк данных угроз безопасности ФСТЭК и руководствоваться методическими документами ФСТЭК России.

Раздел «Угрозы» Банка данных угроз и уязвимостей ФСТЭК России содержит описания более 200 видов угроз. Описания довольно краткие (см. пример на рисунке 1), и самое главное – большинство угроз сформулированы в терминах воздействия на отдельный компонент информационной системы. Без дополнительного анализа по такому описанию невозможно сделать вывод о последствиях воздействия для функционирования информационной системы и для безопасности обрабатываемой в ней информации.

Рисунок 1. Пример описания угрозы из БДУ ФСТЭК

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

Аналогичный документ, рекомендованный для применения в критических информационной инфраструктуре, является документом ограниченного распространения и в настоящей статье не рассматривается.

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

Рисунок 2. Описание атаки ARP spoofing в методическом документе ФСТЭК

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

«Угроза», «способ», «сценарий»

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

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

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

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

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

Подобный подход методически неверен. В указанных источниках угрозы описаны в терминах воздействия на отдельный элемент информационной системы или инфраструктуры, причем для этого воздействия нарушителю требуется обладать определенными возможностями. Так, для перехвата трафика методом ARP spoofing нарушителю необходимо контролировать один из узлов локальной сети. Поскольку изначально нарушитель может не обладать подобными возможностями, у исследователя появляется соблазн признать данную угрозу неактуальной. Но в реальной жизни угрозы, которые могут быть реализованы в одно действие, большая редкость. Каждый известный инцидент – многоходовка, набор последовательных действий нарушителя в рамках некоторого сценария. Целью всех этих действий является достижение нужных нарушителю последствий выполнения сценария, а каждая реализуемая в рамках этого сценария угроза безопасности информации – лишь способ приблизиться к достижению этой цели. Таким образом, концентрация на анализе отдельных угроз безопасности информации может привести к тому, что действительно серьезные и практически реализуемые угрозы критическим процессам так и не будут рассмотрены. Покажем это на примере реального инцидента.

16 августа 2015 года

Подробнее см. в постановлении девятого арбитражного апелляционного суда от 31 августа 2016 г. по делу №А40-209112/2015

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

Для кражи наличных средств из банкоматов часто применяется атака «отмена платежа» (payment reversal). Преступник открывает в банке счет и получает привязанную к нему платежную карту. На счет вносится сумма, которую можно за одну операцию снять наличными в банкомате (150-200 тыс. руб.), и эту сумму банк устанавливает в качестве текущего лимита операций с данной картой. Преступник снимает эту сумму в банкомате, лимит уменьшается до нуля, после чего в процессинговый центр поступает сообщение об отмене платежа и для лимита операций устанавливается прежнее значение. Это дает преступнику возможность снова снять ту же сумму наличными. Такой трюк может повторяться до тех пор, пока в кассетах банкомата не закончатся купюры или пока действия преступника не будут замечены.

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

В данном примере «двойной ввод» не способен был предотвратить кражу. Как установило следствие, преступники внедрялись в информационную инфраструктуру банка, рассылая сотрудникам банка сообщения электронной почты с внедренной вредоносной программой Trojan-Dropper.Win32.Metel. Данная троянская программа позволяет получать контроль над атакованными рабочими местами, устанавливает соединение с сервером управления и дает хакерам возможность удаленно применять стандартные методы атаки на внутреннюю инфраструктуру (поиск и эксплуатация известных уязвимостей, анализ сетевого трафика с перехватом паролей пользователей и т.п.). Получив контроль над рабочими местами уполномоченных пользователей, преступники получили возможность отправлять от их имени управляющие сообщения в процессинговый центр. При этом защита методом «двойного ввода» не является для атакующего препятствием: учетная запись второго сотрудника получается теми же способами, что и первая учетная запись.

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

внедрение вредоносной программы в атакуемую инфраструктуру с применением методов социальной инженерии («УБИ.186: Угроза внедрения вредоносного кода через рекламу, сервисы и контент» – наиболее близкая по смыслу к рассылке инфицированных сообщений электронной почты);
загрузка на контролируемые узлы инфраструктуры инструментальных средств, необходимых для расширения атаки («УБИ.006: Угроза внедрения кода или данных»);
анализ сетевого трафика, получение учетных записей и аутентификационных маркеров («УБИ.034: Угроза использования слабостей протоколов сетевого/локального обмена данными»);
повышение привилегий до получения необходимых прав доступа – чаще всего атакующие стремятся получить административный доступ к контроллеру домена («УБИ.031: Угроза использования механизмов авторизации для повышения привилегий»);
использование привилегированного доступа для выполнения нужных нарушителю действий («УБИ.063: Угроза некорректного использования функционала программного и аппаратного обеспечения»).

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

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

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

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

Сценарии Cyber Kill Chain

Чтобы упростить моделирование действий нарушителя, исследователи неоднократно пытались систематизировать известные сценарии атак и выделить основные их

фазы по аналогии с

фазами ведения боевых действий.

Само понятие «kill chain» (убийственная последовательность) заимствовано из сленга Корпуса морской пехоты США и означает типовую последовательность действий, приводящую к уничтожению противника (например, «find, fix, fight, finish» — «найти, обездвижить, атаковать, прикончить»), в более широком смысле – к достижению требуемого результата.

Одна из первых систематизированных моделей (The Cyber Kill Chain) была предложена компанией Lockheed-Martin в 2011 году. Согласно этой модели, успешная атака на информационную инфраструктуру организации состоит из семи фаз:

разведка (reconnaissance), то есть сбор общедоступной информации об объекте атаки;
подготовка инструментария, прежде всего – вредоносного ПО (weaponization), с учетом особенностей инфраструктуры объекта атаки;
доставка (delivery) вредоносного ПО на атакуемый объект;
внедрение вредоносного ПО с использованием уязвимостей (exploitation);
использование внедренного вредоносного ПО для развертывания дополнительных инструментальных средств (installation), необходимых для развития атаки;
использование внедренных инструментальных средств для удаленного доступа к инфраструктуре и получения контроля над ней (command and control);
достижение целей нарушителя (actions on objective).

Подобное разделение на фазы в целом соответствует большинству атак, связанных с использованием вредоносного ПО, но для моделирования угроз подобная модель практически непригодна, потому что:

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

Тем не менее, несмотря на свои недостатки, модель дала толчок к развитию сценарных методов моделирования атак, и на сегодняшний день основным инструментом моделирования является база знаний ATT&CK (Adversarial Tactics, Techniques & Common Knowledge – тактики, техники и известные факты о противнике) компании MITRE. Ее создатели пошли по пути накопления базовых техник (techniques), то есть способов выполнения нарушителем атакующих действий. Техники группируются в тактики (tactics), направленных на достижение нарушителем некоторой цели, конечной или промежуточной. Всего выделяются двенадцать тактик:

Первичное проникновение (initial access) – получение нарушителем начального (хоть какого-то) доступа к информационной системе или сегменту сети, который в дальнейшем используется в качестве плацдарма для развития атаки.
Выполнение (execution) необходимого нарушителю программного кода (инструментальных средств) на узле, к которому получен первичный доступ. Эта тактика может использоваться для внедрения вредоносного ПО, но не ограничивается им.
Закрепление (persistance) – обеспечение инструментальным средствам нарушителя возможности постоянного присутствия на атакованном узле, в том числе – после принудительного завершения процесса, перезагрузки узла и т.п.
Повышение привилегий (privilege escalation) – название тактики говорит само за себя.
Противодействие защите (defense evasion) – защита инструментальных средств нарушителя от обнаружения или блокирования со стороны применяемых жертвой средств защиты.
Авторизованный доступ (credential access) – получение нарушителем учетных записей легитимных пользователей или иной информации, необходимой для получения доступа к компонентам информационной инфраструктуры от имени легитимных пользователей, а также создание нарушителем собственных учетных записей, обладающих необходимыми привилегиями.
Исследование (discovery) – сбор сведений об инфраструктуре, полезных для начала или развития атаки.
Распространение (lateral movement) – получение начального доступа к компонентам информационной инфраструктуры, смежным с атакованным узлом.
Сбор (collection) данных, которые могут как сами по себе являться целью действий нарушителя, так и способствовать дальнейшим действиям нарушителя (например, перехват клавиатурного ввода или изображения на экране компьютера).
Удаленное управление (command and control) инструментальными средствами нарушителя.
Эксфильтрация (exfiltration), то есть копирование данных за пределы атакованной информационной инфраструктуры, в том числе – с обходом средств противодействия.
Причинение вреда (impact), в том числе – на промежуточных стадиях сценария для сокрытия следов или затруднения противодействия.

В отличие от модели The Cyber Kill Chain, в ATT&CK тактики не образуют последовательность. В этой модели нарушитель может выполнить начальное проникновение в организацию, исследовать ее инфраструктуру и обнаружить незащищенный доступ в инфраструктуру дочерней компании, провести исследование и найти на серверах дочерней компании незащищенную целевую информацию, извлечь ее и совершить иные действия.

Для каждой тактики в базе знаний содержатся возможные способы ее реализации – техники. Так, в зависимости от конкретного программного инструмента, тактика «выполнение» для его внедрения может быть реализована через программный интерфейс API, с помощью утилит командной строки, через регистрацию компонента ActiveX утилитой regsvr32, с помощью расписания Scheduled Task и т.п. Для каждой техники в базе знаний содержится ее подробное описание и публично известные случаи применения этой техники в реальной жизни.

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

Применение ATT&CK для моделирования угроз

Обратной стороной детального описания техник в модели ATT&CK является невозможность ее использования для абстрактной информационной системы на стадии ее создания. Моделирование угроз на основе этой модели возможно только после того, как будут выбраны основные технические решения, а также на стадии оценки защищенности информационной системы для ее последующей модернизации.
При моделировании угроз используется фиксированная модель нарушителя. Рассматриваемый нарушитель:

является высококлассным специалистом;
обладает знанием и навыками применения всех техник ATT&CK;
способен применять известные техники и их вариации;
способен использовать инструментальные средства, имеющиеся в свободном доступе или свободной продаже;
способен самостоятельно разрабатывать инструментальные средства, при условии, что принцип их действия известен;
знает архитектуру программных и аппаратных средств, особенности их реализации и использования их функциональных возможностей на уровне разработчика, но в объеме, соответствующем документации, имеющейся в свободном доступе или предоставляемой пользователям.

Прежде всего, определяются начальные возможности нарушителя:

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

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

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

Описанный выше подход может оказаться очень трудоемким, поэтому на практике часто применяются различные способы оптимизации, например:

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

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

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

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

Заключение

Моделирование угроз на основе сценариев позволяет одновременно решить сразу несколько задач обеспечения информационной безопасности:

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

При этом каждой технике из базы знаний ATT&CK соответствует некоторая угроза из БДУ ФСТЭК, что позволяет использовать БДУ как классификатор действий нарушителя и формализовывать сценарии в соответствии с требованиями нормативных документов ФСТЭК.

При этом следует учитывать, что база знаний ATT&CK имеет свои ограничения. Так, она содержит только примеры действий нарушителя, возможность выполнения которых подтверждена практикой или лабораторными исследованиями, и на ее основе невозможно в полном объеме смоделировать некоторые теоретически возможные угрозы, предусмотренные БДУ ФСТЭК. Таким образом, моделирование угроз на основе сценариев требует не только заимствования готовых знаний, но и самостоятельной оценки возможностей реализации перспективных угроз, особенно когда речь идет о применении мобильной связи, облачных технологий, Интернета вещей и т.п.

Интернет-портал «Безопасность пользователей в сети Интернет»
admin@safe-surf.ru
https://safe-surf.ru

В центре внимания

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

Интернет-портал «Безопасность пользователей в сети Интернет»
admin@safe-surf.ru
https://safe-surf.ru

Источник

Экспертный материал

Алексей Залецкий | специалист по информационной безопасности

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

Столкнувшись с инцидентами информационной безопасности или требованиями регуляторов, первый вопрос, который встает перед любой компанией: «На чём основываться при создании системы защиты информации?». И тут на помощь приходит процедура моделирования угроз, которая позволяет определить актуальные угрозы безопасности, от которых и необходимо защищать бизнес.

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

Что такое модель угроз и кому необходимо ее разрабатывать

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

Что защищаем?
От чего защищаем?
Какой ущерб может быть нанесен?

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

Как результат оценки рисков будет понимание, сколько обосновано компания может потратить на создание системы защиты информации. Так как информационная безопасность — это почти неосязаемая сфера, пока не случится инцидент, крайне важно руководству иметь какие-то ориентиры для определения объёма финансирования этой составляющей.

Но если смотреть с точки зрения построения системы защиты, даже при отчетливо понятных границах бюджета всё равно остаётся вопрос: «А от чего защищать?». И ответ на этот вопрос предоставляет модель угроз. Она позволяет понять, какие угрозы для компании актуальны, а какие нет, и что даёт возможность построить действительно эффективную систему защиты.

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

О том, как разработать модель угроз и на что обратить внимание, мы писали в статье.

Что нового в моделировании угроз

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

С 2015 года существует ресурс bdu.fstec.ru, который крайне полезен при моделировании угроз, а для некоторых типов систем даже обязателен.

Чего пока нет, так это новых базовых моделей угроз. Есть базовая модель угроз КСИИ от 2007 года (которая, в дальнейшем заменила документы по КИИ, кроме как раз базовой модели угроз) и базовая модель угроз персональных данных от 2008 года.

Базовая модель угроз безопасности информации в ключевых системах информационной инфраструктуры (утв. ФСТЭК России 18.05.2007) имеет гриф ДСП (для служебного пользования и не распространяется свободно).

Основные сложности при моделировании угроз

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

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

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

Используемые методики, иные документы и ресурсы

В первую очередь это методика оценки угроз безопасности информации ФСТЭК России от 5 февраля 2021 года.

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

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

Отраслевые базовые модели угроз.

Сайт Банка данных угроз ФСТЭК России.

Основные этапы моделирования угроз

В соответствии с новой методикой определение актуальных угроз проводится в три этапа:

Этап 1. Определение негативных последствий

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

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

Этап 2. Определение возможных объектов воздействия угроз безопасности информации

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

Этап 3. Оценка возможности реализации (возникновения) угроз безопасности информации и определение их актуальности.

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

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

В новой методике определены четыре уровня возможностей нарушителей:

базовые возможности по реализации угроз безопасности информации (Н1);
базовые повышенные возможности по реализации угроз безопасности информации (Н2);
средние возможности по реализации угроз безопасности информации (Н3);
высокие возможности по реализации угроз безопасности информации (Н4).

Здесь есть отличия от того, как возможности классифицируются в Банке данных угроз (БДУ) ФСТЭК России, которые делятся на:

нарушитель с низким потенциалом;
нарушитель со средним потенциалом;
нарушитель с высоким потенциалом.

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

Оценка актуальности угроз безопасности информации

Угроза является актуальной, если от реализации угрозы может быть нанесён ущерб, есть актуальный нарушитель и сценарий реализации угрозы.

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

Самое сложное — это определение сценариев реализации угроз.

В методике приведены примеры таких сценариев, например:

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

Разработка сценариев реализации угроз

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

Более удобный и предсказуемый в плане трудозатрат вариант — сценарии в табличном виде.

Примеры сценариев

Пример сценариев в табличном виде:

УБИ	Наименование угрозы	Актуальность угрозы	Потенциал нарушителя	Тактика	Основные техники
3-й уровень (обеспечения системного программного обеспечения серверных компонентов)
6	Угроза внедрения кода или данных	Актуальная	Внешний нарушитель с низким потенциалом	Т3 T10	Т3.1-Т3.9 Т10.1-Т10.7
8	Угроза восстановления аутентификационной информации	Актуальная	Внешний нарушитель с низким потенциалом	Т6	Т6.1-Т6.7
14	Угроза длительного удержания вычислительных ресурсов пользователями	Актуальная	Внешний нарушитель с низким потенциалом	T10	Т10.10-Т10.11
15	Угроза доступа к защищаемым файлам с использованием обходного пути	Актуальная	Внешний нарушитель с низким потенциалом	T9	Т9.4, Т9.7
22	Угроза избыточного выделения оперативной памяти	Актуальная	Внешний нарушитель с низким потенциалом	T10	Т10.10-Т10.11
28	Угроза использования альтернативных путей доступа к ресурсам	Актуальная	Внешний нарушитель с низким потенциалом	T9	Т9.11
31	Угроза использования механизмов авторизации для повышения привилегий	Актуальная	Внешний нарушитель с низким потенциалом	Т6	Т6.1-Т6.9
34	Угроза использования слабостей протоколов сетевого/локального обмена данными	Актуальная	Внешний нарушитель с низким потенциалом	Т7	Т7.21

Номера тактик и техник можно взять из приложения к методике и добавить собственные. Данный табличный вид позволяет автоматизировать процесс моделирования. Можно разработать свой шаблон сценариев, например, в Excel. Где, выбирая из перечня тактик и техник, можно за сравнительно небольшое время получить сценарии всех актуальных угроз.

Более детально сценарии реализации угроз безопасности, мы рассматривали на вебинаре.

Заключение

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

Ознакомиться с облачным решением 152-ФЗ от Corpsoft24

Источник

Методика моделирования угроз безопасности информации. Мой обзор

15 апреля, 2020

Добрый день, коллеги! 09 апреля на сайте ФСТЭК России появился проект » Методики моделирования угроз безопасности информации «. Предыдущий проект б ыл выпущен еще в 2015 году , но официальным нормативным документом так и не стал. А потребность в новой методике осталась. Мы долго ждали и дождались! Новый проект! Конечно, я не могу пройти мимо. Приступим к анализу, как повелось, обозревать буду в основном с позиции защиты персональных данных.

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

Где применять?

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

Остаются bdu.fstec.ru, базовые и типовые модели угроз.

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

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

Кто составляет модель угроз?

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

Негативные последствия реализации угроз

Негативные последствия определяются из требований законодательства и экспертным методом.

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

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

Описание источников угроз содержит кроме самих источников цели реализации угроз, категории и виды нарушителей и возможности каждого вида нарушителей.

Нарушители могут быть нескольких видов:

1. Нарушитель, обладающий базовыми возможностями (потенциалом);

2. Нарушитель, обладающий повышенными базовыми возможностями (потенциалом);

3. Нарушитель, обладающий средними возможностями (потенциалом);

4. Нарушитель, обладающий высокими возможностями (потенциалом).

Сценарии реализации угроз

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

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

Описание угрозы безопасности

1. Термины и определения.

2. Рекомендации к формированию экспертной группы. Здесь я бы отметила, что членов экспертной группы должно быть не менее 3х.

3. Краткое содержание модели угроз.

1. Методика сложная, для крупных предприятий или для лицензиатов — в самый раз. Для мелких и средних не представляю как применять, а операторами персональных данных являются по факту все организации.

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

3. Непонятно как будет оцениваться полнота модели, как определить, что все возможные сценарии рассмотрены?

4. Наличие удаленного доступа делает уровень опасности угрозы средним и выше.

5. Непонятно что делать дальше с цифровыми значениями уровней опасности угроз.

6. Я не поняла как связаны актуальность и опасность. В определении актуальной угрозы нет указания на опасность, только на негативные последствия.

7. Непонятно как подбирать меры защиты.

_________

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

Источник

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

сиспользованием автоматизированных средств (рисунок 8).

5.3.6.На этапе эксплуатации определение сценариев реализации угрозы

включает:

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

б) проведение инвентаризации информационных систем и сетей и определение объектов воздействия и их интерфейсов;

в) определение внешних интерфейсов, которые могут быть задействованы при реализации угроз безопасности информации;

г) определение внутренних интерфейсов, которые могут быть задействованы при реализации угроз безопасности информации;

д) выявление уязвимостей объектов воздействия, а также компонентов систем и сетей, имеющих внешние интерфейсы, с которыми посредством внутренних интерфейсов взаимодействуют объекты воздействия;

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

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

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

Нарушитель реализовал SQL инъекцию

Сайт

Интернет

Отказ в

обслуживании

веб-приложения

Нарушитель отправил

письмо с вредоносным

Возможен

недопустимый

файлом

Эксплуатация

ущерб

виде простоя

Серверы

уязвимости

бизнес-процессов

компании из-за вывода из

Сервер

строя

инфраструктуры

или

шифрования

информации

Компьютеры

Изменение

Эксплуатация

администраторов

конфигурации

уязвимости

Учетная запись

Получение

администратора

доступа

Сервисная

домена

учётная запись

Граничное

Сервер

сетевое

Атака на

АРМ

оборудование

Использование

Подбор пароля

протокол

вредоносного

Атака на

Подмена

ПО

Подбор

промышленный

Контроллер

Компьютер

прошивки ПЛК

пароля

протокол

домена

сотрудника

Внутренний нарушитель

подключает внешнее устройство к

Получение

АРМ оператора, или реализует

доступа

угрозы на уровне сети

Системы

АРМ

управления и

АРМ оператора

Следует

недопустимый

Перезапись

регистров

ущерб

экологии

Программируемые

памяти ПЛК

человеческие жертвы

логические

Отправка заведомо

контроллеры (ПЛК)

Изменение логики и уставок

ложных распоряжений

от имени

Компьютеры

в ПЛК, приводящие к

финансового

руководства

несрабатыванию

аварийных

директора

задвижек

Полевые устройства и

Следует недопустимый

ущерб репутации и срыв

датчики

соглашений

Подбор пароля

Описание техники реализации угроз безопасности

информации

Компьютеры

бухгалтерии и

Отказ в обслуживании веб-

финансовой

Угроза безопасности информации

системы

приложения

Следует недопустимый

Следует

недопустимый

финансовый ущерб

Недопустимое негативное последствие

финансовый ущерб

Рисунок 8. Пример сценариев реализации угроз безопасности информации

Приложение 1 к Методике оценки угроз безопасности информации

Термины и определения, применяемые для целей настоящего методического документа

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

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

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

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

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

Компонент (системы, сети): программное, программно-аппаратное или техническое средство, входящее в состав систем и сетей.

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

Обладатель информации: лицо, самостоятельно создавшее информацию либо получившее на основании закона или договора право разрешать или ограничивать доступ к информации, определяемой по каким-либо признакам.

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

Основные (критические) процессы (бизнес-процессы):

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

нарушение и (или) прекращение которых может привести к возникновению рисков (ущербу).

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

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

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

Угроза безопасности информации: совокупность условий и факторов,

создающих потенциальную или реально существующую опасность нарушения безопасности информации.

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

Приложение 2 к Методике оценки угроз безопасности информации

Рекомендации по формированию экспертной группы и проведению экспертной оценки при

оценке угроз безопасности информации

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

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

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

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

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

а) формирование экспертной группы

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

подразделения по защите информации (обеспечения информационной безопасности);

подразделения, ответственного за цифровую трансформацию (ИТ-специалистов);

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

систем управления; подразделений обладателя информации или оператора, ответственного за

выполнение основных (критических) процессов (бизнес-процессов).

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

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

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

В состав экспертной группы должны входить не менее трех экспертов.

б) проведение экспертной оценки

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

Экспертную оценку рекомендуется проводить в отношении следующих параметров:

а) негативного последствия от реализации угроз безопасности информации;

б) целей нарушителей по реализации угроз безопасности информации; в) сценария действий нарушителей при реализации угроз безопасности

информации.

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

Опрос экспертов включает следующие этапы:

каждый эксперт проводит оценку оцениваемого параметра (рекомендуется не мене двух раундов оценки), результаты которой заносятся в таблицу;

после оценки каждым из экспертов отбрасываются минимальные и максимальные значения;

определяется среднее значение оцениваемого параметра в каждом раунде; определяется итоговое среднее значение оцениваемого параметра.

Пример таблицы результатов оценки параметров

Эксперты	Значение оцениваемого	Значение оцениваемого
	параметра (раунд 1)	параметра (раунд 2)
Эксперт 1
Эксперт 2
Эксперт n
Итоговое значение

Приложение 3 к Методике оценки угроз безопасности информации

Рекомендуемая структура модели угроз безопасности информации

УТВЕРЖДАЮ

Руководитель органа государственной власти (организации) или иное уполномоченное лицо

________________________

«___» ______________20__г.

Модель угроз безопасности информации

«_________________________________________________»

наименование системы и (или) сети

1. Общие положения

Раздел «Общие положения» содержит: назначение и область действия документа;

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

наименование обладателя информации, заказчика, оператора систем и сетей;

подразделения, должностные лица, ответственные за обеспечение защиты информации (безопасности) систем и сетей;

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

2. Описание систем и сетей и их характеристика как объектов защиты

Раздел «Описание систем и сетей и их характеристика как объектов защиты» содержит:

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

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

нормативные правовые акты Российской Федерации, в соответствии с которыми создаются и (или) функционируют системы и сети;

назначение, задачи (функции) систем и сетей, состав обрабатываемой информации и ее правовой режим;

основные процессы (бизнес-процессы) обладателя информации, оператора, для обеспечения которых создаются (функционируют) системы и сети;

состав и архитектуру систем и сетей, в том числе интерфейсы и взаимосвязи компонентов систем и сетей;

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

описание внешних интерфейсов и взаимодействий систем и сетей с пользователями (в том числе посредством машинных носителей информации, средств ввода-вывода, веб-приложений), иными системами и сетями, обеспечивающими системами, в том числе с сетью «Интернет»;

информацию о функционировании систем и сетей на базе информационно-телекоммуникационной инфраструктуры центра обработки данных или облачной инфраструктуры, о модели предоставления

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

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

3.Возможные негативные последствия от реализации (возникновения) угроз безопасности информации

Раздел «Возможные негативные последствия от реализации (возникновения) угроз безопасности информации» содержит:

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

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

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

Раздел «Возможные объекты воздействия угроз безопасности

информации» содержит:

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

описание видов воздействия на компоненты систем и сетей, реализация которых нарушителем может привести к негативным последствиям.

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

5. Источники угроз безопасности информации

Раздел «Источники угроз безопасности информации» содержит: характеристику нарушителей, которые могут являться источниками угроз

безопасности информации, и возможные цели реализации ими угроз безопасности информации;

категории актуальных нарушителей, которые могут являться источниками угроз безопасности информации;

описание возможностей нарушителей по реализации ими угроз безопасности применительно к назначению, составу и архитектуре систем и сетей.

Соседние файлы в папке Нормативные документы Российской Федерации

#
#
#
#
#
#
#
09.11.202294.26 Кб3Opisaniye ugroz.xlsx
#
09.11.20229.26 Mб2Opisaniye uyazvimostey.xlsx
#
#
#

Источник

Подборка по базе: План работы по подготовке к ЕГЭ на 2022-2023 учебный год _План р, вкр_подвижные игры как средство развития физических способностей, вкр_деятельность психолога с трудными подростками юношами в сель, 090303 ВКР ЗПИС пример.doc, КТП 11 кл новый 2020-2021 учебный год МОЙ.doc, Сайты для подготовки к ОГЭ.pdf, Программа работы с одаренными детьми на 2022-2023 учебный год.do, 2021. Анализ и оценка финансового состояния предприятия на приме, Анализ материальных ресурсов предприятия на примере предприятия , Неделя психологии в школе (2019-2020 учебный год).docx

Определение возможных сценариев реализации угроз безопасности информации

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

Сценарии реализации угроз безопасности информации определяются для соответствующих способов реализации угроз безопасности информации, определенных в Главе 6 настоящей Модели угроз, и применительно к объектам воздействия и видам воздействия на них. Определение сценариев предусматривает установление последовательности возможных тактик и соответствующих им техник, применение которых возможно актуальным нарушителем с соответствующим уровнем возможностей, а также доступности интерфейсов для использования соответствующих способов реализации угроз безопасности информации.

Актуальные для ИСПДн «Название ИСПДн» нарушители и их условные обозначения представлены в Таблице №10.
Таблица №10

№ п/п	Наименование	Условное обозначение
	Отдельные физические лица (хакеры)	Н1
	Лица, обеспечивающие поставку программных, программно-аппаратных средств, обеспечивающих систем	Н2
	Бывшие (уволенные) работники (пользователи)	Н3
	Авторизованные пользователи ИСПДн	Н4
	Лица, привлекаемые для установки, настройки, испытаний, пусконаладочных и иных видов работ	Н5
	Лица, обеспечивающие функционирование ИСПДн или обеспечивающих систем оператора (администрация, охрана, уборщики и др.)	Н6
	Системные администраторы и администраторы безопасности	Н7
	Конкурирующие организации	Н8

Все возможные способы реализации угроз безопасности информации для ИСПДн «Название ИСПДн» и их условные обозначения приведены в Таблице №11.
Таблица №11

№ п/п	Наименование	Условное обозначение
	Использование уязвимостей прикладного программного обеспечения	С1
	Использование уязвимостей системного программного обеспечения	С2
	Внедрение вредоносного программного обеспечения	С3
	Использование недекларированных возможностей программного обеспечения	С4
	Использование уязвимостей протоколов сетевого взаимодействия	С5
	Использование открытых портов сетевого взаимодействия	С6
	Использование некорректной настройки парольной политики	С7
	Физический доступ к техническим средствам ИС	С8
	Ошибочные действия при настройке	С9
	Программные сбои	С10
	Использование уязвимостей сетевого оборудования	С11

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

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

Возможные сценарии реализации угроз представлены в Таблице №12.
Таблица №12

№ п/п	Вероятные нарушители	Способ реализации угрозы	Тактика	Техники
Банк данных угроз ФСТЭК России (bdu.fstec.ru)
1	УБИ.006: Угроза внедрения кода или данных
Н1, Н3	С1, С2, С3, С7	Т1	Т1.3, Т1.4, Т1.11
Т2	Т2.5, Т2.7, Т2.8, Т2.10, Т2.11
Т3	Т3.1, Т3.7, Т3.14
Н2	С1, С2, С3, С7	Т1	Т1.3, Т1.4, Т1.11
Т3	Т3.10
2	УБИ.008: Угроза восстановления аутентификационной информации
Н4, Н6	С7	Т1	Т1.9, Т1.11, Т1.12
Т2	Т2.5, Т2.10, Т2.11
Н5, Н7	С7	Т1	Т1.9, Т1.11, Т1.12
Т2	Т2.5, Т2.10, Т2.11
Н1, Н2, Н3	С7	Т1	Т1.6, Т1.11
Т2	Т2.4, Т2.10, Т2.11
3	УБИ.009: Угроза восстановления предыдущей уязвимой версии BIOS
Н4, Н6	С8, С10	Т1	Т1.11, Т1.13
Т2	Т2.5
Т7	Т7.22
Н5, Н7	С8, С10	Т1	Т1.11, Т1.13
Т2	Т2.5
Т7	Т7.22
…

Источник

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

Зачем нужна модель угроз?

Необходимость разработки модели угроз регламентирована рядом нормативных документов. Вот некоторые из них.

Часть 2 статьи 19 закона №152-ФЗ «О персональных данных»:

2. Обеспечение безопасности персональных данных достигается, в частности:

1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных;

Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных (утверждены приказом ФСТЭК России от 18 февраля 2013г. №21):

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

Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утверждены ФСТЭК России от 11 февраля 2013г. №17)

Формирование требований к защите информации… в том числе включает:
…
определение угроз безопасности информации, реализация которых может привести к нарушению безопасности информации в информационной системе, и разработку на их основе модели угроз безопасности информации;
…

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

Формирование требований к защите информации в автоматизированной системе управления… в том числе включает:
…
определение угроз безопасности информации, реализация которых может привести к нарушению штатного режима функционирования автоматизированной системы управления, и разработку на их основе модели угроз безопасности информации;

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

11. Разработка организационных и технических мер по обеспечению безопасности значимого объекта осуществляется субъектом критической информационной инфраструктуры… и должна включать:

а) анализ угроз безопасности информации и разработку модели угроз безопасности информации или ее уточнение (при ее наличии);

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

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

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

В качестве хрестоматийного примера описания содержания модели угроз можно привести 17 приказ ФСТЭК:

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

Вы не поверите, но это все. Но с другой стороны, хоть текста и не много, но он довольно содержательный. Давайте еще раз перечитаем и выпишем, что должно быть в нашей модели угроз:

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

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

Вступительная часть модели угроз

Хорошо, давайте уже перейдем к содержанию документа.

Думаю про титульный лист, список сокращений, терминов и определений все понятно. Хотя, пожалуй, стоит поподробнее остановиться на… внезапно титульном листе.

В шаблоне его подписывает именно руководитель владельца информационной системы. Это не просто так.

Постановление Правительства РФ от 11 мая 2017г. №555:

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

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

Раздел «Нормативно-методическое обеспечение»

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

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

Частой ошибкой здесь бывает добавление различных ГОСТ и прочих нормативных документов (очень любят сюда вписывать СТР-К), никак не связанных с моделированием угроз. Либо отмененных документов. Например, часто в моделях угроз можно встретить в списке нормативных документов ФСБшные так называемые «Методические рекомендации…» и «Типовые требования…», которые давно не актуальны.

Общие положения

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

Описание информационной системы

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

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

Пример:

Серверная часть информационной системы «Нипель» представляет собой кластер физических серверов, на которых развернут гипервизор ESXi 6.x. Работа серверной части основных сервисов информационной системы обеспечивается виртуальными серверами (имена серверов) под управлением операционных систем (список ОС). Основным программным обеспечением, реализующим технологические процессы обработки является (название ПО). Прикладное программное обеспечение является клиент-серверным приложением. Клиентская часть работает как толстый клиент на рабочих станциях пользователей под управлением операционных систем (список ОС). Пользователи получают доступ к информационной системе, как из локальной сети, так и через сеть интернет с использованием защищенных каналов связи. В целом информационная система функционирует как показано на схеме.

Прикладывается функциональная (не топологическая!) схема информационной системы.

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

Здесь же есть раздел «Охрана помещений». Тут описываем, как охраняются помещения в рабочее и в нерабочее время – видеонаблюдение, СКУД, охранник, вахтер, сигнализация и вот это все.

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

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

Модель нарушителя

Здесь можно разделить эту часть на классическую и новую. Классическая это та самая, где описаны потенциальные нарушители 1, 2 и далее категорий. На самом деле эта часть модели нарушителя оставлена в шаблоне только потому, что регуляторам нравится, когда она есть. Практическую же ценность представляет раздел «Нарушители согласно банку данных угроз ФСТЭК России».

Практическую ценность этот раздел представляет потому, что сами угрозы из банка данных угроз ФСТЭК (далее – БДУ) привязаны к нарушителям с низким, средним и высоким потенциалом. Сам раздел представляет из себя копипасту описаний характеристик нарушителей с низким, средним и высоким потенциалами. Далее делается вывод нашим любимым «экспертным» путем — какой нарушитель для нас актуален. То есть, по сути, составитель выбирает нарушителя «на глаз», потому что каких-либо методик выбора нарушителя просто нет.
Не будем здесь приводить эти описания полностью, постараемся коротко сформулировать, чем отличаются потенциалы нарушителей. Кроме разграничения по потенциалу нарушители еще бывают внешние и внутренние.

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

В реалистичных ситуациях потенциал нарушителя либо низкий, либо средний.

«ФСБшные» разделы

Далее идут разделы «Обобщенные возможности источников атак» и «Реализация угроз безопасности информации, определяемых по возможностям источников атак». Эти разделы не нужны, если не используются криптосредства. Если они все же используются, то исходные данные, да и в целом таблицы для этих разделов выдумывать не нужно, они берутся из нормативного документа ФСБ «Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности» (утверждены руководством 8 Центра ФСБ России 31 марта 2015 года, № 149/7/2/6-432).

У нас правда в шаблоне результат несколько отличается от дефолтного, приведенного в указанном выше, документе ФСБ.

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

Чаще всего применимый класс криптосредств – КС3. Сейчас расскажем почему.

Вообще в документе «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (утверждены приказом ФСБ России от 10 июля 2014 года № 378) класс СКЗИ для рассматриваемой системы устанавливается, во-первых исходя из типа угроз, а во-вторых исходя из возможностей нарушителя.

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

Потому что 378 приказ ФСБ:

СКЗИ класса КА в случаях, когда для информационной системы актуальны угрозы 1 типа;

СКЗИ класса КВ и выше в случаях, когда для информационной системы актуальны угрозы 2 типа;

СКЗИ класса КС1 и выше в случаях, когда для информационной системы актуальны угрозы 3 типа.

Вроде понятно, а в чем проблема? Проблема в том, что СКЗИ классов КА1, КВ1 и КВ2 вы не сможете купить просто так, даже если у вас есть куча денег, которых они стоят.

Проведем небольшое «расследование». Качаем свежий реестр СКЗИ, ищем СКЗИ класса КА1. Поиском первым попался «Аппаратно-программный шифратор М-543К». Идем в гугл, пишем «Аппаратно-программный шифратор М-543К купить» — провал. Пытаемся «купить» следующее криптосредство – опять провал. Вбиваем просто «криптосредство КА1 купить» — провал. Получаем только ссылки на другие криптосредства классов КС1-КС3 или на форумы, где обсуждают криптографию. А дело в том, что, как уже было сказано, просто так купить СКЗИ классов КА и КВ вы не сможете, только через специализированные воинские части. Зачем было эти криптосредства вообще упоминать в документе по персональным данным – до сих пор не ясно. Поэтому в обычной ИСПДн — только третий тип угроз.

С КА и КВ разобрались, но почему именно КС3, а не КС2 и КС1? Тут уже виновато второе условие – нарушитель.

378 приказ ФСБ:

12. СКЗИ класса КС3 применяются для нейтрализации атак, при создании способов, подготовке и проведении которых используются возможности из числа перечисленных в пунктах 10 и 11 настоящего документа и не менее одной из следующих дополнительных возможностей:

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

Тут логика такая:

такие распространенные СКЗИ, как, например ViPNet Client или КриптоПРО CSP реализованы на рабочих станциях пользователей;
пользователи – потенциальные нарушители;
потенциальный нарушитель имеет физический доступ к средствам вычислительной техники, на которых реализованы их СКЗИ и среда функционирования.

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

Уязвимости

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

У составителя модели угроз сразу должен появиться вопрос: а что нужно прям список выявленных сканером уязвимостей к документу прикладывать? Вопрос хороший и ответ не однозначный. Знаем мы коллег, которые делают именно так, но мы считаем такой подход неправильным и вот почему.

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

Список уязвимостей, который формируется сканерами – информация очень динамичная. Сегодня мы выявили уязвимости, завтра их устранили и просканировали заново – получили новый отчет. Послезавтра появились новые сигнатуры, сканер обновился и нашел новые уязвимости и так по кругу. Какой смысл прикладывать отчет сканера уязвимостей, сделанный на момент разработки модели угроз? Никакого.

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

Выход из этой ситуации простой. Указывать в модели угроз не конкретные уязвимости с указанием идентификатора CVE и рейтинга CVSS, а перечислить возможные классы уязвимостей для конкретной информационной системы. А чтобы придать этому списку солидности, возьмем этот список не из головы, а из ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». Перечень под спойлером. Берем его и убираем лишние, не совместимые со структурно-функциональными характеристиками нашей системы. Раздел готов!

Классы уязвимостей по ГОСТ

Уязвимости по области происхождения:

уязвимости кода;
уязвимости конфигурации;
организационные уязвимости;
многофакторные уязвимости.

Уязвимости по типу недостатков информационной системы:

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

Уязвимости по месту возникновения (проявления):

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

Частная модель угроз безопасности

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

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

Здесь сразу же хотелось бы рассказать о плюсах и минусах БДУ. Несомненный плюс – это то, что теперь нет необходимости придумывать и формулировать угрозы самостоятельно, хотя дополнить модель угроз своими угрозами тоже ничего не запрещает. Еще один плюс это прописанный потенциал нарушителя и определенные нарушаемые характеристики безопасности информации для каждой угрозы – не нужно ничего выдумывать.

Минусы. Первый минус это до ужаса скудные возможности по сортировке угроз. Когда вы первый раз начинаете делать модель угроз по БДУ, то естественное желание это отсеять угрозы, которые не могут быть актуальны в вашей системе по структурно-функциональным характеристикам. Например, убрать угрозы для виртуальных контейнеров и гипервизоров, потому что в системе не применяется виртуализация или отобрать угрозы для BIOS/UEFI нужно по какой-то причине, а такой возможности нет. Не говоря уже о том, что в БДУ целый ряд достаточно экзотических угроз, связанных, например, с суперкомпьютерами или грид-системами.

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

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

Вернемся определению списка актуальных угроз.

Уровень исходной защищенности

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

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

Список характеристик под спойлером.

Список характеристик и их значений

Каждому значению соответствует высокий, средний или низкий уровень защищенности. Считаем какой процент у нас получился для показателей с разными значениями. Про высокий уровень исходной защищенности – забудьте, его не бывает. Если «высокий» и «средний» набрали 70% и выше, то определяем средний уровень исходной защищенности (Y1 = 5), если нет, то – низкий (Y1 = 10).

Опасность угроз

Этот раздел в шаблоне называется «Определение последствий от нарушения свойств безопасности информации (опасность угроз)». Назвали его именно так, потому что, по сути, по определению опасности угроз это является определением последствий, но при согласовании модели угроз, проверяющие могут и не провести эту параллель, а поскольку «определение последствий» должно быть в модели угроз – пишут замечание.

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

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

По нашей логике негативные последствия не зависят от способа нарушения конфиденциальности, целостности и доступности. Например, если ваши персональные данные утекут в какой-то базе, то вам скорее всего будет неважно каким образом это произошло – с помощью SQL-инъекции или с помощью физического доступа нарушителя к серверу (профессиональный интерес ИБ-шника не в счет!). Поэтому определяем так сказать три «опасности угроз», для нарушения конфиденциальности, целостности и доступности. Часто они могут совпадать, но все равно в модели угроз лучше отдельно проанализировать. К счастью, в БДУ для каждой угрозы нарушаемые характеристики тоже прописаны.

Исключение «лишних» угроз

Далее, чтобы сразу отсечь лишние угрозы делаем табличку со списком исключаемых угроз и обоснование – почему мы их выкидываем.

В шаблоне в качестве примера представлены:

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

По последнему пункту нужно уточнить пару моментов:

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

Описание угроз

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

Номер по порядку и идентификатор угроз из БДУ – тут все понятно. Столбцы «описание угрозы» и «способ реализации угрозы» — текстовый блок из БДУ. В первый столбик вставляем текст до слов «Реализация угрозы возможна…». Во второй – все остальное. Разделение опять же связано с требованием нормативных документов о том, что в модели угроз должны быть описаны «Способы реализации угрозы». При согласовании это поможет избежать лишних вопросов.

Следующие столбцы таблиц это потенциалы внутреннего и внешнего нарушителей. Для того чтобы сделать таблицу боле компактной и дать больше места текстовым блокам мы предварительно сопоставили высокому, среднему и низкому потенциалам соответственно цифры 1, 2 и 3. Если потенциал в БДУ не указан, ставим прочерк.

Столбец «Объекты воздействия» — также берем данные из БДУ.

Столбец «Нарушаемые свойства» — К, Ц и Д, конфиденциальность, целостность и доступность – заменили на буквы с той же целью, что и в случае с нарушителями.

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

Определение вероятности угрозы

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

маловероятно – отсутствуют объективные предпосылки для осуществления угрозы (например, угроза хищения носителей информации лицами, не имеющими легального доступа в помещение, где последние хранятся);

низкая вероятность – объективные предпосылки для реализации угрозы существуют, но принятые меры существенно затрудняют ее реализацию (например, использованы соответствующие средства защиты информации);

средняя вероятность — объективные предпосылки для реализации угрозы существуют, но принятые меры обеспечения безопасности ПДн недостаточны;

высокая вероятность — объективные предпосылки для реализации угрозы существуют и меры по обеспечению безопасности ПДн не приняты.

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

0 – для маловероятной угрозы;
2 – для низкой вероятности угрозы;
5 – для средней вероятности угрозы;
10 – для высокой вероятности угрозы.

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

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

Список актуальных угроз

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

В последней таблице мы умышленно не стали включать некоторые параметры:

Y1 – этот параметр у нас глобальный, поэтому просто держим его в голове;
предпосылки – в финальной таблице у нас только угрозы, имеющие предпосылки, поэтому смысла в этом столбце нет.

Коротко пройдемся по столбцам. Номер по порядку и угроза уже только в виде идентификатора – тут все понятно.

«Меры приняты» — «экспертным» путем определяем, приняты ли меры для нейтрализации данной угрозы (кстати, еще один прикол методики — если меры «приняты», то угроза все равно может остаться актуальной). Может быть три варианта: приняты; приняты, но недостаточны; не приняты (+, +-, — соответственно).

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

Следующий столбец – коэффициент реализуемости угрозы Y. Вычисляется по простой формуле Y = (Y1+Y2)/20.

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

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

Ну и последнее – актуальность угрозы. Определяется по таблице:

Ура! Наша модель угроз готова.

Источник

Дата: 20.09.2022.

Категории:
Блоги экспертов по информационной безопасности

Урок 2.2. Моделирование угроз. Актуальные угрозы

Добрый день коллеги! В прошлом уроке мы разобрали, как определить возможные угрозы. Это полдела. Теперь пришло время определить то, ради чего пишется модель угроз — угрозы актуальные. Предложу один из довольно простых способов.

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

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

Пример. Техники и тактики для хакеров

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

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

Пример. Актуальные угрозы

Наименование УБИ	Сценарий	Актуальность угрозы
УБИ. 001. Угроза автоматического распространения вредоносного кода в грид-системе	Т 2.3; Т 3.4; Т 10.2	Актуальная

По вопросам сотрудничества и приобретения моих книг (электронных) обращайтесь:

telegram: @KseniaShudrova

Источник — блог Ксении Шудровой «Защита персональных данных и не только — книга рецептов».

Источник

BDU:W01 — Уязвимости, связанные с недостатками проверки вводимых данных

Описание:

Типы ошибок:

Способы эксплуатации:

Рекомендации по устранению и предотвращению:

Примеры сценариев реализации угроз:

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W02 — Уязвимости, связанные с недостатками управления доступом и защиты данных

Описание:

Типы ошибок:

Способы эксплуатации:

Рекомендации по устранению и предотвращению:

Примеры сценариев реализации угроз:

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W03 — Уязвимости, связанные с недостатками работы со структурами данных

Описание:

Типы ошибок:

Способы эксплуатации:

Рекомендации по устранению и предотвращению:

Примеры сценариев реализации угроз:

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W04 — Уязвимости, связанные с недостатками проверки подлинности

Описание:

Типы ошибок:

Способы эксплуатации:

Рекомендации по устранению и предотвращению:

Примеры сценариев реализации угроз:

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

BDU:W05 — Уязвимости, связанные с недостатками управления ресурсами

Описание:

Типы ошибок:

Способы эксплуатации:

Рекомендации по устранению и предотвращению:

Примеры сценариев реализации угроз:

Примеры записей уязвимостей в БДУ:

Ссылки на источники:

Моделирование угроз на основе сценариев или Как Cyber Kill Chain и ATT&CK помогают анализировать угрозы ИБ

Введение

Регламентирование в российской нормативной базе деятельности по анализу угроз

«Угроза», «способ», «сценарий»

Сценарии Cyber Kill Chain

Применение ATT&CK для моделирования угроз

Заключение

В центре внимания

Что такое модель угроз и кому необходимо ее разрабатывать

Что нового в моделировании угроз

Основные сложности при моделировании угроз

Используемые методики, иные документы и ресурсы

Основные этапы моделирования угроз

Этап 1. Определение негативных последствий

Этап 2. Определение возможных объектов воздействия угроз безопасности информации

Этап 3. Оценка возможности реализации (возникновения) угроз безопасности информации и определение их актуальности.

Оценка актуальности угроз безопасности информации

Разработка сценариев реализации угроз

Примеры сценариев

Заключение

Определение возможных сценариев реализации угроз безопасности информации

Зачем нужна модель угроз?

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

Вступительная часть модели угроз

Раздел «Нормативно-методическое обеспечение»

Общие положения

Описание информационной системы

Модель нарушителя

«ФСБшные» разделы

Уязвимости

Частная модель угроз безопасности

Уровень исходной защищенности

Опасность угроз

Исключение «лишних» угроз

Описание угроз

Список актуальных угроз