Как не пустить киберугрозы в физический мир и при чем тут бизнес-мышление

Угрозы переходят в физический мир

Риски кибербезопасности для бизнеса растут не только потому, что хакеры совершают все больше атак, а сами атаки усложняются. Дело в конвергентности: угрозы перетекают из цифрового в физический мир. Если раньше злоумышленники могли похитить деньги, данные или зашифровать информацию, то теперь они способны разогнать автомобиль, включить или перепрограммировать станок, вмешаться в работу целого промышленного объекта.

Это подтверждает статистика компаний, которые подвергались атакам в 2023 году. Жертвы киберпреступлений, совершенных в первом полугодии, сообщали о физических последствиях только в 18% случаев. Во втором полугодии это число выросло более чем вдвое — до 37,5%. Причем такая тенденция наблюдается уже несколько лет. Подобные атаки приводят к остановкам производств или нарушениям поставок продукции, а в некоторых случаях — к убыткам на сотни миллионов долларов и закрытию бизнесов. Причем киберпреступники все чаще выбирают крупные организации, способные заплатить большой выкуп.

Список потенциально уязвимых компаний расширяется вместе с масштабами цифровизации и распространения интернета вещей (IoT), в том числе индустриального (IIoT). Многие промышленные системы становятся доступны через интернет, а это один из самых простых путей проникновения для хакеров.

В 2020 году количество IoT-подключений в мире превысило число всех остальных соединений. К 2027 году, как ожидают эксперты IoT Analytics, в мире будет более 29 млрд IoT-подключений — в основном через Wi-Fi, Bluetooth и сотовые стандарты связи, включая разворачивающийся 5G. «Одно слабое звено — например, скомпрометированное устройство IoT — может поставить под угрозу безопасность всей сети», — предупреждают эксперты Всемирного экономического форума.

Алексей Матюшин, старший аналитик по информационной безопасности подразделения Secure Platform Development «Лаборатории Касперского»: «Перетекание угроз из информационной в материальную среду заметно буквально во всех сферах. Самая очевидная из них — индустриальный интернет вещей (IIoT). Там сближение IT и OT (operational tech), то есть IT и промышленных систем, идет, что называется, по определению. Хотя и обычный IoT тоже стал генерировать значительные риски.

Системы «умного» дома, города и производства скрывают много опасностей, которые пока не принято широко обсуждать. На мой взгляд, судя по спектру атак на конвергентные системы, ни бизнес, ни злоумышленники еще до конца не понимают, в какой ситуации они оказались. Лично я убежден, что преступный мир сейчас прикидывает, что делать с этим огромным и очень богатым полем деятельности — IoT/IIoT, — и ведет своего рода «разведку месторождений». Об этом свидетельствует рост спроса на уязвимости IoT в даркнете.

Злоумышленники достаточно скоро могут освоить новые направления и методы атак на конвергентные системы. И тогда количество таких киберпреступлений будет экспоненциально нарастать — в частности, речь может идти об атаках через промышленные контроллеры».

Софт уязвим и не обновляется

Низкий уровень защиты IoT-среды во многом объясняется устаревшим ПО и отсутствием полноценной поддержки. К началу 2023 года прошивка среднестатистического IoT-устройства устарела на шесть лет, выяснили в компании Phosphorus Cybersecurity. При этом 28% бизнесов говорят о невозможности установки патчей. Среди причин — отсутствие обновлений после ухода вендоров и нехватка собственных компетенций.

Иногда обновление системы в принципе невозможно установить. Например, если оно требует замены специализированного ПО (такого, как системы SCADA для диспетчерского управления и сбора данных), которая, в свою очередь, требует модернизации оборудования. В результате на производствах до сих пор встречаются «древности» — вплоть до технологических процессов под управлением MS DOS.

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

Элементы IoT и особенно IIoT используются в инновационных проектах, которые имеют особые требования по безопасности в силу их конвергентности, то есть слияния IT и OT. А нехватка подходящих средств защиты становится одним из главных препятствий для бизнеса на пути внедрения интернета вещей.

Алексей Матюшин: «До недавних пор особое внимание служб информационной безопасности уделялось корпоративным периметрам защиты. Но в эксплуатации IT-систем в корпоративном секторе уже фактически произошел массовый переход к системам в концепции Zero Trust.

Основная идея этой концепции проста. Если провести аналогию с государствами, периметральная защита — это проверка на границе, после которой вас слабо контролируют. А в парадигме Zero Trust никто никому не доверяет: на границе нет суровых проверок, но вас будут проверять на входе в каждый ресторан и каждую парикмахерскую. Вместо одного большого периметра защиты образуется множество микропериметров, вместо большой поверхности атаки мы заботимся о небольших поверхностях защиты.

Покупать внешние средства защиты на каждый из множества микропериметров — дорого. Причем в IoT/IIoT все еще сложнее: как защитить каждый контроллер, шлюз, датчик или, например, камеру, которые не всегда работают под ОС Windows или Linux, а часто вообще не имеют выделенной системной прослойки в виде операционной системы?

Мы продвигаем кибериммунный подход к разработке софта, это наша практическая методология в идеологии Secure by Design. Этот подход концептуально близок Zero Trust, только он не про защиту готовых программных продуктов при эксплуатации, а про их собственное внутреннее устройство, про их разработку.

В кибериммунном продукте каждый элемент изолирован и каждое взаимодействие строго контролируется».

Бизнесу сложно ставить задачи по безопасности

В некоторых прикладных сферах уже сложилось регулирование по безопасности. Например, есть требования по безопасности для объектов критической информационной инфраструктуры (КИИ), авионики, автомобилей и так далее. Для КИИ в законе прописаны принципы обеспечения ИБ и ее оценки, особенности контроля и взаимодействия с государственными системами. В авиастроении свой набор отраслевых стандартов, в автомобилестроении — свой, но в обоих случаях внимание сосредоточено на физической безопасности (safety). При этом не все представляют долю софта в стоимости разработки, например, самолета: для гражданского судна эта доля достигает 50%, а для военного — 60%.

Алексей Матюшин: «Существует несколько проблем с постановкой задач в сферах, где нет жесткой регуляции по безопасности, но есть объективная необходимость в ней — например, в IoT/IIoT.

Часто заказчики не ставят задачи по безопасности перед разработчиками, считая, что это само собой разумеется. Однако разработчики не склонны решать никем не поставленные задачи. Им платят не за это, а за реализацию функционала.

Даже если заказчик озабочен безопасностью, он часто переносит ответственность по выработке требований на разработчика, ставя задачу в виде «сделайте все безопасно». Это подразумевает наличие подходящих компетенций у разработчика. Но если вы не решаете задачи определенного типа на регулярной основе, откуда у вас будут соответствующие компетенции? И откуда возьмется регулярная основа, если задачи обычно вообще не ставят?

Кроме этого, при такой постановке задачи нет критериев ее выполнения. В итоге неясно, насколько необходимы и достаточны реализованные меры защиты и насколько они качественно реализованы.

Еще одна серьезная проблема — необязательность. Требования по безопасности, даже если они формулируются, до сих пор были и сейчас являются нефункциональными требованиями (non functional requirements, NFR). Если честно, для разработчика это звучит как «необязательные».

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

Подумать о безопасности можно раньше

Альтернативный подход к безопасности — принцип «Сдвиг влево» (англ. Shift Left). Применительно к разработке он означает «давайте подумаем об этом раньше». То есть нужно с самого начала сформулировать требования по безопасности и с их учетом разработать архитектуру и дизайн продукта.

Безопасность продукта в этом случае рассматривается не как опциональная надстройка, а как обязательная часть архитектуры. Если придерживаться принципа Shift Left, появляется принципиальная возможность создать софт в парадигме Secure by Design (SbD), по-русски — конструктивно безопасным.

Однако принцип Shift Left и, соответственно, парадигма Secure by Design пока не применяются массово в разработке софта.

Во-первых, компании не до конца понимают, что такое на практике Secure by Design, что конкретно нужно делать. Создавать продукт в этой парадигме без соответствующей методологии сложно — все равно что применять философию Agile без методологий Scrum или Kanban.

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

Алексей Матюшин: «Компании привыкли мириться с некоторым количеством инцидентов безопасности — это сложившийся майндсет бизнеса. Хотя во многих других сферах безопасность продукта — одна из главных его функций. Вы же не будете покупать, скажем, бытовую технику, которая заведомо может вызвать короткое замыкание и пожар? Почему считается, что миллионы киберинцидентов в год — это норма? Мы же не считаем нормой миллионы пожаров в год.

Можно снизить число инцидентов, если думать о безопасности на этапе разработки программных продуктов (Shift Left) и создавать их конструктивно безопасными (Secure by Design). Мы создаем собственные кибериммунные продукты, оттачиваем и пропагандируем кибериммунный подход. Мы выстраиваем такую методологию, в которой разработчику и бизнесу не нужны суперкомпетенции в кибербезопасности. Достаточно в правильном порядке совершать понятные шаги на каждом этапе работы, на каждом уровне компетенций — заказчика, разработчика, тестировщика».

В «Лаборатории Касперского» сравнили затраты для обычных и конструктивно безопасных решений на примере кибериммунного тонкого клиента (компактного маломощного компьютера, переносящего все или большую часть задач по обработке информации на сервер). Согласно расчетам компании, стоимость владения (TCO, Total Cost of Ownership) для этого SbD-продукта на протяжении трех лет эксплуатации 1 тыс. устройств снижается на 33%. Это происходит благодаря сокращению затрат на развертывание в инфраструктуре, администрирование и обновление операционной системы, а также за счет того, что не нужно закупать наложенные средства защиты.

В компании отмечают, что выбор между внешними (наложенными) системами защиты и вложениями в конструктивно безопасные продукты определяется экономикой и другими объективными условиями.

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

Инвестиции в создание конструктивно безопасных продуктов оправданы в определенных условиях. Если компания территориально распределена, в ней работают несколько десятков тысяч человек и нет средств централизованного обновления софта, то патчить его уязвимости накладно и долго. Чтобы обновить все рабочие места за приемлемое время, понадобится огромное количество IT-специалистов.

Нередки ситуации, когда устройства, на которых работает софт, физически недоступны или размещены на территориально распределенных объектах — сетях АЗС, трубопроводах, территориальных отделениях компании.

Наконец, для кибер-физического мира часто неприемлем даже единичный (первый) инцидент: ущерб слишком велик или непредсказуем. Здесь традиционная схема «инцидент — расследование — контрмера» не подходит. Во всех этих ситуациях необходим конструктивно безопасный, более устойчивый к угрозам софт.