SOT

SOT

SOAR
Security Orchestration, Automation and Response

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

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

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

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risk Management

Формирование реестра рисков, угроз, мер защиты и других параметров контроля, оценка по выбранной методике, формирование перечня дополнительных мер для изменения уровня риска, контроль исполнения, периодическая переоценка

ORM
Operational Risk Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

SSDL: Знай своего opensource-поставщика в лицо и не только

SSDL: Знай своего opensource-поставщика в лицо и не только
23.05.2024

Гайнуллина Екатерина, инженер по информационной безопасности, Отдел развития Производственного департамента Security Vision

Беляева Ева, руководитель отдела развития Производственного департамента Security Vision

 

Введение


Как часто, пользуясь open source, вы задумывались о том, что придет с грядущим обновлением? Скорее всего, регулярно, особенно за последние несколько лет. Весь мир давно говорит о том, что любые обновления проприетарного ПО требуют тестирования и проверки, с обновлениями opensource-решений такая же история.


В последние годы атаки на цепочку поставок стали значительной угрозой для безопасности программного обеспечения.

 

рис 1.png

 

Рисунок 1. Рост атак на цепочку поставок, 2019-2022


Злоумышленники могут внедрить вредоносный код или компрометировать зависимости в открытом исходном коде, в результате чего вредоносные элементы проникают в систему вместе с обновлениями или новыми версиями. Это делает отслеживание и обеспечение безопасности opensource-проектов более сложным.


Как атаки на цепочки поставок влияют на бизнес?

· Утечка данных

· Финансовые потери

· Сбои в работе

· Ущерб репутации


Вместо прямой атаки на системы, сети или сотрудников целевой организации злоумышленник проникает в доверенную организацию в цепочке поставок, используя доверие этой организации и доступ к ней по отношению к цели.


От чего нужна защита


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


Внедрение вредоносного кода


Внедрение вредоносного кода - тонкая, но весьма опасная форма атаки, которая подчеркивает угрозы, с которыми сталкиваются разработчики.


Сценарий атаки часто начинается с получения злоумышленником доступа к исходному коду библиотеки, будь то через компрометацию (как в случаях codecov и SolarWinds) или путем выдачи себя за оригинального разработчика с открытым исходным кодом. Затем, когда доступ получен, в код вносятся изменения, которые содержат в себе вредоносные нагрузки. Это может варьироваться от обычной утечки учетных данных до сложного крипто-ограбления, где киберпреступники похищают криптовалюту на миллионы долларов.


В контексте Log4j, который стал катализатором обсуждений в сообществе кибербезопасности, отчет Verizon DBIR 2023 выделяет неожиданные аспекты его использования, включая шпионаж и организованную преступность.


Для недопущения последствий подобных кампаний необходимы два ключевых элемента:


· Осведомленность о программных компонентах: важно знать, какие программные компоненты интегрированы в программное обеспечение, как прямо, так и временно. Использование SBOM (Software Bill of Materials) или спецификаций программного обеспечения позволяет лучше понимать структуру и зависимости в программном коде. Это обеспечивает прозрачность и обнаружение уязвимостей на более ранних этапах разработки.


· Способность к быстрым изменениям: когда поврежденный выпуск программного обеспечения обнаружен, критическим является возможность быстрого внесения корректив. Гибкость и оперативность в реагировании на угрозы позволяют минимизировать временной промежуток между обнаружением и устранением уязвимости.


Одним из позитивных аспектов в сообществе с открытым исходным кодом является возможность тщательного анализа кода. Это означает, что многие такие кампании быстро обнаруживаются и раскрываются, что способствует оперативной реакции на угрозы и быстрому внесению необходимых изменений.


Протестное ПО


Еще один подвариант внедрения вредоносного кода, за которым мы могли наблюдать последние два года – это протестное ПО. В этом сценарии инцидент возникает, когда сопровождающий намеренно саботирует свой собственный проект, причиняя вред или вызывая сбой в работе таким образом, чтобы нарушить работу его пользователей.


Хотя технически разработчик открытого ПО имеет право делать со своим кодом все, что захочет, внедрение вредоноса, нарушающего работу программы или собирающего дополнительную информацию – не самая лучшая идея.


Протестное ПО стало актуальной темой после серии изменений в пакете JavaScript node-ipc. Поскольку node-ipc необходим для функциональности ряда других кодов, включая фреймворк Vue.js для пользовательских интерфейсов, некоторые исследователи по безопасности изначально отнесли злонамеренные изменения к категории атак на цепочку поставок. В то время как в прошлых атаках на цепочку поставок виновными всегда были внешние лица, Брэндон Ноздаки Миллер, основной разработчик node-ipc, использующий псевдоним RIAEvangelist, внес изменения в знак протеста. Обозначенный как peacenotwar, код был разработан для стирания данных, если он использовался на системах, расположенных в России или Беларуси.


Важно различать протестное ПО и хактивизм, которые часто имеют общие цели в передаче сообщений, но различаются в методах выполнения. В хактивизме злоумышленник нарушает услуги различными способами, включая инъекцию кода, дефейс веб-сайтов и атаки DDoS, чтобы выразить свое возражение. Протестное же ПО предполагает участие легитимного разработчика с разрешенным доступом к коду, вносящего намеренные изменения в знак протеста.


Некоторые вендоры, в частности Лаборатория Касперского, уже подстроились под новые реалии и при работе с зависимыми библиотеками позволяют проверять их на своей платформе.


Путаница в зависимостях


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


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


Typosquatting


Typosquatting (опечаточный домен) продолжает быть популярным методом для проведения атак на цепочки поставок программного обеспечения и основывается на обманчиво простой технике. Берется популярный компонент, слегка меняется его название и дальше работает предположение, что некоторые разработчики допустят ошибку при добавлении компонента. Работа с программным обеспечением в конечном итоге представляет собой очень повторяющуюся форму письма. С миллионами пар рук, набирающих npm install или редактирующих requirements.txt на миллионах клавиатур, неизбежно будут допущены ошибки.


Примером, наблюдаемым в реальной жизни, является кампания против библиотеки colors, когда противники называют свои пакеты colors-2.0 или colors-helper и так далее.


Вредоносная полезная нагрузка


Эти методы часто сочетаются с вредоносной полезной нагрузкой, которая выполняется немедленно, используя встроенную функциональность инструмента сборки разработчика. Большинство современных утилит сборки, таких как npm, cargo, pip3 и т.д., позволяют сопровождающему пакета выполнять какой-либо установочный скрипт во время установки пакета.


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


Наиболее распространенные типы нагрузок включают установку вредоносных программ и извлечение системных учетных данных и токенов, а также другой системной информации.


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


Как защищаться


Вендорские решения


1. Kaspersky Open Source Software Threats Data Feed

Как уже было упомянуто ранее, Лаборатория Касперского запустила сервис данных об уязвимостях Kaspersky Open Source Software Threats Data Feed. Предоставляя данные о программном обеспечении с открытым исходным кодом, поток данных об угрозах Касперского включает в себя компоненты с необъявленными возможностями и пакеты с небезопасным программным обеспечением. CodeScoring использует эти данные для автоматизированной проверки компонентов с открытым исходным кодом, предоставляя разработчикам результаты анализа. Использование готовых пакетов в разработке ПО стало обычной практикой для экономии времени.


2. GitHub Code Scanning

GitHub предоставляет инструменты для статического анализа кода, такие как CodeQL. Это позволяет обнаруживать уязвимости и потенциальные проблемы безопасности в открытом исходном коде. Инструмент использует логический анализ с возможностью дедукции. Интегрируется с обширным объемом данных из экосистемы GitHub.


3. CodeScoring

CodeScoring – российское решение OSA/SCA, предоставляющее средства для проверки компонентов с открытым исходным кодом и обеспечения безопасности цепочек поставок программного обеспечения. Использует данные об угрозах от Kaspersky Open Source Software Threats Data Feed. Обеспечивает управление информацией об используемых компонентах и отслеживание безопасности.


4. Snyk

Snyk предоставляет решения для обеспечения безопасности открытого исходного кода и зависимостей. Основное внимание уделяется раннему обнаружению уязвимостей. Использует анализ зависимостей и интеграцию с CI/CD системами. Предоставляет информацию о безопасности зависимостей.


5. WhiteSource

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


6. Sonatype Nexus Lifecycle

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


Самостоятельная защита


Несмотря на то, что на рынке пока нет универсальной стратегии защиты от этой угрозы, существует несколько подходов, которые вы можете использовать самостоятельно для защиты от protestware и внедрений вредоносного кода в зависимости в вашем коде. Вот несколько рекомендаций:


1. Ручные проверки кода

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


2. Используйте инструменты статического анализа

Применяйте утилиты статического анализа кода для автоматического обнаружения потенциальных проблем безопасности. Эти инструменты могут помочь выявить подозрительные участки кода.

Пример: SonarQube - инструмент для непрерывной проверки качества кода, который может выявлять потенциальные уязвимости и проблемы безопасности в коде.


3. Обновляйте зависимости

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

Пример: Dependabot - инструмент, автоматически создающий запросы на обновление зависимостей в вашем проекте при появлении новых версий.


4. Используйте проверенные источники

Предпочитайте использование пакетов из официальных репозиториев или источников с доверенной репутацией.

Пример: Использование пакетов из официальных репозиториев, таких как npm (Node Package Manager), PyPI (Python Package Index) или Maven.


5. Мониторинг изменений

Настраивайте мониторинг изменений в ваших зависимостях. Это может включать в себя отслеживание обновлений и проверку безопасности нового кода.

Пример: Snyk - инструмент для обнаружения и мониторинга уязвимостей в зависимостях вашего проекта.


6. Используйте подписи и хеши

Проверяйте цифровые подписи и хеши загружаемых зависимостей для обеспечения их целостности.

Пример: Использование инструментов, таких как GPG (GNU Privacy Guard), для проверки цифровых подписей и SHA-256 для проверки хешей файлов.


7. Образцы кода

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


8. Следите за обновлениями безопасности

Подписывайтесь на обновления безопасности ваших зависимостей, чтобы быть в курсе новых уязвимостей и обновлений.

Пример: Подписка на обновления безопасности через инструменты, такие как OWASP Dependency-Check, который проверяет проект на наличие зависимостей с известными уязвимостями.


Выводы


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


Без должных проверок безопасности и регулярного мониторинга программного кода мы сталкиваемся с серьезными рисками. Процессы подмены зависимостей, опечаточные домены и другие методы атак на цепочки поставок становятся более изощренными. Это не только создает угрозы для конфиденциальности и целостности данных, но и ставит под угрозу непрерывность разработки и функционирования программных продуктов.





Практика ИБ Управление ИБ Управление инцидентами

Рекомендуем

Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Процессы управления ИБ (конспект лекции)
Процессы управления ИБ (конспект лекции)
Искусственный интеллект в информационной безопасности
Искусственный интеллект в информационной безопасности
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Управление доступом и учетными записями (конспект лекции)
Управление доступом и учетными записями (конспект лекции)
Защита персональных данных (конспект лекции)
Защита персональных данных (конспект лекции)
Управление рисками информационной безопасности. Часть  7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Управление рисками информационной безопасности. Часть 7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 2
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 2

Рекомендуем

Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности. Часть 1. Основные понятия и методология оценки рисков
Управление рисками информационной безопасности (конспект лекции)
Управление рисками информационной безопасности (конспект лекции)
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Категорирование объектов критической информационной инфраструктуры в рамках 187-ФЗ. Постановление Правительства РФ № 127
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Процессы управления ИБ (конспект лекции)
Процессы управления ИБ (конспект лекции)
Искусственный интеллект в информационной безопасности
Искусственный интеллект в информационной безопасности
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Управление доступом и учетными записями (конспект лекции)
Управление доступом и учетными записями (конспект лекции)
Защита персональных данных (конспект лекции)
Защита персональных данных (конспект лекции)
Управление рисками информационной безопасности. Часть 7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Управление рисками информационной безопасности. Часть  7. Стандарт ISO/IEC 27005:2018 (продолжение). Стандарт IEC 31010:2019
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 2
Практическая защита персональных данных. Как компания должна обрабатывать и защищать персональные данные? Часть 2

Похожие статьи

Польза от Pentest для постинцидента
Польза от Pentest для постинцидента
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
IDE для разработки средств защиты в формате no-code
IDE для разработки средств защиты в формате no-code
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
SSDL: ML для проверки кода и поведения opensource-решений
SSDL: ML для проверки кода и поведения opensource-решений
Атаки на веб-системы по методологии OWASP Top 10
Атаки на веб-системы по методологии OWASP Top 10
Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS

Похожие статьи

Польза от Pentest для постинцидента
Польза от Pentest для постинцидента
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
Логины, пароли и другие способы аутентификации: описание, особенности, угрозы
IDE для разработки средств защиты в формате no-code
IDE для разработки средств защиты в формате no-code
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
Взломы в информационной безопасности - что это, как они происходят и как от них защититься
SSDL: ML для проверки кода и поведения opensource-решений
SSDL: ML для проверки кода и поведения opensource-решений
Атаки на веб-системы по методологии OWASP Top 10
Атаки на веб-системы по методологии OWASP Top 10
Технология SOAR и ее место в SOC
Технология SOAR и ее место в SOC
Живее всех живых: непрерывность бизнеса
Живее всех живых: непрерывность бизнеса
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS
Что такое системы анализа трафика (Network Traffic Analysis, NTA), их отличие от NDR и IDS