Comments 18
Спасает только железный ящик с замком.
У нас все компьютеры операторов физически находились в серверной (соседнее помещение). Мониторы и клавиатуры — через KVM.
А у нас операторы не косячат.
никакая остановка никаких серверов абсолютно не влияет на работу системы
аварийная остановка центрального сервера АСУТП на полчаса, может привести к полному перезапуску производственной линейки
никакая остановка никаких серверов абсолютно не влияет на работу системы
сам постоянно сталкиваюсь с такими же проблемами, только наш отдел на предприятии уже выработал стратегию по обеспечению безопасности. Если по вашим пунктам идти, то сделали следующее:
1. в каждом цехе своя локальная сеть системы управления, которая связна с заводской сетью с помощью шлюзового компьютера с антивирусом корпоративным, который регулярно (где это можно, ибо есть оооочень древние станции) обновляется;
2. тут сложнее, где-то как написано выше удаленные терминалы, где-то ящики с замком, а где сделать так невозможно, то просто отключаются внешние USB порты, вынимаются приводы и флопики, в биосе отключается загрузка с флешек и где также возможно закрываются корпуса на ключ, сервера всегда далеко от аппаратчиков в шкафах;
3. на рабочих станциях только скады, на шлюзовых антивирь и фтп для передачи в заводскую сеть хозучета, все; ну и ребята из ОИТ не имеют на эти станции удаленного доступа;
4. тут проще, на предприятие если постараться, то можно принести нетбук, но подключить его только удастся к шлюзовому компу и это будет заметно, вайфая нету, свичи под замком;
5. паролей нет только у аппаратчиков, все админские и инженерные пароли свои собственные, также учетке оператора обрубаем все лишнее от командной строки и диспетчера задач, до проводника и невозможности свернуть или закрыть скаду, и т.д. и т.п., чтобы по ночам не лазили куда не нужно;
6. обновления не ставим, только критические патчи, также почти везде у нас всё резервируется, от серверов до сети, ну и по всем станциям и серверам есть актуальные бэкапы;
7. тут сложнее, в основном метод кнута и удар по кошельку чтобы другим не повадно было.
Работаю вот уже пять лет и проблем было всего пару штук, так что эти методы у нас работают.
1. в каждом цехе своя локальная сеть системы управления, которая связна с заводской сетью с помощью шлюзового компьютера с антивирусом корпоративным, который регулярно (где это можно, ибо есть оооочень древние станции) обновляется;
2. тут сложнее, где-то как написано выше удаленные терминалы, где-то ящики с замком, а где сделать так невозможно, то просто отключаются внешние USB порты, вынимаются приводы и флопики, в биосе отключается загрузка с флешек и где также возможно закрываются корпуса на ключ, сервера всегда далеко от аппаратчиков в шкафах;
3. на рабочих станциях только скады, на шлюзовых антивирь и фтп для передачи в заводскую сеть хозучета, все; ну и ребята из ОИТ не имеют на эти станции удаленного доступа;
4. тут проще, на предприятие если постараться, то можно принести нетбук, но подключить его только удастся к шлюзовому компу и это будет заметно, вайфая нету, свичи под замком;
5. паролей нет только у аппаратчиков, все админские и инженерные пароли свои собственные, также учетке оператора обрубаем все лишнее от командной строки и диспетчера задач, до проводника и невозможности свернуть или закрыть скаду, и т.д. и т.п., чтобы по ночам не лазили куда не нужно;
6. обновления не ставим, только критические патчи, также почти везде у нас всё резервируется, от серверов до сети, ну и по всем станциям и серверам есть актуальные бэкапы;
7. тут сложнее, в основном метод кнута и удар по кошельку чтобы другим не повадно было.
Работаю вот уже пять лет и проблем было всего пару штук, так что эти методы у нас работают.
С грустью вспоминаю, когда система работала на венгерском D-Mon под QNX. Вот уж пихай что хочешь.
даже не слышал про такое. у нас на заводе целый зоопарк систем, но самое страшное — это питерский Автонит-46. мы сразу бэкапы сделали, а станции на растерзание оставили аппаратчикам — они уже год без дела сидят, так как уже два кривых вала для турбины из Питера пришло))) ждем третий…
Как говорится, почувствуйте разницу :)
www.exploit-db.com/platform/?p=QNX
www.exploit-db.com/platform/?p=windows
www.exploit-db.com/platform/?p=QNX
www.exploit-db.com/platform/?p=windows
Чем-то напоминает притчу про неуловимого Джо и почему он неуловим…
Если бы QNX стоял на каждом «углу» как и винда, то любителей его поломать было бы гораздо больше, и списочки бы были почти одинаковые. Да, конечно QNX гораздо надежнее винды, но я бы не стал особо полагаться на разницу только на основании вышеприведенных списков.
Если бы QNX стоял на каждом «углу» как и винда, то любителей его поломать было бы гораздо больше, и списочки бы были почти одинаковые. Да, конечно QNX гораздо надежнее винды, но я бы не стал особо полагаться на разницу только на основании вышеприведенных списков.
Хорошие методы :)
2. Вообще стараемся применять многослойный подход при создании рекомендаций инженерам: зайца сначала утопить, потом расстрелять и тд. То есть отключение того же usb в биосе, совмещаем с отключением usb средствами ОС, совмещаем с физической изоляцией. Человеческий фактор и всякие случайности, типа забытых ключей от корпусов АРМ-ов начинают играть меньшую роль.
4. По поводу замков, сразу вспомнился случай с очередным «дураком». Есть на заводах любители искать и сдавать медь. Вот как то один такой, вскрыл замочек хитрой проволочкой, забрался в распределительный шкаф слаботочки и порезал «ненужные» провода. Вот уж действительно, против лома нет приема.
5. Еще очень полезно настроить белые списки SRP, особенно когда много однотипных АРМ-ов.
6. Удобно определять, что где поставить с помощью традиционных сетевых сканеров безопасности. Это как правило применяется при плановых аудитах сети. Там уже стали появляться и проверки компонентов SCAD-а Все проблемы которые вылазят, незамедлительно закрываются. Ибо такие очевидные проблемы, рай для для потенциально занесенной вирусни. Инженеров также учим использовать локальные сканеры, там все просто, запустил и видно какие критические патчи не стоят. Вообще просветительская работа играет очень большую роль, многие просто не понимают зачем это нужно. В идеале, если инженеры с пониманием, аудиты вообще не выявляют никаких очевидных проблем.
2. Вообще стараемся применять многослойный подход при создании рекомендаций инженерам: зайца сначала утопить, потом расстрелять и тд. То есть отключение того же usb в биосе, совмещаем с отключением usb средствами ОС, совмещаем с физической изоляцией. Человеческий фактор и всякие случайности, типа забытых ключей от корпусов АРМ-ов начинают играть меньшую роль.
4. По поводу замков, сразу вспомнился случай с очередным «дураком». Есть на заводах любители искать и сдавать медь. Вот как то один такой, вскрыл замочек хитрой проволочкой, забрался в распределительный шкаф слаботочки и порезал «ненужные» провода. Вот уж действительно, против лома нет приема.
5. Еще очень полезно настроить белые списки SRP, особенно когда много однотипных АРМ-ов.
6. Удобно определять, что где поставить с помощью традиционных сетевых сканеров безопасности. Это как правило применяется при плановых аудитах сети. Там уже стали появляться и проверки компонентов SCAD-а Все проблемы которые вылазят, незамедлительно закрываются. Ибо такие очевидные проблемы, рай для для потенциально занесенной вирусни. Инженеров также учим использовать локальные сканеры, там все просто, запустил и видно какие критические патчи не стоят. Вообще просветительская работа играет очень большую роль, многие просто не понимают зачем это нужно. В идеале, если инженеры с пониманием, аудиты вообще не выявляют никаких очевидных проблем.
Насчет отключения загрузки — как-то столкнулся с тем, что на некоторых материнках даже при отключении в биосе всё равно можно загрузиться с флэшки по нажатию какой-то функциональной клавиши.
Метод удара по кошельку — это уже организационный вопрос, и требуется вовлеченность начальства в процесс, а также минимальное понимание важности ИБ. Лично я не видел, чтобы где-то назначались штрафы (хотя и давно не видел я реальных производств с цехами и станками, что делать)
Метод удара по кошельку — это уже организационный вопрос, и требуется вовлеченность начальства в процесс, а также минимальное понимание важности ИБ. Лично я не видел, чтобы где-то назначались штрафы (хотя и давно не видел я реальных производств с цехами и станками, что делать)
1. Антивирусы.
Если АСУТП уровня станков с ЧПУ (утрирую конечно) — то нет проблем или есть, но они не фатальны. В противном случае отсутствие антивируса вполне понятная вещь (говорю из практики, а не теоретизирую). Производитель АСУТП говорит — не гарантирую совместимость моего софта и антивирусных решений. И точка. И никто не рискнет вопреки рекомендации производителя что-то делать там, где на АСУТП действительно завязано что-то серьезное. И это резонно.
Выбирать же из производителей средств автоматизации не всегда возможно.
Вот случится что-то вроде forum.kaspersky.com/index.php?showtopic=255519&st=0 и нарушит работу АРМ-а. И по ссылке еще достаточно безобидный пример. Бывают и хуже, типа полного отсутствия сети, ложных срабатываний, аварийных перезагрузок. И свои тараканы не только у Касперского. Кто пойдет на такой риск?
2. Есть промышленное защищенное исполнение АРМ-ов. И многие их используют. Да, их тоже можно вскрыть. Но есть разумный предел всему. В конце концов, если человек сойдет с ума, вооружившись инструментом он может много натворить на объекте. Здесь уже другая история и другие меры.
3. Справедливо. Но не надо обобщать. Воздушный зазор (а не то, что просто сегментация с фв на границе) встречается достаточно часто.
6. Решается изоляцией и контролем трафика внутри сети с помощью инлайн включенных IPS. Концепция простая — не можем оперативно патчить машины, «патчим» сетевой трафик. И это касается только разрешенного трафика, который может быть, увы, и RPC в силу особенностей, остальное просто тупо же режем. Да, дыры на хостах остаются, но эксплуатировать их становится сложно, по крайней мере по сети.
Про «поставить на бабки» — опять же пример по ссылке из разряда «станок с ЧПУ». На серьезных объектах (КСИИ) такое теоретически тоже возможно, но каков риск для желающих подзаработать? Если поймают за руку — мало не покажется. Все же серьезные области курируются и ФСБ и ФСТЭК и прочими серьезными дядями.
На счет организационных мер — опять же вопрос критичности и масштаба. Если из-за неуемного желания начальника смены станции, допустим, посмотреть кино, не будет выдержена нужная мощность или какая команда РДУ не отработна — будет много всего неприятного для больших дядь, вплоть до всяких там коммисий министерских. И получат по башке все, начиная от руководства и кончая рядовыми. И штрафами там может не ограничиться.
Если АСУТП уровня станков с ЧПУ (утрирую конечно) — то нет проблем или есть, но они не фатальны. В противном случае отсутствие антивируса вполне понятная вещь (говорю из практики, а не теоретизирую). Производитель АСУТП говорит — не гарантирую совместимость моего софта и антивирусных решений. И точка. И никто не рискнет вопреки рекомендации производителя что-то делать там, где на АСУТП действительно завязано что-то серьезное. И это резонно.
Выбирать же из производителей средств автоматизации не всегда возможно.
Вот случится что-то вроде forum.kaspersky.com/index.php?showtopic=255519&st=0 и нарушит работу АРМ-а. И по ссылке еще достаточно безобидный пример. Бывают и хуже, типа полного отсутствия сети, ложных срабатываний, аварийных перезагрузок. И свои тараканы не только у Касперского. Кто пойдет на такой риск?
2. Есть промышленное защищенное исполнение АРМ-ов. И многие их используют. Да, их тоже можно вскрыть. Но есть разумный предел всему. В конце концов, если человек сойдет с ума, вооружившись инструментом он может много натворить на объекте. Здесь уже другая история и другие меры.
3. Справедливо. Но не надо обобщать. Воздушный зазор (а не то, что просто сегментация с фв на границе) встречается достаточно часто.
6. Решается изоляцией и контролем трафика внутри сети с помощью инлайн включенных IPS. Концепция простая — не можем оперативно патчить машины, «патчим» сетевой трафик. И это касается только разрешенного трафика, который может быть, увы, и RPC в силу особенностей, остальное просто тупо же режем. Да, дыры на хостах остаются, но эксплуатировать их становится сложно, по крайней мере по сети.
Про «поставить на бабки» — опять же пример по ссылке из разряда «станок с ЧПУ». На серьезных объектах (КСИИ) такое теоретически тоже возможно, но каков риск для желающих подзаработать? Если поймают за руку — мало не покажется. Все же серьезные области курируются и ФСБ и ФСТЭК и прочими серьезными дядями.
На счет организационных мер — опять же вопрос критичности и масштаба. Если из-за неуемного желания начальника смены станции, допустим, посмотреть кино, не будет выдержена нужная мощность или какая команда РДУ не отработна — будет много всего неприятного для больших дядь, вплоть до всяких там коммисий министерских. И получат по башке все, начиная от руководства и кончая рядовыми. И штрафами там может не ограничиться.
По 6 пункту действительно весьма полезно контролировать сетевой трафик. Может идти как дополнительная мера на особо критичных и серьезных объектах, ибо в системе могут быть дыры удаленной эксплуатации неизвестные производителю, но известные черным шляпам.
Но обычное Российское производство таким людям врятли интересно, там больше нужна именно защита от дурака.
По 1. Дело в том что когда «припрет», деваться то некуда будет (тоже из практики). И в авральном режиме будет установка патчей, поскольку сетевой червяк через древние дыры пролезает, где только можно, и установка антивируса с актуальными базами.
Вот кстати интересная ссылка, по теме заражений.
цитата
***********************
Началось с жалоб на потери связи клиент-сервер. И еще были жалобы, по симптомам смахивающие на результат действия вредоносного ПО. Если учесть, что я полгода назад лечил этот объект от Conflickera, то я подумал, что опять началось. Хотя уже всех диспетчеров повздрючивали материально, усилили меры безопасности и т.д. вплость до того, что повыдирали USB порты на самых стремных АРМах. Как потом выяснилось, заразу привезла одна из подрядных организаций… Объект распределенный, около 30 САУ на 315 ПЛК, и часть из них у разных подрядчиков. И каждый без спроса норовит всунуть свой программатор в сеть. История банальна до безобразия. Кстати, флешка заражалась только с ихнего программатора, а вот уже мои сервера и АРМы заразились по сети, и воткнутую в них флешку не заражали.
***********************
iadt.siemens.ru/forum/viewtopic.php?t=14276&postdays=0&p=75091
Но обычное Российское производство таким людям врятли интересно, там больше нужна именно защита от дурака.
По 1. Дело в том что когда «припрет», деваться то некуда будет (тоже из практики). И в авральном режиме будет установка патчей, поскольку сетевой червяк через древние дыры пролезает, где только можно, и установка антивируса с актуальными базами.
Вот кстати интересная ссылка, по теме заражений.
цитата
***********************
Началось с жалоб на потери связи клиент-сервер. И еще были жалобы, по симптомам смахивающие на результат действия вредоносного ПО. Если учесть, что я полгода назад лечил этот объект от Conflickera, то я подумал, что опять началось. Хотя уже всех диспетчеров повздрючивали материально, усилили меры безопасности и т.д. вплость до того, что повыдирали USB порты на самых стремных АРМах. Как потом выяснилось, заразу привезла одна из подрядных организаций… Объект распределенный, около 30 САУ на 315 ПЛК, и часть из них у разных подрядчиков. И каждый без спроса норовит всунуть свой программатор в сеть. История банальна до безобразия. Кстати, флешка заражалась только с ихнего программатора, а вот уже мои сервера и АРМы заразились по сети, и воткнутую в них флешку не заражали.
***********************
iadt.siemens.ru/forum/viewtopic.php?t=14276&postdays=0&p=75091
На моей практике при разумном (я даже не говорю — профессиональном и исчерпывающем по мерам) подходе вреда от ав бывает больше. Могу наблюдать уже более 5 лет несколько закрытых техносетей с более-менее вменямым руководством. Ав нет, вирусов тоже. По факту, а не по фантазиям. На счет тех же червяков. Если для работы технологии не требуется tcp 135,139,445 и прочее — как червь пролезет? Запрещаем все, открываем избранное. Веб для тонкого клиента, нужные спефичные порты технософта и все. Никаких конфликеров ака кидо. Или, если подцепили локально — изоляция проблемы за счет жестких acl. Я даже в офисной сети в рамках одного влан-а трафик между юзерами полностью душу, а уж в техносети это просто обязательно делать. Другой вопрос, что решения технические бывают разные и где-то RPC необходим для работы.
Началось с жалоб на потери связи клиент-сервер.
У нас самый злобный вирус это сам процесс сервера скады, падающий с завидной регулярностью. Разработчик сделать ничего не может. Благо сервера 2, один падает, второй подхватывает.
Вот приведу еще маленький пример по обновлениям и дырявости.
Спустимся чуть ниже. Вот стоит хороший такой контролер, который отпахал уже десяток лет, к нему полно запасных блоков, в свое время за это хозяйство было заплачено немало денег. Отпашет еще десяток лет.
А вот сетевая часть реализована в нем на огрызке linux-а.
Внутри стоит
linux_kernel — 2.4 (сборка 2003 года).
Подняты и торчат наружу.
mini_httpd — 1 версии (2003)
Порт RCP.
Все крутится под root-ом.
Под столь дремучую сборку я сходу нашел несколько столь-же дремучих паблик сплоитов… И кто возьмется его обновить?
Да никто не возьмет на себя такой риск, производитель давно говорит — покупайте новый. Купишь новый, а там будет тот же линукс, ну пусть 2010 года сборки, с дырявыми сервисами. Те же яйца только в профиль.
Получается, если строить защищенные сети АСУТП, производитель должен рассматривать с точки зрения ИБ все компоненты системы, а не только акцентироваться на уровне SCADA.
Спустимся чуть ниже. Вот стоит хороший такой контролер, который отпахал уже десяток лет, к нему полно запасных блоков, в свое время за это хозяйство было заплачено немало денег. Отпашет еще десяток лет.
А вот сетевая часть реализована в нем на огрызке linux-а.
Внутри стоит
linux_kernel — 2.4 (сборка 2003 года).
Подняты и торчат наружу.
mini_httpd — 1 версии (2003)
Порт RCP.
Все крутится под root-ом.
Под столь дремучую сборку я сходу нашел несколько столь-же дремучих паблик сплоитов… И кто возьмется его обновить?
Да никто не возьмет на себя такой риск, производитель давно говорит — покупайте новый. Купишь новый, а там будет тот же линукс, ну пусть 2010 года сборки, с дырявыми сервисами. Те же яйца только в профиль.
Получается, если строить защищенные сети АСУТП, производитель должен рассматривать с точки зрения ИБ все компоненты системы, а не только акцентироваться на уровне SCADA.
В итоге мы приходим к тому, что интегрированная безопасность нам не светит, потому что всегда там будет линукс, который сегодня свежий-актуальный, завтра там найдут дыры. Итого развиваем безопасность навесную, которая нам прикроет наши дыры и в которой знание дыр обновлять легче-проще, чем прошивки контроллеров и длл-ки винды.
Как правило, системные сервисы выведены на отдельный lan разъем на контроллере (у нас так). Поэтому что-то ломать можно только физически присоединившись к контроллеру.
Sign up to leave a comment.
Безопасность АСУТП практика и примеры