Продукты для различных M2M-систем – АСУ ТП, автоматизации зданий, транспорта, медицинского оборудования, телекома – невозможно защитить наложенными средствами безопасности, поскольку ни в ПЛК, ни в блок управления автомобилем, ни в базовую станцию сотовой связи антивирусную защиту не поставишь. Способность таких решений противостоять киберугрозам полностью определяется окружением и собственной устойчивостью к атакам (конструктивной безопасностью). Однако техническая сложность большинства современных систем автоматизации и различных умных решений такова, что даже ведущие мировые производители не способны самостоятельно гарантировать их надежную защиту.
Проблема
Решение
Комплексный подход к обеспечению безопасности, предполагающий наличие следующих этапов:
- глубокий анализ защищенности M2M-систем, включающий многоуровневое исследование используемых технологических компонентов;
- приоритизация выявленных проблем безопасности;
- описание потенциальных векторов атак и возможных последствий для устройства, инфраструктуры и бизнеса;
- разработка вариантов устранения обнаруженных проблем, а также формирование перечня альтернативных мер по снижению рисков эксплуатации этих проблем в атаках злоумышленников.
Для кого
- Разработчики, производители различных M2M и прочих специфических продуктов для АСУ ТП, IoT/IIoT, транспорта (автомобилей, поездов, судов, авиации), медицинских приборов и устройств, систем телекома (базовые станции мобильной связи, системы ядра сети) и т. д.
- Разработчики компонентов М2М-систем: отдельных блоков управления, чипов, стеков сетевых протоколов, прошивок, операционных систем, сред выполнения программного кода, средств контроля лицензионных ограничений и прочих программных или программно-аппаратных модулей.
- Владельцы таких продуктов.
Содержание
Проблематика
Общим местом множества различных M2M-систем — АСУ ТП, автоматизации зданий, транспорта, медицинского оборудования, телекома — с точки зрения их киберзащиты является сложность или невозможность использовать наложенные средства защиты. Аппаратные ограничения и архитектурные решения, специфические требования по времени реакции, отказоустойчивости и потреблению ресурсов, редкие и экзотические операционные системы и прочие технические особенности делают разработку или адаптацию дополнительных защитных технологий нецелесообразной, излишне дорогой или технически невозможной.
Способность таких М2М-систем противостоять киберугрозам полностью определяется их сценариями использования, окружением и собственной устойчивостью к атакам (конструктивной безопасностью).
Количество и сложность сценариев использования для большинства продуктовых линеек неуклонно растет, и производители все чаще наделяют свои продукты, даже нишевые и узкоспециальные, возможностями гибкого изменения и расширения функциональности. Во многом, это делается за счет перехода от узко специализированных к универсальным решениям при выборе компонентов. И это в свою очередь наделяет продукты скрытыми функциональными возможностями — не только недокументированными для пользователя, но зачастую, как показывает наша практика, и неизвестными производителю конечного решения.
Вдобавок многие предположения разработчика относительно сценариев использования и возможного окружения их продуктов оказываются часто неверны — пользователи всегда делают что-то «не то, не так и не там». Например, гарантировать, что средства промышленной автоматизации и прочие специфические программно-аппаратные комплексы 100% времени находятся в изолированной среде, практически невозможно, даже если этого требуют внутренние политики и регуляторы. Даже если производитель уверен, что изоляция надежна, а пользователи оборудования не допускают ошибок и не подвергают критические системы киберугрозам (такого мы за многие годы практики ни разу не встречали), всегда остается риск компрометации в цепочке поставок — вредоносные изменения могут быть внедрены по пути, пройденном оборудованием от завода изготовителя, в сервисной мастерской, через ноутбук инженера и диагностическое оборудование.
То есть единственной по-настоящему действенной стратегией снижения киберриска является инвестиция в собственную (встроенную) кибербезопасность продукта — разрабатываемого или используемого. Прекрасно, если производитель разрабатывает, поддерживает и развивает продукт, всегда и во всем следуя методологии конструктивной безопасности. Однако такие случаи на практике почти не встречаются.
Даже если все делать правильно в отношении собственного кода и принимать правильные архитектурные решения, все равно возникает проблема неконтролируемости используемых третьесторонних компонентов. RCE уязвимость в модеме может стать никак не устранимым на уровне конечного решения вектором MiTM-атаки, а если этот модем интегрирован в SoC, то такая уязвимость грозит уже всему решению целиком, обнуляя любые попытки защитить ОС и прикладной код, выполняемый процессором приложений.
Относительно небольшие M2M-решения с точки зрения информационной безопасности на практике оказываются чрезвычайно сложными системами, включающими один или несколько чипов и развесистые стеки «общих» компонентов, реализующих протоколы сетевой коммуникации, функции среды выполнения программного кода, контроля лицензионных ограничений и т. д.
Выполнить самостоятельно всесторонний анализ защищенности всех этих программных и программно-аппаратных компонентов такого широкого охвата и такой глубины, чтобы обнаружить и устранить все основные киберриски, не под силу даже самым крупным разработчикам и мировым лидерам в своих продуктовых сегментах.
Для продуктов, применяемых в транспорте, энергетике, телекоме, автоматизации зданий, медицине и других киберфизических средах, такие риски особенно велики. Уязвимость одного компонента может затронуть не только само устройство, но и смежные системы, технологическое оборудование, нести угрозу функциональной и физической безопасности.
Что мы предлагаем
Мы предлагаем глубокое исследование и детальный экспертный анализ защищенности, в ходе которых выявляем и показываем проблемы безопасности продукта и его компонентов, определяем, какие компоненты находятся в зоне наибольшего риска, как найденные уязвимости могут быть использованы в реальных атаках, и к каким последствиям это может привести. Мы предлагаем способы исправления уязвимостей и варианты доработки архитектуры продукта заказчика, взаимодействуем с его поставщиками — разработчиками уязвимых компонентов, помогая им эффективно устранить уязвимости, влияющие на безопасность конечного решения.
На ранних этапах разработки продукта
Сервис особенно полезен на ранних этапах разработки продукта. Исследовав выбранные заказчиком сторонние компоненты до запуска продукта в серийное производство, мы поможем устранить обнаруженные в них уязвимости или снизить риски их эксплуатации до вывода продукта на рынок.
На этапах пилотного или промышленного внедрения
Сервис также может быть полезен и крупному заказчику конечного продукта на этапах пилотного или промышленного внедрения, при прохождении приемочных испытаний и сертификации — например, перед внедрением.
После выпуска новой версии прошивки
Разработчикам сервис поможет снизить риски возможных инцидентов после выпуска новой версии прошивки, содержащей существенные функциональные изменения, например, добавление удаленного управления или изменение архитектуры взаимодействия со смежными системами.
Результат анализа
Результат анализа — не общий вывод «хорошо / плохо», а многомерная и глубокая оценка состояния защищенности продукта от различных векторов атак, позволяющая заказчику осознать критичность обнаруженных уязвимостей в своей системе координат и модели рисков и получить помощь ведущих экспертов кибербезопасности в поиске эффективных способов исправления наиболее существенных для него проблем безопасности.
Как мы работаем
Работы начинаются с определения объекта и границ анализа: устройство, модуль, прошивка, сервисное ПО, протоколы, аппаратные интерфейсы, наличие облачных компонентов, учет сценариев использования и взаимодействия с окружением.
Далее заказчик выбирает форматы тестирования:
- black box — анализ без доступа к внутренней информации о продукте, с позиции внешнего нарушителя;
- grey box — анализ с частичным доступом к документации, прошивкам, конфигурациям, учетным записям;
- white box — углубленный анализ с доступом к архитектуре, исходному коду, схемам, отладочным интерфейсам и сервисным инструментам.
Форматы тестирования выбираются согласно целям и возможностям заказчика и не влияют на качество анализа, но влияют на его продолжительность и стоимость: чем меньше исходных данных нам доступно для анализа, тем больше времени и ресурсов потребуется на его выполнение.
Тестирование мы проводим в безопасной среде: на лабораторном стенде, тестовом экземпляре устройства, изолированном сегменте инфраструктуры или в специально подготовленной среде заказчика. Это позволяет проверять реальные сценарии атак без риска для промышленной, клиентской или продуктивной инфраструктуры.
Анализ может охватывать все уровни продукта и любые аспекты его использования.
Архитектура и логика работы продукта
Оцениваем, из каких компонентов состоит продукт, как эти компоненты взаимодействуют между собой и со смежными системами, где находятся доверенные связи. Это позволяет выявить слабые места в архитектуре решения — избыточные права, небезопасный обмен данными, отсутствие сегментации, недостаточный контроль доступа — и оценить его устойчивость к эксплуатации потенциальных уязвимостей в различных функциональных и технологических компонентах.
Программное обеспечение и прошивки
Проверяем прикладные компоненты, прошивки, загрузчики, модули обновления, обработчики команд, механизмы хранения конфигурации, ключей, сертификатов и журналов событий. Цель — выявить ошибки реализации, уязвимости, недокументированные возможности, способы модификации программного обеспечения или обхода защитных механизмов.
Аппаратная часть и физические интерфейсы
Исследуем аппаратную архитектуру, сервисные разъемы, отладочные интерфейсы, порты подключения, внешние носители и другие способы физического взаимодействия с устройством. Это важно для оборудования, к которому потенциальный нарушитель может получить прямой доступ: контроллеров, шлюзов, телематических модулей, IoT/IIoT-оборудования и других устройств.
Что получает клиент
По итогам работ формируется комплект документов, который можно использовать как дорожную карту для принятия решений по доработке и улучшению защищенности продукта.
В комплект документов входят:
- технический отчет, включающий:
- описание выявленных уязвимостей;
- оценку критичности уязвимостей и потенциального влияния их эксплуатации на продукт и связанную инфраструктуру;
- подтверждение воспроизводимости значимых уязвимостей*;
- карту возможных векторов атак со сценариями несанкционированного воздействия и условиями их реализации;
- рекомендации по устранению выявленных проблем.
* Код, воспроизводящий эксплуатацию уязвимости, предоставляется только разработчику уязвимого программного компонента.
- управленческое резюме с ключевыми рисками и выводами;
- итоговая презентация результатов аудита;
- при необходимости, повторный аудит после исправлений.
Для технических команд готовим отчет, который содержит сведения, необходимые для анализа и устранения обнаруженных проблем: затронутые компоненты, условия эксплуатации уязвимостей, возможные причины, рекомендации по изменению логики работы, конфигурации, механизма обновления, реализации протокола или защиты интерфейсов.
Для руководителей и владельцев продукта готовим краткое резюме: ключевые риски, возможные последствия для бизнеса, приоритетные зоны внимания и рекомендуемые шаги по снижению рисков.
Результат
Заказчик получает объективное понимание того, насколько продукт устойчив к современным атакам, какие компоненты требуют доработки, какие риски необходимо закрыть в первую очередь и понять, готово ли программно-аппаратное средство к производству, выходу на рынок, пилотному внедрению, масштабированию.
