Злоумышленники всё чаще атакуют цепочки поставок ПО, чтобы получить доступ к исходным кодам, процессам сборки или механизмам обновления ПО. Но сложно напрямую атаковать инфраструктуры компаний, которые серьёзно относятся к своей кибербезопасности. В последнее время в СМИ появляются сообщения об атаках на ИТ‑гигантов, финтех, объекты критической инфраструктуры через разработчиков и поставщиков ПО. Яркий пример — инциденты атак на 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 к Методике ФСТЭК.
Чтобы заполнить таблицу, нужно предварительно:
- Сформировать общий перечень угроз безопасности.
- Исключить угрозы, не связанные со структурно‑функциональными характеристиками АС, применяемыми информационными технологиями и особенностями функционирования АС.
- Если системы функционируют на основе облачной инфраструктуры, то нужно учитывать угрозы, касающиеся именно её. Для этого запросите выписки из модели угроз поставщика облачных услуг, или продумайте угрозы вместе с ним. Нужно также учитывать распределение границ между оператором и поставщиком облачных услуг, а также различные технологические и архитектурные уровни системы — от физического обеспечения ЦОД до уровня обеспечения рабочих мест.
После составления адаптированного перечня УБИ необходимо оценить их актуальность в соответствии с Методикой ФСТЭК и с учётом следующих тезисов:
1) Угроза безопасности информации возможна, если есть:
- нарушитель или иной источник угрозы;
- объект воздействия;
- способы реализации угрозы безопасности информации;
- возможность негативных последствий из-за реализации угрозы.
2) Если есть хотя бы один сценарий угрозы, то она признаётся актуальной для системы и сети и включается в модель. Обосновывается выбор организационных и технических мер по защите информации.
Мы вкратце рассмотрели, как разработать модель угроз информационной безопасности производственного конвейера ПО. Надеюсь, мне удалось убедить вас в том, что моделирование угроз — это не рутина, а интересная, и даже творческая работа. В области моделирования угроз при разработке ПО предстоит сделать ещё многое: объединить российский и зарубежный опыт, разработать собственные подходы, предложить меры по автоматизации моделирования.
Моделирование угроз — важная часть работы специалистов в области кибербезопасности, как и доведение результатов моделирования до логического завершения и воплощение их в организационных и технических мероприятиях по кибербезопасности. Об этом подробнее поговорим в одной из следующих статей.
