-
Похожий контент
-
От KL FC Bot
В какой-то момент ИБ-департамент крупной компании неизбежно задумывается о внедрении или замене SIEM-системы и сталкивается с задачей оценки бюджета, необходимого для ее внедрения. Но SIEM — это не легковесный продукт, который можно развернуть в имеющейся инфраструктуре. Практически все решения этого класса требуют дополнительного оборудования, так что для их работы придется приобретать аппаратное обеспечение (или арендовать его).
Поэтому для расчетов бюджета необходимо представлять себе предполагаемую конфигурацию оборудования. В этом посте мы попробуем рассказать о том, как архитектура SIEM влияет на требования к аппаратной составляющей, а также предоставим примерные параметры, на которые стоит ориентироваться, чтобы определить предварительную стоимость необходимого оборудования.
Оценка потока информации
По своей сути SIEM-система собирает данные о событиях с источников и на основании корреляции этих данных выявляет угрозы для безопасности. Поэтому, прежде чем прикидывать, какое железо необходимо для работы системы, стоит оценить, а какой, собственно, объем информации эта система будет обрабатывать и хранить. Для того чтобы понять, какие источники потребуются, следует выделить наиболее критичные риски и определить источники данных, анализ которых поможет в выявлении и анализе угроз, связанных с этими рисками. Такая оценка нужна не только для расчета необходимого аппаратного обеспечения, но и для оценки стоимости лицензии. Например, стоимость лицензии на нашу систему KUMA (Kaspersky Unified Monitoring and Analysis Platform) напрямую зависит от количества событий в секунду (Events Per Second, EPS). И еще один важный аспект — при выборе SIEM-системы важно проверить, как именно вендор считает количество событий для лицензирования. Мы, например, учитываем количество EPS после фильтрации и агрегации, причем мы считаем среднее количество событий за последние 24 часа, а не их пиковые значения, но так поступают далеко не все.
View the full article
-
От KL FC Bot
В ходе атак на инфраструктуру различных компаний злоумышленники все чаще прибегают к манипуляции с модулями, взаимодействующими с процессом Local Security Authority (LSA). Это позволяет им получать доступ к учетным данным пользователей и закрепиться в системе, повысить свои привилегии или развить атаку на другие системы атакуемой компании. Поэтому при подготовке очередного ежеквартального обновления для нашей SIEM-системы Kaspersky Unified Monitoring and Analysis Platform мы добавили правила, служащие для детектирования таких попыток. По классификации MITRE ATT&CK, новые правила позволяют выявлять техники T1547.002, T1547.005 и T1556.002.
В чем суть техник T1547.002, T1547.005 и T1556.002?
Оба вышеупомянутых варианта техники T1547 подразумевают загрузку процессом LSA вредоносных модулей. Подтехника 002 описывает добавление вредоносных DLL-библиотек с пакетами проверки подлинности Windows (Windows Authentication Packages), а подтехника 005 — библиотек с пакетами поставщиков безопасности (Security Support Providers). Загрузка этих модулей позволяет злоумышленникам получить доступ к памяти процесса LSA, то есть к критическим данным, таким как учетные данные пользователей.
Техника T1556.002 описывает сценарий, когда атакующий регистрирует в системе вредоносные DLL-библиотеки фильтров паролей (Password Filter), которые по сути являются механизмом, принуждающим к исполнению парольных политик. Когда легитимный пользователь меняет пароль или же устанавливает новый, процесс LSA сверяет его со всеми зарегистрированными фильтрами, при этом он вынужден передавать фильтрам пароли в открытом, нешифрованном виде. То есть если злоумышленнику удается внедрить в систему свой вредоносный фильтр паролей, то он сможет собирать пароли при каждом запросе.
Все три техники подразумевают подкладывание вредоносных библиотек в директорию C:Windows\system32, а также их регистрацию в ветке системного реестра SYSTEM\CurrentControlSet\Control\LSA\ с ключами Authentication Packages для T1547.002, Security Packages для T1547.005 и Notification Packages для T1556.002.
View the full article
-
От KL FC Bot
Чем раньше действия злоумышленников попадут в сферу внимания защитных решений и экспертов, тем эффективнее получится минимизировать, а то и вовсе предотвратить ущерб. Поэтому, работая над новыми правилами детектирования для нашей SIEM-системы KUMA (Kaspersky Unified Monitoring and Analysis Platform), мы уделяем особое внимание выявлению активности хакеров на самом начальном этапе атаки — то есть на этапе сбора информации о защищаемой инфраструктуре. То есть к действиям, относящимся к тактике Discovery по классификации Enterprise Matrix MITRE ATT&CK Knowledge Base.
В последнее время все чаще внимание атакующих привлекает инфраструктура контейнеризации, в которой нередко находят достаточно опасные уязвимости. Например, в нашем майском отчете об эксплойтах и уязвимостях описывается уязвимость CVE-2024-21626, эксплуатация которой позволяет совершить побег из контейнера. Поэтому в обновлении KUMA SIEM за третий квартал 2024 года среди правил для выявления нетипичного поведения, которое может свидетельствовать об активности злоумышленников на этапе первичного сбора данных, мы добавили правила детектирования, которые ловят попытки сбора данных об используемой инфраструктуре контейнеризации, а также следы различных попыток манипуляций с самой системой контейнеризации.
Сделано это было с помощью детектирующих правил R231, R433 и R434, которые уже доступны пользователям KUMA SIEM через систему обновления правил. В частности, они служат для детектирования и корреляции следующих событий:
доступ к учетным данным внутри контейнера; запуск контейнера на неконтейнерной системе; запуск контейнера с избыточными правами; запуск контейнера с доступом к ресурсам хоста; сбор информации о контейнерах с помощью стандартных инструментов; поиск слабых мест в контейнерах с помощью стандартных инструментов; поиск уязвимостей безопасности в контейнерах с помощью специальных утилит. С учетом вышеописанного обновления сейчас на платформе доступно более 659 правил, из них 525 правил с непосредственно детектирующей логикой.
Мы продолжаем ориентироваться на Enterprise Matrix MITRE ATT&CK Knowledge Base, которая сегодня включает в себя 201 технику, 424 подтехники и тысячи процедур. На данный момент наше решение покрывает 344 техники и подтехники MITRE ATT&CK.
Кроме того, мы доработали множество старых правил путем исправления или корректировки условий, например, для снижения количества ложных срабатываний (false-positives).
View the full article
-
От yare4kaa
Здравствуйте, был в рейсе и не чистил пк от вирусов, заразился много фигней, нужна помощь специалистов.
Логи ниже CollectionLog-2024.11.25-18.32.zip
-
От KL FC Bot
Риски применения ИИ-систем человечество будет изучать и устранять десятилетиями. Одним из наименее изученных на сегодня является риск троянизации модели, когда полезная и на первый взгляд верно работающая система машинного обучения содержит скрытую функциональность или намеренно внесенные ошибки. Создать такого «троянского коня» можно несколькими способами, которые отличаются уровнем сложности и сферой применения. И это не прогнозы на будущее, а реальные кейсы.
Вредоносный код в модели
Некоторые форматы хранения ML-моделей могут содержать исполняемый код. Например, произвольный код может быть выполнен при загрузке файла в формате pickle — стандартном для Python формате сериализации (приведения к форме, подходящей для сохранения и передачи) данных, используемом, в частности, в библиотеке для глубокого обучения PyTorch. В другой популярной библиотеке для машинного обучения TensorFlow модели в форматах .keras и HDF5 могут содержать «лямбда-слой», тоже по сути выполняющий произвольные команды на Python. В этом коде легко спрятать вредоносную функциональность.
В документации TensorFlow можно найти предупреждение, что модель в TensorFlow при исполнении может читать и записывать файлы, получать и отправлять данные по сети и даже запускать дочерние процессы. В общем, является по сути полноценной программой.
Вредоносный код может срабатывать сразу же при загрузке ML-модели. В популярнейшем репозитории публичных моделей Hugging Face в феврале 2024 года было обнаружено около ста моделей с вредоносной функциональностью. Из них 20% создавали на зараженном устройстве оболочку для удаленного доступа (Reverse Shell), а 10% запускали дополнительное ПО.
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти