Комментарии 54
Однако избыточные меры ИБ, внедряемые без учёта этой специфики, наносят ущерб, сравнимый с реальными авариями.
О, если бы это касалось только АСУТП ...
Как это верно:
Остальные продолжат терять миллионы, борясь с ветряными мельницами киберугроз.
О, если бы это касалось только АСУТП ...
Я так думаю, если есть параноидально-шизофреничная технология пром безопасности и не только, ее внедряд в любом случае, но не потому что она необходима кровь из носу, а потому что она есть и потому что это "красиво" :), а какие будут последствия, на этапе внедрения ни кто об этом не думает. Более того, систему безопасности могут сделать так что и "мышь не проскочит" и "муха не пролетит", на это ума хватает, а вот правильно реализовать какое нить инженерное решение... посмотришь порой на это и подумаешь какие олигофрены это делали, а главное все сертифицировано, что ужас как серьезно... :)))
Компании, которые найдут этот баланс, не только избегут простоев, но и станут лидерами в своей отрасли. Остальные продолжат терять миллионы, борясь с ветряными мельницами киберугроз.
Это не важно. Главное - отчитаться о осваивании бюджетов и рапортовать.
Как на самом деле никого не волнует.
Так устроен мир.
Интересно, какова необходимость шифровать показания температуры? Если эти данные прочтёт кто-то посторонний, то что произойдёт?
он узнает температуру
Ну например это будет одной из частей которая позволит восстановить тех процесс производства какой-нибудь секретной марки стали.
А как он поймет где этот датчик установлен и чего он вообще показывает?
Есть складские ведомости. Есть закупочные тендеры. Есть бухгалтерия, отчеты и т. д.
То есть когда утечка информации в одном месте, делает ранее не пригодные к эксплуатации уязвимости возможными к реализации.
Ведь если злоумышленник имеет на руках список из 20 наличествующих на заводе датчиков, то перехваченная информация, если она не зашифрована может быть декодирована.
Плюс линия связи, например, по RS-485. Понятно, что перехватить сигнал дистанционно никак не выйдет, особенно, если таких же линий рядом ещё штук 20. Значит, злоумышленнику придётся проникнуть на территорию предприятия физически, а, возможно, что и вскрывать экранировку.
ну-ну
В теории это не только не даст её прочитать, но и не даст подделать, не?
Ограничения доступа: Бюрократия вместо оперативности
Интересные примеры. Но интереснее какие были сделаны выводы и на кого возложена ответственность. Главная проблема СБ в том, что они тефлоновые. Завод под землю провалится - а с них спроса нет. Всё ж было по регламенту, который они сами же и написали.
Спрос должен быть с тех, кто такие регламенты утверждает
Каких ИБшников по объявлениям набрали (или на какую зарплату с соответствующей квалификацией) - такие и регламенты :)
Каких ИБшников по объявлениям набрали (или на какую зарплату с соответствующей квалификацией)
я боюсь что набирают их не по объявлению, а по степени родства-знакомства, и зарплата у них, соответственно, соответствующая этой степени. Безопасность это вообще такое дело - туда кого попало не берут, только своих да наших.
Частично так. По степени-родства обычно берут в руководство ИБ. Но, т.к. они ничего в ИБ не понимают (иногда вообще это пенсионеры из органов), то сами ничего не пишут и руками не делают. С улицы туда как раз берут, но только тех, кто будет руками работать. Ну и из-за низкой квалификации рук (из-за зарплаты) и получаются всякие неприятные эффекты на другие подразделения компании.
Любая безопасность асимптотически стремится к осуществлению контролирующих функций с параллельным снижением технических компетенций и увиливанием от ответственности.
почему, несмотря на десятилетия страхов о кибератаках, не зафиксировано случаев массовых разрушений или гибели людей из-за взлома АСУТП?
на мой взгляд больше из-за того, что злоумышленники просто не в курсе конкретной реализации АСУТП. а автономные элементы физической безопасности они постепенно заменяются разными автоматизированными системами.
плюс причины аварий не всегда становятся известны широкому кругу лиц.
Некоторые аварии действительно скрываются. По опыту в газодобывающей отрасли: в силу работы приходилось с этим заниматься. Когда общался с операторами SCADA, то они мне показали, что какой бы не был инцидент в ИТ-части SCADA или электронике АСУТП, всегда находился "Дядя Вася" с ключом на 46, который шел к установке и закручивал необходимые гайки и запорную арматуру для предотвращения аварии.
А шифрование в АСУТП и тому подобное - это больше помыл от руководства предприятий, чтобы не утекала отчетность по процессу, т.к. скорее всего там тоже не всё чисто :)
О какой отчетности идет речь? Если это касается датчиков или передачи данных надо еще понять, что это за датчик в каких он пределах работает. С датчиков все в попугаях приходит и тд. Да и никакой информации секретной там нет. Это же не банк.
Понятно, что там в основном телеметрия и эти параметры известны только узкоспециализированным специалистам. И даже если "вклиниться" в линию и начать искажать данные, то с высокой долей вероятности это не к чему не приведет. Я уже говорю выше, на уровне SCADA, где информация агрегируется и появляются отчеты, например по добыче. С банком действительно не сравнить.
Вопрос с отчетами конечно интересный. Если есть конечно, что скрывать. Но я думаю эти же отчеты во всей остальной компании есть у всех заинтересованных лиц. Думаете будут пробовать самую неприступную часть взламывать? Можно же просто устроится на работу и все и так узнать. А устраиваться на работу в любом случае придется так как чаще всего АСУТП сеть изолирована воздушным зазором или есть защита между сетями если данные до корпоративной сети идут. Но тогда в корпоративной сети это все находится. Еще раз повторю это не банк. На заводе любой оператор знает чего и сколько произвели и тд.
Вы правы, 80% всех инцидентов КБ связана с внутренними нарушителями. Остальное уже связано с высокими технологиями - например нужен антивирус, чтобы не попасть под шифровальщик.
Т.к. оператор знает конфиденциальную информацию, то в случае, если он не сможет это рассказать и нужно унести файлы - нужна DLP. А вот если такая информация у оператора в голове, то тут сложнее - нужно в трудовом договоре обязать его не распространять информацию. Но эти методы уже к статье не имеют отношения.
Вы начинаете описывать всю модель угроз предприятия.
Ну про дядю Васю Вы завернули. Вы регулярно проверяйте источники сигналов на исправность + раз в год и после доработки ПО проверяйте алгоритмы. И будет Вам счастье. И останется только человеческий фактор, некачесвеный монтаж, неисправность оборудования. Про хороший проект и нормальных строителей я молчу, это само собой.
Мониторинг настроен. В описываемом случае были проблемы с тем, что некоторые компоненты оборудования даже по серым схемам не приобрести, но они выходят из строя. Из-за этого на местах стали строить свои "велосипеды" из того, что есть, т.к. руководству дорого переходить на имеющуюся в свободном для покупке доступе элементную базу (а может быть и не всё покрыто).
Для взлома Wi-Fi злоумышленник должен находиться в зоне действия сети, что невозможно на охраняемом объекте
С направленной антенной и специализированным приемо-передатчиком можно соединяться на сотнях метров.
Недавно была публикация на Хабре про взлом сети через соседей в офисном центре. Взломщики снаружи здания взломали соседнюю контору, а через них взломали целевую в соседнем офисе с ними.
почему, несмотря на десятилетия страхов о кибератаках, не зафиксировано случаев массовых разрушений или гибели людей из-за взлома АСУТП?
А вам не кажеться что инцидентов нет именно из-за ИБ? Пример очень напоминает классическое высказывание: зачем на админ, если и так все работает.
"На фармацевтическом предприятии запрет на удалённый доступ к SCADA вынудил технолога лететь из Германии в Индию для настройки дозатора."
Это не проблема ИБ, а проблема организации работ, когда требуемый технолог отсуствует на площадке.
Как в данной ситуации защитят приводимые вами "физические системами безопасности" если хакер изменит сломает настройку дозатора?
4. Удалённый доступ: Запрет, который стоит миллионов
В современном мире есть много встариваемого в человека мед. оборудования: кардиостимуляторы, инсулиновые помпы и т.д. Вот скажите, вы хотели бы, что у дорогоих вам людей подобное оборудование (если не дай бог пришлось бы его устанавливать) работало бы с вожможностью удаленного доступа и ошибка настройки которого могла привести к фатальному исходу?
Вы хотели бы жить рядом с вредным/опасным производством, где для удобства администраторов сделан доступ к системам управления через Wi-Fi?
Баланс ИБ польза vs сопуствующие издержки найти довольно сложно. Но большая часть приведенных примеров сводится к "давайте запретим замки, ибо сотрудникам требуется их открывать, что приводит к издержкам в работе".
P.S. Хотелось бы видить пруфы на примеры.
Вот настоящий ИБ. Для того, что бы беседу вести надо понимать как производство работает. Администраторы =))) Вы наконец матчастью займитесь, а потом будете всем рассказывать как надо, а то фантастические истории придумываете и потом такие же ИТшники в них верят и на заводах своих рассказывают. Любая поломка в АСУТП ничем не отличается. Атака и сломанный датчик, контроллер, ПК со SCADA. В чем разница. Это физическая система, а не просто ПО. Сломаться может все и все это знают. При проектировании уже закладываются сценарии что будет происходить если, что либо сломается. Да и по поводу ПО в АСУТП лучшая защита в мире. Недостижимая для ИТ. В АСУТП есть бекапы всего. Абсолютно всего. И мне не кажется, что инцидентов нет из за ИБ. ИБ только недавно решили в заводы лезть.
Причем объем кода обработки ошибок зачастую намного превышает объем кода самого техпроцесса.
Можно конкретику по моим вопросам?
Ответы в стиле "ПО в АСУТП лучшая защита в мире. Недостижимая для ИТ. В АСУТП есть бекапы всего." Как-бы по мягче сказать.... это не ответ технического специалиста. Поясню. На одном заводе может быть бэкапы, а на другом нет. Проецировать единичный опыт на всю отрасль не вполне корректно.
Будьте добры аргументировать свои тезисы верифицируемой информацией.
Win32/Stuxnet и история Crypto AG передают привет.
P.S. Хотелось бы видить пруфы на примеры.
поддерживаю, хотелось бы видеть не ссылки на дорогих людей, а какие-нибудь пруфы
А как отличается атака от поломки? Например у вас полностью умер сервер SCADA. Это похоже на вирус шифровальщик? Думаю похоже и там не работает и там. И время ремонта будет одинаковым. А вот вероятность если посчитать? Что вероятнее сломанный ПК или взлом? Тогда вопрос зачем жертвовать всем остальным ради обычных проблем которые случаться каждый день и при этом постоянно терять деньги? Взлом не нанесет большего ущерба чем обычная поломка.
А спизженные техпроцессы для вас шутка?
Да просто оператором устраиваетесь и все эти данные на бумажку записываете. Или хантите технолога с этого завода. Для чего все эти сложности мне непонятно. Да и техпроцесс если он такой секретный не только цифрами ограничивается. Обычно там цифры не самое главное.
Я думаю, эти риски бизнес должен оценивать и сравнивать со стоимостью предотвращения.
На мой взгляд, ИБ здорового человека - экспертная оценка угроз, дело инженеров - оценка стоимости последствий, а дело бизнеса - оценка рисков.
В то же время, мы повсеместно наблюдаем ИБ курильщика.
Особенно забавно слышать разговоры "безопасников" после конференций. Собирают большой зал, рассказывают всякое, дирекция тоже чего-нибудь добавит про новые технологии. Чувствуешь себя в каком-то крутом месте.
А потом приходишь на производство, а там компьютеры с windows xp, древние ПЛК со всего мира, какие-то спутанные провода по стенам о которых никто не знает и т.п.
З.Ы. Согласен, что на производстве "ИТ безопасность" как собаке пятая лапа, но приведите, пожалуйста, источники откуда взяты все эти миллионы убытков в статье?
Поддерживаю комментаторов выше: можете дополнить статью или в комментариях написать источники новостей об убытках и их причинах (по каждому приведенному примеру)? Интересно почитать оригиналы -- что там пишут.
Истории рассказаны однобоко, проблема с ИБ выставлена единственной причиной. На самом деле, каждый инцидент связан с несколькими причинами. Автоматика не должна внезапно из-за ошибки логина переходить в разрушительный режим.
Должен быть экстренный режим получения доступа.
Ни разу не упомянута безопасность с использованием токенов или как их там сейчас.
От перегрева печи можно спастись физической кнопкой аварийного отключения.
Оповещение можно сделать через мессенджер.
Сети можно отделять, промышленные от некритических. И в то же время иметь шлюз с защищённым входом.
Двухфакторная идентификация тоже часто достаточно тупая.
Вывод: ко всему надо подходить с головой, а не с непонятно откуда растущими руками. И сертификаты - в основном чтобы прикрыться.
Наверное, толковый сторонний аудит должен помочь.
Информационная Безопасность - это ещё полбеды, а вот АСУшникам в энергетике приходится еще каждый день работать с обычной Безопасностью, производственной… Вот уж где ненужная и глупая вещь - сюда не ходи, тут не трогай, удостоверение с собой носи, верхнюю пуговицу на форме застегивай, а уж про наряды и допуски я молчу! И все это мешает ужасно, потому что Настоящий Грамотный Мушкетер свой тех. процесс знает и ни за что не полезет за ограждение, а кто полез - тот, соотвественно, не Настоящий..
Это сарказм конечно, по ГОСТу ИБ и ТБ может и вполне адекватные, но большая часть локальных мер зависит от местного ИБ специалиста, чем от ГОСТа. Как, собственно, и в любой работе.
Постоянные отключения, разлогинивания, перезапуски виртуальных машин (все ради безопасности!), сотни вводов пароля за рабочий день, очень снижают продуктивность удаленной работы...
Присоединяюсь в тем, кто согласен что многие описанные кейсы с долгим получением доступа - что-то из области фантастики (кстати, автор мог бы прикрепить ссылки на данные случаи/новости, если бы это действительно было правдой).
Любое производство на котором установлена АСУ имеет определенные процедуры как реагировать в случае утечки/аварии/сборя и прочим ситуациям когда технологический процесс становится нестабильным. Кроме того, в составе АСУ есть отдельная категория ESD/SIS (ПАЗ - противоаварийная Защита), ПЛК которых автоматически отрабатывают в случае утечки, превышения/понижения параметра и прочих опасных/аварийных ситуациях. Данные системы как правило проектируются и реализуются после проведения HAZID/HAZOP и их алгоритмы аварийного останова производства основаны на расчетах.
Даже если, по какой-то причине, есть сбой, который требует доступа к ПЛК/DCS серверу - то такой доступ будет организован эксплуатацией в самые короткие сроки. На любом производстве ВСЕГДА, есть процедура, которая позволяет байпасить требования ИБ в любой ситуации которая несет угрозу стабильности процесса или человеческим жизням. Но если такой процедуры нет - то тогда обоср@лись ответственные за бесперебоную эксплуатацию и ответсвенные за ИБ - Вместе. Потому что для АСУТП действует триада ИБ - AIC (Availability, Integrity, Confidentiality) вместо классической CIA (Confidentiality Integrity Availability) традиционно использующейся в IT Security.
Согласен с автором по пункту№9: кибербез для АСУТП должен дополнять его и подстраиваться под бизнес-процесс, а не диктовать условия (если это только не предмет соответствия требованиям регулятора) и блокироть нормальный бизнес процесс.
ПАЗ - противоаварийная Защита
Попробуйте рассматривать ИБ как автономную противоаварийную защиту от ряда сценариев и вам сразу станет проще. Тем более что так оно и есть.
а не диктовать условия (если это только не предмет соответствия требованиям регулятора) и блокироть нормальный бизнес процесс.
Это вопрос скорее точки зрения что есть диктовать свои условия. ТБ тоже диктует условия. Слава богу что уже по большей части все осознали что получить кусок породы в каску лучше чем в голову. С ИБ ровно та же ситуация. Ну а всем АСУшникам я бы советовал подключаться к проектам заранее и начинать учиться ИБ - обратного пути нет и чем сложнее и обширнее будут становится системы АСУ ТП тем актуальнее и злее будет информационная защита.
если это только не предмет соответствия требованиям регулятора
Отдельный момент - это нормативка. Можете открыть 239 приказ ФСТЭК и почитать что там наворочено. Часть из пунктов сильно спорные в формулировках и трактовке. Но это закон и в интересах всех служб, и АСУ и ИБ выработать решение устраивающие для всех. А потом выполнять а не устраивать тихий саботаж средств ИБ "так же неудобно".
В этом и есть посыл этой статьи. Работать нужно вместе, вырабатывать решения, удобные всем.
Потому, как полный отказ от инфобеза в текущих условиях не рационален. Многие промышленные протоколы не имеют встроенных механизмов аутентификации, modbus tcp, например. Однако, бредовая ситуация, когда инженер не может 4 часа подключится к ПЛК, чтобы устранить утечку столь же бредова, как и архитектура системы, требующая такого подключения чтобы устранить аварию. Я видел программы для HMI когда, чтобы прочитать список ошибок, нужно ввести пароль, с автоматически разлогиниванием каждые 3 мин. Это - тоже маразм.
Резюме: голову нужно включать. Думать надо..
когда инженер не может 4 часа подключится к ПЛК, чтобы устранить утечку столь же бредова
Скажем так - с помощью аргументированных докладных и требования принятия ответственности сотрудников ИБ в случае нарушения функционирования АСУ ТП по причине средств ИБ нормальный начальник АСУ может вертеть на оси вращения практически все нормы ИБ, даже абсолютно здравые. Вопрос в готовности разбираться что зачем нужно и как повлияет. Ну и описанная проблема это извините не проблема ИБ - это проблема АСУ ТП которую чтобы прикрыть свой косяк скидывают на ИБ. Конечно на ПЛК самозародился пароль, ИБ мерзко хихикая ночью его установили и никому не сказали.
Многие промышленные протоколы не имеют встроенных механизмов аутентификации, modbus tcp, например.
Есть modbus TCP security.
Для меня примеры довольно странные. В одной части говорится, что есть физические средства защиты, которые сработают, в случае сбоя ПЛК даже если злоумышленник что-то испортит, с другой приводятся примеры, которые говорят, что из-за неверное работы ПЛК мог случится взрыв...
Я вот не понимаю, как может инженер устранить утечку газа, получив доступ к программе ПЛК. И вообще, почему все смотрели на утечку ожидая инженера. На любом производстве есть запорная арматура, которая управляется как ПЛК, так и локально, когда переводишь переключатель в "местное" управление. Ну если и это не работает, то слесаря+кран+сварной обычно закроют любую задвижку без инженера. Да и сам инженер странный, не может получить доступ к ПЛК, ладно, но у тебя ПЛК дает логические или аналоговые сигналы на управляемые элементы, берешь схему, смотришь на какие элементы надо подать управляющие сигнал, с каких клеммников, идешь и кидаешь перемычку имитируя этот сигнал, и происходит чудо, все работает само, без ПЛК.
Приведенные примеры либо очень преувеличены, либо из очень специфичных производств.
· На АЭС в Швеции во время передачи смены оператор не успел авторизоваться, и система не зафиксировала падение давления в контуре охлаждения. Автоматика сработала только через 10 минут, едва не допустив расплавления активной зоны.
Но вредоносное ПО тоже может заблокировать авторизацию и получается едва не допустить расплавление активной зоны. Вы тут доказали то, что пытаетесь опровергнуть.
Ну в Иране центрифуги всё-таки взорвали, так что примеры нанесения убытков взломом есть. И сколько таких историй осталось нераскрыто или не опубликовано, неизвестно.
Как избыточные меры ИБ в АСУТП губят производство, увеличивают простои и создают ложные угрозы