В России внедрен инновационный механизм защиты организаций от киберугроз.
Ежедневно специалисты обнаруживают около 60 новых уязвимостей в программном обеспечении, что создает серьезный вызов для служб информационной безопасности. Успевает ли ваша организация? Для решения этой проблемы ГРЧЦ запустил специализированный внешний сканер безопасности, работающий по принципу External attack surface management (EASM). Этот инструмент проверяет внешние IP-адреса компаний на наличие потенциальных угроз, доступных через интернет.
Ключевая задача для специалистов по безопасности - опережать злоумышленников в обнаружении уязвимостей. При этом ИТ-отделы должны своевременно обновлять и настраивать системы для минимизации рисков внешнего доступа к уязвимостям. Этот комплексный подход, известный как Vulnerability Management, стал необходимым стандартом кибербезопасности.
Понимая, что не все организации имеют ресурсы для постоянного внешнего мониторинга, Центр мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) ФГУП «ГРЧЦ» взял на себя эту функцию. На данный момент более 300 организаций получили уведомления о выявленных уязвимостях в их системах, что позволило им принять необходимые меры защиты. Такой подход существенно укрепляет как безопасность отдельных компаний, так и киберзащиту страны в целом.
Эту информацию представил Сергей Хуторцев, директор ЦМУ ССОП ФГУП «ГРЧЦ», во время своего выступления на СПЕКТР ФОРУМЕ, который прошел 23-24 октября 2024 года в Сочи.
В России развернута Национальная система противодействия DDoS-атакам (НСПА) и она показывает свою эффективность уже два года.
Самая масштабная DDoS-атака
2023 год: 150 гигабит в секунду и 16 миллионов пакетов в секунду
2024 год: 1730 гигабит в секунду и 155 миллионов пакетов в секунду
Самая продолжительная DDoS-атака
2023 год: 24 часа
2024 год: 73 часа
Статистику по атакам предоставил Центр мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) ФГУП «ГРЧЦ» на конференции СПЕКТР ФОРУМ 23-24 октября 2024 года.
Здесь видно как расходятся публичные данные из рекламы и реальные результаты тестов. Ideco в тесте серьезно просело по производительности с 5 официальных до 0,75 реальных Гбит/с.
После скачивания архива картинок из Google Photo через Google Takeout (Google Архиватор) у многих встает проблема, что все файлы с картинками и видео имеют текущую дату создания, а не реальную дату, когда фотка была сделана.
Реальную дату, когда фотка снята можно посмотреть в EXIF полях самого JPG файла. Время будет указано по часовому поясу той локации, где вы находились. Для этого в MacOS кликните два раза на сам файл JPG и когда картинка откроется для просмотра, нажмите кнопку i
Одновременно, если посмотреть json файл, приложенный к данной картинке добрыми программистами Google, то в нем есть дата и время:
"photoTakenTime": {
"timestamp": "1540712405",
"formatted": "28 окт. 2018 г., 07:40:05 UTC"
},
Однако, эта дата еще и испорчена - она написана в часовом поясе UTC (единое мировое время). И время по UTC тоже есть в EXIF заголовке. (Кстати, для меня загадка почему время не совпадает между EXIF полями в самом JPG файле: 7:39 и 15:40 - разница в 1 минуту)
Получается, чтобы поправить время из JSON файла в UTC надо еще считать и GPS координаты и поменять на нужный часовой пояс. Они там тоже есть:
"geoData": {
"latitude": -8.500833300000002,
"longitude": 114.96166670000001,
"altitude": 39.0,
"latitudeSpan": 0.0,
"longitudeSpan": 0.0
},
И если вы хотите сделать все даты верными, то это грандиозный труд над 363 гигабайтами архивов, как у меня.
Что делать?
1. За 24 доллара купить MetaData Fixer for Google Takeout. Данная утилита возьмет ваши ZIP файлы, разархивирует и сама поменяет время и затем вторым шагом справит время на соответствующую Тime Zone. Это выглядит для меня странно - зачем два раза обращаться к файлу, если можно было сразу и время поменять и временную зону.
2. За 20 долларов купить Photo Exifer прямо из Apple Store:
В реальных сетях невозможно, чтобы все устройства устанавливали все сессии одновременно. Даже при тестировании на скорости 400 Гбит/с нельзя подавать все 400 Гбит/с и одновременно открывать 1 000 000 сессий в секунду, так как это приведет к DDoS-атаке, которая может вывести из строя NGFW без должной защиты. NGFW подвержены атакам, основанным на большом количестве новых сессий. Чтобы предотвратить это, разработчики внедряют защиту от DoS на интерфейсах.
Для эффективного тестирования NGFW необходимо использовать стадию RAMP UP, которая предполагает постепенное увеличение количества новых соединений через тестируемое устройство.
Этапы тестирования Throughput на IXIA
Тестирование Throughput включает три ключевых этапа: RAMP UP, STEADY и RAMP DOWN.
RAMP UP: На этом этапе происходит плавный рост всех параметров. Например, открывается 100 новых сессий в секунду с целью достичь 1000 одновременных сессий. Этот процесс занимает несколько минут.
STEADY: На основном этапе мы продолжаем подавать необходимый трафик в уже установленные сессии, имитируя типичную работу сети. Это может длиться от нескольких минут до суток, чтобы удостовериться в стабильности устройства под максимальной нагрузкой. Если тест STEADY длится всего несколько минут, это может свидетельствовать о неуверенности поставщика. Длительное тестирование позволяет выявить утечки памяти, что может привести к перезагрузке устройства.
RAMP DOWN: На заключительном этапе мы плавно завершаем все сессии через TCP FIN или RST. Этот процесс также занимает несколько минут.
При тестировании двух NGFW в режиме HA Active-Passive, когда активное устройство выходит из строя, весь трафик перенаправляется на резервное устройство. Даже в этом случае не все сессии будут пытаться открываться одновременно. Если первая попытка не удалась, сессия будет повторно запускаться через несколько секунд.
Если ваша цель — тестирование на CPS, возможно, вам потребуется создать 1000 новых сессий в секунду, чтобы оценить реакцию устройства, его процессора, буферов памяти, лог-коллекторов и дисков. Важно также учитывать, какой функционал включен для каждой сессии. Показатель CPS будет снижаться по мере увеличения объема анализа, выполняемого NGFW, включая DPI, URL, OCSP, SSL, IPS, AV и TI.
Выражаю благодарность компании Bi.Zone и Код Безопасности за достаточно смелую публикацию результатов тестирования. Поскольку я фанат NGFW и занимаюсь защитой сетей с 1998 года, то мне было интересно узнать подробности.
PS: Ко мне обратились коллеги из Кода Безопасности. Оказалось, что схема стенда в отчете - верна только для тестов с 5 по 10. Тесты с 1 по 3 проводились на том же стенде, где включен один межсетевой экран. По 4 тесту сейчас без схемы непонятно что там было с чем соединено и как физически и логически тестировался LAG.
Аппаратная часть
Коллеги создали мощный стенд:
кластер из двух L3 коммутаторов Eltex MES5500-32 версия
ПО — 6.6.2.9;
кластер из двух сетевых балансировщиков DS Integrity-100G (каждый разделен логически пополам);
кластер из 16 устройств межсетевого экранирования IPC-R3000 версия ПО — 4.1.9
В качестве генератора трафика были выбраны генераторы трафика Ixia Cloud Storm и Novus 100G с генератором XGS2-HSL2 с карточками L4 и L7. Напомню, что IXIA использует FPGA для ускорения работы.
Устройство IXIA.
Функционал межсетевого экрана
Само межсетевое экранирование производилось по IP портам, то есть функционал блокирования приложений движком DPI не тестировался.
Я, конечно, хотел уже дальше не читать отчет... И я думаю вы тоже.. но природная любознательность заставила... Причина проста: большинство приложений сегодня работает по 443 порту и вам обязательно нужна контентная фильтрация, потому что по портам вы либо просто запрещаете этот порт, либо просто разрешаете. И это уже не работает. Чтобы не повторяться: прошу прочитать про это статью "Межсетевой экран нового поколения - это маркетинг", где приведены какие это 173 приложения работают на 443 порту из реальной сети. То же самое с 80 портом.
Число правил для теста выбрано 1000, что подходит для небольших заказчиков.
Но поскольку производительность ожидалась 400 Гбит/с, то 1000 правил я бы поменял на 10000. Самое большое количество правил, что я видел в своей жизни - 120000. А сколько вы видели? ) Предлагаю сделать такой же тест на 10000 и 100000 правил.
Тесты
В ходе проверок было проведено 10 различных тестов.
Основные тесты это: 1. Максимальное число успешно открытых новых TCP соединений в секунду в режиме L4; 2. Максимальное число одновременных TCP соединений в памяти в режиме L4; 3. Максимальная пропускная способность в режиме L7 (DPI) без маршрутизации, с маршрутизацией, с NAT и без NAT, с IPS и без IPS; 4. Проверка потерь сессий при выходе из строя устройства; 5. Максимальная пропускная способность в режиме L4 на UDP; И еще пять, что описано на 11 странице отчета.
Результат 26 Гбит/с в режиме DPI и SNAT на 1 межсетевом экране
Поскольку было 73000 транзакций в секунду, то это в среднем 35Кб на транзакцию.
Сам поток трафика состоял из различных приложений, вот их список и процент разбивки в самом потоке.
19.21% 115348 байт транзакции TLS 1.2, без расширования 15.37% 26184 байт транзакции Google Search GET Home Page - я так понимаю это тоже TLS 14.09% 6267 байт транзакции Yahoo Search GET Home Page - я так понимаю это тоже TLS 12.81% 12450 байт транзакции TLS 1.2, без расшифрования
2.56% 217403 байт транзакции GMAIL и это тоже TLS
В итоге 64% трафика был зашифрованный поток данных в TLS, в котором чаще всего нечего проверять фильтру контента, кроме TLS Handshake где можно глянуть версии TLS, SNI и URL категории. Это все не проверялось. По распределению TLS 1.2 и TLS 1.3 в интернет лучше посмотреть на сайте ssllabs.com/ssl-pulse/ на момент прочтения статьи.
Скриншот из интерфейса IXIA, где показаны настройки тестового трафика.
Результат 4 Гбит/с IPS на 1 устройстве
На мой взгляд, тестировать производительность IPS просто подачей трафика - некорректно. Нужно еще проверять, что на этом максимальном потоке трафика IPS вообще как-то работает - то есть блокирует атаки. А то, что у нас есть устройство, которое просто быстро пропускает трафик - и что? )
В других тестах мы выявляли, что при подаче трафика IPS перестает блокировать атаки. И поэтому я бы добавил еще в тест страйки IXIA. И именно так - только вместе с атаками мы понимаем максимальную производительность IPS.
Скриншот IXIA где показано сколько атак заблокировано и сколько пропущено.
Павел Луговов на конференции SSTA в Бизон отлично рассказал как правильно тестировать атаки и вирусы в трафике. Также Владислав Закревский на той же конференции показывал как падает производительность Suricata при подаче трафика.
Четыре неожиданных результата
1. Выяснилось, что сам генератор IXIA максимально может выжать 200 Гбит/с в режиме L7. Поэтому пришлось выключать генерацию трафика приложений и переходить на режим L3 без проверки, что сессии были реально уставлены.
Если кто-то из производителей говорит, что у него больше 200 Гбит/с NGFW, то спросите их чем они трафик приложений генерировали. ;-) Вдруг yandex-tank.
2. Выяснилось, что пакетный брокер тоже пропускает не бесконечно много трафика: он достиг производительность 400 Гбит/с для двунаправленного трафика. Поэтому если вы тестируете такой трафик, то вам нужно ЧЕТЫРЕ пакетных брокера.
3. Одна система управления не справляется с журналированием такого объема трафика: 400 Гбит/с.
4. Уперлись в ограничения BGP в коммутаторе Eltex. Ну и какие-то проблемы с ICMP (подробнее описывает 32 страница отчета).
Вывод
Ставить 16 межсетевых экранов и балансировать их - непростое решение для технических специалистов. Как написано в отчете Bi.Zone, отлаживать проблемы было почти невозможно - не проходил ICMP длиной 64 байта через стенд, не было возможности запустить сниффер трафика на Eltex. В эксплуатацию я бы такое не принял.
Тестирование на UDP трафике - это самое странное, что можно делать при выборе межсетевого экрана, ведь в реальной сети такого трафика нет. Тестировать то, чего не бывает? Чтобы что? ) Я догадываюсь, что для того, чтобы впечатлить непрофессионалов. Это все равно что, тестировать производительность поликлиники, где люди входят и сразу выходят. Очень быстрая поликлиника. Скоро видимо у нас и такие будут. А полечиться? Впрочем, я уже писал про это.
Поэтому если вам где-то пишут производительность на UDP 1500 байт (или в PPS или FPS) - шлите их лесом. Так делают Check Point и Fortinet? Вот их и шлите. Это делают их люди из маркетинга. И скажите этим людям то, что написано ниже:
Самое важное в NGFW - это Threat Protection или Threat Prevention Troughput.
Это тот самый параметр производительности, который нужен заказчику.
Рынок РФ должен целиться в создание высокоростных устройств: которые в одном устройстве дают нужную производительность.
В итоге, я бы лучше купил PA-3440 две штуки и поставил в кластер HA, чем всю эту огромную конструкцию из 21 устройств. Во первых займет всего 2 юнита, во-вторых производительность даже больше в тесте trhoughput и new sessions, в третьих и питания нужно меньше. И самое главное - там будет настоящий HA где будут синхронизироваться состояния сессий. А в данном решении такого не было.
Посмотрите, число одновременных сессий у Palo Alto 3 000 000, но как мы знаем это в режиме L7, когда запоминается состояние приложений L7. Число одновременных сессий в режиме L4 и L7 отличается минимум в 10 раз, потому что в режиме L7 на состояние сессий нужен буфер большего обмена при той же памяти устройства. Поэтому 10 0000 000 сессий в тесте выше в режиме L4 будет падать до 1 миллиона сессий в режиме L7.
PS: Одна важная вещь
Когда вы смотрите datasheet или когда вы смотрите тесты независимой лаборатории, то учитывайте, что все строки - это РАЗНЫЕ тесты. Не существует такого устройства, которое одновременно дает 10 миллионов TCP сессий, одновременно при этом 150000 новых сессий и одновременно при этом 28 Гбит/с. Это все результаты трех РАЗНЫХ тестов на РАЗНОМ трафике, пусть для одного и того же устройства. Подавался разный трафик и тестировалось РАЗНОЕ. В реальной жизни эти числа достигнуты НЕ БУДУТ все одновременно.
Например, тут - три разных теста.
Для погружения в тестирование NGFW рекомендую серию из трех видеороликов
Как проходит тестирование
Как смотрят параметры CC, CPS, Throughput разные поставщики
Разбираемся с размером транзакций через тесты NSS Labs
Как правильно оценить производительность NGFW: путеводитель по метрикам безопасности сети
Введение: аналогия с поликлиникой
Представьте себе поликлинику, способную пропускать 360 пациентов в час или одного в секунду. Звучит впечатляюще, не так ли? Но отражает ли это реальную эффективность медицинского учреждения? Конечно, нет. Ведь мы понимаем что за 1 секунду нельзя проверить здоровье человека и тем более вылечить. Это бессмысленный параметр, показывающий производительность входной двери, но не поликлиники в целом. Аналогичная ситуация складывается с оценкой производительности устройств сетевой безопасности, таких как Next-Generation Firewall (NGFW). Высокие значения пропускной способности поначалу впечатляют, а после изучения вызывают недоумение.
Ключевые факторы влияющие на производительность NGFW
Движки проверки трафика:
DPI (Deep Packet Inspection)
User-ID
IPS (Intrusion Prevention System)
URL-фильтрация
Антивирусная защита
Threat Intelligence
Песочница (Sandbox)
Преобразование зашифрованного трафика и сертификатов:
IPSEC туннели
SSL-шифрование
Почему "сырые" показатели скорости могут вводить в заблуждение?
Производительность NGFW, измеренная только на UDP-пакетах или в пакетах в секунду, подобна оценке работы поликлиники по скорости входа и выхода пациентов. Эти метрики не учитывают реальные процессы обработки данных и обеспечения безопасности.
На что обратить внимание при выборе NGFW?
Ключевой показатель: Threat Prevention или Threat Protection (TP)
При изучении технических характеристик (datasheet) NGFW, обратите особое внимание на параметр "Threat Prevention" или "Threat Protection". Это наиболее важный показатель, отражающий реальную скорость проверки сетевых пакетов на наличие угроз.
Заключение
Выбирая NGFW для защиты вашей сети, не поддавайтесь соблазну "сырых" показателей производительности: на UDP пакетах, Packet Per Second (PPS) Frame Per Second (FPS). Сосредоточьтесь на метриках, отражающих реальную способность устройства, чтобы затем обеспечивать комплексную защиту при реальных рабочих потоках трафика.
Для более глубокого понимания темы рекомендуем ознакомиться с видеоматериалами, демонстрирующими практические примеры оценки производительности NGFW.
Создатель мессенджера Telegram, миллиардер Павел Дуров арестован в аэропорту Парижа. Об этом сообщает французский новостной канал LCI.
Вот что пишут французы (переведено в google translate):
«На своей платформе он допустил совершение бесчисленных правонарушений и преступлений, в отношении которых он не предпринимал никаких действий для модерации или сотрудничества», — анализирует источник, близкий к делу.
Telegram — это улей криминального контента. В настоящее время платформа фигурирует в новостях с нелегальной трансляцией матчей Лиги 1. Но на этом сервисе зашифрованных сообщений многие учетные записи используются организованной преступностью. Помимо терроризма, самые опасные дети-преступники общаются в Telegram для обмена контентом. «За долгие годы она стала платформой номер 1 для организованной преступности», — комментирует следователь.
В мире киберугроз происходит нечто удивительное: хакеры сами стали жертвами своих собственных уловок! Как это возможно? Давайте разберёмся.
Современные вредоносные программы очень хитрые: они проверяют, установлены ли на компьютере средства анализа, такие как отладчики или виртуализация. Если такие инструменты обнаружены, вредоносное ПО просто останавливается, думая что его уже обнаружили или что оно работает в песочнице для анализа.
И на сцену выходит Киберпугало — ваш защитник в мире киберугроз! Эта программа работает в фоновом режиме, «подделывая» индикаторы работы защитных средств. Вредоносные программы начинают думать, что ваш компьютер не подходит для атаки и не запускаются.
- Киберпугало запускает поддельные процессы, которые выглядят как инструменты для анализа безопасности, но на самом деле ничего не делают.
- Киберпугало создает фиктивные записи в реестре Windows, создавая иллюзию, что на вашем компьютере установлены средства защиты.
Это только начало! Уже сейчас Scarecrow демонстрирует потрясающие результаты.
В мире кибербезопасности важно быть на шаг впереди. Киберпугало — ваш надежный союзник в борьбе с вредоносными программами. Читайте блог, чтобы узнать больше о том, как защитить себя в этом опасном цифровом мире!
Цикл хайпа по Gartner. Где SOAR многие разочарованы.
SOAR жив: Развенчиваем мифы о судьбе Security Orchestration, Automation and Response
В мире кибербезопасности появились слухи о "смерти" 😱SOAR (Security Orchestration, Automation and Response) после некоторых заявлений Gartner. Давайте разберемся, что происходит на самом деле и почему SOAR остается важным инструментом для специалистов по безопасности.
Что на самом деле сказал Gartner о SOAR
😱Странные слухи, что Gartner чуть ли не убил весь класс продуктов SOAR. С чего вы взяли? 🚫 Gartner всего лишь не планирует публиковать Magic Quadrant для SOAR. Исследование Gartner по IT-услугами (ITSM) указывает на неудовлетворенность специалистов по безопасности и устаревшими продуктами и решениями SOAR. А с тем же SIEM такого никогда не было? Я помню тех людей, которые покупали SIEM и потом ждали что у них сами люди обучатся инциденты расследовать и процессы наладятся сами - а оказалось, что это тоже работа менеджмента.
Критика ограничений SOAR: Насколько она обоснована?
В отчете Gartner отмечены следующие критические ограничения SOAR:
Высокие первоначальные затраты на установку и внедрение. А SIEM или NGFW прямо с полпинка внедряется? ;)
Высокие затраты на поддержку и обслуживание. Даже так? ) По сравнению с чем? ) А переписывать питон скрипты при смене API - это прямо совсем недорого? )
Требование наличия специалистов с обширными навыками программирования. А они вообще пробовали SOAR или что-то из области No-Code? )
Проблемы интеграции и совместимости с инструментами третьих сторон. Это да, согласен, но это общая проблема рынка, а не только продуктов SOAR. Так ведь SOAR и создан, чтобы эту проблему решать.
Нереалистичные ожидания, что SOAR может решить все проблемы безопасности как автономное решение. А от других продуктов значит ожидания реалистичные? )
Мое понимание, что в Gartner просто не нашлось специалиста, который смог адекватно оценить и сравнить продукты этого класса, как это смог сделать Антон Чувакин для SIEM в свое время. Я почитал их отмазку "Недостаточная зрелость рынка: SOAR как категория технологий находится на стадии формирования. Gartner предпочитает дождаться более четкой картины для создания качественной и информативной оценки" ЧТО?! ) ДА ЛАДНО! 😆
История и развитие SOAR: От инновации до зрелого решения
Я прекрасно настраивал людям Cortex XSOAR и это был прекрасно сформировавщийся продукт и его сделала изначально компания Demisto. Людям было удобно подключать молодых сотрудников к процессам, на основе готовых плейбуков, и которые молодежь даже не знала как работают, и они учились по этим плейбукам старших товарищей - это позволяет быстрее адаптировать нового сотрудника в SOC. Спасибо, SOAR.
Я прекрасно помню как на конференции RSA я был под впечатлением от выступления компании Phantom, которая и придумала идею SOAR - цеплять всех вендоров через API и управлять ими через плейбуки. Удобная автоматизация и оркестрация - это мечта любого специалиста.
Phantom выступал на RSA Conference еще в 2016 году 🔥, где был назван "Самым инновационным стартапом" конференции. Это признание было получено в результате конкурса, в котором участвовало 10 финалистов, и Phantom был выбран победителем жюри, состоящего из венчурных капиталистов и экспертов в области безопасности.
И Splunk потом купил Phantom.
Будущее автоматизации кибербезопасности: SOAR vs AI
Gartner считает, что нужно смотреть на более зрелые решения класса AI. Да, пусть AI угадывает параметры XML для новой версии API вендора - ведь проблема то в этом.
Инструменты автоматизации рабочих процессов должны преобразовывать события в оповещения для администраторов, создавать каналы связи между разными типами устройств защиты, обновлять статус инцидента в реальном времени. В общем очередная мечта об одной красной кнопке "сделать все" умерла....
Ну так это не проблема класса продуктов, это работа человеческой психологии. Могут ли сегодняшние средства защиты устранять проблемы в один клик для сценария, например, когда все Windows лежат в синем экране от CrowdStrike бага? Нет.
Несмотря на критику, SOAR продолжает играть важную роль в современной кибербезопасности.
Что вы думаете о будущем SOAR? Поделитесь своим опытом использования этих инструментов в комментариях.
Сегодня мы вынуждены констатировать ситуацию, что хакеры находят способы проникать в корпоративные сети. Например, они воруют логин и пароль сотрудника и заходят во внутреннюю сеть через наш VPN шлюз, и работают от имени легитимного пользователя и забирают данные компании легитимными утилитами. Так было во время взлома Uber и Cisco, и многих российских компаний, которые пожелали остаться неизвестными.
Поэтому задача команды SOC сегодня – как можно быстрее 🙈 обнаружить, что злоумышленник уже в сети.
Существует несколько вариантов получения сигналов в SIEM, SOAR, IRP (и SOC), о том, что злоумышленник уже в сети.
Самый быстрый эффект дают системы, использующие поведенческий анализ, профилирование действий и также ловушки (Deception), поскольку в них работают поведенческие алгоритмы. Если вредоносный код можно заново скомпилировать под компанию и скрыть его, то вредоносное поведение в сети изменить сложно. Именно на это нацелены эти классы решений. Рассмотрим эти варианты:
1. Сравнение типового поведения пользователей и выявления паттернов вредоносной деятельности в их действиях. Важно, что NDR работает как в корпоративной сети, так и ICS/SCADA, ведь пользователи и там и там буду использовать сеть:
передача злонамеренных программ с хоста на хост – это модуль проверки передаваемых файлов в протоколах SMB, FTP, HTTP, SMTP, POP3, IMAP. В SMB и FTP часто можно увидеть передачу программ удаленного управления и криптолокеров; cистемы класса NDR позволяют своевременно остановить такое распространение и изолировать хост и аккаунт атакующего;
lateral movement, когда злоумышленник с одного хоста пытается залогиниться на другой хост, к которому ему не нужен доступ по работе, или не было доступа ранее; Deception и NDR своевременно это обнаруживают и блокируют;
скачивание аномального большого объема данных с серверов или отправка данных в Интернет на внешние ресуры;
появление несанкционированных устройств, которые ранее не были зарегистрированы ИТ службой (Shadow IT);
использование известных уязвимостей – выявляется модулем IDS встроенным в такие системы;
использование Zero Day выявляется постфактум, во время разбора инцидента, поскольку система полностью записывает трафик;
использование Zero Day в файлах минимизируется за счет интеграции с песочницей и проверкой всех новых файлов в компании на системах поведенческого анализа;
контроль исходящих соединений из сети в Интернет на основе уже известных баз Threat Intelligence, проверки DNS запросов и также за счет работы обученных моделей Machine Learning.
контроль трафика может происходить как на основе сбора сырых пакетов с сетевых брокеров и SPAN портов, так и с других систем сбора статистики NetFlow, уже имеющихся в компании;
в ICS/SCADA будут выявлены аномальные команды, которые ранее не передавали в контроллеры;
единая система управления позволяет увидеть все что происходит во всех уголках сети, поэтому защиту можно и нужно расширять и устанавливать дополнительные компоненты контроля в разных филиалах и подразделениях компании. Ведь филиалы - часто страдают от недостатка внимания - поставьте там сенсор NDR и/или Deception.
19 способов проникновения и как NDR их отслеживает.
2. Ловушки (DDP, Deception), расставленные по сети, будут первыми выявлены злоумышленником, поскольку специально разработаны, чтобы приманка была то самое сладкое, что увидел злоумышленник на рабочей станции и в сети. И также системы класса Deception привлекут злоумышленника, как только он попытается перемещаться по сети (lateral movement) и изучать ее.
От чего защищают Deception (DDP) продукты или как обнаружить злоумышленника в сети компании.
Используйте эти средства быстрого выявления злоумышленника. Не ждите, когда он сам объявится с просьбой заплатить выкуп.
