Методы и проектирование значимых объектов КИИ

Как обеспечить защиту ЗО КИИ?

Все субъекты критической информационной инфраструктуры проводят категорирование своих объектов по Постановлению Правительства №127.

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

Для таких АСУ, ИС и ИТКС после определения категории становятся актуальны требования по защите ЗОКИИ.

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

Например, показатель ущерба бюджетам РФ рассчитывается практически для каждого объекта, однако его значение практически никогда не достигает и сотой доли от минимального порога. Однако, например, существует показатель обеспечения ГОЗ, имеющий нулевое пороговое значение. Таким образом любой объект будет значимым, если атака на него может хоть сколько-то замедлить выполнение ГОЗ.

Входные данные: перечень бизнес-процессов, перечень эксплуатируемых потенциальных объектов КИИ.
Результат: перечень объектов КИИ с указанием категории значимости.

Далее разберем типовые действия по защите ЗОКИИ, которые должен выполнить субъект.

Защита значимых объектов КИИ и проектирование

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

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

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

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

Техническое задание должно определять:

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

Корректное определение границ системы безопасности в т. ч. сокращает затраты на его реализацию.

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

На основании требований ТЗ начинается процесс подготовки технического проекта, включающий:

• Архитектуру подсистем безопасности
• Настройки систем защиты
• Применяемые средства защиты информации
• Организационные меры и иные данные из п.11.2 приказа ФСТЭК №239

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

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

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

Третья цель: составление проекта системы безопасности.
Результат: комплект проектной документации.

Выбор средств защиты ЗОКИИ. Практика внедрения и интеграция системы безопасности с существующими системами

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

При подготовке проектного решения необходимо:

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

Примечание

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

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

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

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

Среди таких средств необходимо рассмотреть (как минимум):

• Системы защиты от НСД – контроль предоставления доступа на уровне отдельных ресурсов и домена
• Антивирусные средства – защита от вредоносного кода
• Межсетевые экраны и программные решения по защите от сетевых атак – межсетевое экранирование, мониторинг сетевой активности, автоматическое блокирование подозрительной активности
• Системы централизованного сбора данных
• Системы резервного копирования
• Системы контроля съемных носителей
• Системы контроля состава ПО

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

Отдельный вопрос – построение подсистемы разграничения доступа, которая в большинстве случаев строилась (и до сих пор строится) на встроенных функциях Windows server, который сейчас не удовлетворяет некоторым требованиям к СЗИ

Разработка ОРД для значимых объектов критической информационной инфраструктуры

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

В общем случае разработка ОРД включает разработку документов 4 уровней:

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

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

Эталонной вариант – тот, который подходит компании вашего уровня. Однако стоит уточнить, что проектирование СБ ЗОКИИ – это уровень достаточно больших компаний, которым все же рекомендуется придерживаться четырёхуровневого формата.

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

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