16 октября, 2012
ЛК пишет свою операционную систему? Подтверждаем слухи и опровергаем домыслы!
Привет всем!
Сегодня поговорим о будущем. О мрачном будущем массированных кибератак на атомные электростанции, системы управления энергоснабжением и транспортом, финансовые и телекоммуникационные системы и в целом то, что мы называем критически важными объектами. Если проще – о сценарии, показанном в четвертом «Крепком Орешке», когда атака на объекты инфраструктуры повергает в хаос чуть ли не всю страну.
Увы, решить проблему уязвимости промышленных систем методами Джона Макклейна не получится. Но мы работаем и над технологиями, а конкретно – над защищенной операционной системой, предназначенной именно для критически важных информационных систем (Industrial Control Systems, ICS). Слухов об этом проекте в сети появилось достаточно и поэтому мы решили немного приоткрыть завесу тайны и рассказать, что же на самом деле происходит.
Но сначала – немного о том, как мы докатились до такой жизни, и зачем собственно нужна такая «ось»?
Беззащитность индустриальных систем
У промышленных информационных систем и обычных, скажем, офисных компьютерных сетей, несмотря на их кажущееся сходство, совершенно разные приоритеты в плане безопасности и функционирования. В обычных компаниях важнее всего конфиденциальность информации. Например, если на корпоративном файловом сервере обнаружили троян, проще отключить зараженную систему от сети и потом уже разбираться с проблемой. В промышленной информационной системе так сделать не получится, так как здесь самый высокий приоритет имеет сохранение работоспособности. На заводе любой ценой, и в первую очередь, обеспечивается непрерывность производства, а уж после этого думают о защите.
К чему это приводит? К тому, что чаще всего софт на работающем объекте обновляется только после тщательной проверки, а иногда и не обновляется вовсе, оставаясь неизменным десятки лет. Обновление ПО может быть и прямо запрещено политикой безопасности на конкретном предприятии. Но даже если возможность обновить софт и залатать дыры есть, это не всегда помогает. Дело в том, что производители такого специализированного ПО мало заинтересованы в постоянных исследованиях исходного кода и латании дыр. Как показывает практика, на этом обычно стараются сэкономить, выпуская «заплатки», только если в сети уже обнаружен и действует некий эксплойт. Если честно, это высказывание верно не только для специализированного, но и для обычного ПО, но сегодня мы говорим именно о промышленном софте.
Дальше проблема заключается вот в чем: уязвимость управляющего ПО, программируемых контроллеров, промышленных сетей связи приводит к тому, что у оператора условной промышленной системы на самом деле нет средств получения заведомо правдивой информации о её работе! Теоретически возможна ситуация, когда, допустим, атакуется система распределения электроэнергии, в результате чего где-то на отдалённом объекте происходит авария. Контролёр или оператор об этом даже не подозревают: атакующие выводят на их компьютеры заведомо ложную информацию.
Показательные примеры
Звучит знакомо? Ничего удивительного — за примерами далеко ходить не надо. Оригинальный способ, который, по сути, был самым настоящим киберсаботажем и заключался в прямой атаке на систему SCADA, случился в 2000 году в Австралии. Работник контрактной компании, работавший над системой контроля очистительной системы Maroochy Shire Council в ходе 46(!) атак делал так, что насосы не работали вообще или работали не так, как надо. Никто не мог понять, что происходит — коммуникация внутри системы была нарушена. Только спустя месяцы компании и властям удалось разобраться, что произошло. Оказывается парень очень хотел получить работу в очистительной компании, а в результате затопил нечистотами огромную территорию штата Квинсленд.
На самом деле таких примеров достаточно – просто большинство из них остаются за рамками статей в СМИ. Пострадавшие компании вполне резонно стараются не придавать дела огласке. О многих инцидентах не догадываются даже они сами. Вот недавно в промышленных роутерах RuggedCom была обнаружена «дыра«, которая позволяла простому пользователю запросто повысить свои привилегии до администратора и получить контроль над устройством. Кто, когда, как и где ей смог воспользоваться – можно только догадываться. Для саморазвития ещё рекомендую почитать про успешные атаки на ICS здесь, здесь и здесь.
Давайте подумаем, кому ещё кроме шантажиста-работника доступны исходные коды управляющего ПО, контроллеров, операционной системы и всего прочего? Правильно, «компетентным органам», иными словами – государственным структурам. Именно тем, которые одним своим отделом сертифицируют ПО для работы в критически важных системах, а другим – разрабатывают (с относительно недавних пор) кибероружие для атаки систем противника. Примеры: Stuxnet и последовавшие за ним Duqu, Flame и Gauss – проекты настолько сложные, что возможны только при технической и финансовой поддержке очень мощных субъектов. И не важно, кто кому угрожает в настоящий момент, важно то, что такие кибервооружения разрабатываются и применяются. Пусть не всеми странами и не против всех, но будучи открытым этот «ящик Пандоры» уже не закроешь: вооружаться для атаки на ключевые объекты противника рано или поздно станут все. Самая большая угроза исходит не от обычной кибершпаны и даже не от организованного кибер-криминала, а от создателей кибероружия.
Защита сейчас: увы, неэффективная
Вооружаясь, компании и государства не забывают и о защите. Причем защищаться, в принципе, они начали уже давно, вопрос в том, как они это делают? Реально используемых методов – два. Первое – изоляция критически важных объектов: отключение их от Интернета или физическая изоляция от внешнего мира каким-то другим способом. Однако, как показывает практика, если оператор на объекте захочет в ночную смену посмотреть на управляющем ПК фильмы с зараженной флэшки – его ничто не остановит (у нас есть работающие способы блокирования таких попыток, но сейчас не об этом). Второе – секретность. Коллективные и масштабные попытки закрыть все и вся. Разработчики ICS-систем держат в тайне исходные коды, владельцы заводов и объектов инфраструктуры ставят гриф «секретно» на характеристики информационных систем, типы используемого ПО и прочее. Увы, забывая при этом, что информация об уязвимостях в большинстве популярных систем SCADA есть в открытом доступе в сети. Копаем глубже: уже несколько лет существует открытый поисковик SHODAN, заточенный в том числе и на поиск уязвимых промышленных систем (в том числе SCADA-систем), чьи хозяева додумались подключить их к Интернету.
Параллельно специалисты компаний держат на вооружении и традиционные методы защиты заведомо уязвимого софта и операционной системы: и в том, и в другом случае безопасность можно повысить путём контроля как над программами, так и над действиями операторов. Но стопроцентную гарантию защищённости такие методы не обеспечивают, опять же в силу заведомой дырявости того, что предполагается контролировать. А в случае с критически важными узлами гарантия должна быть. Вопрос – на что именно?
Защита как она должна быть
Конечно, было бы идеально взять и переписать весь «промышленный» софт. С учётом наработанных техник безопасной разработки и новых реалий кибер-атак. Увы, это долгий титанический труд, сопряжённый с огромными вложениями в тестирование и отладку, которые всё равно не гарантируют достаточно устойчивую работу системы.
Но есть вполне реализуемая альтернатива — защищённая операционная система, на которой как раз и будут «крутиться» ICS-системы, которую можно встроить в существующую инфраструктуру, контролирующую «здоровье» существующих систем и гарантирующую получение достоверной информации.
Сначала отвечу на самый очевидный вопрос: как у нас получится создать защищённую ОСь, если это не получилось ни у Microsoft, ни у Apple, ни у опенсорсного комьюнити? Все просто. Во-первых, наша система – узкоспециализированная, она разрабатывается для решения конкретной задачи, и не предназначена для игры в Half-Life, редактирования видео или общения в соцсетях. Во-вторых, мы работаем над методом написания ПО, которое в принципе (by design) не будет способно выполнять незаявленную в нем функциональность. Этот момент – самый важный: невозможность выполнения стороннего кода, взлома системы или программ в нашем проекте – это вещь доказываемая и проверяемая.
Подробнее о системе, требованиях к ней и предпосылках к ее разработке вы можете прочитать в здесь. Я же в заключение хочу предвосхитить множество вопросов от коллег, партнёров, СМИ и просто заинтересованных людей. Разработка по-настоящему безопасной среды – проект сложный, практически невыполнимый без активной работы с потенциальными заказчиками. Множество деталей этого проекта мы сейчас не можем раскрыть как раз по причине такого сотрудничества. О чём-то не хотим рассказывать, чтобы технологии не перехватили конкуренты. А кое-что останется в закрытом доступе только для заказчиков навсегда по соображениям защиты от кибер-терроризма. Но как только возможность появится – мы расскажем что сможем о проекте подробнее.
На связи!