Благодарно-неблагодарная тема защиты АСУ ТП

Выступал я тут давеча на одном мероприятии для ТЭК с рассказом о безопасности АСУ ТП (полная версия выложена тут). Выступил, но вопросов не было. То ли утро субботы сказалось (после пятничного отжига), то ли еще что. И на обратном пути, размышляя о безопасности АСУ ТП, пришла мне в голову мысль, что тема эта благодарно-неблагодарная.

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

Но есть и множество неблагодарных вопросов. Новизна приводит к тому, что в России нет ни обучения по этой теме, ни достаточного количества литературы, ни специалистов. Т.е. у сотрудников служб ИБ просто не хватает опыта и знаний, чтобы заниматься этой, новой для них темой. Во-вторых, безопасников зачастую просто не подпускают к АСУ ТП. И по историческим причинам, и по чисто меркантильным. Вот пример от одной российской компании. Ее АСУ ТП процентов на 90 заражены Stuxnet’ом. Все все знают, но ничего не делают. Мотивация простая — приостановка АСУ ТП и связанных с ней процессов на 1-2 дня (чтобы вычистить все элементы от вредоносного кода) встанет в несколько миллиардов долларов (!). А ведь Stuxnet может и не сработать… И кто будет принимать решение об остановке системы при такой диллеме? То-то и оно…

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

Ну и вендоры тоже смотрят на эту тему традиционно — пытаясь просто переложить имеющийся опыт на новую область. Причем, не имея опыта защиты АСУ ТП и не общаясь с реальными их пользователями, представители вендоров называют компании, уже пострадавшие от атак на АСУ ТП идиотами, ничего не смыслящими в безопасности. Но пример выше показывает, что безопасники может и рады, но их не пускают. А уж когда вендоры просто предлагают свои продукты для установки в АСУ ТП, не удосужившись уточнить, возможно ли это в принципе (например, обычный МСЭ для нетрадиционных TCP/IP-протоколов или антивирус на PLC), это вообще…

Может поэтому на семинарах безопасники в основном молчат?.. Опыта нет, делиться пока нечем, а показывать свое незнание боятся…

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

Нажимая кнопку "Отправить", я даю свое согласие на обработку персональных данных (если вдруг они указаны в комментарии) в соответствие с политикой конфиденциальности. Также я соглашаюсь с тем, что в своем комментарии не раскрываю никаких сведений, составляющих государственную тайну, а также никакой иной информации, охраняемой законом (для этого используйте иные способы :-) ), если это не разрешено ее владельцем. Ваш комментарий может появиться не сразу, а после модерации (так бывает не всегда, но бывает).

  1. Unknown

    Вполне логично. Хотя по мне лучше плюнуть, чем промолчать.

    Ответить
  2. Unknown

    Этот комментарий был удален автором.

    Ответить
  3. Александр

    Да и для безопасников эта тема получается неблагодарной. К пром. оборудованию действительно не пускает — ведь оно работает, а если работает, то не трожь. А реальные инциденты, где они были?! В Иране, 3 года назад — неее, риск слишком низкий, чтобы во-первых приостанавливать производство, а во-вторых брать на себя другие риски, от вмешательства в сложные устройства, которые как правило обслуживаются напрямую производителем.

    Ответить
  4. Алексей Лукацкий

    Инцидентов и в России немало. Но непубличных

    Ответить
  5. Rusik

    К сожалению принципу "не трожь, а то сломается" противопоставить нечего. Это практически не пробиваемая стена,так как с одной стороны инженеры и диспетчеры АСУТП заложники некачественной продукции, неграмотных решений, собственной ограниченности в ресурсах и времени, некомпетентности и других факторов. С другой стороны этот принцип защищает их от рискованной на их взгляд дополнительной работы и ответственности. Кто будет отвечать, если из-за инструментальных проверок АСУТП, произойдет авария на производстве? Думаю диспетчер. А зачем ему это надо, если сейчас в его зоне ответственности все и так нормально? И Stuxnet не мешает. Это порочный круг. Чтобы его разорвать, во-первых, нужны дополнительные грамотные специалисты и перераспределение приоритетов в сторону ИБ. На мой взгляд, к сожалению, только серьезные и массовые инциденты могут повлиять на приоритеты по принципу "пока гром не грянет…". В наших силах решить: быть готовым к этому моменту или не быть готовым. Во-вторых нужно вести работу по повышению живучести АСУТП. А есть ли у нас время на первое и второе?

    Ответить
  6. vit

    Пока идейные безопасники считают, что нужно запрещать все, что не разрешено и что нужно внедрять единые решения для корпоративных и технологических сетей, пускать их в асутп нельзя. Централизовано и одновременно накатывать политики на МЭ филиала и технологического объекта нельзя. Хотя бы по той причине, что в асутп могут быть плоские сети, которые только в своем влане работают. Там МЭ не поможет и у безопасников начинается разрыв шаблонов, что их чекпойнты применить нельзя, а трафик L2 по релейкам шифровать нечем.

    Ответить
  7. vit

    Ну и про видеонаблюдение тоже напишу. Внезапно появляется идея безопасников внедрить видеонаблюдение на объекте, где для технологического трафика запроектирован и реализован канал связи, с головой покрывающий потребности по опросу контроллеров (до 64к, например).
    Конечно, им надо выбрать решение "Хернис" (да, есть такое) и возмущаться, почему невозможно обеспечить передачу 4мбит/с с каждой камеры через проектную технологическую сеть.

    Ответить
  8. Анонимный

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

    Ответить
  9. Алексей Лукацкий

    😉 Справедливости ради, эта преза читалась в полном варианте только на ИнфоБЕРЕГе

    Ответить
  10. Анонимный

    для Vitaliy Soldatov

    L2 смежность не проблема, на L2 трафик тож можно фильтровать. От обычных классических Vlan ACL (VACL) или Port ACL (PACL) в качестве первой и грубой линии обороны в cisco до более продвинутых вещей в виде модульных IPS, inline-включенных IDS/IPS и прочее.

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

    Ответить
  11. Анонимный

    Узкая специфическая область.
    Вот если бы ты 20 лет проработал на АЭС занимаясь безопасностью ИТ и у тебя был бы у тому же опыт по двум десяткам эвентов. К тебе подошел бы твой коллега которого ты бы и так знал давно и поделились бы опытом. Ну и отраслевых вендоров вы бы вдвоем и пинали бы.
    А ты говоришь не спрашивают… неукого нечего некому спрашивать!

    Ответить