Не споря с его важностью, хотелось бы показать неверность выбранного многими интеграторами пути. Что они обычно делают и предлагают с точки зрения своего портфолио? Пентесты и иные анологичные продукты и услуги, связанные с сетевой составляющей АСУ ТП. Это безусловно важно; особенно учитывая, что многие вендоры предлагают решения по защите АСУ ТП (например, Cisco предлагает систему предотвращения вторжений для SCADA), но достаточно ли? И немаловажный вопрос — нужно ли это заказчикам?
Для этого надо ответить себе на вопрос, что такое современная система, обслуживающая критически важный объект? Есть неплохая обзорная иллюстрация, показывающая взаимосвязь элементов современной АСУ ТП. По вертикали их 3:
- Сетевой уровень, представленный протоколом IP, который сейчас повсеместно используется в решениях АСУ ТП большинства зарубежных и отечественных вендоров.
- Уровень Middleware, как я его называю. Это то, что касается «родных» АСУ ТПшных вопросов — контроллеры, сенсоры, управляющее ПО и т.д. Сюда же можно отнести и общесистемное ПО, которое используется на компонентах АСУ ТП.
- Бизнес-уровень, отвечающий как за формирование различной отчетности по различным срезам работы АСУ ТП, так и управление ею (отгрузить столько-то руды, заполнить цистерну на столько-то и т.д.).
3 уровня, объединенные на иллюстрации в «цистерну», являются локальными и могут быт развернуты на одной площадке. Если таких площадок множество, то у нас проявляется 4-й компонент, отвечающий за взаимодействие всех элементов.
А теперь, собственно, о том, что и как делают интеграторы в России. Они концентрируются только на сетевом уровне. Это очевидно — защита на сетевом уровне более проста и понятна. Протокол IP знаком многим; средства его защиты в лице межсетевых экранов и IPS тоже известны. Что может быть проще, чем взять уже известный продукт и выдать его за средство защиты АСУ ТП? Хорошо, если он поддерживает специфические для АСУ ТП протоколы (например, DNP3, Modbus и т.д.). Но если нет, то тоже ничего 😉 Правда, тут возникает задача правильного внедрения решений для защиты АСУ ТП. Ведь между ними существует очень серьезная разница. Можно воспользоваться рекомендациями вендоров по дизайну системы защиты для АСУ ТП (например, от Cisco), но про такие дизайны еще надо знать.
Но очевидно, что только защитой сетевого уровня дело не ограничивается. Пример с Stuxnet показал, что защиты только на уровне сети не достаточно. Но адекватных решений на этом уровне почти нет ;-( Касперский давно пытается создать свою ОС для решения таких задач, но пока до готового и тиражируемого продукта дело не дошло. А ведь им еще надо заинтересовать производителей решений для АСУ ТП.
С уровнем взаимодействия более менее все понятно — технологии обеспечения конфиденциальности и целостности существуют давно. А вопрос их соответствия требованиям ФСБ к СКЗИ я поднимать не буду преднамеренно 😉
Но самое интересное заключается в другом — в России защита этих уровней не так востребована, как это кажется интеграторам, предлагающим защиту именно их. Многих заказчиков волнует совершенно другой вопрос. А как мне предотвратить кражу пары составов с рудой, которую может провернуть привилегированный пользователь системы управления цепочками поставок? А вы можете отследить на каком звене цепочки доставки нефтепродукта от нефтехранилища по нефтепроводу до нефтеперерабатывающего завода (принадлежащих зачастую разным юрлицам) произошла кража нефтепродукта? Или еще один из вопросов, который могут задать, когда возникнет тема «защиты АСУ ТП» (под которой понимают очень много различных задач, не всегда впрямую связанных с самой АСУ ТП). А вы можете нам помочь отследить операторов-мошенников, которые несанкционированно изменяют маршруты транспортировки бензина в системе контроля передвижения опасных грузов через ГЛОНАСС/GPS? Или вот еще. Как можно обнаружить модификацию ПО, отвечающее за сигнализацию о падении давления в магистральном трубопроводе (по снижению давления можно определить наличие и примерное местоположение незаконной врезки в трубу).И как защищаться от таких инцидентов?
Решить такие задачи очень непросто, т.к. требуется досконально знать, как работает та или иная система на уровне ее бизнес-логики. Инструментов для обнаружения инцидентов на бизнес-уровне немного и можно пересчитать по пальцам одной руки. Например, Appercut Security (и то с оговорками и доработками). Но это именно то, что нужно потребителю и то, на чем он теряет деньги, несопоставимые с ущербом от других видов инцидентов. Точнее это реальные деньги, которых недополучает владелец критически важного объекта. В отличие от вирусных эпедимей, простоев от DoS-атак, утечек информации, ущерб от которых еще надо посчитать и обосновать.
Возможно ситуация со временем поменяется. Если документ СовБеза начнут претворять в жизнь, то акценты могут и сместиться в сторону первых двух описанный мной уровней. Ведь Совету Безопасности по сути все равно — сколько денег не досчитается конкретный владелец критически важного объекта. А вот инцидент, который может повлиять на национальную безопасность, привести к чрезвычайной ситуации, сделать невозможным оказание какой-либо услуги в час Х и т.п. их волнует гораздо больше и поэтому их документы, скорее всего, будут описывать то, что описывают почти все современные стандарты безопасности АСУ ТП — традиционные вопросы защиты — обеспечение доступности, конфиденциальности, целостности компонентов АСУ ТП на нижних уровнях; закрывая глаза на верхний. И потребитель задумается о решении и этой задачи только тогда, когда число инцидентов применения кибероружия увеличится многократно (и именно в России) или когда за невыполнение требований нормативных документов будут выставляться реальные и значительные штрафы.
Пока же потребитель подходит к вопросу защиты АСУ ТП с точки зрения риск-ориентированного подхода (за что было бы глупо его ругать) и требует совершенно не тех средств и услуг защиты АСУ ТП, которые ему пытаются предлагать интеграторы и вендоры. А может я ошибаюсь и есть интеграторы, которые учитывают то, что я написал?
PS. Помимо ИнфоБЕРЕГа на тему АСУ ТП буду также выступать 3-го октября на круглом столе в рамках «Инфобезопасности«.
Умные интеграторы на рынке есть, и они (мы :)) стараемся подобные моменты учитывать. Однако, пока что в наибольшем количестве случаев клиентов в РФ уровень бизнес-логики в КСИИ АСУ ТП не стандартизован и закрыт от взаимодействия — не имеет никаких внятных интерфейсов. А заказчик чаще всего не готов его перестраивать на чем-либо более унифицированном.
Конечно, когда задача защиты КСИИ возникает до момента создания бизнеса, такой проблемы нет, но за мой ~10летний опыт в интеграции я помню ровно один случай, когда заказчик пришел к нам, как к интеграторам, до того, как построил бизнес-логику.
Согласен с pLuto. Тем более что внятной унификации бизнес-логики не получится в принципе — слишком разные ставятся задачи к конкретно взятой АСУТП и ее логике работы.
А что касается защиты АСУТП: передовой международный опыт Вы исследовали?
Сдается мне такая "прелесть" с защитой есть у всех…
На Инфоберег-2010 был мой доклад по результатам неправильного применения средств защиты информации в системе управления компрессорным оборудованием с демонстрацией результатов. За два года производитель систем управления ничего не сделал для изменения ситуации.
Описанную проблематику можно перефразировать: Интегратор что умеет то и продает…
Попытки применения "академического подхода", как мне говорят, не плодотворны по двум причинам:
1 — необходимо "дотягивать" возможности Интегратора на новый уровень;
2 — необходимо "дотягивать" реализацию АСУ ТП, что в рыночных условиях невозможно.
количество грамматических ошибок говорит о спешке… надо тэг специальный ставить о том, что пост проплачен. 🙂
Ага. Получил деньги от НАИБАЛ
Интеграторы, как правило, обеспечивают соответствие требованиям, поэтому таков их подход.
Безопасностью самих систем должны таки заниматься разработчики и эксплуататоры.
ИМХО, правильный подход к защите АСУ ТП очень наглядно и убедительно демонстрирует слайд Вашего коллеги "Безопасность — это не опция" (который с автомобилями).
Говоришь: "Многих заказчиков волнует совершенно другой вопрос. А как мне предотвратить кражу пары составов с рудой…" Но это не вопрос безопасности АСУТП, а вопрос о дополнительных инструментах экономической безопасности. А в АСУТП больше всего их волнует возможность несанкционированного управления технологическими процессами. И pentest является самой популярной услугой потому, что далеко не всегда заказчик всерьез верит, что это возможно, и потом искренне удивляется, когда все взламывается элементарно через незащищенный удаленный доступ, используя банально слабую парольную защиту (к примеру пароли по умолчанию в приложениях), даже не доходя до уровня уязвимостей в технологическом ПО с его STUXNET-ами и пр.хр.
Так что нечего в интеграторов (нас) грязью кидаться 🙂 Ну у нас тобой еще интересный Инфобез впереди, поговорим 🙂
Критика подхода к защите АСУ ТП обоснована, но лишь частично, так как сама не учитывает специфику отрасли, что инкриминирует интеграторам.
Продают те услуги, которые пользуются спросом. Если бы владельцы АСУ ТП были бы действительно обеспокоены указанными проблемами, то и услуги соответствующие бы появились — спрос рождает предложение. Но у нас большая часть предприятий и заводов в гробу видела безопасность этих систем и хочет выполнить обязательные требования и работать спокойно дальше (инфа от общения с ними же). Да, изредка попадаются фанатики, которые знают и хотят безопасность "по правилам" и с учетом требований Cisco и NIST и т.д. вот только все это заканчивается сразу же, когда они понимают, что и самим нужно будет сопровождать СУИБ, реализовывать и поддерживать соответствующие процессы. Не надо строить иллюзий, что интегратор придет весь в белом и на коне и за N миллионов сделает хорошо раз и навсегда.
Защита сети — основа, понятная и нужная и в условиях всех зоопарков АСУ ТП от разных производителей самое эффективное и простое, что нужно сделать, поэтому данная услуга и есть у всех в портфолио. Кстати и в руководствах Cisco фактически только о защищенной сетевой архитектуре и говорится + некоторые общие принципы 😉 То же самое с анализом защищенности.
А вот когда начинаем смотреть глубже в специфику области, то начинается самое веселое: многие вендоры АСУ ТП просто запрещают что-то модифицировать и устанавливать средства защиты (включая антивирусы) и сами организации ни в какую не поддаются, с установкой обновлений такая же ситуация, в коде ПО ковыряться никто не даст (так что не совсем понятны ссылки на продукт от Appercut Security), более того, сам заказчик не понимает зачем вообще там что-то защищать, а в добавок ко всему за АСУ ТП отвечает отдельное подразделение, которое знать не знает про ИБ и вообще никого не подпускает к своим системам, а уж что говорить про реализацию нормальных процессов управления ИБ.
Вот и остается в основном то, что можно навесить отдельно к сети и аккуратно на бизнес-зону антивирусы и т.д. Да, ещё остаются специфические поделки типа продукции Modcon или отечественного Щита, но и на них организации смотрят скептически, так как "формально не требуется".
Приведенные в заметке проблемы — скорее вопрос мониторинга транзакций и контроля самих процессов на уровне ПО и данных. Но не могу согласиться, что это действительно самая важная проблема ИБ. Мониторинг и сопровождение системы, реагирование на инциденты и действия в чрезвычайных ситуациях на мой взгляд самая важная тема для АСУ ТП и именно ей уделяется внимание в международных стандартах.
В общем, выпад хороший, но скорее мимо
Кстати, обелить интеграторов не пытаюсь, так как не по наслышке знаю как они могут зачастую лажать, кто-то из-за обстоятельств, кто-то в целом 🙂
Алексей, а чтобы не быть голословным про интеграторов — можете примеры привести кто и что конкретно предлагает? Как-то безосновательно получается "многими интеграторами" и "обычно делают и предлагают". С примерами будет более предметно и информативно.
И уж если говорить про реальные риски, давайте вспомним персональные данные, которые все вот уже 4 года как защищают навешиванием мегатонн разных СЗИ, которые в реальности мало помогают (ну или решают те самые 20% вопросов, а платить за них нужно 80% денег). И судя по всему такая ситуация выгодна всем.
Защита АСУ ТП — дело, видимо, непростое. И обвинять интеграторов в "не комплексном" подходе на данный момент времени, когда все это только зарождается, не совсем корректно.
Хорошо. Давайте считать, что российские интеграторы все прекрасно понимают. Это клиенты, как обычно, не знают, что хотят и требуют того, что им не надо и вообще к ИБ не относится. Пусть так.
Да кто же говорит, что они все знают. Ситуация сейчас такая — направление это у нас пока что молодое. Вопрос в другом — как можно изменить ситуацию.
И, кстати, по поводу клиентов. По моему опыту (именно в части защиты АСУТП) они действительно плохо понимают, что им нужно. Может, клиенты, конечно не те.
Но нужно констатировать, что пока не будет построен диалог "клиент — регулятор — поставщики услуг", рынок не сформируется.
Сейчас ведь начнется — сообщество профессионалов по защите АСУТП, SCADA Security Russia, отдельные направления у крупных интеграторов, нормативные акты от ФСТЭК и ФСБ, длинные вопросы в их стороны в рамках каких-нибудь РусКрипто и тому подобное.
Вот как начнется, так и можно будет говорить о том, кто что предлагает и зачем все это нужно.