Приказ ФСТЭК по защите АСУ ТП №31

Приказ ФСТЭК по защите АСУ ТП №31
Участвуя в экспертизе или разработке того или иного нормативного акта, забываешь потом про него рассказать :-) Буду исправляться, тем более, что и повод подоспел как нельзя кстати. Итак, 30 июня Минюстом был зарегистрирован долгожданный приказ ФСТЭК №31 от 14.03.2014 по защите АСУ ТП. Презентацию по данному проекту я уже выкладывал .



Теперь пройдусь по ключевым тезисам, которые я хотел бы выделить в отношении данного приказа. Они остались неизменными по сравнению с озвученными  на февральской конференции ФСТЭК:
  1. Приказ №31 продолжает курс ФСТЭК по унификации требований по защите информации и информационных систем (а теперь еще и АСУ ТП). На мой взгляд это хорошо.
  2. Приказ №31 - это задел на будущее. Сегодня не так много технических решений, способных закрыть даже половину требований приказа. Я про этого уже говорил . Но и опасаться этого не стоит - свобода выбора защитных мер позволяет пока не принимать в расчет то, что невозможно выполнить. Правда, свобода выбора  тоже для кого-то является злом, но тут уж ничего не поделаешь.
  3. Приказ говорит об автоматизированных, а не информационных системах. Видимо мы еще долго будем жить на два мира - мира ИС и АС. Введенная в 2006-м году, в трехглавом законе определение информационной системы заставило всех регуляторов пересмотреть свою нормативную базу, но в тех же ГОСТах остались системы автоматизированные. Более того, ФСТЭК вынуждена развивать ГОСТы по АС в защищенном исполнении, параллельно развивая свои НПА по информационным системам. Я бы на месте ФСТЭК в каком-нибудь ГОСТе уравнял эти понятия или выступил бы с инициативой по внесению изменений в 149-ФЗ и включению туда понятия АС наряду с ИС.
  4. Приказ вводит 3-хуровневую классификацию АСУ ТП. Это одно из отличий от 4-хуровневой классификации ГИС в 17-м приказе и уровней защищенности ИСПДн в ПП-1119/приказе №21. Связано это с принятой на критически важных объектах трехуровневой классификацией уровней опасности, уровней антитеррористической защищенности и т.п. 
  5. Обязательная сертификация средств защиты информации не требуется - вместо нее явно говорится об оценке соответствия в соответствии с ФЗ "О техническом регулировании". Это хорошо, т.к. сегодня в РФ существует либо специализированное ПО, сертифицированное по требованиям ИБ (например, ПО управления электровозами), либо промышленное оборудование, сертифицированное как МСЭ (таких изделий я навскидку в реестре ФСТЭК нашел всего 3 - Cisco Smart Grid Router, Cisco Smart Grid Switch, Cisco IE 3000). Других решений просто нет и при наличии требования обязательной сертификации выполнить его было бы физически невозможно. Да и испытательные лаборатории пока не готовы подступиться к этому вопросу - обычные ФСТЭКовские требования тут не работают. Кстати, тут стоило бы обратиться к проекту документа  ФСТЭК по жизненному циклу ИТ. В нем очень неплохо было показано, что есть требования функциональные (они проверяются в рамках сертификации по обычным РД), есть требования к доверию (плохо прижившиеся у нас ОУДы в "Общих критериях") и есть требования к среде, в которой будет функционировать изделие ИТ. Вот последнего у нас пока нет, а в АСУ ТП без этого уже не обойтись.
  6. В отличие от 6 этапов построения системы защиты для ГИС, для АСУ ТП таких этапов 5 - исключена аттестация, которая является сугубо добровольной. Ее можно заменить на приемку самой АСУ ТП, в том числе и с точки зрения ИБ. Тоже решение закономерное - приемка АСУ ТП и так процесс непростой и проходит жесткое "модерирование" (цена ошибки слишком высока). Дублировать этот процесс еще и с точки зрения ИБ нецелесообразно; особенно при убогих и совершенно неадекватных реалиям требованиях по аттестации ( тут  и тут ).
  7. Смена парадигмы, согласно которой конфиденциальность в АСУ ТП обеспечивается только если нужно заказчику, а на первое место выходит доступность АСУ ТП и ее целостность. При этом красной нитью по тексту приказа проходит мысль, что меры защиты информации должны быть согласованы с мерами по промышленной, физической, пожарной, экологической, радиационной безопасности, иными мерами по обеспечению безопасности АСУ ТП и управляемого (контролируемого) объекта и (или) процесса и не должны оказывать отрицательного (мешающего) влияния на штатный режим функционирования АСУ ТП.
  8. Возможно как обоснованное исключение защитных мер, так и применение мер компенсирующих.

Но финальный текст поменялся по сравнению с проектом. Было внесено немало изменений. Беглый анализ позволяет выделить следующие отличия принятой версии от предварительной:
  • Изменен п.2 - предназначение требований. Если в проекте речь шла о снижении рисков незаконного вмешательства, то в итоговом варианте - об обеспечении функционирования АСУ ТП в штатном режиме (риски тоже остались, но на втором месте).
  • Убран п.6 о том, что ФОИВы в своей сфере регулирования и корпорации имеют право разрабатывать свои собственные отраслевые и корпоративные стандарты. Не могу сказать, что это критично, т.к. аналогичная норма включена в алгоритм выбора защитных мер (на этапе дополнения защитных мер).
  • Добавлен новый блок в п.7 (раньше это был п.8), описывающий архитектуру и уровни АСУ ТП. На мой взгляд не хватает иллюстраций, которые у ФСТЭК есть, например, в рекомендациях по защите КСИИ. Может быть стоило бы разработать аналог методички по ГИСам, но для АСУ ТП. В нее я бы включил описание 6 блоков защитных мер, которых нет в ГИС, а также добавил бы из КСИИшных документов специфики АСУ ТП, включая и иллюстрации.
  • Незначительно расширен перечень объектов защиты - добавлены промышленные сервера и системы локальной автоматики, микропрограммное ПО. Убрана "информация о промышленном или технологическом процессе", но добавлена "иная критическая важная информация".
  • Переформулировали 8-й пункт (ранее 9-й), но суть осталась той же.
  • По тексту некоторые абзацы в пунктах переставили местами и переписали некоторые абзацы немного другими словами (суть осталась неизменной).
  • Убран фрагмент в п.14.1 (ранее 15.1) о том, что при отсутствии необходимых средств защиты информации необходимо их разработать (доработать).
  • П.15.1 (ранее 16.1) переписали с средств защиты на ПО АСУ ТП. Раньше речь шла о настройке средств защиты информации АСУ ТП - теперь о настройке параметров АСУ ТП, приводящих к снижению рисков. Вообще видно, что даже после общественного обсуждения работа с документом велась очень активно и не бездумно - там где средств защиты нет и не появится в ближайшее время произошла замена на встроенные в АСУ ТП защитные механизмы (там где они есть). 
  • В п.15.3 (ранее 16.3) ввели новый фрагмент про введение ограничений на действия персонала.
  • П.15.4 - новый. Он посвящен установке и настройке средств защиты информации в АСУ ТП.
  • В п.16.4 (ранее 17.4) добавили анализ уязвимостей, как часть процесса анализа угроз в процессе эксплуатации.
  • В п.17.2 (ранее 18.2) добавили уничтожение машинных носителей, содержащих энергонезависимую память.
  • В п.20 (ранее 21) добавили, что для каждого уровня АСУ ТП меры защиты рассматриваются отдельно от других уровней, реализуя тем самым принцип эшелонированной обороны. А вот пункт 22 из проекта (про сегментирование) убрали.
  • В п.24 (ранее 26) добавили, что в первую очередь надо рассматривать встроенные механизмы защиты АСУ ТП.
В приложение 2 (перечень защитных мер) внесли следующие изменения в части базового набора мер:
  • УПД.10 - мера убрана из базового набора для всех трех классов защищенности АСУ ТП (раньше для всех классов мера входила в базовый набор)
  • ЗНИ.6 - мера добавлена в базовый набор для 1-го уровня защищенности (раньше не было ни в одном)
  • ЗНИ.7 - мера добавлена в базовый набор еще и для 3-го уровня защищенности (раньше было для 2-го и 1-го)
  • РСБ.6 - мера убрана из базового набора для 3-го уровня защищенности
  • АНЗ.5 - мера убрана из базового набора для 3-го уровня защищенности
  • ОЦЛ.6 - мера добавлена в базовый набор для 1-го уровня защищенности (раньше не было ни в одном)
  • ОЦЛ.7 - мера добавлена в базовый набор для 1-го и 2-го уровней защищенности (раньше не было ни в одном)
  • ОДТ.0 - мера добавлена в базовый набор еще и для 3-го уровня защищенности (раньше было для 2-го и 1-го)
  • ОДТ.1 - мера добавлена в базовый набор для 1-го и 2-го уровней защищенности (раньше не было ни в одном)
  • ОДТ.3 - мера добавлена в базовый набор для 1-го и 2-го уровней защищенности (раньше не было ни в одном)
  • ЗСВ.8 - мера добавлена в базовый набор для 1-го уровня защищенности (раньше не было ни в одном)
  • ЗТС.5 - мера добавлена во все уровни защищенности базового набора
  • ЗИС.17 - мера добавлена в базовый набор еще и для 3-го уровня защищенности (раньше было для 2-го и 1-го)
  • ДНС.3 - мера убрана из базового набора для 3-го уровня защищенности
  • ДНС.4 - мера убрана из базового набора для 3-го уровня защищенности
  • ДНС.5 - мера добавлена во все уровни защищенности базового набора
Получается вот такая картина. Сейчас предстоит осознать, что будет меняться в отрасли с выходом данного приказа. Заказчикам придется закладывать реализацию его положений в свои планы-графики. Интеграторам придется изучать положения нового приказа для его внедрения у заказчиков. Разработанный мной курс, читаемый  в АИСе, уже учитывает и сам приказ и сделанные в нем правки.

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

  • Как соотносятся выпущенные требования и требования по КСИИ (особенно учитывая, что ФСТЭК продолжает выпускать ГОСТы по КСИИ)?
  • Как защищать АСУ ТП с гостайной (ответ "по закону о гостайне" - это не то, чего ждут заказчики)?
  • Как моделировать угрозы для АСУ ТП (все-таки там есть нюансы по сравнению с ГИС и ИСПДн)?
  • Чем руководствоваться, если все-таки заказчик АСУ ТП захочет ее аттестовать (РД ограниченного распространения тут никак не помогут)?
  • В России используется разными регуляторами разная терминология – критически важный объект, потенциально опасный объект, объект жизнеобеспечения, особо опасный объект, объект повышенной опасности. Приказ распространяется только на КВО и потенциально опасные объекты или на остальные тоже?
  • Как защищать системы, являющиеся критическими инфраструктурами (в терминах законопроекта ФСБ), но не являющиеся АСУ ТП?
  • Планируется ли выпуск методического документа, раскрывающего меры защиты, неучтенные в методичке по ГИСам?
  • Что такое требования к средствами защиты критических информационных инфраструктур из законопроекта по КИИ?
ЗЫ. Внесение в Госдуму законопроекта по безопасности критических информационных инфраструктур перенесено на осень.

ЗЗЫ. Кстати, мне кажется, ФСТЭК могла бы на основе уже имеющихся приказов №17, №21 и №31 разработать методические рекомендации по защите врачебной тайны и иных видов тайн, которые являются достаточно чувствительными, активно обрабатываются в информационных системах, но их обладатели не знают как подступиться к этому вопросу. А ФСТЭК уже набила руку в этом вопросе :-)
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Наш канал защищен лучше, чем ваш компьютер!

Но доступ к знаниям открыт для всех

Получите root-права на безопасность — подпишитесь