Комментарии 28
А где будет привязка к ФСТЭК 31? Ну и 187-ФЗ для полного счастья?
НЛО прилетело и опубликовало эту надпись здесь
И такое устойчивое мнение – одна из причин появления нашей статьи. Забегая немного вперед, скажу, что мы считаем, что «слона надо есть по частям», понемногу приучая производство к безопасности.
НЛО прилетело и опубликовало эту надпись здесь
Интересно было бы еще увидеть ваши рассуждения касательно обоснования целесообразности защит, поскольку, как я уже сказал выше, часто разговоры о безопасности разбиваются о «Да кому мы вообще нужны, чтобы нас ломать»Наши диалоги с заказчиками и соответствующие обоснования сильно разнятся в зависимости от конкретного предприятия. Например, в некоторых случаях потенциальные последствия успешной атаки на АСУ ТП настолько ужасны, что рассуждать в классической парадигме в принципе неправильно.
А есть, конечно, менее критичные объекты, и в этом случае мы апеллируем и к реальным инцидентам на аналогичных предприятиях, и, если есть возможность, к инцидентам в периметре данной компании, и к требованиям регуляторов, наконец.
«Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
Чтобы общение с АСУТПшниками не было столь сложным процессом, попробуйте для начала хотя бы минимально понять, что такое АСУТП, чем отличается от обычных информационных систем. Не пытайтесь, чуть сунувшись в тему, учить людей, что и как надо делать. Лучше сами поучитесь, полезно.
НЛО прилетело и опубликовало эту надпись здесь
17 лет в АСУТП, количество сданных проектов после 10-го считать перестал. Чем ещё меряться будем? :)
По сути:
— Дыры в контроллерах. Есть и будут. Постепенно фиксятся производителями, но специфика такова, что быстро это не сделать — в продакшн выводить можно только то, что уже хорошо откатано на стендах. Технологическая установка — не база данных, из бэкапа не восстановишь. Проблема всех «привносимых извне» систем закрывания этих дыр в том, что они не решают имеющихся проблем, и при этом в лучшем случае — просто не ухудшают характеристик системы. И зачем такая радость?
— Несовершенство протоколов. Да, несовершенны. Разработаете совершенный — вам памятник при жизни поставят. Но когда ИБшники мне принесли схему с 19 (!) файрволами между DCS и ПАЗ — были посланы искать SFP-модуль для Profibus DP :). Ну вот использовали они его в схеме. Что такая схема могла улучшить?
— Нормальные пароли. «Нормальные» — это 16 знаков со спецсимволами, переменным регистром и прочими радостями жизни? Ну так это само по себе офигенная дыра в безопасности: никто таких паролей не помнит (особенно, когда их минимум 2 на устройство, количество устройств в системе — не меньше десятка, количество систем в обслуживании — 15-20 штук, и требование смены всех этих паролей раз в 3 месяца). Отсюда — файлы с паролями на компьютерах. В лучшем случае. В более плохом — пароли на стикерах, приклеенных к мониторам. В худшем — единая на все объекты интегратора схема придумывания паролей, зная которую можно подобрать пароль к любому устройству любого объекта. Кстати, наиболее часто используемая схема.
— Обновления хотя бы там, где возможны. Только после официального подтверждения производителя оборудования и ПО, что это обновление опробовано и ничего в системе не ломает.
— «Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает.» На любую защиту от дурака отдел кадров найдёт более талантливого идиота. Если air gap не работает — такова же будет судьба 19 файрволов.
По сути:
— Дыры в контроллерах. Есть и будут. Постепенно фиксятся производителями, но специфика такова, что быстро это не сделать — в продакшн выводить можно только то, что уже хорошо откатано на стендах. Технологическая установка — не база данных, из бэкапа не восстановишь. Проблема всех «привносимых извне» систем закрывания этих дыр в том, что они не решают имеющихся проблем, и при этом в лучшем случае — просто не ухудшают характеристик системы. И зачем такая радость?
— Несовершенство протоколов. Да, несовершенны. Разработаете совершенный — вам памятник при жизни поставят. Но когда ИБшники мне принесли схему с 19 (!) файрволами между DCS и ПАЗ — были посланы искать SFP-модуль для Profibus DP :). Ну вот использовали они его в схеме. Что такая схема могла улучшить?
— Нормальные пароли. «Нормальные» — это 16 знаков со спецсимволами, переменным регистром и прочими радостями жизни? Ну так это само по себе офигенная дыра в безопасности: никто таких паролей не помнит (особенно, когда их минимум 2 на устройство, количество устройств в системе — не меньше десятка, количество систем в обслуживании — 15-20 штук, и требование смены всех этих паролей раз в 3 месяца). Отсюда — файлы с паролями на компьютерах. В лучшем случае. В более плохом — пароли на стикерах, приклеенных к мониторам. В худшем — единая на все объекты интегратора схема придумывания паролей, зная которую можно подобрать пароль к любому устройству любого объекта. Кстати, наиболее часто используемая схема.
— Обновления хотя бы там, где возможны. Только после официального подтверждения производителя оборудования и ПО, что это обновление опробовано и ничего в системе не ломает.
— «Ваш air gap в половине случаев на самом деле никакой не air gap, и в принципе не работает.» На любую защиту от дурака отдел кадров найдёт более талантливого идиота. Если air gap не работает — такова же будет судьба 19 файрволов.
Слышал слышал про такое на заводах.
Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы.
По ходу любой школьник может уронить случайно какой нибудь завод или электро-станцию.
Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы.
По ходу любой школьник может уронить случайно какой нибудь завод или электро-станцию.
К счастью или к сожалению, но это не всегда возможно. И даже из таких самых сложных ситуаций есть выход. Но в целом в последнее время ситуация с безопасностью АСУ ТП улучшается. Мы все чаще видим, что в ТЗ на создаваемые и модернизируемые системы закладываются требования по обеспечению ИБ.
Хм… молодой человек, а не появлялось ли у Вас желание для начала хотя бы в минимальном объёме ознакомиться с тем, что такое АСУТП, дабы в дальнейшем… как бы это мягче сказать… более осторожно относиться к изрекаемым словам?
Эх… Ваша ирония была бы уместна, если бы всё не было так грустно. Его слова на самом деле не так уж далеки от реальности,
Я был по-настоящему шокирован, когда N лет назад мне пришлось познакомиться с Simatic WinCC, в частности, с тем, как в означенной системе устроено сетевое взаимодействие (завязанное на высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей). И вот когда я осознал, что на ЭТОМ строят АСУ ТП (причём достаточно критичными и небезопасными ТП), мне стало не очень хорошо. А ещё года через полтора пошли публикации про Stuxnet — и я как-то совсем не удивился…
Молодой человек, скорее, недостаточно радикален. Мне кажется, что тут надо не только винду гнать ссаными тряпками, но и большинство линуксов, мейнстримовых, по крайней мере. Если только специализированные RT-решения. А объектам типа тех, которые поразил Stuxnet в Иране, ОС и SCADA общего назначения вообще противопоказаны.
(Да, мой комментарий немножко сумбурен, немножко про ОС, немножко про SCADA, но Вы же понимаете, что безопасность надо рассматривать в комплексе.)
Я был по-настоящему шокирован, когда N лет назад мне пришлось познакомиться с Simatic WinCC, в частности, с тем, как в означенной системе устроено сетевое взаимодействие (завязанное на высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей). И вот когда я осознал, что на ЭТОМ строят АСУ ТП (причём достаточно критичными и небезопасными ТП), мне стало не очень хорошо. А ещё года через полтора пошли публикации про Stuxnet — и я как-то совсем не удивился…
Молодой человек, скорее, недостаточно радикален. Мне кажется, что тут надо не только винду гнать ссаными тряпками, но и большинство линуксов, мейнстримовых, по крайней мере. Если только специализированные RT-решения. А объектам типа тех, которые поразил Stuxnet в Иране, ОС и SCADA общего назначения вообще противопоказаны.
(Да, мой комментарий немножко сумбурен, немножко про ОС, немножко про SCADA, но Вы же понимаете, что безопасность надо рассматривать в комплексе.)
Какая ирония? Нет никакой иронии. Если человек говорит "Проще все снести и сделать заново. Вот как раз тотальная переделка и будет поводом перейти на linux системы для адекватной работы." — это либо стёб, либо элементарное непонимание того, что есть АСУТП и из чего состоит. Я совсем не против линуксов, более того, у меня на домашней машине федора (на ней сейчас и печатаю :) ). Но вот в АСУТП — куда???
Не, реально существуют линуксовые управляющие системы (я, кстати, с такими работаю, срециализированные RT), но это — далеко не лучший вариант, на мой взгляд. В нормальных контроллерах… я вот вообще не знаю, есть там какая-то ОС между целевым софтом и железом, или там монолитный продукт.
Тогда что? Операторский интерфейс? Допустим. Решений немного, но они существуют. Но. Это — отдельные scada-системы. Интегрировать в общий проект системы управления — не получится. То есть — каждый канальчик прописывать ручками. Живой пример (один из знакомых мне объектов): объект из 320 двигателей, 170 клапанов, 1300 сигналов в поле. На каждом двигателе — порядка 8 сигналов состояния, на клапанах — 5-6. Плюс у каждого двигателя и клапана — 15-20 блокировочных сигналов. Можно перемножить и посчитать. Молодой падаван будет это вручную делать? Сколько времени у него на это уйдёт? Сколько ошибок останутся невыловленными? И это… операторский интерфейс — ещё далеко не вся система. Я бы оценил примерно как 2-3%, вряд ли больше. Так что «всё снести и переделать» — далеко не проще.
Да, есть такое дело, MS вовремя подсуетилась со своими продуктами и теперь они везде.
Кстати, а где в WinCC вы видели "высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей"? Не то, чтобы их там не было совсем… но чтобы до них добраться, надо делать систему несколько специфичного назначения и со специфичным комплектом программного обеспечения, которое уже никак не назовёшь типовым.
Не, реально существуют линуксовые управляющие системы (я, кстати, с такими работаю, срециализированные RT), но это — далеко не лучший вариант, на мой взгляд. В нормальных контроллерах… я вот вообще не знаю, есть там какая-то ОС между целевым софтом и железом, или там монолитный продукт.
Тогда что? Операторский интерфейс? Допустим. Решений немного, но они существуют. Но. Это — отдельные scada-системы. Интегрировать в общий проект системы управления — не получится. То есть — каждый канальчик прописывать ручками. Живой пример (один из знакомых мне объектов): объект из 320 двигателей, 170 клапанов, 1300 сигналов в поле. На каждом двигателе — порядка 8 сигналов состояния, на клапанах — 5-6. Плюс у каждого двигателя и клапана — 15-20 блокировочных сигналов. Можно перемножить и посчитать. Молодой падаван будет это вручную делать? Сколько времени у него на это уйдёт? Сколько ошибок останутся невыловленными? И это… операторский интерфейс — ещё далеко не вся система. Я бы оценил примерно как 2-3%, вряд ли больше. Так что «всё снести и переделать» — далеко не проще.
Да, есть такое дело, MS вовремя подсуетилась со своими продуктами и теперь они везде.
Кстати, а где в WinCC вы видели "высокоуровневые windows-only протоколы, которые проектировались, мягко говоря, для других целей"? Не то, чтобы их там не было совсем… но чтобы до них добраться, надо делать систему несколько специфичного назначения и со специфичным комплектом программного обеспечения, которое уже никак не назовёшь типовым.
Вы уж простите, но почему на иконке с подписью "электропривод" у вас изображён двигатель внутреннего сгорания?
Как электроприводчик интересуюсь. :)
После «Пети» многие заказчики типа начали приставать «нам надо чтоб всё было безопасно».
При этом культуры, понимания и даже просто людей, которые понимают что можно сделать, почему это нужно и на что это повлияет — такого нет.
Обычно всё сводится к «продайте такую штуку, что б пришло счастье. О, файрвол! А почему так дорого? Не, нам попроще бы».
При этом культуры, понимания и даже просто людей, которые понимают что можно сделать, почему это нужно и на что это повлияет — такого нет.
Обычно всё сводится к «продайте такую штуку, что б пришло счастье. О, файрвол! А почему так дорого? Не, нам попроще бы».
Ситуации бывают разные, и, как показывает практика, кому-то будет мало и двух «Петь» подряд. Но сейчас мы видим значительно меньше подобных кейсов. Это следствие не только «Пети» и активных действий государства и регуляторов, а скорее даже совокупного движения компаний в сторону повышения уровня зрелости в вопросах обеспечения ИБ.
Уже идут лидеры отечественой отрасли и скоро всё зашифруют:)
на самом деле, нет в этом ничего необычного или америки, которую можно открыть… это тот компромисс, от которого начинаем уходить в светлое будущее или в закат )))
при реализации всех возможных и невозможных мер упираемся в самое узкое место — человеческий фактор… при создании любой технологической системы учитываются требования к обслуживающему персоналу… которые что?! правильно… как правило, нивелируются ))))
при реализации всех возможных и невозможных мер упираемся в самое узкое место — человеческий фактор… при создании любой технологической системы учитываются требования к обслуживающему персоналу… которые что?! правильно… как правило, нивелируются ))))
Давайте будем оптимистами. Тем более, мы с вами видим рост спроса на квалифицированные кадры в области обеспечения ИБ в АСУ ТП. Среди задач, которые ставятся перед этими людьми, помимо соответствия требованиям, мы видим задачи обеспечения реальной безопасности, снижения рисков ИБ за счет применения организационных и технических мер.
Так что скорее все же движемся в светлое будущее)
Так что скорее все же движемся в светлое будущее)
ООоо, конечно )))) будем оптимистами, мы движемся в указанном направлении… но будем и реалистами, прибытие в этом направлении, скорее всего, доведется увидеть нашим потомкам )))
и если вообще совсем быть реалистами, то стоит, все же, отметить, что спрос на квалифицированные кадры в данном сегменте скорее не растет, а только формируется ))))
и если вообще совсем быть реалистами, то стоит, все же, отметить, что спрос на квалифицированные кадры в данном сегменте скорее не растет, а только формируется ))))
Итак, очередная статья, где специалисты по ИБ знают точно, что должны делать мы, АСУТПшники. А мы, глупенькие, сопротивляемся прогрессу. Господа ИБшники, а вы ничего не забыли? К примеру, ознакомиться с тем, что собираетесь защищать — не надо? Или вы как в старом армейском анекдоте — «Подводная лодка, р-равняйсь, смирно!» (если кто не знает, могу ниже в каментах рассказать).
Итак, минимальный ликбез для ИБшника на тему того, что такое АСУТП.
Начнём с двух последних букв. ТП — это «технологический процесс». Вот первое и главное отличие АСУТП от разных «обычных» информационных систем. Если в привычных вам системах во главе угла — информация, которую надо защищать от разных напастей (потери, повреждения, несанкционированного доступа), то в АСУТП главное — технологический процесс. Информация — лишь отображение технологического процесса в виде, понятном системе управления. Что из этого следует? А то, что и защищать надо именно технологический процесс. Когда вы предлагаете анализировать информацию между контроллером и полевыми устройствами и, при наличии обоснованных подозрений, блокировать её (конкретно у вас такого не читал, но обычно все ИБшники это предлагают) — вы уверены, что ваш анализ точен и решение правильно? Вас не смущает, что именно вы можете перевести объект в неуправляемый режим с гораздо большей вероятностью, чем какой-нибудь петя или стакснет? А потому, когда суровые АСУТПшники на местах встречают вас не слишком радушно — скажите спасибо, что пинками за территорию не выгоняют.
Итак, минимальный ликбез для ИБшника на тему того, что такое АСУТП.
Начнём с двух последних букв. ТП — это «технологический процесс». Вот первое и главное отличие АСУТП от разных «обычных» информационных систем. Если в привычных вам системах во главе угла — информация, которую надо защищать от разных напастей (потери, повреждения, несанкционированного доступа), то в АСУТП главное — технологический процесс. Информация — лишь отображение технологического процесса в виде, понятном системе управления. Что из этого следует? А то, что и защищать надо именно технологический процесс. Когда вы предлагаете анализировать информацию между контроллером и полевыми устройствами и, при наличии обоснованных подозрений, блокировать её (конкретно у вас такого не читал, но обычно все ИБшники это предлагают) — вы уверены, что ваш анализ точен и решение правильно? Вас не смущает, что именно вы можете перевести объект в неуправляемый режим с гораздо большей вероятностью, чем какой-нибудь петя или стакснет? А потому, когда суровые АСУТПшники на местах встречают вас не слишком радушно — скажите спасибо, что пинками за территорию не выгоняют.
И собственно, обещанный старый армейский анекдот.
Командир (К) части спрашивает свежеприбывшего из училища молодого лейтенанта (Л):
К: Товарищ лейтенант, вы взводом командовать можете?
Л: Так точно!
К: А ротой, если потребуется?
Л: Так точно!
К: Полком?
Л: Так точно!
К: Кораблём, самолётом, подводной лодкой?
Л: Так точно!
К: Продемонстрируйте!
Л: Подводная лодка! Р-равняйсь! Смирно!
(это я к чему, собственно: не всегда один подход годится везде)
Командир (К) части спрашивает свежеприбывшего из училища молодого лейтенанта (Л):
К: Товарищ лейтенант, вы взводом командовать можете?
Л: Так точно!
К: А ротой, если потребуется?
Л: Так точно!
К: Полком?
Л: Так точно!
К: Кораблём, самолётом, подводной лодкой?
Л: Так точно!
К: Продемонстрируйте!
Л: Подводная лодка! Р-равняйсь! Смирно!
(это я к чему, собственно: не всегда один подход годится везде)
НЛО прилетело и опубликовало эту надпись здесь
Ну, тогда продукт под названием KICS и его разработчиков Вы отнесли к числу неадекватных ИБшников :)
Предлагалась следующая схема:
1. Пассивная часть. Берётся все сетевое оборудование, на каждом из свитчей зеркалится весь трафик на один из портов, из которого идёт на внешний сервер для анализа. Оставим за скобками то, что нередко протоколы проприетарны и внутренности их производитель вот так просто разглашать не будет. Ограничились для пилотного проекта объектом с заведомо поддерживаемым оборудованием — системой от Siemens (опять же, если посмотреть в список поддерживаемого оборудования и ПО — там от Siemens только WinCC OA, который не совсем WinCC и не совсем Siemens, ну да ладно). То, что изменения в конфигурации мы не будем делать и не разрешим делать без согласования с разработчиком системы — пришлось объяснять. Хотя на мой взгляд такие требования — из области «само собой разумеется». Опять же, оставим за скобками то, что установленное оборудование такого зеркалирования делать не умеет. Ну вот не характерно это для промышленного сетевого оборудования. Вариант поменять всё на cisco… блин, где cisco, а где profinet… кого я там, Вы говорите, недопонял? Вариант внедрить туда ещё устройства для выдёргивания трафика из каждого физического линка… ну как бы это сказать… интересно, людям знакомо понятие «надёжность»?
Далее, опять же касаясь пассивной части. Анализ этого самого трафика на «легитимность». Уже хорошо, что нам не предложили какой-либо «эвристический анализатор» (либо ещё какой «думатель»). То есть — правила прописываются вручную. То есть — человек, прописывающий эти правила, по сути должен повторить проект АСУТП в виде этих правил. Учитывая количество устройств, вариантов блокировок на них, алгоритмов управления — количество правил на объекте получилось бы где-то к сотне тысяч. ИБшники готовы к такому объёму? Уверены? А отследить все косяки в таком объёме они в состоянии? Точно? А работу правил, которые нельзя опробовать, они готовы гарантировать?
2. Активная часть. От которой отказались сразу и безоговорочно. Предлагалось на основе того, что наанализоровала вышеописанная пассивная часть, блокировать трафик, признаваемый нелегитимным. Не знаю, каким образом. Дополнительные устройства? Отрубание портов, откуда идёт «атака» на существующих свитчах? Бред, вы говорите? Что я здесь «неправильно понял»? Открытым текстом — блокирование нелегитимного трафика.
3. Также активная часть. Тут уже, в отличие от п.1, нужны не зеркальные порты свитчей, а доступ в сеть со стороны внешнего сервера. Сервер периодически залезает в контроллеры и сверяет версии и контрольные суммы загруженных модулей. Где гарантия, что этот самый сервер не будет скомпрометирован и использован для атаки на эти самые контроллеры? Ведь его предлагается оставлять в сети постоянно, в отличие от инженерной станции/программатора, подключаемых в случае необходимости выполнения каких-либо работ. И, в отличие от операторского интерфейса (также постоянно подключенного), этот сервер уже имеет в себе необходимые для доступа к «потрохам» контроллера компоненты. Ну и нафиг нам эта пороховая бочка?
«Предложения и меры обычно лежат в совершенно в других плоскостях и с другими обоснованиями.». В каких, интересно? Или «у нас есть такие приборы, но мы вам про них не расскажем»?
Предлагалась следующая схема:
1. Пассивная часть. Берётся все сетевое оборудование, на каждом из свитчей зеркалится весь трафик на один из портов, из которого идёт на внешний сервер для анализа. Оставим за скобками то, что нередко протоколы проприетарны и внутренности их производитель вот так просто разглашать не будет. Ограничились для пилотного проекта объектом с заведомо поддерживаемым оборудованием — системой от Siemens (опять же, если посмотреть в список поддерживаемого оборудования и ПО — там от Siemens только WinCC OA, который не совсем WinCC и не совсем Siemens, ну да ладно). То, что изменения в конфигурации мы не будем делать и не разрешим делать без согласования с разработчиком системы — пришлось объяснять. Хотя на мой взгляд такие требования — из области «само собой разумеется». Опять же, оставим за скобками то, что установленное оборудование такого зеркалирования делать не умеет. Ну вот не характерно это для промышленного сетевого оборудования. Вариант поменять всё на cisco… блин, где cisco, а где profinet… кого я там, Вы говорите, недопонял? Вариант внедрить туда ещё устройства для выдёргивания трафика из каждого физического линка… ну как бы это сказать… интересно, людям знакомо понятие «надёжность»?
Далее, опять же касаясь пассивной части. Анализ этого самого трафика на «легитимность». Уже хорошо, что нам не предложили какой-либо «эвристический анализатор» (либо ещё какой «думатель»). То есть — правила прописываются вручную. То есть — человек, прописывающий эти правила, по сути должен повторить проект АСУТП в виде этих правил. Учитывая количество устройств, вариантов блокировок на них, алгоритмов управления — количество правил на объекте получилось бы где-то к сотне тысяч. ИБшники готовы к такому объёму? Уверены? А отследить все косяки в таком объёме они в состоянии? Точно? А работу правил, которые нельзя опробовать, они готовы гарантировать?
2. Активная часть. От которой отказались сразу и безоговорочно. Предлагалось на основе того, что наанализоровала вышеописанная пассивная часть, блокировать трафик, признаваемый нелегитимным. Не знаю, каким образом. Дополнительные устройства? Отрубание портов, откуда идёт «атака» на существующих свитчах? Бред, вы говорите? Что я здесь «неправильно понял»? Открытым текстом — блокирование нелегитимного трафика.
3. Также активная часть. Тут уже, в отличие от п.1, нужны не зеркальные порты свитчей, а доступ в сеть со стороны внешнего сервера. Сервер периодически залезает в контроллеры и сверяет версии и контрольные суммы загруженных модулей. Где гарантия, что этот самый сервер не будет скомпрометирован и использован для атаки на эти самые контроллеры? Ведь его предлагается оставлять в сети постоянно, в отличие от инженерной станции/программатора, подключаемых в случае необходимости выполнения каких-либо работ. И, в отличие от операторского интерфейса (также постоянно подключенного), этот сервер уже имеет в себе необходимые для доступа к «потрохам» контроллера компоненты. Ну и нафиг нам эта пороховая бочка?
«Предложения и меры обычно лежат в совершенно в других плоскостях и с другими обоснованиями.». В каких, интересно? Или «у нас есть такие приборы, но мы вам про них не расскажем»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Не влезай, убьет!» или вся правда о безопасности АСУ ТП