Компания
322,28
рейтинг
11 ноября 2014 в 11:46

Разработка → Защита АСУ ТП в России: исследуем новые требования ФСТЭК

image

О кибератаках на АСУ ТП и промышленных диверсиях «в один клик» к 2014 году слышали, кажется, уже даже дети. Тут и havex, и «самый страшный поисковик» Shodan (где, кстати, недавно опубликовали карту АСУ ТП), и десяток инцидентов, описанных в последнем отчете Novetta.

Российские организации, ответственные за регулирование в области безопасности, до поры до времени не уделяли внимания уязвимостям промышленных систем, однако приказ ФСТЭК № 31 от 14 марта 2014 года обещает коренным образом изменить ситуацию.

Нельзя сказать, что раньше в России безопасность АСУ ТП (SCADA) совсем не регулировалась. С 2007 года процессы ИБ на основных критически важных объектах регламентируются требованиями, предъявляемыми к «ключевым системам информационной инфраструктуры» (КСИИ), однако методические указания в этом документе имеют ограничения по распространению: предприятия, которым они адресованы, должны быть внесены в специальный перечень. В этом списке КСИИ могли, оказаться и банки, и любые другие организации, но при этом не учитывались особенности применения АСУ ТП как систем реального времени, а также тенденции развития IТ-инфраструктур (к примеру, работа в визуализированных средах). Отделить АСУ ТП, учесть специфическую архитектуру и слабые места таких систем — задача требований, сформулированных в приказе № 31.

Часто российское нормотворчество упрекают в том, что оно оторвано от передового международного опыта и не соответствует последним тенденциям. Чтобы поверить это предположение, мы сравнили требования приказа ФСТЭК № 31 с ведущими зарубежными стандартами в области систем промышленной автоматизации, а именно:

  • семейством отраслевых стандартов NERC Critical Infrastructure Protection (NERC CIP);
  • семейством стандартов ISA/IEC 62443 Industrial Automation and Control Systems Security;
  • рекомендациями NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security» и NIST SP 800-53 «Security and Privacy Controls for Federal Information Systems and Organizations».

Что интересного в приказе ФСТЭК № 31 есть уже сейчас


Разработка и документирование правил и процедур (политик) обеспечения безопасности (эти меры защиты идут под номерами на 0). Это важные меры: любой процесс обеспечения безопасности, причем не только информационной, начинают строить с тщательного документирования всех процедур. Регулярный чекинг можно сравнить с предполетным осмотром самолета и проверкой бортового журнала, и звучит все это скучновато для пассажира лишь до тех пор, пока пассажир не поднялся на высоту 10 тысяч метров.

Требования к защите среды виртуализации (ЗСВ). Технологии виртуализации позволяют оптимизировать ресурсы, однако порождают новые угрозы. Понятно, что снижение издержек интереснее борьбы за безопасность, поэтому критически важные системы в целом и АСУ ТП в частности очень быстро оказываются в не совсем безопасных облаках, и этот процесс необходимо как-то контролировать. Соответствующие пункты в приказе № 31 можно только приветствовать, а вот в перечисленных нами зарубежных стандартах вопросы защиты виртуальных сред не рассмотрены.

Обучение и отработка действий пользователей в случае возникновения нештатных (непредвиденных) ситуаций (ДНС). Повышение осведомленности персонала уменьшает как минимум риски, связанные с социальной инженерией. Репетиция «плана спасения» важна также для понимания сотрудниками своей роли в процессах управления инцидентами безопасности.

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

Требования по инцидент-менеджменту (ИНЦ) и анализу угроз безопасности (УБИ). Данные требования составляют суть риск-ориентированного подхода, отраженного в приказе № 31. Их наличие означает формирование защиты на основании характерных для системы рисков: это позволяет учитывать новые угрозы и улучшать процессы обеспечения ИБ.

image

Что хотелось бы увидеть


Скорейшее появление детальных рекомендаций и методических указаний для специалистов ИБ и аудиторов. Сейчас приказ ФСТЭК № 31 — это достаточно высокоуровневый документ.

Разделение на сетевом уровне корпоративной ЛВС и технологических сетей по аналогии с IEC-62443-2-1 и NIST SP 800-82. Требование о необходимости сегментирования ЛВС в приказе присутствует (ЗИС-17), однако в соответствующем методическом документе наилучшим решением будет явно отметить необходимость отделения технологических сетей от корпоративных.

Рекомендации по построению безопасной архитектуры компонентов АСУ ТП с учетом разделения на уровни, как это сделано в стандартах IEC-62443-2-1, NIST SP 800-82: нижний уровень — полевой, средний — ПЛК, верхний уровень — SCADA.

Инвентаризация компонентов АСУ ТП. Подобное требование есть во всех рассмотренных документах. При этом инвентаризация предусматривает не только идентификацию компонентов, участвующих в технологических процессах, но и хранение дополнительной информации, позволяющей определить их назначение, степень значимости и т. п. Данная процедура имеет одно из первостепенных значений для риск-ориентированного подхода, потому ждем ее появления в дальнейших ревизиях документа.

Проверка персонала перед предоставлением допуска к работе с АСУ ТП. Подобные требования есть NERC CIP и ISA/IEC 62443, но в текущую версию приказа № 31 пока не вошли.

Мероприятия, связанные с увольнением персонала. Не самые веселые, но необходимые действия, включающие блокирование учетных записей, смену паролей и т. п., прописаны в ISA-62443-2-1 и NERC-CIP. Говорят, что бывшие следователи лучше всех умеют уничтожать улики, а экс-сотрудник КВО, хорошо знакомый с технологическим процессом, может быть значительно опаснее нарушителя со стороны. Хотелось бы в дальнейших версиях приказа № 31 увидеть требования к мероприятиям, связанным с увольнением сотрудников КВО.

В целом, несмотря на отдельные шероховатости, документ соответствует лучшим международным стандартам и практикам в области обеспечения информационной безопасности АСУ ТП, а в отдельных пунктах вводит самые современные требования, необходимость в которых как раз назрела.

Более подробное сопоставление требований приказа ФСТЭК от 14 марта 2014 г. № 31 с аналогичными пунктами международных стандартов представлено на сайте Positive Technologies.
Автор: @ptsecurity
Positive Technologies
рейтинг 322,28

Комментарии (13)

  • –15
    Что такое АСУ ТП? Ну, «ТП» — это не очень умная девушка, блондинка…
    • +2
      В поисковиках довольно много информации на этот счет
      • –4
        И что конкретно здесь имелось ввиду и какой был смысл инкрустировать статью туманными аббревиатурами? Ну вот честно )
        • +1
          В этих аббревиатурах нет ничего туманного, о чем вы? Это терминология, которая просто используется, если вы с ней незнакомы, это ни о чем еще не говорит — вполне нормальная ситуация
        • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Мне кажется, этот термин всем, кто «в теме», понятен без перевода. А кому не знаком — тот наслаждается итогами работы тех, кто «в теме».

      Даже если он весь мир делит на ТП и «не ТП» )
  • +2
    пока пассажир не поднялся на высоту 10 тысяч километров

    Я бы такой авиакомпанией никогда не полетел несмотря на все меры безопасности:)
  • 0
    Два раза перечитал статью и так и не нашёл обозначенного в заголовке «исследования».
    • 0
      Поскольку содержательной критике уже подверглась почти треть нашего заголовка (сначала термин «АСУ ТП», теперь слово «исследуем»), мы с нетерпением ждём таких же содержательных комментариев о том, как трудно расшифровать аббревиатуру «ФСТЭК» и как оскорбительно звучит понятие «требования» для каждого свободного человека.
  • 0
    Планируется ли уточнение конкретных мер безопасности вместо указания нормативов?
    То есть было бы здорово почитать обзор, в котором блее конкретно прописаны меры безопасности. Понятно, что совсем мелкие детали в статью не влезут, да и не так нужны: при желании всё находится.
    Здесь бы очень помогла именно обзорная статья с конкретными примерами — это самое ценное знание, которое из поисковика не получишь. Только от профи, который работает в конкретной нише не первый год.
    • 0
      Мы регулярно такое публикуем для различных платформ (см www.scadasl.org), сейчас работаем над рекомендациями для различных индустрий. К сожалению, быстро такие дела не делаются, но работа ведется.
  • 0
    Подраздел статьи «Что хотелось бы увидеть» я предлагаю дополнить еще одним пунктом:

    Требования по организации хранения Backup-ов баз данных. В большинстве случаев ИТ-специалисты понимают и уважают требования по созданию backup-ов. Одним из способов обеспечения безопасности является организация надежного хранения этих копий, а организация доступа к серверам и инфраструктуре серверов backup-а должна быть строго ограничена.
  • 0
    Документ любопытный. Однако, гораздо надёжнее и проще порушить систему «ломом» в руках киповца :) Никаких концов ни в каких логах, а опытный киповец заметёт следы не хуже следователя :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка