Безопасник познает ОУД. Применение ОУД в АСУ ТП. Часть 1 (Задание на безопасность)03.03.2024 23:00

1. А зачем?

Статья (в последствии цикл статей) посвящена поэтапному освоению и применению безопасной разработки в сфере АСУ ТП. Эта часть рассказывает о проецирование методики разработки задания на безопасность (Серии ГОСТ 15 408) для сферы где это редко (пока) применяют (вывод о редкости, делаю на основе принятия участия в апробации в широкого спектра продуктов для промышленных систем).

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

По ГОСТ 15 408–3 этапность ОУД подразумевает начало с разработки документации на исследуемое ПО, но как показала практика, этого ничего нет, поэтому мы невольно переключаемся к этапу подготовки проведения тестирования ПО, подразумевающее подготовку задания на безопасность.

Основной лейтмотив статьи

Я постараюсь не взваливать всю экспозицию всего процесса сразу (там очень страшно). Начнем пока только с этапа «Задание на безопасность». Остальные этапы рассмотрим позднее… Соответствующие этапы буду сопровождать полученными результатами на основе изучаемого абстрактного примера.

2. Дорожная карта

Для начала сформируем дорожную карту рассматриваемого этапа.

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

3. Обследование

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

Часть 1.

1. Зачем нужен ОО (нужно понимать в чем смысл то Ваших изысканий);

2. Определение модулей (микросервисы или отдельно взятые процессы);

3. Определение составных частей ПО (клиенты, мобильные приложения, веб порталы, ПАК, ОС). Удобно это обозначить подсистемами;

4. Требуемые средства для разработки и поддержки ОО, сюда могут быть включены так же ОС и ПАК тоже;

5. Определение ролевой моделей пользователей и технических учетных записей;

6. Определение характера передаваемых данных (ПДн, технологические данные, коммерческая тайна т.д.) и протоколы передачи данных;

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

Часть 2.

1. Обозначаем функции управления;

2. Обозначаем функции мониторинга;

3. Возможность передачи/сбора данных и направления передачи/сбора;

4. Возможность обработки данных.

5. Описание существующих ФТБ

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

Пример

Часть 1.

1. Сервер устанавливаемый в ЛВС АСУ ТП производит сбор технологических данных на объекте КИИ.

2. Микросервисы: PSQL15, nginx, frontend-service (собственная разработка заказчика на python). FreeOpcUa отдельная служба устанавливаемая на сервер ОО.Набор библиотек для работы OPC. Подключение пользователя производится по ВЕБ браузера. сбор технологических данных использованием SNMP/OPC UA.

3. Клиенты (источники технологических данных), Пользователи использующие ВЕБ-портал, непосредственно сам Сервер. Сервер Авторизации пользователей, сервер мониторинга заказчика (мониторинг осуществляется по SNMP/PING).

4. Используемый язык Python, что подразумевает наличии соответствующих библиотек на ОО. Используемая операционная система Astra Linux SE/CE версии 1.6 и выше. Веб-браузер для доступа к ОО со стороны пользователя. Администратор ОС осуществляет контроль с использованием SSH и GUI интерфейса ОС, администрирование ПАК осуществляется локально (физически),

5. Оператор АСУ ТП; инженер АСУ ТП; Аудитор ИБ.

6. Технологические данные АСУ ТП, OPC UA.

Часть 2.

Отображаем данные полученные из пунктов 1–4 Части №2.

Функциональная схема ОО

5.Далее необходимо произвести описание всех ФТБ, но для пример укажу только два:

4. Утверждение о соответствии

Определяемся с используемыми ГОСТами, утверждаем используемый профиль защиты, ну или проще говоря, определяемся к каким показателям мы стремимся и какой набор документов будем формировать по факту. Причем на просторах интернета был найден ПРОФИЛЬ ЗАЩИТЫ МЕЖСЕТЕВЫХ ЭКРАНОВ ТИПА «Д» ШЕСТОГО КЛАССА ЗАЩИТЫ от 2016 года, который ФСТЭК России скорее всего использовал для сертификации, несмотря на то, что там был представлен ОУД.1, было решено пойти по ОУД.4 из-за популярно этого уровня и из-за особенности регуляторной политики в сфере КИИ и заказчика.

Пример:

Объект оценки и ЗБ разрабатываются в соответствии:

—     ГОСТ Р ИСО/МЭК 15408–2;
—     ГОСТ Р ИСО/МЭК 15408–3;
— Приказ ФСТЭК № 239;
— Внутренние требования Заказчика

Требования доверия представлены в виде оценочный уровень доверия (ОУД4).

5. Определение угроз

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

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

Пример:

Итого получил перечень мер (перечислил только некоторые из них для наглядности):
АВЗ.1.5 Проверка в масштабе времени, близком к реальному, объектов (файлов) из внешних источников (съемных машинных носителей информации, сетевых подключений, в том числе к сетям общего пользования, и других внешних источников) при загрузке, открытии или исполнении таких файлов;
АВЗ.2.1 Применение средств антивирусной защиты на прокси-серверах, почтовых шлюза, почтовых серверах и иных точках доступа в информационную систему, подверженных внедрению (заражению) вредоносными компьютерными программами (вирусами) через съемные машинные носители информации или сетевые подключения, в том числе к сетям общего пользования (вложения электронной почты, веб- и другие сетевые сервисы);
АВЗ.3.1 Проверку в масштабе времени, близком к реальному, объектов (файлов) архивных, исполняемых и зашифрованных при загрузке, открытии или исполнении таких файлов.;
…

УПД.4.1 Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы, в соответствии с их должностными обязанностями (функциями). Определение в организационно-распорядительных документах по защите информации (документирование) полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы.»

6. Получаем итоговый набор ФТБ

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

Пример (прописал только некоторые):

7. Вывод

Получил итоговый вывод ФТБ необходимых к реализации. Базовые выводы, которые были сделаны:

1. ГОСТ 15 408 сложная, непонятная, мутная, но классная штука…не вкусно, но рекомендую.

2. Угрозы и цели безопасности из профиля защиты, запросто можно приравнять к угрозам и мерам ФСТЭК.

3. Нужно дописывать свои ФТБ из-за особенностей КИИ АСУ ТП (некоторые из них):

• ФТБ_001: Усиленные требования на совместимость с SIEM (syslog cef);

• ФТБ_002: Требование на совместимость с сертифицированное ОС;

• ФТБ_003: Наличие технической поддержки решения;

• ФТБ_004: Совместимость с Антивирусными решениями АСУ.

8. Список терминов и сокращений

Список литературы

© Habrahabr.ru