Как стать автором
Обновить

Комментарии 22

Спасибо за статью.

Возник вопсрос откуда взялась статистика? Можно линк?
А также линки на «vulnerability database» и «exploit pack»?
Базы знаний по уязвимостям:

ICS-CERT,
NVD,
CVE,
Bugtraq,
OSVDB,
Mitre Oval Repositories,
exploit-db,
Siemens Product CERT.

Сборники эксплойтов:
SAINTexploit,
Metasploit Framework,
Immunity Canvas,
Agora Pack,
Agora SCADA+,
D2 Exploit Pack,
White Phosphorus exploit pack,
VulnDisco Exploit Pack.

линки на каждый из них можно легко нагуглить :)
Блин, «эксперты»…
У меня вот вопрос к автору, а Вы вообще представляете из чего состоят современные АСУ ТП?
Почти треть уязвимостей (36%) связана с переполнением буфера (Buffer Overflow).

Буфера чего? HMI, SCADA, PLC?? У меня такое ощущение, что термины услышали, а что они именно означают как бы не поняли.
… составляющие АСУ ТП, как SCADA и человеко-машинного интерфейс (HMI)
То есть SCADA — это часть АСУ ТП, так? А что такое SCADA?
Ну и конечно написать про сегмент компаний по объявлениям в hh.ru, это вообще жесть… Где такие компании как Honeywell??
Прошу прощения за резкую критику, но я уверен, что перед написанием статьи надо разобраться в предмете, либо вообще не писать…
Вообще от себя хочу добавить, что писать подобную статью надо вдумчиво, опираясь на конкретные случаи, а уж не hh.ru, и хочу добавить, что я на своей практике не встречался ни с одной АСУ ТП, которая бы смотрела напрямую в интернет, даже не слышал о таком…
За торчащие наружу элементы, касающиеся внутренней инфраструктуры, управления, и того, что обычно подразумевают, говоря про SCADA надо увольнять администраторов системы, проектировщиков инфраструктуры и сети, офицеров ИТ безопасности и ИТ руководителей, как несущих ответственность и допустивших такое.
Как минимум списки доступа, ограничивающие подключения, как максимум — vpn и менеджмент станции, находящиеся где-то глубоко внутри закрытые для доступа только с рабочих станций операторов.
Не говоря уже об полностью отдельной сетевой инфраструктуре для объектов техпроцесса, куда физически можно попасть пройдя все контуры физической безопасности досмотры и сдавания телефонов/флешек/фотиков и прочей аппаратуры
Эмм… это мягко говоря — слабо реализуемо на практике
Суть проблемы
передает статья на лурке «всем по...» применительно к начальству, не желающему выделять денег на отдельную инфраструктуру для АСУТП предприятия. В итоге имеем систему безопасности держащуюся на честном слове админов.

Можно максимально предохраняться, но с внешним миром (сетью предприятия) сообщаться необходимо. Другой вопрос, что сделать это можно по разному. Я могу реализовать, что с моих систем в реальном времени в сети можно будет видеть информацию о техпроцессе. Но это будет просто набор данных выведенных в html. Все, моя асутп видна в интернете.
Про Honeywell автор статьи таки забыл. А у них весьма крупный кусок рынка, особенно касаемо нефтехимии. А еще Yokagava, Foxboro, Emerson. В общем пропустил крупнейших производителей DCS систем.
Emerson в исследовании есть, по остальным – мы брали только производителей для которых существуют опубликованные уязвимости.
Зря заминусовали, автор коммента то прав :)
В России уязвима ровно половина доступных извне систем АСУ ТП.
Интересно, не означает ли это «одна из двух»? :-) Приведите хотя бы одну абсолютную цифру (например, общее количество доступных через Интернет систем в штуках).
Тоже было бы интересно увидеть абсолютные показатели. С раскладом по тому, что там именно выведено в Интернет. Потому что если речь просто о некоей визуализации — то при грамотной реализации это может и странно, но еще не криминал.
С АСУТП может все и плохо в плане ИБ, но и с пониманием этого у руководства не все так плачевно, как обычно представляют. Часто воздушный зазор. Что? Профессиональные ИБ-шники хитро заухмылялись, намекая на другие каналы, типа флоппинета, usb модемов, левых вайфай точек? Не все и не всегда такие идиоты на производстве, что бы этих простых вещей не понимать и не принимать хотя бы минимальных организационных мер по противодействию.
Организационные меры — это, конечно, прекрасно, вот только не надо недооценивать идиотов. Точнее, не идиотов, а просто необразованных в этом плане людей.
Кроме того, есть банальные флешки с вирусами (если правильно помню, Stuxnet таким образом распространялся). Так что воздушный зазор а) не панацея, б) не всегда возможен (безопасность не должна нарушать или серьезно усложнять бизнес-процессы).
Ну да, а про флешки никто не понимает. Только господа с презентаций и форумов по ИБ.
Про воздушный зазор — написал предельно ясно, понимание канала в широком смысле, а не только сетевом у людей есть чаще всего.
На счет идиотов. Если оператор технологического процесса — идиот, вам не поможет никакая система защиты. Это критичное рабочее место, от вменяемости персонала на этом месте много чего зависит, вплоть до жизни и здоровья людей. Если там идиот или в доску безграмотный человек — не надо никакого стакснета, этот человек и так вам устроит веселую жизнь.
На счет не всегда возможен — да, есть такая тенденция, как стык АСУТП и АСУП, что бы АСУП данными кормить и далее модные словечки типа ERP, OLAP и прочее. Но в АСУТП система системе рознь. Те системы, где возможно управляющее воздействие со всеми вытекающими очень часто именно изолированы. А данные на верхний уровень для управленцев другие системы выдают, которые к взлому не столь критичны.
Да, действительно, интеграция с MES и ERP может приносить неприятные сюрпризы, например такие Что касается изоляции, она зачастую достаточно условна. Пример из жизни: на энергогенерирующем предприятии для загрузки проекта на SCADA/PLC необходимо использовать токен для авторизации. Иначе никак. Однако PLC внезапно доступен по telnet/ftp с root: и можно просто заливать туда что душе угодно. Тот же проект, например, с приятными сердцу модификациями
Да, телнет/фтп-доступ вещь неприятная. Но при изоляции всей системы от общей ЛВС кто этим может воспользоваться?

1. Инсайдер дядя Вася. Но он или тот, кто эти проекты ваяет, и ему не надо ломать самого себя. В этом случае и так все держится на доверии ему. Или это оператор, который, если очень захочет… много чего может и без телнет/фтп, у него это все под боком, включая ПАЗ, которую он может… кхм, не будем об этом.

2. Вирь, зловредный код. И вот тут встает вопрос о канале его попадания в закрытую сеть. Изоляцию сетевую хоть и обозвали условной, но она есть. Остаются флешки, ноуты. Это люди более менее понимают. Когда подрядчик со своим ноутом — могут и просто не пустить в сетку с собственным девайсом. И флешку свою воткнуть не дадут на какую-нибудь инженерную станцию. А если вдруг припрет и придется — устроят ТО на вшивость после ухода. Да, это все не панацеи, просто уровень шумихи вокруг АСУТП в последнее время зашкаливает, но только от части оправданно. Я понимаю, коньюнктура. Закончат с ПДН, возьмутся за КСИИ, рамочные документы уже есть, векторы обозначены.
Спасибо.
Цель аналитики не абсолютные цифры (мы приводим процентные доли), к тому же просканировать весь интернет смысла нет. Методика поиска систем описана в исследовании (Google, ShoudanHQ ERIPP и т.д.).

Вообще в тексте исследования (со страницы 24) приводится достаточно большое количество показателей.
Я прошу прощение, но с типами уязвимостей надо срочно что-то делать.
Переполнение буфера эта вышедший из под контроля программы процесс манипуляции с данными в памяти. Выполнение кода (а может просто DoS) это, как вариант, последствия переполнения, а WEB-сервер это элемент архитектуры приложения…
Иными словами сложили теплое с мягким и красным и получили 100%… бывает наверное и такое.
К сожалению не всегда получается однозначно классифицировать уязвимость на основе существующего описания.
Кроме того, количество уязвимостей в ICS не так велико, чтобы можно было использовать более детальную классификацию, как CWE. Поэтому мы укрупнили до использованной в исследовании.

Buffer overflow – манипуляция памяти, когда последствия непонятны
Remote Code Execution – явно приводят к выполнению кода
Web (Server/Client) – согласно WASC/OWASP соответственно

Ну и далее. Отдельно выделили проблемы управления «секретами», поскольку их очень много, практически 23%. С нашей точки зрения это показывает насколько мало задумывались о безопасности при проектировании SCADA и прочих, поскольку в большинстве случаев это архитектурный баг.
Просмотрел до первого графика и понял, что дальше читать не стоит, извините. Сравнивать в одном графике ПО различных уровней и предназначения глупо, как, в принципе совершенно безумно брать статистику с hh.

По моему опыту отрасль автоматизации закрытая, поэтому очень сомневаюсь в достоверности приводимых данных.

От спецов с АСУТПшного форума (http://asutpforum.ru/viewtopic.php?f=11&t=3239) ответ авторам статьи в виде анекдота:

Шотландский пастух пасет овец на изумрудно-зелёном поле. Вдруг к краю поля подлетает «Мерседес» последней модели, из него выскакивает молодой человек в шикарном костюме и с Rolex'ом на руке, подходит к пастуху и говорит: «Я могу помочь тебе в твоём деле».
«Что ж, давай!» — отвечает пастух.
Молодой человек достает из машины ноутбук, вытягивает антенны и начинает работать. Он получает снимки со спутников, обрабатывает их, делает какие-то сложные расчёты, беспрестанно звонит важным людям и экспертам в разных областях, и в конце концов вытаскивает цветной принтер, печатает красивый толстый отчёт, тут же его сброшюровывает, подходит к пастуху и говорит:
«Вот, держи. Я вычислил: принимая во внимание все имеющиеся факторы, оптимальный размер твоего стада — 156 овец. А у тебя их 157! Это портит весь твой бизнес! Я одну овцу заберу, и всё наладится».
Молодой человек хватает овцу и начинает запихивать её в багажник «Мерседеса».
В этот момент пастух его окликает:
«Послушай, дружок, ты, должно быть, из PriceWaterhouseCoopers?»
«А как ты догадался?!»
«Очень просто. Во-первых, тебя никто не звал, ты сам пришёл. Во-вторых, ты работал целый день и дал мне ответ на вопрос, на который я и сам знаю ответ. А в-третьих, отдай МОЮ СОБАКУ, кретин! Ты в моём бизнесе ничего не понимаешь!»
Зарегистрируйтесь на Хабре , чтобы оставить комментарий