Злоумышленники всё чаще атакуют цепочки поставок ПО, чтобы получить доступ к исходным кодам, процессам сборки или механизмам обновления ПО. Но сложно напрямую атаковать инфраструктуры компаний, которые серьёзно относятся к своей кибербезопасности. В последнее время в СМИ появляются сообщения об атаках на ИТ‑гигантов, финтех, объекты критической инфраструктуры через разработчиков и поставщиков ПО. Яркий пример — инциденты атак на SolarWinds, Codecov, GitHub, ССleaner от Avast. Ущерб от этих атак оказался огромен.
Меня зовут Сергей Кубан, я руководитель направления в отделе защиты инфраструктуры производства ПО в СберТехе. Мы поставляем заказчикам программное обеспечение и SaaS-сервисы. Чтобы они соответствовали требованиям кибербезопасности, необходимо всестороннее обеспечение безопасности инфраструктуры как собственного производственного конвейера ПО, так и предоставляемых заказчикам SaaS-инсталляций.
Сегодня расскажу об одном из важных методологических подходов к противодействию атакам на цепочки поставок ПО — разработке модели угроз информационной безопасности.
Что такое модель угроз и зачем она нужна
Модель угроз — это один из основополагающих документов, который помогает планировать работу подразделения кибербезопасности. Он содержит список актуальных угроз безопасности защищаемого объекта. Я работаю с моделированием с 2008 года и прошел все вехи развития методологической базы, от методологии ключевых систем информационной инфраструктуры (КСИИ) до методологии, связанной с объектами критической информационной инфраструктуры. Пользу модели угроз я сформулировал для себя следующим образом:
Это методологическая база для эффективной настройки средств защиты информации. Она позволяет максимально использовать возможности по обнаружению атак (разработка правил корреляции в SIEM), реагированию на инциденты кибербезопасности (IRP) и предотвращению атак (проактивная защита) с учётом их векторов, техник и тактик нарушителя.
Модель угроз позволяет сформировать требования кибербезопасности при разработке автоматизированных систем (АС) и обосновании затрат на закупку средств защиты перед руководством.
Модель угроз помогает обеспечить соответствие нормативным требованиям в области защиты персональных данных и критической информационной инфраструктуры.
Для более глубокого погружения в тему предлагаю посмотреть, как развивалась методическая база по моделированию угроз в России и в мире.
Как развивалась методическая база по моделированию угроз в России
Одни из первых документов по моделированию угроз вышли в 2008 году, в пакете документов для ключевых систем информационной инфраструктуры (КСИИ). Они включали в себя базовую модель угроз безопасности информации и методику определения актуальных угроз безопасности информации в КСИИ. Но они были недоступны для массового применения, и их приходилось заказывать через ФСТЭК России.
Вслед за этим ФСТЭК выпустил подобные документы в составе методических документов по защите персональных данных. Они были гораздо удобнее и доступнее для массового использования. Многие специалисты взяли их за основу не только для информационных систем персональных данных (ИСПДн), но и для других АС, нормативная база для которых в области моделирования угроз на тот момент отсутствовала (ГИС, АСУ ТП и другие).
В 2015 году появился Банк данных угроз безопасности информации ФСТЭК России. Он постоянно пополняется и сейчас насчитывает более 200 угроз.
В 2019 году вышел ГОСТ Р 58 412 «Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО». В нём впервые были заложены основы моделирования угроз для компаний‑разработчиков ПО.
В 2021 году ФСТЭК в документе «Методика оценки угроз безопасности информации» (далее — Методика ФСТЭК) объединил подходы к моделированию угроз для государственных и муниципальных информационных систем, ИСПДн, значимых объектов критической информационной инфраструктуры Российской Федерации. Регулятор постарался учесть и современный международный опыт. Предыдущие документы по моделированию угроз в сфере защиты персональных данных и КСИИ были отменены.
Как развивалась методическая база по моделированию угроз в мире
В мировой практике используется довольно много подходов и фреймворков. Рассмотрим самые, на мой взгляд, интересные и применяемые.
Всё началось в 2011 году с Cyber Kill Chain — модели жизненного цикла кибератак, разработанной компанией Lockheed Martin. В 2013 году появилась модель MITRE ATT&CK, в которой были шире рассмотрены эти подходы, а также добавлены рекомендации по снижению угроз. Правда, на мой взгляд, были недостаточно раскрыты вопросы, связанные с CI/CD — производственным конвейером разработки ПО. Тем не менее модель постоянно развивается и пополняется угрозами для CI/CD, рекомендациями по их снижению и способами отслеживания попыток их реализации.
После нашумевших атак на цепочки поставок ПО некоторые известные компании также опубликовали свои методики. В 2023 году Google выпустил методику SLSA, которая подробно расписывает угрозы, касающиеся CI/CD-конвейера, и постоянно совершенствуется.
В том же году вышла методология OSC&R (Open Software Supply Chain Attack Reference), которая в некотором смысле расширила MITRE ATT&CK. Её разрабатывало сообщество действующих и бывших сотрудников GitLab, Microsoft, Google, OWASP, CheckPoint.
Стоит обратить внимание и на другие интересные фреймворки — DevOps threat matrix от Microsoft и OWASP Top 10 CI/CD Security Risks от OWASP.
Практические аспекты моделирования угроз
В этой статье я не буду подробно объяснять, как разрабатывать модель угроз. Это описано в Методике оценки угроз ФСТЭК и множестве публикаций от экспертов по кибербезопасности. Остановимся на важных аспектах моделирования с точки зрения производственного конвейера разработки ПО, в том числе в облачной инфраструктуре.
Методика ФСТЭК применяется для государственных информационных систем, ИСПДн, значимых объектов критической информационной инфраструктуры и других организаций. В первую очередь она апеллирует к техникам и тактикам, которые описаны в Банке данных угроз ФСТЭК России. Она учитывает наработки MITRE ATT&CK, Cyber Kill Chain и угрозы, связанные с разработкой ПО. Однако, на мой взгляд, последние в ней представлены недостаточно. Тем не менее, Методика ФСТЭК предлагает при оценке угроз безопасности информации (далее — УБИ) также учитывать описания векторов, или шаблонов, и компьютерных атак, содержащихся в базах данных и иных источниках, опубликованных в сети (CAPEC, ATT&CK, OWASP, STIX, WASC и других).
Выше я говорил о стандарте ГОСТ Р 58412 «Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО», который вышел через четыре года после появления Банка данных угроз безопасности информации ФСТЭК. У этого стандарта нет четкой взаимосвязи с Методикой ФСТЭК. Описанные в нем угрозы недостаточно детализированы в части техник и тактик нарушителя, которые присутствуют в Методике ФСТЭК и указанных выше зарубежных фреймворках. Этот стандарт также не устанавливает критерии определения актуальности угрозы.
Ни один из перечисленных выше российских и зарубежных фреймворков не представляет собой всеобъемлющий методический документ для моделирования угроз. Чтобы получить целостную картину, я попытался установить между ними некое соответствие:
В верхней части перечислены российские методические документы и зарубежные фреймворки. В нижней изображён фрагмент таблицы для формирования перечня актуальных угроз Модели угроз безопасности производственного конвейера ПО.
Модель может получиться достаточно громоздкой: техник и тактик много, ещё больше занимает описание источников угрозы, способов реализации и негативных последствий. Поэтому я разбил таблицу на отдельные блоки вроде шаблонов, указанных в Приложении 3 к Методике ФСТЭК.
Чтобы заполнить таблицу, нужно предварительно:
Сформировать общий перечень угроз безопасности.
Исключить угрозы, не связанные со структурно‑функциональными характеристиками АС, применяемыми информационными технологиями и особенностями функционирования АС.
Если системы функционируют на основе облачной инфраструктуры, то нужно учитывать угрозы, касающиеся именно её. Для этого запросите выписки из модели угроз поставщика облачных услуг, или продумайте угрозы вместе с ним. Нужно также учитывать распределение границ между оператором и поставщиком облачных услуг, а также различные технологические и архитектурные уровни системы — от физического обеспечения ЦОД до уровня обеспечения рабочих мест.
После составления адаптированного перечня УБИ необходимо оценить их актуальность в соответствии с Методикой ФСТЭК и с учётом следующих тезисов:
-
Угроза безопасности информации возможна, если есть:
нарушитель или иной источник угрозы;
объект воздействия;
способы реализации угрозы безопасности информации;
возможность негативных последствий из-за реализации угрозы.
Если есть хотя бы один сценарий угрозы, то она признаётся актуальной для системы и сети и включается в модель. Обосновывается выбор организационных и технических мер по защите информации.
Мы вкратце рассмотрели, как разработать модель угроз информационной безопасности производственного конвейера ПО. Надеюсь, мне удалось убедить вас в том, что моделирование угроз — это не рутина, а интересная, и даже творческая работа. В области моделирования угроз при разработке ПО предстоит сделать ещё многое: объединить российский и зарубежный опыт, разработать собственные подходы, предложить меры по автоматизации моделирования.
Моделирование угроз — важная часть работы специалистов в области кибербезопасности, как и доведение результатов моделирования до логического завершения и воплощение их в организационных и технических мероприятиях по кибербезопасности. Об этом подробнее поговорим в одной из следующих статей.