Hacked World

Hacked world

РусЗнающий об угрозах имеет шанс предотвратить их...
EngWho knows about threats, prevents them

Аналитика

Главная » Статьи » Требования и рекомендации

Анализ нового проекта ФСТЭК Требований к безопасности КИИ

Проект Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации. Первые впечатления.

Требования по обеспечения безопасности (ОБ) значимых объектов критической информационной инфраструктуры Российской Федерации (ЗО КИИ РФ) выглядят как более совершенная версия 31-го приказа (требования к АСУ ТП на КВО) однако есть отличия

Преамбула документа

Отличия

Положение 31-го приказа

сейчас»)

Положение проекта Требований по ОБЗО КИИ РФ («потом»)

Сужены Цели документа. Если 31-ый был как продолжение 149-ФЗ с учётом тематики ФСБ России (т.к. про защиту информации), то Проект – вообще только про ФСБшные компьютерные атаки и устойчивость функционирования.

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

1. Настоящие Требования … направлены на обеспечение устойчивого функционирования ЗО КИИ РФ при проведении в отношении них компьютерных атак

 

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

 

Честно говоря, дальше непонятно читать или нет. Т.к. ФСТЭКовские системы обнаружения вторжений – это, конечно, клоны ФСБшным системам обнаружения компьютерных атак, однако, во-первых, раньше кроме СКЗИ ФСТЭК не давал явные ссылки на ФСБшную тематику, во-вторых, от остальных угроз [кроме угрозы компьютерной атаки] не надо защищать?

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

Итак, судя по назначению документа, дальше нам определять, что минимально надо сделать, что система сохранила текущее состояние при компьютерной атаке (не понятно, почему это объясняет ФСТЭК, но это не моё дело). Посмотрим, что надо сделать для обеспечения устойчивости функционирования ЗО КИИ РФ.

 

Отличия

Положение 31-го приказа

сейчас»)

Положение проекта Требований по ОБЗО КИИ РФ («потом»)

Криптография «потерялась». (это точно ФСТЭК писал?)

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

Ничего

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

 

Отличия

Положение 31-го приказа

сейчас»)

Положение проекта Требований по ОБЗО КИИ РФ («потом»)

  1. К АСУ ТП примкнули ИС и ИТС;
  2. АСУ ТП (как и ИС и ИТС) должны быть значимыми для применения Проекта
  3. Немного не понятно, как мы обеспечим устойчивость функционирования ИС, если КЦД оказывается за рамками документа…

3. Действие настоящих требований распространяется на

АСУ ТП

3. Действие настоящих Требований распространяется на следующие значимые объекты:

а) ИС;

б) АСУ ТП;

в) ИТС (сети передачи данных).

Теперь есть жизненный цикл из требований к ИС (например, п. 1 ПП-676)

Ничего

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

Для ГосЗО надо делать Проект + Приказ-17.

А для ЗОИСПДн надо делать Проект + ПП-1119.

Следовательно, с учётом информационного сообщения ФСТЭК, для ГосИСПДнЗО (значимый объект КИИ РФ, являющийся государственной ИС, в которой обрабатываются ПДн) надо делать Проект + ПП-1119 + Проект

Ничего

6. Для обеспечения безопасности ЗО, являющихся государственными ИС, настоящие Требования применяются наряду с Требованиями о защите информации…

Для обеспечения безопасности ЗО, являющихся ИСПДн, настоящие Требования применяются наряду с [ПП-1119]

По поводу п. 6.  – надеюсь, что Меры из Проекта не конфликтуют с Приказом-17, ибо Приказ-17 конфликтует с Приказом-21, но там не важно, для ГосИСПДн формула не Приказ-17 + Приказ-21, а Приказ-17 + ПП-1119 (тут нет конфликтов).

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

 

Отличия

Положение 31-го приказа

сейчас»)

Положение проекта Требований по ОБЗО КИИ РФ («потом»)

Нет, за исключением объекта правоприменения

12.  Для  обеспечения  ЗИ в АСУ проводятся следующие мероприятия:

формирование требований к защите информации в …;

разработка системы защиты …;

внедрение системы защиты …;

обеспечение  ЗИ  в  ходе  эксплуатации  …;

обеспечение ЗИ при выводе из эксплуатации …

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

формирование требований к ОБ ЗО;

разработка организационных и технических мер по ОБ ЗО;

внедрение организационных и технических мер по ОБ ЗО…;

обеспечение безопасности ЗО в ходе его эксплуатации;

обеспечение безопасности ЗО при выводе его из эксплуатации.

 

Этап 1

Дальше пошли странности.

Отличия

Положение 31-го приказа

сейчас»)

Положение проекта Требований по ОБЗО КИИ РФ («потом»)

  1. Исчезли ГОСТы на проектирование
  2. Исчезло «принятие решения»
  3. Переехало моделирование угроз в Проектирование.

12.  Формирование требований к ЗИ в АСУ … включает:

принятие решения о необходимости ЗИ …;

классификацию АСУ по требованиям ЗИ;

определение угроз БИ, реализация которых может привести к нарушению штатного режима функционирования АСУ, и разработкумодели угроз БИ;

определение требований к системе защиты автоматизированной системы управления.

11. … Формирование требований к ОБ ЗО включает:

 

категорирование объекта;

 

 

 

 

задание требований к ОБ ЗО.

Здесь надо подробней. ФСТЭК ранее объявлял о своём желании перенести моделирование угроз на второй этап (проектирование), но не сделал этого в Приказе 17-17. Сейчас же перенёс. Однако:

  1. появляется первый конфликт требований к ГосОЗ – теперь надо Модель угроз формировать до ТЗ (как для ГосИС) и после ТЗ (как для ОЗ);
  2. вообще официальное моделирование угроз после требований к средствам – это странно. Предположим, как это будет происходить. Встретились, значит, Заказчик и Потенциальный исполнитель. Сформировали ТЗ (в котором посчитали спецификацию, что купить и сколько), а выставили его на конкурс для проектирования.
    Другая организация, выигравшая конкурс получается должна выбрать средства под требования (а фактически средства уже известны, ибо если написано средство защиты среды виртуализации, то оно сейчас вообще одно). Мало того, другая организация, должна понять, какие же угрозы будут закрываться этими средствами, т.е. подогнать.
    Поясню, почему плохо на примере. Есть угроза УБИ.018: Угроза загрузки нештатной операционной системы. Против неё есть контрмера – СДЗ. Собственно, СДЗ – это контрмера против этой единственной угрозы. Сейчас как (в общем случае): Заказчик в Модели УБИ признал УБИ.018 актуальной – покупает СДЗ, не признал – не покупает. А если действовать по Проекту – от обратного, то получается так:

 

Заложился в ТЗ на СДЗ (предъявил требования к наличию СДЗ)

Не заложился в ТЗ на СДЗ

Признал потом угрозу УБИ.018 актуальной

Всё хорошо

Система защиты – не эффективна. Или финансовых средств не достаточно (не заложились)

Не признал потом угрозу УБИ.018 актуальной

Нецелевое использование финсредств.

Всё хорошо

 

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

Что ещё про формирование требований

Отличия

Положение 31-го приказа

сейчас»)

Положение проекта Требований по ОБЗО КИИ РФ («потом»)

  1. Добавили перечень защищаемых информационных ресурсов. Это для чего? Мы же (см. п. 1 Проекта) вообще не планируем защищать информацию – только обеспечивать непрерывность бизнеса устойчивость функционирования.
  2. Добавили слово «организационным». Это значит, что другие не нужны? Другие где-то далее без указания, что они другие?
  3. Зачем остались требования/меры/средства ЗИ? Мы же (см. п. 1 Проекта) вообще не планируем защищать информацию – только обеспечивать устойчивость функционирования.
  4. Документы по безопасности – это отдельная песня. Их надо учесть при формировании ТЗ, но сделать их надо только на этапе внедрения (абз. 4 п. 13 Проекта)

14.4. Требования к системе защиты информации… должны содержать:

 

 

требования к мерам и средствам ЗИ, применяемым в ИС;

11.2 Требования к обеспечению безопасности …должны содержать:

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

требования к организационным мерам и средствам ЗИ, применяемым для ОБ ЗО;

требования к поставляемым программным и программно-аппаратным средствам, в том числе средствам ЗИ;

требования к защите средств и систем, обеспечивающих функционирование ЗО (обеспечивающей инфраструктуре)

При определении требований к ОБ ЗО учитываются положения ОРД по ОБ ЗО, разрабатываемых субъектами КИИ (далее – документы по безопасности значимых объектов).

 

Этап 2

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

Положение Проекта

Комментарий

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

Учитывать или нет, что мы уже сформировали требования к:

организационным мерам и средствам ЗИ, применяемым для ОБ ЗО;

требования к поставляемым программным и программно-аппаратным средствам, в том числе средствам ЗИ;

требования к защите средств и систем, обеспечивающих функционирование ЗО (обеспечивающей инфраструктуре)?

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

Стоп, стоп, стоп. «Настоящие Требования … направлены на обеспечение устойчивого функционирования ЗО КИИ РФ при проведении в отношении них компьютерных атак». Всё. Компьютерных атак.

Вот это зачем: «в первую очередь»?

Так «в первую очередь» или «в отношении них компьютерных атак»?

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

Новшество. Прям вот вижу, я сформировал рекомендации Заказчику по корректировке архитектуры ЗО. Отправил. Заказчик читает. И-и-и? Мне учитывать эти изменения при разработке проекта? Или нет?

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

Рекомендации можно «после». Запроектировали, внедрили. Всё соответствует. И в качестве рекомендаций – вот вам ещё. Сделают, не сделают, когда определятся? Не важно. В минимуме уже всё хорошо и соответствует

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

Ещё новшество.

  1. Кто будет утверждать Модель угроз, если ЗО имеют разных субъектов КИИ? Интегратору – нельзя
  2. Что такое «типовые угрозы БИ»? Если имеется ввиду что-то типа «типового сегмента», то в абз. 3 п. 17.3 Приказа 17-17 указано явно «одинаковые … угрозы БИ»

 

Переходим к проектированию. Всё страньше и страньше (с)

Положение Проекта

Комментарий

12.2 … подсистемы безопасности значимого объекта…

Название подсистемы хорошее, с учётом п. 1 Проекта. Но не хорошее, с учётом, что в подсистему безопасности входят средств ЗИ.

Проектирование подсистемы безопасности ЗО должно осуществляться на основе модели УБИ …

Проектировать на основе угроз, а не на основе ТЗ? Зачем тогда ТЗ?

Проектирование подсистемы безопасности ЗО должно … предусматривать обоснование необходимости принятия организационных и технических мер по обеспечению безопасности значимого объекта, направленных на защиту значимого объекта от угроз безопасности информации

Это прям подарок.

  1. Мы уже ТЗ утвердили с мерами, а сейчас их только будем обосновывать
  2. «Обоснование необходимости принятия…»? Для 17-го было наоборот – в случае невозможности обосновывается замена » неприятие меры. То есть, если сейчас не сделал/не захотел/забыл/не смог обосновать «необходимость принятия», то … что? Не надо принимать?!

С учётом того, что спецификацию мы на первом этапе посчитали, а здесь решили, что ничего принимать не надо, а закупку, на третьем этапе, проведём, то …да это сказка какая-то ))

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

Чем обосновываются? У нас ТЗ утверждённое на первом этапе на руках. В нём написано, требования к мерам такие-то. Всё. Что сейчас то обосновывать? Это не выбор средства? Дешёвое/недешёвое.

Всё. Пока больше не смог. Спать хочется.
На неделе добью и выложу остатки

Спасибо всем, кто дочитал ))


Если Вам понравилось - поделитесь ссылкой с друзьями в соцсетях. Кнопки ниже:
Категория: Требования и рекомендации | Добавил: vaminakov (11.12.2017) | Автор: Владимир Минаков W
Просмотров: 206 | Теги: Требования к обеспечению безопаснос, Значимые объекты, КИИ, ФСТЭК | Рейтинг: 0.0/0
Всего комментариев: 0
Среда
21.08.2019
06:14
Вход на сайт
Категории раздела
Угрозы [5]
Аналитические материалы об угрозах, моделях угроз безопасности информации
Уязвимости [1]
Уязвимости кода, конфигурации, документации
Средства и меры [2]
Средства защиты информации, меры защиты информации. Их применение. Проблемы и решения
Требования и рекомендации [5]
Требования нормативных правовых актов. Рекомендации методических документов. ФСТЭК России. ФСБ России. NIST. ISO. ISACA
Популярное
Поиск
Наш опрос
Следует ли использовать сертифицированные средства ЗИ
Всего ответов: 6
Автор в медиа
Блоггер
Читатель твиттера
Архитектор систем защиты информации
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0