-
Похожий контент
-
Автор KL FC Bot
Сейчас практически невозможно представить себе современную компанию, которая не рассказывает о применении искусственного интеллекта. Причем маркетологи далеко не всегда утруждают себя объяснением того, зачем ИИ в продукте нужен, а главное, как именно он там реализован, — им кажется, что самого факта применения достаточно для того, чтобы сделать продукт более ценным, инновационным и высокотехнологичным. Мы сторонники другого подхода — нам важно не просто сказать «у нас есть ИИ», а объяснить, как именно технологии машинного обучения и искусственного интеллекта применяются в наших решениях. Перечислять все наши ИИ-технологии в одном посте было бы слишком долго — у нас есть целый центр экспертизы AI Technology Research, который занимается различными аспектами ИИ. Поэтому в данном материале я сосредоточусь исключительно на технологиях, облегчающих жизнь SIEM-аналитика, работающего с Kaspersky Unified Monitoring and Analysis (KUMA).
SIEM AI Asset Risk Scoring
Традиционно одной из самых ресурсоемких задач аналитика SIEM является приоритизация алертов. Особенно если система только установлена и работает с дефолтными правилами корреляции из коробки, пока еще не подогнанными к реалиям конкретной компании. Помочь с этой проблемой могут технологии анализа больших данных и системы искусственного интеллекта — благодаря модулю SIEM AI Asset Risk Scoring команды мониторинга и реагирования могут определять приоритеты алертов и предотвращать потенциальный ущерб. Этот модуль служит для оценки рисков активов путем анализа исторических данных и тем самым помогает приоритизировать входящие оповещения, что, в свою очередь, ускоряет проведение триажа и позволяет генерировать гипотезы, которые можно использовать для проактивного поиска.
На базе информации об активируемых цепочках правил корреляции SIEM AI Asset Risk Scoring позволяет строить паттерны нормальной активности на конечных точках. Затем, сравнивая с этими паттернами повседневную активность, модуль выявляет аномалии (например, резкие скачки трафика или множественные обращения к сервисам), которые могут говорить о том, что происходит реальный инцидент и аналитику следует глубже изучить именно эти алерты. Это позволяет обнаружить проблему на ранней стадии, до того как будет нанесен ущерб.
View the full article
-
Автор KL FC Bot
В попытке обойти механизмы защитных решений злоумышленники все чаще прячут вредоносные и фишинговые ссылки внутрь QR-кодов. Поэтому в решение [KSMG placeholder] Kaspersky Secure Mail Gateway [/placeholder] мы добавили технологию, способную «читать» QR-коды (в том числе и спрятанные внутрь PDF-файлов), доставать из них ссылки и проверять их до того, как они окажутся в почтовом ящике сотрудника компании. Рассказываем, как это работает.
Пример фишингового QR-кода внутри PDF-файла
View the full article
-
Автор KL FC Bot
В июле 2024 года Mozilla вместе с новой версией своего браузера Firefox представила технологию, которая называется Privacy-preserving attribution (атрибуция с сохранением приватности) и предназначена для отслеживания эффективности интернет-рекламы. Она включена по умолчанию в Firefox 128.
Это довольно быстро привлекло внимание поборников онлайн-приватности и привело к появлению в новостях заголовков вроде «Теперь и Mozilla начинает продавать данные пользователей». Шумиха поднялась настолько серьезная, что техническому директору Firefox Бобби Холли пришлось объясняться с пользователями Reddit, что же на самом деле Mozilla сделала и зачем.
Самое время разобраться более подробно, в чем суть технологии Privacy-preserving attribution, зачем она вообще нужна и почему в Mozilla решили представить ее именно сейчас.
Google Ad Topics и «История ссылок» в Facebook*
Начну с предыстории. Как вы, возможно, помните, разработчики самого популярного в мире браузера — Google Chrome — еще с 2019 года вынашивают планы по полному отключению поддержки сторонних cookies.
Эта технология уже третье десятилетие повсеместно используется для отслеживания действий пользователей в Интернете. Так что, с одной стороны, она является основой индустрии онлайн-рекламы, а с другой — главным инструментом нарушения приватности пользователей.
В качестве замены сторонних cookies некоторое время назад Google представила собственную разработку под названием Ad Topics. В рамках этой технологии отслеживание пользователя происходит на основе истории браузера Chrome и истории взаимодействия пользователя с приложениями в Android. Предполагалось, что благодаря внедрению Ad Topics поддержку сторонних cookies в браузере отключат уже во второй половине 2024 года.
Другой крупнейший игрок индустрии цифровой рекламы, компания Meta**, которая также полагается на сторонние куки, придумала собственный вариант слежки за пользователями. Это так называемая История ссылок: все внешние ссылки в мобильных приложениях Facebook* теперь открываются во встроенном в приложение браузере, где компания все еще может следить за действиями пользователя.
Что в итоге получается: в результате отключения поддержки сторонних cookies преимущество получают те участники рынка интернет-рекламы, у которых есть какое-либо крупное, полностью контролируемое ими цифровое пространство: самые популярные в мире браузер и ОС в случае Google, самая популярная соцсеть в случае Meta**. Более мелкие игроки при этом оказываются в зависимом положении.
При этом данные пользователей все равно продолжают собирать в промышленных масштабах. И делают это все те же компании, к которым обычно и предъявляют основные претензии с точки зрения нарушения приватности, — Google и Facebook*.
Возникает вопрос: а нельзя ли разработать какой-то механизм, который одновременно позволит рекламодателям отслеживать эффективность рекламы и при этом не предполагает массовый сбор данных пользователей? Ответом именно на этот вопрос и является технология Privacy-preserving attribution.
View the full article
-
Автор KL FC Bot
Утечки учетных данных остаются одним из самых популярных у злоумышленников способов проникновения в организацию. Только за 9 месяцев 2023 года по данным Kaspersky Digital Footprint Intelligence в даркнете было опубликовано 315 миллионов записей учетных данных, среди которых множество реквизитов доступа к корпоративным ресурсам, в том числе и к ресурсам компаний из списка Fortune 500. Чтобы эффективнее управлять связанными с этим рисками, минимизировать число уязвимых аккаунтов, быстрее замечать и пресекать несанкционированный доступ, компании внедряют системы управления identity, о которых мы подробно писали ранее. Но эффективный процесс управления identity невозможен, пока большинство корпоративных систем не поддерживают процедуру унифицированной аутентификации. Для внутренних систем компании она обычно завязана на централизованный каталог, например Active Directory, а во внешних SaaS-системах взаимодействие с корпоративным каталогом identity ведется через платформу Single Sign-on (SSO) —либо внешнюю, либо развернутую в инфраструктуре компании, такую как ADFS.
Для сотрудников это предельно удобно — логинясь во внешние системы, такие как SalesForce или Concur, сотрудник проходит единый для корпоративной сети процесс аутентификации, включая ввод пароля и предъявление второго фактора (кода OTP, USB-токена и так далее, согласно корпоративной политике), ему не нужны никакие дополнительные логины и пароли. Более того, однократно войдя утром в одну из систем, в остальные можно входить автоматически. Помимо удобства этот процесс в теории безопасен, поскольку службы IT и ИБ имеют полный централизованный контроль над учетными записями, парольными политиками, методами МФА и логами.
Но на практике уровень безопасности внешних систем, поддерживающих SSO, зачастую оказывается не таким уж высоким.
Подводные камни Single Sign-On
Пока пользователь входит в SaaS-систему, сервер этой системы, клиентское устройство пользователя и платформа SSO проходят несколько этапов взаимодействия, в которых платформа SSO проверяет пользователя и выдает SaaS-системе и клиентскому устройству токены аутентификации, которые подтверждают права пользователя. При этом платформа может снабжать токен целым рядом параметров, напрямую влияющих на безопасность. Они могут включать:
указание периода действия токена (и сессии), по истечении которого потребуется повторная аутентификация; привязка токена к конкретному браузеру или мобильному устройству; привязка токена к конкретным IP-адресам или IP-диапазонам, что позволяет реализовать в том числе географические ограничения; дополнительные условия окончания сессии, например закрытие браузера или выход пользователя из самой SSO-платформы. Ключевая проблема заключается в том, что некоторые облачные провайдеры неверно интерпретируют или вовсе игнорируют эти ограничения, нарушая таким образом модель безопасности, которую выстроила команда ИБ. Более того, в ряде случаев SaaS-платформы недостаточно контролируют корректность самих токенов, открывая простор для их подделки.
Посмотреть статью полностью
-
Автор DeniTornado
Доброго всем!
Переходим на KES с другого продукта. На данный момент активно изучаю справочные материалы. Делаю по шагам, но есть нюансы, вопросы и проблемы. Прошу помочь советом или информацией по данным вопросам на текущий момент
Дано:
Облачный Kaspersky Endpoint Security для Бизнеса расширенный. Настроена Облачная консоль для управления. В локальной сети на отдельно взятый сервер установил агент администрирования и объявил его Точкой распространения. Из AD импортировал группы и создал структуру групп как для доменных, так и для ПК не в домене (сервисники, командировочники и т.п.). На несколько ПК уже установил агентов и сам антивирус, подкорректировал немного политики по умолчанию.
Теперь вопросы и проблемы:
1) Создаю задачу удаленной установки Агента и кидаю ей в ПК. В свойствах задачи выбираю "Средствами операционной системы с помощью точек распространения" (т.к. агента еще ведь нет). Указываю на какой ПК ставить и указываю, учетные данные для установки - локального админа ПК получателя задачи. Задача отправляется и через минуту ошибка - "Distribution point "SRV-KES-01" has failed to start remote installation. Installation package download from the Administration Server to the shared folder on the device returned an error: Adminis, .\Adminis, Firma\Adminis, <Учетная запись службы Агента администрирования Kaspersky Security Center 14.2> (Отказано в доступе.) No more distribution points have been found.". Если указать в задаче учетные данные доменного админа, то задача отрабатывает нормально. Вот и не понимаю, почему данные локального админа на ПК получателе не нравятся установщику?
2) Некоторые ПК после импорта их из AD все равно имеют состояние "Не видим в сети". Хотя эти ПК включены и с других ПК и серверов в локальной сети нормально пингуются! Что влияет на эту видимость? Какие условия должны быть соблюдены? Это KES через Точку Распространения делает по ICMP или подтягивает как-то по другому?
3) Уже не помню как это у меня получилось.... Столько всего делал уже, но вроде после отработки Мастера первичной настройки. Если зайти в Обнаружение устройств и развертывание-Развертывание и назначение-Инсталляционные пакеты, провалиться например в пакет для Агента под Windows, то внутри есть вкладка "Автономные пакеты" и там есть пакет Агента который я могу скачать и установить в ручную на любом ПК. Но если например, зайти в свойства пакета самого Антивируса KES 12.1 на ту же вкладку, то там пусто. И Как мне получить автономный пакет для самого антивирусного продукта? В Идеале иметь бы такой пакет установки, запустив который вручную на ПК он поставил стразу и агент и сам антивирь за раз. Не нашел как сделать доступным для скачивания пакет для антивируса!
4) Агент администрирования нельзя распространять через GPO в домене AD? В справке вообще не нашел по этому ни строчки! Где MSI? Он есть в природе?
5) Ну и пока странность на MAC Mini моем рабочем. Поставил на него агента через скаченный автономный пакет SH скрипт. Потом через консоль поставил сам антивирус средствами уже самого агента. После первого запуска, я понажимал кнопки Разрешить в интерфейсе антивируса на MAC OS и нажал установить некий сертификат, чтобы Каспер мог HTTPS смотреть. Сертификат вроде как проставился. Но просмотр HTTPS так и не работает
Жмешь Разрешить, вводишь пароль админа MAC OS и все равно такая картина. Не включается HTTPS анализ! Как победить?
Версия MAC OS Ventura 13.4.1. Версия антивируса, который я поставил через облачную консоль - 11.3.0.320a.
Просьба кто знает по какому-либо из вопросов помочь. Буду крайне признателен.
Спасибо!
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти