Оптимизация системы
-
Похожий контент
-
От KL FC Bot
Хотя искусственный интеллект можно применять в ИБ-сфере разными способами, от детектирования угроз до упрощения написания отчетов об инцидентах, наиболее эффективными будут применения, которые значительно снижают нагрузку на человека и при этом не требуют постоянных крупных вложений в поддержание актуальности и работоспособности моделей машинного обучения.
В предыдущей статье мы разобрались, как сложно и трудоемко поддерживать баланс между надежным детектированием киберугроз и низким уровнем ложноположительных срабатываний ИИ-моделей. Поэтому на вопрос из заголовка ответить очень легко — ИИ не может заменить экспертов, но способен снять с них часть нагрузки при обработке «простых» случаев. Причем, по мере обучения модели, номенклатура «простых» случаев будет со временем расти. Для реальной экономии времени ИБ-специалистов надо найти участки работ, на которых изменения происходят более медленно, чем в «лобовом» детектировании киберугроз. Многообещающим кандидатом на автоматизацию является обработка подозрительных событий (триаж).
Воронка детектирования
Чтобы иметь достаточно данных для обнаружения сложных угроз, современная организация в рамках своего SOC вынуждена ежедневно собирать миллионы событий с сенсоров в сети и на подключенных устройствах. После группировки и первичной фильтрации алгоритмами SIEM эти события дистиллируются в тысячи предупреждений о потенциально вредоносной активности. Изучать предупреждения обычно приходится уже людям, но реальные угрозы стоят далеко не за каждым таким сообщением. По данным сервиса Kaspersky MDR за 2023 год, инфраструктура клиентов генерировала миллиарды событий ежедневно, при этом за весь год из них было выделено 431 512 предупреждений о потенциально вредоносной активности. Но лишь 32 294 предупреждения оказались связаны с настоящими инцидентами ИБ. То есть машины эффективно просеяли сотни миллиардов событий и лишь ничтожный процент из них отдали на просмотр людям, но от 30 до 70% этого объема сразу помечаются аналитиками как ложные срабатывания, и около 13% после более глубокого расследования оказываются подтвержденными инцидентами.
View the full article
-
От 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
-
От yare4kaa
Здравствуйте, был в рейсе и не чистил пк от вирусов, заразился много фигней, нужна помощь специалистов.
Логи ниже CollectionLog-2024.11.25-18.32.zip
-
От Qray
Здравствуйте, недавно слетела активация виндовс 10 и я как обычно скачал кмс активатор с того же сайта, с которого скачивал и до этого. Система активировалась, все хорошо. Сегодня заметил, что компьютер в простое сильно шумит. А именно куллер видеокарты. Зашел в диспетчер задач - загрузка цп и гп обычная, но температура гп около 67 градусов. (ранее при активации системы кмсом такого не наблюдалось) Далее начали провялятся другие интересные симптомы: При попытке поиска информации об удалении вируса тупо закрывается эдж, также через некоторое время закрывается диспетчер задач и почти сразу начинается нагрев. Поискав информацию в интернете на другом пк наткнулся на эту тему, прочитал порядок оформления запроса о помощи делаю все по инструкции (пытаюсь по крайней мере) Скачал автологгер, запустил процесс, получил нужный файл. Но при этом перезагрузка системы не происходила (система 64 бит виндовс 10)
Приклепляю файлы из автолггера и FRST. Помогите пожалуйста 🥺
CollectionLog-2024.12.29-14.21.zip Addition.txt FRST.txt
-
От 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
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти