Проконсультируйте по вопросу безопасности

[Ivan69]

День добрый. Образования в области асутп у меня, поэтому вопросы могут показаться глупыми. Сейчас много исследований в области получения доступа к АСУ ТП, в качестве самых простых случаев - получение доступа к scada, возможность воздействия на плк и hmi. Но возникает вопрос а реальны ли угрозы? Ведь изменил хакер параметр в системе, упал какой-то модуль. Через какое-то время watchdog все модули перезагрузил и поднял демоны. А что если можно было оценить реальную опасность изменение параметра, например, отвечающего только за температуру. Полагаю что тут должны как-то моделироваться ситуации работы системы и проверять "положительную обратную связь". Возможно ли такое? Есть ли такие решения?

[Jackson]

Смотрите на задачу:
а) проще;
б) конкретнее.

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

Конкретнее, потому что лучше взять конкретную АСУТП и на неё взглянуть с учётом вышеназванного пункта.

Никто пока не слышал об атаке хакеров, приведшей к взлому интерфейса RS-485 - потому что он (интерфейс), как неуловимый Джо, ни на чёрта никому не сдался. Тут уже немало об этом написано, почитайте.

[Ivan69]

Я с Вами согласен, но ведь технологии стремительно развиваются, так же как и промышленный сектор. В итоге может случится такая ситуация, что в интернет (даже пусть за NATом) будет смотреть какой-нибудь порт, отвечающий за демон контроля чего-то там. Пусть даже несерьезного.

Как раз в этом и была задумка - на датчик контроля температуры или давления мы повлиять не может, но может быть на что-то другое "незначительное", которое в контексте полож. обр. связи даст серьезные нарушения.

Вопрос в другом на каком уровне можно проанализировать систему? Т.е. очевидно, что рассматривать всю систему сложно. Может есть смысл оценить работу конкретного плк? Т.е. как на его уровне изменение одного параметра повлечет изменение других.
Или это фантазии?

[Jackson]

Я с Вами согласен, но ведь технологии стремительно развиваются, так же как и промышленный сектор.

В промышленном секторе до сих пор и используется Модбас, Харт, 4-20 мА и ещё туча разных протоколов, взлом которых никому не нужен, несмотря на стремительно развивающиеся технологии. И будут использоваться и дальше.

Давайте не будем переливать из пустого в порожнее, тут рядом 4 темы есть ровно с таким же содержанием. Нет физического доступа - нет взлома. Вот и вся защита.

А как можно систему проанализировать - смотрите все те же темы. Там есть даже ссылки на готовые анализы. Но анализы эти бездарные, потому что их делали люди, далёкие от АСУТП. В общем анализы и есть. :)

И ещё раз: 1 - проще и 2 - конкретнее. Разговор о сферическом малогабаритном вакуумном коне вряд ли кого-то тут заинтересует, так что конкретику давайте - какую систему проанализировать собираетесь, и, самое главное, зачем?

[rwg]

Сейчас много исследований в области получения доступа к АСУ ТП. Но возникает вопрос а реальны ли угрозы?

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

[CHANt]

Поддержу rwg!
Был у меня в практике такой случай - есть специализированная скада, основной сервер работает, резервный стоит в "теплом" резерве. Через отдельную сетевую карту отправляет основному число, назад получает измененное.
Инженер по защите информации смежной службы, анализируя сетевой трафик на цисках, обнаружил порт по которому практически не идет информация))) Пошел да и вытащил патч-корд с патч-панели. Проверить так сказать - что же это такое))) Четыре диспетчерских уровня лишились информации по Центральному энергорайону, так как резервный сервер "потерял" связь с основным, включился и оттянул на себя коммуникационные контроллеры связи, которые не могут работать с двумя серверами одновременно. Полный затык на полностью работоспособной системе!
А кто защитит системы от защитника?! :)

[Ivan69]

Я с Вами согласен, но ведь технологии стремительно развиваются, так же как и промышленный сектор.

В промышленном секторе до сих пор и используется Модбас, Харт, 4-20 мА и ещё туча разных протоколов, взлом которых никому не нужен, несмотря на стремительно развивающиеся технологии. И будут использоваться и дальше.
зачем?

Мне кажется, что надо разделять взлом протокола от взлома плк. И почему не может быть ситуации когда modbusTCP будет смотреть в инет?

Давайте не будем переливать из пустого в порожнее, тут рядом 4 темы есть ровно с таким же содержанием. Нет физического доступа - нет взлома. Вот и вся защита.

но ведь в shodan можно найти достаточно разномастные плк, хотя актуален вопрос, что даже если хакер получит доступ к плк - всегда есть резервирование, либо возможности самой плк на влияние тех процесса достаточно ограничены.

А как можно систему проанализировать - смотрите все те же темы. Там есть даже ссылки на готовые анализы. Но анализы эти бездарные, потому что их делали люди, далёкие от АСУТП. В общем анализы и есть. :)

Полагаю тут Вы говорите об Pos itive Te ch. Да видел, действительно первые доклады с путаницей в терминологии.

И ещё раз: 1 - проще и 2 - конкретнее. Разговор о сферическом малогабаритном вакуумном коне вряд ли кого-то тут заинтересует, так что конкретику давайте - какую систему проанализировать собираетесь, и, самое главное, зачем.

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

Сейчас много исследований в области получения доступа к АСУ ТП. Но возникает вопрос а реальны ли угрозы?

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

"Если у тебя паранойя это не значит, что за тобой не следят" Хотя согласен бизнес в первую очередь.

[Ryzhij]

Мне кажется, что надо разделять взлом протокола от взлома плк.

И что это даёт помимо "густоты мысли" в дипломной работе?
"Безопасность" вообще понятие относительное, а меры по её обеспечению должны быть комплексными.
Иначе эти меры бесполезны.

И почему не может быть ситуации когда modbusTCP будет смотреть в инет?

Человек, применяющий modbus подобным образом, или должен чётко представлять себе все недостатки и прочие особенности применяемого протокола, или не заниматься промышленной автоматикой вообще.
Подобно тому, как Вы или должны соблюдать ПДД, переходя улицу, или вообще сидеть дома. Опять же ради безопасности себя и других.
Но даже дома Вам придётся соблюдать определённые правила (протоколы) безопасности.
Изучите особенности протокола Modbus-TCP, и тогда у Вас появится понимание об ограниченной совместимости Modbus-TCP и TCP/IP.

[Exactamente]

А вопрос-то занятный, по-моему. Так, как мозговая акробатика :) Не уверен, что практический смысл есть.
Так вот, со времени моей дискуссии с BigDog'ом на тему интернета вещей мои взгляды на это явление претерпели именения :) Но безотносительно моего ИМХО об IoT, факт остаётся фактом - АСУ перестают быть изолированными от внешнего мира.

>А что если можно было оценить реальную опасность изменение параметра, например, отвечающего только за температуру.
Так оценивайте :) Ваш же диплом. Разделите на цель атаки - скаду и/или плк. Возьмите 2-3 конкретных образца (хз как это сделать, если не работаете там, где есть доступ к ПО и железу).
Изучите как, например, в плк устроена программа. Изучите все варианты как её можно изменить, как можно изменить значения переменных. Сходу варианты - прикинувшись скадой или средой разработки, что-то типа атаки Man in the Middle. Попробуйте это реализовать. Начать можно послушав траффик между ПЛК и, например, скадой. Проанализировать пакеты, попробовать обмануть ПЛК, подсунув ему свои "хакерские" значения PV, SP или пределы. Подумайте, к чему приведёт подмена этих значений (это вообще очень обширный вопрос сам по себе, может, с него и надо начать). Это как один из вариантов, весьма детское исполнение, чисто на смекалку. Рекомендую почитать вообще на тему IT безопасности, тот же хабр - для формирования вообще думки в этом направлении, куда можно залезать и как сломать, а потом попробовать под этим углом посмотреть на АСУТП.

Можно нырнуть более хардкорно, на уровне исполнения стакснета и всяческих zero day уязвимостей, только если бы да - вы бы такой вопрос не задавали на форуме, а продавали свои услуги на чёрном рынке :) Ну и я соответственно, не трепался бы тут ^_^

[Jackson]

Это бизнес, сначала проблему озвучиваем, потом раскручиваем и наконец зарабатываем на ней.

Конечно! Сначала создать проблему, затем героически её преодолеть, за что и получить ордена. Так происходит уже лет двести.

Мне кажется, что надо разделять взлом протокола от взлома плк.

ЗАЧЕМ?

Я специально выделил покрупнее. А то Вы как-то так лихо беседуете, сами вопросы задаёте, а на другие отвечать не торопитесь. Тут люди не от нечего делать сидят, им есть чем заняться.

И почему не может быть ситуации когда modbusTCP будет смотреть в инет?

Скажите, а почему не может быть ситуации когда точно на сервер падает обломок метеорита, пробив три этажа перекрытий, и выносит исключительно сервер?
Я сам же и отвечу: такое действительно может быть. Но никто такого ещё не видел.

[Jackson]

А вопрос-то занятный, по-моему. Так, как мозговая акробатика :) Не уверен, что практический смысл есть.

Да тут рядом 4 темы точно такого же вопроса (счас наговоримся всласть и я все их солью в одну). :)

Способ решения любой задачи определяет ответ на очень простой вопрос: зачем?

Пока нет ответа - будем трепаться.

А пока, продолжаем развлекаться.

Давайте не будем переливать из пустого в порожнее, тут рядом 4 темы есть ровно с таким же содержанием. Нет физического доступа - нет взлома. Вот и вся защита.

но ведь в shodan можно найти достаточно разномастные плк, хотя актуален вопрос, что даже если хакер получит доступ к плк - всегда есть резервирование, либо возможности самой плк на влияние тех процесса достаточно ограничены.

Хотелось бы узнать, где это конкретно "всегда есть резервирование" и, извиняюсь за прямоту, на..зачем нужен ПЛК, не влияющий на техпроцесс? Притом резервированный!

[Михайло]

Можно еще один вопрос? Что такое "положительная обратная связь" в контексте безопасности АСУТП?

[Exactamente]

>Способ решения любой задачи определяет ответ на очень простой вопрос: зачем?
У меня есть конкретный пример, но он под NDA, о неразглашении :)

В широком смысле: надо из точки А как минимум видеть, что происходит с техпроцессом в точках Б, В, ... Между А и Б от несколько сотен км, между А и В океан (в буквальном смысле). Как максимум - иметь возможность ограниченно (но существенно) управлять.

Чем кроме интернета их можно связать? Ну, можно смсками, но это как-то сразу хромающий на обе ноги проект, по-моему.

[Ivan69]

Мне кажется, что надо разделять взлом протокола от взлома плк.

И что это даёт помимо "густоты мысли" в дипломной работе?
"Безопасность" вообще понятие относительное, а меры по её обеспечению должны быть комплексными.
Иначе эти меры бесполезны.

Чуть выше TEB написал, что

В промышленном секторе до сих пор и используется Модбас, Харт, 4-20 мА и ещё туча разных протоколов, взлом которых никому не нужен, несмотря на стремительно развивающиеся технологии. И будут использоваться и дальше.

я согласен, что взлом, например харт, достаточно экзотичен - по сути означает прямой доступ к системе. Поэтому я предложил различать получение удаленного доступа к плк и взлом протокола (например врезка в харт).

И почему не может быть ситуации когда modbusTCP будет смотреть в инет?

Человек, применяющий modbus подобным образом, или должен чётко представлять себе все недостатки и прочие особенности применяемого протокола, или не заниматься промышленной автоматикой вообще. Подобно тому, как Вы или должны соблюдать ПДД, переходя улицу, или вообще сидеть дома. Опять же ради безопасности себя и других. Но даже дома Вам придётся соблюдать определённые правила (протоколы) безопасности. Изучите особенности протокола Modbus-TCP, и тогда у Вас появится понимание об ограниченной совместимости Modbus-TCP и TCP/IP.

По вашей логике тогда никак не надо контролировать водителей - есть же пдд и если водитель их не соблюдает - это только его проблема, а не остальных водителей. В жизни ездят водители которые не знают пдд и работают инженеры не разбирающиеся в промышленной автоматике.

[Ivan69]

А вопрос-то занятный, по-моему. Так, как мозговая акробатика :) Не уверен, что практический смысл есть.
Так вот, со времени моей дискуссии с BigDog'ом на тему интернета вещей мои взгляды на это явление претерпели именения :) Но безотносительно моего ИМХО об IoT, факт остаётся фактом - АСУ перестают быть изолированными от внешнего мира.

Согласен - достаточно поискать в интернете и легко найти sheider, siemens

>А что если можно было оценить реальную опасность изменение параметра, например, отвечающего только за температуру.
Так оценивайте :) Ваш же диплом. Разделите на цель атаки - скаду и/или плк. Возьмите 2-3 конкретных образца (хз как это сделать, если не работаете там, где есть доступ к ПО и железу).
Изучите как, например, в плк устроена программа. Изучите все варианты как её можно изменить, как можно изменить значения переменных. Сходу варианты - прикинувшись скадой или средой разработки, что-то типа атаки Man in the Middle. Попробуйте это реализовать. Начать можно послушав траффик между ПЛК и, например, скадой. Проанализировать пакеты, попробовать обмануть ПЛК, подсунув ему свои "хакерские" значения PV, SP или пределы. Подумайте, к чему приведёт подмена этих значений (это вообще очень обширный вопрос сам по себе, может, с него и надо начать). Это как один из вариантов, весьма детское исполнение, чисто на смекалку. Рекомендую почитать вообще на тему IT безопасности, тот же хабр - для формирования вообще думки в этом направлении, куда можно залезать и как сломать, а потом попробовать под этим углом посмотреть на АСУТП.

Можно нырнуть более хардкорно, на уровне исполнения стакснета и всяческих zero day уязвимостей, только если бы да - вы бы такой вопрос не задавали на форуме, а продавали свои услуги на чёрном рынке :) Ну и я соответственно, не трепался бы тут ^_^

Спасибо дельные советы. Я хотел бы пояснить свою идею: например, есть у нас программа(на STL). её надо проанализировать и на выходе получить ответ - изменение вот такого-то, потом такого-то и потом такого того параметра повлечет за собой резкое увеличение например показателя температуры. Тут возникают трудности - программы не универсальны, языков много, топология систем разная. Может есть исследования на эту тему? Я искал и не нашёл. Надеюсь моя идея ясна

[Ivan69]

Это бизнес, сначала проблему озвучиваем, потом раскручиваем и наконец зарабатываем на ней.

Конечно! Сначала создать проблему, затем героически её преодолеть, за что и получить ордена. Так происходит уже лет двести.

Мне кажется, что надо разделять взлом протокола от взлома плк.

ЗАЧЕМ?

Партийное задание) А если серьезно, не анализировать систему в целом а на уровне 1 плк. Т.е. анализ программ. Я думаю мы отталкиваемся от разных начальных условий. Скажу про свои - хакер получил доступ к плк\ смог повлиять на работу плк и смог изменить значения. Но вот в чем проблема изменение одних параметров со стороны хакера никакой пользы не принесло, а вот изменение других принесло.

И почему не может быть ситуации когда modbusTCP будет смотреть в инет?

Скажите, а почему не может быть ситуации когда точно на сервер падает обломок метеорита, пробив три этажа перекрытий, и выносит исключительно сервер?
Я сам же и отвечу: такое действительно может быть. Но никто такого ещё не видел.

Вопрос в вероятности - найти в интернете плк с открытым 502 портом достаточно легко.

[Ivan69]

Давайте не будем переливать из пустого в порожнее, тут рядом 4 темы есть ровно с таким же содержанием. Нет физического доступа - нет взлома. Вот и вся защита.

но ведь в shodan можно найти достаточно разномастные плк, хотя актуален вопрос, что даже если хакер получит доступ к плк - всегда есть резервирование, либо возможности самой плк на влияние тех процесса достаточно ограничены.

Хотелось бы узнать, где это конкретно "всегда есть резервирование" и, извиняюсь за прямоту, на..зачем нужен ПЛК, не влияющий на техпроцесс? Притом резервированный!

Виноват непонятно выразился - говорил, о том что в программе на плк может много параметров - какие-то сильно влияют на пром процесс, какие-то меньше. Т.е. даже если хакер получит доступ к плк - не обязательно он сможет повлиять на тех процесс. В качестве подлянки хакер сможет задосить плк, но тогда вступает в дело резервный.

[Ivan69]

Можно еще один вопрос? Что такое "положительная обратная связь" в контексте безопасности АСУТП?

Конечно можно) Хакеру надо так скомбинировать влияние на плк (то бишь изменение набора параметров), чтобы нанести максимальный ушерб. Мне кажется как раз этот момент и отражает ПОС.

[Jackson]

Можно еще один вопрос? Что такое "положительная обратная связь" в контексте безопасности АСУТП?

Конечно можно) Хакеру надо так скомбинировать влияние на плк (то бишь изменение набора параметров), чтобы нанести максимальный ушерб. Мне кажется как раз этот момент и отражает ПОС.

Думаю, терминология сейчас многих удивит. :) Ну да ладно.

"...хотя, ты знаешь, мне кажется, я начал понимать, что ты имела в виду!" (с) песня

Давайте я обобщу чуток.

Конкретно о безопасности взлома. Почему-то Вы опасаетесь именно его, хотя интернет легко Вам подскажет какой % аварий произошел по этой причине (и вопрос должен автоматически сняться). Нет физического выхода в интернет и даже интранет - нет проблемы. Вообще. А там где выход в интернет есть, то поверьте, если кому-то очень понадобится сломать нужный контроллер - он его сломает.

Любая система защиты настолько эффективна, насколько она блокирует работоспособность объекта. Абсолютно 100%-эффективная система защиты на те же 100% блокирует объект, который в принципе не может функционировать. Пример: дверь, где самая эффективная мера защиты - вообще не делать проём, 100% защита, но зайти будет нельзя, а если есть всё-таки дверь с петлями и замками - они так или иначе вскрываются, вопрос времени и квалификации. Чем дороже Вы поставили дверь - тем больше будут Ваши убытки по её ремонту (и разочарование), когда её всё-таки вскроют. Вывод: дыры есть везде.

В широком смысле: надо из точки А как минимум видеть, что происходит с техпроцессом в точках Б, В, ... Между А и Б от несколько сотен км, между А и В океан (в буквальном смысле). Как максимум - иметь возможность ограниченно (но существенно) управлять. Чем кроме интернета их можно связать?

А не надо связывать, вот и всё. Вариант - голосовая телефонная связь, можно с видео. Я не поверю в то что на той стороне за океаном нет ни одной живой души.
И опять же вопрос: зачем?
Вот заказчик один выкатил претензию. Почему на корабле сигнал о снижении напряжения на шинах ГРЩ появляется на пульте на мостике лишь спустя 3 секунды после аварии в ЭС. Т.е. модель примерно та же что и Ваша: ГРЩ где-то ниже ватерлинии в корме, а мостик - высоко и ближе к носу (корабль боевой), это всё равно что из Москвы рулят цехом во Владивостоке, всё равно что океан. Возникает вопрос: "зачем? или ты не видишь что свет на мостике погас и переключился на аварийный, не слышишь что АДГ запустился, не слышишь что ИБП верещат как резанные? Если по всем этим признакам ты так и не понял что ГРЩ обесточился - ты всё равно ничего не поймёшь даже если получишь этот сигнал раньше аварии, тебе нечего делать на корабле вообще и на мостике в особенности, это сложное дорогостоящее оборудование, абы кому тут не место. И главное, для этого процесса плюс-минус три секунды - ничто, потому что время переходных процессов в корабельной ЭС - больше минуты. Если в бою что-то грохнуло и при этом погас свет - даже далёкий от корабля человек поймёт что ЭС накрылась. По какой конкретно причине - неважно, потому что там есть персонал и если он ещё жив то устранит так быстро как сможет, также и автоматика если жива и жив ГРЩ с генераторами - всё сделает сама и выведет ЭС из аварии. Если не вывели - значит и не выведут, и тебе с мостика туда бежать бесполезно, занимайся своим делом на мостике в условиях сложившейся обстановки." Примерно такого содержания ответ был дан заказчику, и возразить было нечего. Собственно до сих пор так и ходят по морю гражданские суда и боевые корабли только с телефонной связью между мостиком и электростанцией, на каждой стороне есть четкие инструкции в том числе и на нештатные ситуации, есть требования к технике. И всё в порядке. 99,9% всех аварий на море - человеческий фактор.

Так же и у Вас. Что-то изменится принципиально если картинку из точки А увидят в точке Б не через 10 секунд, а через 5 минут, и не по тыку кнопки а по телефонному звонку?

То есть, сложные технические задачи проще решить организационным, а не техническим способом.

Второй вариант: прямое соединение через GPRS-модем, которое инициирует модем с динамическим IP. Поднял связь, данные передал, разорвал. Сам модем работает в режиме OPC-сервера. Хочется поуправлять - шлите SMS. А номер телефона и формат команд говорить никому не надо. Если очень боязно - смените формат команд и делайте это периодически, и номер сменить тоже можно. Взлом возможен только при утечке информации о телефоне, кодах - а это снова проблема вовсе не техническая, а организационная. Проще говоря, как приготовить говядину по-гамбургски? - возьмите... и поезжайте в Гамбург.

Краткое резюме: разумный подход и разграничение задач на технические и организационные, значительно повышает безопасность, неразумное - наоборот снижает.

Человек, применяющий modbus подобным образом, или должен чётко представлять себе все недостатки и прочие особенности применяемого протокола, или не заниматься промышленной автоматикой вообще.
Подобно тому, как Вы или должны соблюдать ПДД, переходя улицу, или вообще сидеть дома. Опять же ради безопасности себя и других.
Но даже дома Вам придётся соблюдать определённые правила (протоколы) безопасности.

Вот именно!

Изучите особенности протокола Modbus-TCP, и тогда у Вас появится понимание об ограниченной совместимости Modbus-TCP и TCP/IP.

Да. Однако, я понимаю что автор пришел к нам и задал этот вопрос как раз потому, что не владеет вопросом, на то и форум. Но я особо обращаю внимание автора на то, что не надо лезть со своей терминологией и рассуждениями о том, как оно всё в АСУТП. Не надо и всё, иначе Вы так ничего и не узнаете.

[Exactamente]

>Может есть исследования на эту тему? Я искал и не нашёл. Надеюсь моя идея ясна
Мне не попадалось. По теме ИБ в АСУТП я видел только статьи Positive Technologies на хабре, про которых все здесь так негативно отзываются. Но у них никакой конкретики, только статистика "дцать процентов АСУТП уязвимы".

В случае с программой плк не представляю какое вообще может быть объективное исследование. Ну, ясное дело, если собрать показательную выборку хотя бы из сотни проектов, то ещё можно попытаться найти закономерности в построении логики ПО, и сказать, что с вероятностью ХХ% подмена %значения% приведёт к %последствиям%. Только кто сможет найти сто разных независимых проектов, это ж не шаблоны для вордпресса, которых в инете на развес и пачками.

Повторюсь, для начала возьмите хотя бы один, но конкретный проект (вот прям перед вами открыта IDE, а там код на STL или LD'шки), изучите (что уже фора перед мнимым хакером, у котрого не должно быть исходников) и взломайте его подручными средставми :) Если (когда?)) не получится - проанализируйте почему. По-моему, для диплома вполне достаточно, особенно, если получится.

>И опять же вопрос: зачем?
Я стараюсь решать задачу максимально своими силами - автоматика должна быть автоматизированной. А то там АСУТП, тут АСУТП, а обмен телеграммами :) Сами же говорите, человеческий фактор причина 99,9% аварий. Но в данном вопросе не столько аварии, сколько именно нужда управлять "отсюда" и именно независимо от "тамошнего" человеческого фактора. То есть завод "наш", а "там" на заводе "они", которые платят за пользование заводом. Такая интересная схема. Не я придумал :) Не знаю, чем закончится дело, и закончится ли в ближайшие годы, я над тем проектом уже не работаю)
upd: я про скаду в инет говорю, разумеется, плк далеко и глубоко спрятаны.

[Ryzhij]

Вопрос в вероятности - найти в интернете плк с открытым 502 портом достаточно легко.

Допустим, нашли Вы такой ПЛК.
Дальше что? Вы всерьёз полагаете, что по модбасу можно изменить программу в ПЛК?
Вам известна карта модбас? Открытый модбас-порт это ещё не возможность атаки сама по себе.
Вы представляете себе техпроцесс и знаете, по каким адресам что именно лежит? Без инсайдерской информации вероятность поражения системы ничтожно мала.
Кто-то настолько наивен, что по модбасу вообще, а не то что через инет, управляет техпроцессом или СПАЗ на ОПО? Идиоты в природе есть, не спорю, но там они не водятся.

Даже приборы КИП для мало-мальски серьёзных применений не позволяют без прохождения процедуры аутентификации менять свои настройки по полевой шине. И это при абсолютной необходимости физического доступа к оборудованию.

[Михайло]

Всем:
Потенциальный ущерб и необходимость мероприятий по защите информации зависит от реального объекта. Сейчас каждый подумал о своем текущем объекте и говорит соответственно каждый о своем.

Конечно можно) Хакеру надо так скомбинировать влияние на плк (то бишь изменение набора параметров), чтобы нанести максимальный ушерб. Мне кажется как раз этот момент и отражает ПОС.

Не всегда. Некоторым более реальным хакерам нужно остаться незамеченным. Допустим, когда хакер приворовывает продукцию предприятия... Ущерб он не стремится максимизировать.
Ну а ПОС - это термин из теории линейных систем... Умный термин.

[VADR]

Кто-то настолько наивен, что по модбасу вообще, а не то что через инет, управляет техпроцессом или СПАЗ на ОПО?

Тут имеется в виду конкретно modbus tcp или любой modbus? Управления через modbus - сколько угодно, в том числе и на опасных объектах. Те же частотники, подключаемые по modbus rtu - совершенно обычное явление. В защитах - да, нечего делать, но (к примеру) обмен данными между собственно АСУТП и СПАЗ через modbus - тоже обычное явление.

[Ryzhij]

Кто-то настолько наивен, что по модбасу вообще, а не то что через инет, управляет техпроцессом или СПАЗ на ОПО?

Тут имеется в виду конкретно modbus tcp или любой modbus? Управления через modbus - сколько угодно, в том числе и на опасных объектах. Те же частотники, подключаемые по modbus rtu - совершенно обычное явление. В защитах - да, нечего делать, но (к примеру) обмен данными между собственно АСУТП и СПАЗ через modbus - тоже обычное явление.

Как обычно, предлагаю сначала определиться с терминами.
По моим представлениям СПАЗ наряду с САУ и ЧМИ (или даже SCADA) является составной частью АСУТП.
Поэтому ИМХО правильнее было бы говорить об использовани modbus внутри АСУТП на ОПО.
При этом очевидно, что внутри любой АСУТП есть контура управления влияющие на опасность производства в разной степени. Почему бы не управлять из РСУ через modbus, скажем, системами АВОК?

Меня вот тут на днях склоняли к тому, чтобы реализовать из РСУ по существующей сети модбас на ОПО управление контурами регулирования в ручном режиме, передавать в локальный ПЛК уставки и команды управления блокировками ПАЗ. Пришлось проводить среди технологов лик.без. по промышленным сетям.
В настоящее время по modbus там выводятся данные в РСУ для индикации и регистрации.
Пуркуа бы и не па?

Для более серьёзных задач потребуется организация более серьёзной сети и соответствующие вложения.

[quq]

...возникает вопрос а реальны ли угрозы?

Да.

факт остаётся фактом - АСУ перестают быть изолированными от внешнего мира.

Согласен.
1 969 финских SCADA-систем доступны в интернете.
Следует различать
1. целенаправленный взлом
2. случайно "попал под раздачу".
В первом случае поможет только когда стоимость затрат на взлом защищённой системы более стоимости полученных результатов (обратная теорема: стоимость защиты д.б. сравнима с потерями от взолма).
В втором случае (мой случай: Через полгода после появления публикаций о Stuxnet, притащили флешку с докуметами, на которой он был)помогут меры защиты, установленные приказом ФСТЭК от 14 марта 2014 г. № 31, с требованиями ведущих отраслевых стандартов.