Благодарна она потому, что она относительно нова, а потому интересна. Она также нестандартна, т.к. АСУ ТП отличаются от обычных информационных систем и по используемым технологиям, и по их жизненному циклу.
Но есть и множество неблагодарных вопросов. Новизна приводит к тому, что в России нет ни обучения по этой теме, ни достаточного количества литературы, ни специалистов. Т.е. у сотрудников служб ИБ просто не хватает опыта и знаний, чтобы заниматься этой, новой для них темой. Во-вторых, безопасников зачастую просто не подпускают к АСУ ТП. И по историческим причинам, и по чисто меркантильным. Вот пример от одной российской компании. Ее АСУ ТП процентов на 90 заражены Stuxnet’ом. Все все знают, но ничего не делают. Мотивация простая — приостановка АСУ ТП и связанных с ней процессов на 1-2 дня (чтобы вычистить все элементы от вредоносного кода) встанет в несколько миллиардов долларов (!). А ведь Stuxnet может и не сработать… И кто будет принимать решение об остановке системы при такой диллеме? То-то и оно…
Регуляторы тоже не сильно пока помогают в данном вопросе. А все потому, что парадигма защиты АСУ ТП отличается от традиционной, в которой нужно обеспечить в первую очередь конфиденциальность. А в АСУ ТП на первое место выходит доступность. Если же посмотреть на документы по КСИИ, то при всей их замечательности, в них тоже не избежали этого недостатка. При постулировании открытости информации в КСИИ, основные механизмы защиты направлены именно на обеспечение конфиденциальности, а не доступности или целостности.
Ну и вендоры тоже смотрят на эту тему традиционно — пытаясь просто переложить имеющийся опыт на новую область. Причем, не имея опыта защиты АСУ ТП и не общаясь с реальными их пользователями, представители вендоров называют компании, уже пострадавшие от атак на АСУ ТП идиотами, ничего не смыслящими в безопасности. Но пример выше показывает, что безопасники может и рады, но их не пускают. А уж когда вендоры просто предлагают свои продукты для установки в АСУ ТП, не удосужившись уточнить, возможно ли это в принципе (например, обычный МСЭ для нетрадиционных TCP/IP-протоколов или антивирус на PLC), это вообще…
Может поэтому на семинарах безопасники в основном молчат?.. Опыта нет, делиться пока нечем, а показывать свое незнание боятся…
Вполне логично. Хотя по мне лучше плюнуть, чем промолчать.
Этот комментарий был удален автором.
Да и для безопасников эта тема получается неблагодарной. К пром. оборудованию действительно не пускает — ведь оно работает, а если работает, то не трожь. А реальные инциденты, где они были?! В Иране, 3 года назад — неее, риск слишком низкий, чтобы во-первых приостанавливать производство, а во-вторых брать на себя другие риски, от вмешательства в сложные устройства, которые как правило обслуживаются напрямую производителем.
Инцидентов и в России немало. Но непубличных
К сожалению принципу "не трожь, а то сломается" противопоставить нечего. Это практически не пробиваемая стена,так как с одной стороны инженеры и диспетчеры АСУТП заложники некачественной продукции, неграмотных решений, собственной ограниченности в ресурсах и времени, некомпетентности и других факторов. С другой стороны этот принцип защищает их от рискованной на их взгляд дополнительной работы и ответственности. Кто будет отвечать, если из-за инструментальных проверок АСУТП, произойдет авария на производстве? Думаю диспетчер. А зачем ему это надо, если сейчас в его зоне ответственности все и так нормально? И Stuxnet не мешает. Это порочный круг. Чтобы его разорвать, во-первых, нужны дополнительные грамотные специалисты и перераспределение приоритетов в сторону ИБ. На мой взгляд, к сожалению, только серьезные и массовые инциденты могут повлиять на приоритеты по принципу "пока гром не грянет…". В наших силах решить: быть готовым к этому моменту или не быть готовым. Во-вторых нужно вести работу по повышению живучести АСУТП. А есть ли у нас время на первое и второе?
Пока идейные безопасники считают, что нужно запрещать все, что не разрешено и что нужно внедрять единые решения для корпоративных и технологических сетей, пускать их в асутп нельзя. Централизовано и одновременно накатывать политики на МЭ филиала и технологического объекта нельзя. Хотя бы по той причине, что в асутп могут быть плоские сети, которые только в своем влане работают. Там МЭ не поможет и у безопасников начинается разрыв шаблонов, что их чекпойнты применить нельзя, а трафик L2 по релейкам шифровать нечем.
Ну и про видеонаблюдение тоже напишу. Внезапно появляется идея безопасников внедрить видеонаблюдение на объекте, где для технологического трафика запроектирован и реализован канал связи, с головой покрывающий потребности по опросу контроллеров (до 64к, например).
Конечно, им надо выбрать решение "Хернис" (да, есть такое) и возмущаться, почему невозможно обеспечить передачу 4мбит/с с каждой камеры через проектную технологическую сеть.
Лично я молчал на том мероприятии, потому что все сказанное там вами от вас уже ранее слышал и видел, в т.ч. и в блоге. Вы ж по накатанной откатали программу как артист театра, играющий спектакль в 101 раз 😉
Да и утро субботы, конечно, сработало.
😉 Справедливости ради, эта преза читалась в полном варианте только на ИнфоБЕРЕГе
для Vitaliy Soldatov
L2 смежность не проблема, на L2 трафик тож можно фильтровать. От обычных классических Vlan ACL (VACL) или Port ACL (PACL) в качестве первой и грубой линии обороны в cisco до более продвинутых вещей в виде модульных IPS, inline-включенных IDS/IPS и прочее.
В целом же да, есть проблема непонимания специфики. И если в АСУТП нижнего уровня еще пока удается не пускать с офисными замашками и подходами, то верхний уровень, условно назовем АСУП/MES уже давно залезли и изгадили.
Узкая специфическая область.
Вот если бы ты 20 лет проработал на АЭС занимаясь безопасностью ИТ и у тебя был бы у тому же опыт по двум десяткам эвентов. К тебе подошел бы твой коллега которого ты бы и так знал давно и поделились бы опытом. Ну и отраслевых вендоров вы бы вдвоем и пинали бы.
А ты говоришь не спрашивают… неукого нечего некому спрашивать!