Категорирование объектов критической информационной инфраструктуры. Учебное пособие
.pdfдолжна содержать краткое описание архитектуры значимого объекта, характеристику источников угроз безопасности информации, в том числе модель нарушителя, и описание всех угроз безопасности информации, актуальных для значимого объекта.
Всвою очередь описание каждой угрозы безопасности информации должно включать:
− источник угрозы безопасности информации; − уязвимости (ошибки), которые могут быть использованы
для реализации (способствовать возникновению) угрозы безопасности информации;
− возможные способы (сценарии) реализации угрозы безопасности информации;
− возможные последствия от реализации (возникновения) угрозы безопасности информации.
Вкачестве исходных данных для анализа угроз безопасности информации должен использоваться банк данных угроз безопасности информации, ведение которого осуществляется ФСТЭК России.
Таким образом, пункт 11.1 Приказа ФСТЭК России от 25.12.2017 № 239 формулирует требования и принципы, которые следует учитывать при построении моделей угроз безопасности значимых объектов критической информационной инфраструктуры. Важно отметить, что использование текущих методик и базовых моделей угроз, разработанных ФСТЭК России для важнейших информационных систем, в настоящее время представляется тактически неверным, поскольку планируемые к утверждению методические рекомендации по моделированию угроз безопасности объектов
КИИ (сообщено в информационном письме от 4.05.2018 № 240/22/2339) будут базироваться на действующих нормативных актах, включая вышеуказанный Приказ ФСТЭК России № 239. Следовательно, созданные ранее модели угроз и потенциальных злоумышленников потребуется скорректировать после принятия новых методических материалов.
Кроме того, важно отметить, что модель угроз безопасности информации может разрабатываться для нескольких ЗОКИИ, имеющих одинаковые цели создания и архитектуру, а также типовые угрозы безопасности информации, что достаточно удобно, когда число ЗОКИИ составляет несколько сотен или даже тысяч.
51
После определения актуальных угроз перед проектированием СОИБ ЗО КИИ необходимо проведение так называемого диагностического аудита (в общей теории менеджмента более известного как «GAP анализ»), целью которого является определение тех мер по защите информации, которые уже приняты в отношении данного объекта КИИ, и тех, которые необходимо будет реализовать в процессе создания СОИБ.
Для проведения указанного аудита необходимо взять весь перечень ЗОКИИ и сопоставить уже принятые меры по обеспечению безопасности каждого из объектов КИИ с мерами, перечисленными в приказе ФСТЭК России от 25.12.2017 № 239: первоначально определить, какие меры выполняются, а какие нет (по принципу «да»/«нет»), затем понять, как и насколько полно они выполняются.
Итогом проведения диагностического аудита станет ясное представление о том, какая доля обязательных мер по обеспечению безопасности значимого объекта критической информационной инфраструктуры уже внедрена, а какую ещѐ предстоит реализовать в ходе построения системы обеспечения информационной безопасности. Также аудит позволит выявить меры, которые могут быть обеспечены внутренними защитными механизмами, и те, для которых понадобится внедрение дополнительных защитных средств.
По итогам проведенного анализа и формирования требований к СОИБ ЗО КИИ подготавливается и утверждается руководителем субъекта КИИ план мероприятий по обеспечению безопасности ЗОКИИ (п. 29-31 Приказа ФСТЭК России от 21.12.2017 № 235).
Этап 2. Реализация.
На данном этапе осуществляется внедрение организационных и технических мер, реализация плана мероприятий по обеспечению безопасности ЗОКИИ (п. 34 Приказа ФСТЭК России от 21.12.2017 № 235).
Организационные и технические меры по обеспечению безопасности ЗОКИИ (состав подробно приведен в приложении к Приказу ФСТЭК России № 239 от 25.12.2017):
−идентификация и аутентификация (ИАФ);
−управление доступом (УПД);
−ограничение программной среды (ОПС);
−защита машинных носителей информации (ЗНИ);
52
−аудит безопасности (АУД);
−антивирусная защита (АВЗ);
−предотвращение вторжений (компьютерных атак) (СОВ);
−обеспечение целостности (ОЦЛ);
−обеспечение доступности (ОДТ);
−защита технических средств и систем (ЗТС);
−защита информационной (автоматизированной) системы и
еекомпонентов (ЗИС);
−реагирование на инциденты информационной безопасности
(ИНЦ);
−управление конфигурацией (УКФ);
−управление обновлениями программного обеспечения
(ОПО);
−планирование мероприятий по обеспечению безопасности
(ПЛН);
−обеспечение действий в нештатных ситуациях (ДНС);
−информирование и обучение персонала (ИПО).
Приказ ФСТЭК России от 26.03.2019 № 60 (о внесении изменений в Приказ от 25.12.2017 № 239) внес изменения в так называемые «нулевые меры»: заменил требования по «разработке политик» на требования по «регламентации правил и процедур». Кроме того, в защиту машинных носителей информации (ЗНИ) добавились съемные машинные носители информации. Немного уменьшили количество мер в базовом наборе для объектов первой категории значимости. Однако входящие в состав значимого объекта первой категории значимости программные и программно-аппаратные средства, осуществляющие хранение и обработку информации, теперь должны размещаться на территории Российской Федерации.
Приказ ФСТЭК России от 9.08.2018 № 138 внес изменения в требования приказов ФСТЭК России № 31 и № 239, исключив разночтение состава мер защиты информации. Сравним меры приказов ФСТЭК России № 239, № 31 и № 17 (утратит силу с 01.03.2026 в связи вступлением в силу с 01.03.2026 Приказа ФСТЭК России от 11.04.2025 №117) (таблица 6):
53
Таблица 6. Сравнительный анализ мер приказов ФСТЭК России № 239, № 31, № 17
Приказ ФСТЭК |
Приказ ФСТЭК |
Приказ ФСТЭК |
России № 239 |
России №31 |
России №17 |
ИАФ |
ИАФ |
ИАФ |
УПД |
УПД |
УПД |
ОПС |
ОПС |
ОПС |
ЗНИ |
ЗНИ |
ЗНИ |
АУД |
АУД |
РСБ |
АВЗ |
АВЗ |
АВЗ |
СОВ |
СОВ |
СОВ |
ОЦЛ |
ОЦЛ |
АНЗ |
ОДТ |
ОДТ |
ОЦЛ |
ЗТС |
ЗТС |
ОДТ |
ЗИС |
ЗИС |
ЗСВ |
ИНЦ |
ИНЦ |
ЗТС |
УКФ |
УКФ |
ЗИС |
ОПО |
ОПО |
|
ПЛН |
ПЛН |
|
ДНС |
ДНС |
|
ИПО |
ИПО |
|
Углубимся в пункты приказов ФСТЭК России № 239, № 17, по которым наблюдаются различия (таблица 7).
Таблица 7. Сравнение приказа ФСТЭК России № 237 и приказа ФСТЭК России № 17 (утратит силу с 01.03.2026 в связи вступлением в силу с 01.03.2026 Приказа ФСТЭК России от 11.04.2025 № 117)
Из Приказа ФСТЭК № 239 |
Из Приказа ФСТЭК № 17 |
V. Аудит безопасности |
V. Регистрация событий безопасности |
(АУД) |
(РСБ) |
Регламентация правил и про- |
Определение событий безопасности, подле- |
цедур аудита безопасности |
жащих регистрации, и сроков их хранения |
Инвентаризация информаци- |
Определение состава и содержания инфор- |
онных ресурсов |
мации о событиях безопасности, подлежа- |
|
щих регистрации |
|
54 |
Из Приказа ФСТЭК № 239 |
|
Из Приказа ФСТЭК № 17 |
||
Анализ |
уязвимостей и их |
Сбор, |
запись и хранение информации о со- |
|
устранение |
бытиях безопасности в течение установлен- |
|||
|
|
ного времени хранения |
|
|
Генерирование временных ме- |
Реагирование на сбои при регистрации со- |
|||
ток и (или) синхронизация си- |
бытий безопасности, в том числе аппаратные |
|||
стемного времени |
и программные ошибки, сбои в механизмах |
|||
|
|
сбора информации и достижение предела |
||
|
|
или переполнения объема (емкости) памяти |
||
Регистрация событий безопас- |
Мониторинг (просмотр, анализ) результатов |
|||
ности |
|
регистрации событий безопасности и реаги- |
||
|
|
рование на них |
|
|
Контроль и анализ сетевого |
Генерирование временных меток и (или) |
|||
трафика |
синхронизация системного времени в АСУ |
|||
Защита информации о событи- |
Защита информации о событиях безопасно- |
|||
ях безопасности |
сти |
|
|
|
Мониторинг безопасности |
Обеспечение возможности просмотра и ана- |
|||
|
|
лиза информации о действиях отдельных |
||
|
|
пользователей |
|
|
Реагирование на сбои при ре- |
VIII. Контроль (анализ) защищенности |
|||
гистрации событий безопасно- |
информации (АНЗ) |
|
||
сти |
|
|
|
|
Анализ действий пользовате- |
Разработка правил и процедур (политик) |
|||
лей |
|
контроля (анализа) защищенности |
||
Проведение внутренних ауди- |
Выявление, анализ уязвимостей и оператив- |
|||
тов |
|
ное устранение вновь выявленных уязвимо- |
||
|
|
стей |
|
|
Проведение внешних аудитов |
Контроль установки обновлений программ- |
|||
|
|
ного обеспечения, включая обновление про- |
||
|
|
граммного обеспечения средств защиты ин- |
||
|
|
формации |
|
|
XIV. Управление обновлениями |
Контроль работоспособности, |
параметров |
||
программного обеспечения |
настройки и правильности функционирова- |
|||
(ОПО) |
|
ния программного обеспечения и средств |
||
|
|
защиты информации |
|
|
Регламентация правил и про- |
Контроль состава технических средств, про- |
|||
цедур управления обновлени- |
граммного обеспечения и средств защиты |
|||
ями программного обеспече- |
информации |
|
||
ния |
|
|
|
|
Поиск, |
получение обновлений |
Контроль правил генерации и смены паролей |
||
программного обеспечения от |
пользователей, заведения и удаления учет- |
|||
доверенного источника |
ных записей пользователей, реализации пра- |
|||
|
|
вил |
разграничения доступа, |
полномочий |
|
|
|
55 |
|
Из Приказа ФСТЭК № 239 |
Из Приказа ФСТЭК № 17 |
|||
|
|
|
|
пользователей |
Контроль |
целостности |
обнов- |
XI. Защита среды виртуализации (ЗСВ) |
|
лений программного обеспе- |
|
|||
чения |
|
|
|
|
Тестирование |
обновлений |
|
||
программного обеспечения |
|
|||
Установка |
обновлений |
про- |
|
|
граммного обеспечения |
|
|
||
Таким образом, по итогам анализа требований приказов ФСТЭК России № 239, № 31, № 17 (утратит силу с 01.03.2026 в связи вступлением в силу с 01.03.2026 Приказа ФСТЭК России от 11.04.2025 № 117) можно сделать следующий вывод: если у субъекта КИИ уже в полном объеме реализованы меры приказа ФСТЭК России от 14.03.2014 № 31 (с изменениями приказа ФСТЭК от 9.08.2018 № 138), обеспечить соответствие приказу ФСТЭК России от 25.12.2017 № 239 будет не сложно (обращаем внимание на внесенные изменения).
Труднее придется субъектам КИИ, выполнившим лишь требования приказа ФСТЭК России от 11.02.2013 № 17 (утратит силу с 01.03.2026 в связи вступлением в силу с 01.03.2026 Приказа ФСТЭК России от 11.04.2025 №117). Им потребуется реализовать ряд обеспечительных мер:
−планирование мероприятий по обеспечению безопасности
(ПЛН);
−управление конфигурацией (УКФ);
−управление обновлениями программного обеспечения
(ОПО);
−реагирование на инциденты информационной безопасности
(ИНЦ);
−обеспечение действий в нештатных ситуациях (ДНС);
−информирование и обучение персонала (ИПО).
Приказом ФСТЭК России от 27.03.2019 № 64 (о внесении изменений в Приказ ФСТЭК России от 21.12.2017 № 235) закреплена ответственность за обособленные подразделения (филиалы, представительства). Системы обеспечения информационной безопасности создаются с учетом ЗОКИИ в обособленных подразделениях.
56
Кроме того, с 01.01.2021 введены требования квалификации и стажа для специалистов по безопасности: «наличие у руководителя структурного подразделения по безопасности высшего профессионального образования по направлению подготовки (специальности) в области информационной безопасности или иного высшего профессионального образования и документа, подтверждающего прохождение обучения по программе профессиональной переподготовки по направлению «Информационная безопасность» (со сроком обучения не менее 360 часов), наличие стажа работы в сфере информационной безопасности не менее трех лет.
Наличие у штатных работников структурного подразделения по безопасности, штатных специалистов по безопасности высшего профессионального образования по направлению подготовки (специальности) в области информационной безопасности или иного высшего профессионального образования и документа, подтверждающего прохождение обучения по программе повышения квалификации по направлению «Информационная безопасность» (со сроком обучения не менее 72 часов);
Прохождение не реже одного раза в 5 лет обучения по программам повышения квалификации по направлению «Информационная безопасность».
Этап 3. Мониторинг и контроль.
Цель проведения аудита информационной безопасности – определить, какое положение дел в области обеспечения информационной безопасности существует сейчас и какие дальнейшие действия необходимо предпринять для создания либо улучшения системы защиты информации.
Процесс проведения аудита информационной безопасности схематично можно разделить на шесть последовательных этапов:
1 этап: Инициирование аудита ИБ.
−Назначение руководителя группы аудиторов.
−Формирование группы аудиторов.
−Определение целей, границ проведения аудита ИБ, крите-
риев.
−Разработка плана проведения аудита ИБ.
−Установление первоначального контакта с проверяемой организацией.
57
2 этап: Заочное обследование.
Целью данного этапа является получение первичных данных об объекте аудита и разработка на их основе программы очного обследование (аудита «на месте»).
−Подготовка опросных листов заочного обследования.
−Рассылка опросных листов по ответственным лицам.
−Анализ заполненных опросных листов.
3 этап: Подготовка к очному обследованию (аудиту «на месте»).
−Подготовка программы (плана) очного обследования.
−Распределение заданий в группе по аудиту.
−Подготовка опросных листов очного обследования, рабочих документов.
4 этап: Очное обследование.
−Проведение вводного совещания.
−Проведение интервьюирования специалистов.
−Проведение инструментального обследования (при наличии потребности).
−Проведение тестирования на проникновение (Penetration Test) (при наличии потребности).
−Сбор и проверка информации.
−Проведение завершающего совещания.
−Подготовка протокола.
5 этап: Разработка отчета об аудите ИБ.
−Подготовка раздела отчета, описывающего текущее положение дел.
−Подготовка раздела отчета с рекомендациями (плана дей-
ствий).
−Утверждение и рассылка отчета по аудиту ИБ.
6 этап: Завершение аудита ИБ.
−Согласование отчета с заинтересованными сторонами, разъяснение спорных вопросов.
−Проведение итогового совещания, уточнение и (или) разъяснение рекомендаций по итогам аудита.
Данная последовательность действий выработана на основе ГОСТ Р ИСО 19011-2012.
58
Вчасти организации и проведения аудита информационной безопасности ЗОКИИ необходимо обратить внимание на следующие моменты:
1. Обязательность проведения аудита информационной безопасности ЗОКИИ.
Согласно п. 35 и п. 36 «Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования» (утв. приказом ФСТЭК России от 21.12.2017 № 235) в рамках контроля состояния безопасности ЗОКИИ должен осуществляться внутренний контроль организации работ по обеспечению их безопасности, и эффективности принимаемых организационных и технических мер.
Входе проведения контроля проверяется выполнение требований нормативных правовых актов в области обеспечения безопасности КИИ, а также организационно-распорядительных документов по безопасности ЗОКИИ.
Для оценки эффективности принятых организационных и технических мер по обеспечению безопасности ЗОКИИ могут применяться средства контроля (анализа) защищенности – это так называемый инструментальный аудит (анализ) защищенности
Контроль проводится ежегодно комиссией, назначаемой субъектом КИИ. В случае проведения по решению руководителя субъекта КИИ внешней оценки (внешнего аудита) состояния безопасности ЗОКИИ внутренний контроль может не проводиться.
Замечания, выявленные по результатам внутреннего контроля или внешней оценки (внешнего аудита), подлежат устранению в порядке и сроки, установленные руководителем субъекта КИИ (уполномоченным лицом).
Таким образом, законодательно предусмотрена обязательность проведения аудита информационной безопасности ЗОКИИ в форме внутреннего аудита, проводимого силами работников субъекта КИИ, либо внешнего аудита, проводимого специализированной организацией.
2. Уверенность в том, что объект КИИ действительно хорошо защищен и вероятность возникновения компьютерного инцидента мала может обеспечить только проведение инструментального
59
аудита (анализ уязвимостей), включающего тестирование на проникновение (Penetration Test).
Анализ уязвимостей ЗОКИИ является обязательным как на этапе создания (до ввода в эксплуатацию), так и в ходе его эксплуатации (п. 12.6, п. 13, п. 13.2, п. 13.8 Требований по обеспечению безопасности значимых объектов КИИ Российской Федерации, утв. Приказом ФСТЭК России от 25.12.2017 № 239).
Анализ уязвимостей проводится в целях выявления недостатков (слабостей) в подсистеме безопасности ЗОКИИ и оценки возможности их использования для реализации угроз безопасности информации.
При этом важно обратить внимание на то, что согласно вышеупомянутым требованиям, анализу подлежат уязвимости кода, конфигурации и архитектуры значимого объекта.
Анализ уязвимостей проводится для всех программных и про- граммно-аппаратных средств, в том числе средств защиты информации ЗОКИИ.
По результатам анализа уязвимостей должно быть подтверждено, что в ЗОКИИ, отсутствуют уязвимости, как минимум содержащиеся в банке данных угроз безопасности информации ФСТЭК России, или выявленные уязвимости не приводят к возникновению угроз безопасности информации, а в идеале, чтобы тестирование на проникновение подтвердило отсутствие возможности успешного проведения компьютерной атаки со стороны потенциального злоумышленника.
При проведении анализа уязвимостей применяются следующие способы их выявления:
−анализ проектной, рабочей (эксплуатационной) документации и организационно-распорядительных документов по безопасности;
−анализ конфигураций программного и аппаратнопрограммного обеспечения, включая средства защиты информации.
−выявление известных уязвимостей программного и аппа- ратно-программного обеспечения, включая средства защиты информации, путем изучения состава установленных программ и обновления безопасности с использованием инструментов контроля (анализа) защищенности и других методов защиты информации.
60
