Друзья, всем привет. Недавно мы анонсировали серию публикаций о детектировании атак (attack detection) и тех вызовах, c которыми сталкиваются пользователи средств защиты. В первой статье этого цикла материалов мы уже раскрыли секреты attack detection в привязке к SIEM-решениям (системам мониторинга событий ИБ и выявления инцидентов, security information and event management) и поделились лайфхаками, как облегчить работу операторов и автоматизировать часть рутинных задач. В этом материале — подробнее о том, как механизм построения цепочек запускаемых процессов в MaxPatrol SIEM помогает выявлять атакующих в сети.
Поиск аномалий при запусках процессов Windows с помощью рекомендательных систем
В SIEM-системах есть множество написанных экспертами правил, которые помогут отследить подозрительное поведение. Однако существует много сценариев атак, которые нельзя описать строгими правилами, а значит, эффективно отслеживать.
Учитывая объем данных, обрабатываемый SIEM-системой ежедневно, а также специфические задачи анализа этих данных (целью которого является поиск действий злоумышленников), применять машинное обучение сегодня необходимо и чрезвычайно эффективно.
О том, как правильно использовать «магию» машинного обучения, какой алгоритм фактически самостоятельно «понимает» функциональные обязанности каждого пользователя и предназначение конкретной программы и при чем здесь рекомендации товаров в интернет-магазине, рассказываем в посте.
Как угнать данные за 15 минут
Привет, Хабр! Осенью состоялась десятая, юбилейная кибербитва Standoff. Три дня десять команд этичных хакеров со всего мира пытались ограбить банк, нарушить работу нефтегазовой отрасли и транспорта или реализовать другие недопустимые события в виртуальном Государстве F, построенном на настоящих физических IT-системах и контроллерах. Шесть команд защитников наблюдали за действиями атакующих и расследовали инциденты. Сегодня мы разберем один из них.
Если вы следите за публикациями в нашем блоге, то знаете, что мы далеко не в первый раз делаем разбор-расследование атак, реализуемых красными во время Standoff. Так вот, на прошлом Standoff входной точкой атаки стало фишинговое письмо. Так случилось и в этот раз: фишинговое письмо послужило причиной серьезной утечки конфиденциальной информации с компьютера руководителя финансового департамента.
Как Карл данные у Клары крал. Реконструкция ИБ-инцидента на 100+ млн. рублей
Разбор громких инцидентов с Road Show SearchInform на Хабре имеет шансы стать традицией. В прошлом году я представил реконструкцию инцидента, связанного с выносом базы данных за пределы одной финансовой компании. Его главным и единственным организатором был ловкий и умелый инсайдер «Иван Денисович».
В этот раз источником вдохновения послужило не менее любопытное дело. Оно также связано с утечкой информации, но уже с другими героями в главных ролях. Решил реконструировать инцидент. Как и в прошлый раз: «все выдумано, а совпадения случайны».
Участники: Карл - инсайдер, Клара - жертва, Кораллы - данные почтового ящика Клары.
Под катом рассказываю, как Карлу удалось украсть «кораллы» и нанести компании ущерб в 100+ млн рублей, каким образом его вычислили и как он оправдывал себя в суде. И самое главное – показываю, какими инструментами компания могла бы упростить себе поиски виновного и предотвратить инцидент.
UserGate LogAnalyzer: 12 лайфхаков в помощь ИБ-специалисту для настройки систем мониторинга безопасности
Современный ландшафт киберугроз настолько разнообразен и динамичен, что использование одних лишь базовых средств защиты уже не является достаточным шагом к построению защищенной инфраструктуры. Немаловажным является способность бизнеса анализировать данные, находить среди них значимые события, выявлять инциденты и расследовать их.
В помощь ИБ-специалисту предлагаем 12 лайфхаков для настройки систем мониторинга безопасности.
XDR vs SIEM, SOAR. Перемешать, но не взбалтывать
Привет, Хабр! Меня зовут Сергей Куценко, я являюсь экспертом направления информационной безопасности в К2Тех. Рынок решений информационной безопасности динамично развивается. В последнее время все больше на слуху концепции EDR (Endpoint Detection and Response) и XDR (Extended Detection and Response), и, несмотря на то, что в интернете достаточно много материалов по данной теме, нет четкого ответа на вопросы: что это такое, зачем это нужно, в чем отличие от SIEM или SOAR?
В этой статье мы попробуем в этом разобраться.
Особенности DevSecOps в облаке или как управлять безопасностью с помощью CSPM
В данной статье мы хотим осветить особенности организации безопасности в облаках и рассказать, как CSPM продукты помогают автоматизировать процесс обеспечения безопасности в рамках методологии DevSecOps. Также расскажем о продукте собственной разработки, который как раз решает эту задачу.
Соответствие стандартам и политикам в сканерах уязвимостей и SIEM
Помимо международных стандартов существуют их отечественные аналоги, корпоративные политики и требования NIST.Проводить оценку соответствия этим документам также необходимо. Стандарты содержат наборы требований: выполнение всех требований стандарта фактически означает соответствие ему. Пример отдельного требования: «Должен иметься дисциплинарный процесс для служащих, которые произвели нарушение защиты» (ИСО/МЭК 2005 A.8.2.3).
SIEM: ответы на часто задаваемые вопросы
Вместо предисловия
Я приветствую всех, кто читает этот пост!
В последнее время мне стали часто задавать вопросы, связанные с SIEM. Окончательно добило общение с товарищем, с которым мы собрались вечером попить пивка и как-то незаметно перешли на тему, связанную с безопасностью. Он сказал, что они собираются внедрять SIEM — потому что «она помогает защитить инфраструктуру». И даже нашли людей, которые им соглашаются сделать это «за недорого и быстро». Вот тут-то я и насторожился… Как выяснилось, они думали, что внедрение SIEM разом избавит их от неприятностей вроде утечки данных, и к тому же будет недорогим и быстрым — мол, нашли систему, которая не требует настройки. Ну и дела, подумал Штирлиц, и решил накропать свои соображения по этому поводу, дабы отправлять вопрошающих к печатному источнику. Постараюсь быть кратким и охватить наиболее часто задаваемые вопросы.
SIEM для ИТ и ИБ
JSOC: как измерить доступность Security Operation Center?
Итоговая цель нашего сервиса (JSOC) − выявление и оперативный анализ возникающих у заказчиков инцидентов ИБ. Это создает три основных требования к его доступности:
- Платформа сбора и обработки информации должна быть доступна и работоспособна. Если информации о событиях и инцидентах некуда поступать, ни о каком выявлении инцидентов речи идти не может.
- Информация с источников событий ИБ должна быть максимально полной: мы должны получать все требуемые события аудита, на основании которых построены наши сценарии по выявлению инцидентов.
- В момент, когда система зафиксировала инцидент, мы должны иметь возможность максимально оперативно собрать и проанализировать всю информацию, необходимую для его расследования.
Эти требования порождают три разных уровня мониторинга доступности сервиса JSOC.
JSOC: как готовить инциденты
Мы чуть затянули с выпуском нашей очередной статьи. Но тем не менее она готова и я хочу представить статью нашего нового аналитика и автора — Алексея Павлова — avpavlov.
В этой статье мы рассмотрим наиболее важный аспект «жизнедеятельности» любого Security Operation Center – выявление и оперативный анализ возникающих угроз информационной безопасности. Мы расскажем, каким образом происходит настройка правил, а также выявление и регистрация инцидентов в нашем аутсорсинговом центре мониторинга и реагирования JSOC.
Как сегодня строится центр оперативного управления информационной безопасностью (SOC-центр)
Большую часть времени оператор SOC-центра работает с SIEMами. SIEM-системы собирают данные с различных источников по всей сети и совместно с другими решениями сопоставляют события и оценивают угрозу — как индивидуально для каждого пользователя и сервиса, так и в целом для групп пользователей и узлов сети. Как только кто-то начинает себя вести слишком подозрительно, оператору SOC-центра поступает уведомление. Если уровень подозрительности зашкаливает, сначала изолируется подозрительный процесс или рабочее место, а уже потом приходит уведомление. Дальше начинается расследование инцидента.
Очень упрощая, за каждое подозрительное действие пользователь получает штрафные очки. Если действие характерно для него или его коллег — очков мало. Если действие нетипичное — очков много.
Для UBA-систем (User Behaviour Analytics) последовательность действий также имеет значение. По отдельности резкий скачок объёма трафика, подключение к новому IP или копирование данных с файлового сервера случается время от времени. А вот если сначала юзер открыл письмо, потом у него было обращение к только что зарегистрированному домену, а затем он начал шариться по соседним машинам и отправлять странный зашифрованный трафик в Интернет — это уже подозрение в атаке.
Как за один день разработать SIEM (систему управления инцидентами информационной безопасности)
«Коллеги, напоминаю, в этом квартале запланированы курсы повышения квалификации для партнеров на тему управления информационной безопасностью. Нашему коллективу предлагается подготовить практическое занятие, посвященное вопросам построения SIEM систем!» – после такого предложения начальника возникла пауза во время очередной летучки.
Участники заседания из числа предполагаемых исполнителей понимали, к чему обязывает такое предложение (
После двух месяцев напряженной работы и подготовки окончательной версии занятия мы признались, что провели это время невероятно продуктивно. И даже не предполагали, насколько полезным в профессиональном плане для коллектива окажется ответ на подобный «вызов».
Делимся материалами практикума по разработке собственной SIEM системы за один день с убедительными примерами.
Дисклеймер. Материал — объемный, рассчитанный на полный учебный день занятий в размеренном темпе. Пример — примитивный. Авторы сомневаются в возможности промышленного применения open-source решений SIEM, но вместе с тем считают, что изучение практических примеров позволит лучше разобраться в предметной области.
Дашборды Check Point — вот что я люблю
— Зачем вы мне втираете про удобный интерфейс? Это вообще не важно. Меня интересует только функционал! (из беседы с клиентом)
При выборе NGFW (или UTM) чаще всего смотрят исключительно на функционал устройства. С этим подходом трудно поспорить (да и не нужно). Устройство безопасности в первую очередь должно защищать! При этом очень важно количество и качество механизмов защиты! Именно для этого публикуются различные отчеты Gartner и NSS Labs. Однако, еще одним важным аспектом любого NGFW является встроенная отчетность и качество ее визуализации. Ниже я попытаюсь рассказать почему это важно и почему Check Point в этом реально крут.
Краткий анализ решений в сфере СОВ и разработка нейросетевого детектора аномалий в сетях передачи данных
В статье приведён анализ решений в сфере IDS и систем обработки траффика, краткий анализ атак и разбор принципов функционирования IDS. После чего сделана попытка разработки модуля для обнаружения аномалий в сети, на основе нейросетевого метода анализа сетевой активности, со следующими целями:
- Обнаружение вторжений в вычислительную сеть.
- Получения данных о перегрузках и критических режимах работы сети.
- Обнаружение проблем с сетью и сбоев в работе сети.
Check Point Smart Event. Мини-руководство
В этой статье я хочу рассказать о продукте SmartEvent компании Check Point. Данный продукт дополняет и расширяет возможности файрвола Check Point, превращая его в эффективный инструмент, который помогает выявить, распознать и обработать инциденты информационной безопасности. Совсем недавно мой коллега публиковал статью о дашбордах Check Point. Продолжим эту тему и посмотрим как устроен блейд Smart Event.
Программные блэйды файрвола Check Point генерируют огромное количество разнообразных сообщений, которые сохраняются в базе данных логов. В основной своей массе – это сообщения о разрешённых и заблокированных соединениях, реже – сообщения о срабатывании защит IPS и других блэйдов продукта. Сохраняемая в виде логов информация может использоваться для изучения и анализа инцидентов безопасности, однако оперативно выявлять на основе логов эти инциденты чрезвычайно трудно. В первую очередь потому, что этих логов ну очень много. Можно конечно использовать механизмы фильтрации, но нужно знать, что отфильтровывать и выявления для разного рода инцидентов важны разные логи. Выходом может служить автоматизация процесса анализа логов. Именно задачу автоматизации анализа логов с целью выявления инцидентов безопасности в первую очередь и решает SmartEvent.
Зачем вам нужен Splunk? Аналитика событий безопасности
Было ли нарушение информационной безопасности предприятия? Какие внутренние угрозы есть у организации? Как и насколько быстро мы можем обнаружить, заблокировать или остановить атаку? В этой статье мы расскажем, как вам может помочь Splunk в поиске ответов на эти вопросы.
Пентест-лаборатория «Pentestit Test lab 12» — полное прохождение
Каждый год компания Pentestit запускает новую лабораторию для тестирования на проникновение «Test Lab», и данная статья будет посвящена прохождению 12-ой лаборатории, получившей название «z 9r347 39u411z3r» или если раскодировать — «The great equalizer».
Подключение к лаборатории
Подключение к лаборатории происходит через VPN-соединение (так как я проходил лабораторию на машине под управлением ОС Linux, то все действия будут описаны именно для этой платформы). Для того чтобы попасть в частную сеть, необходимо выполнить следующие шаги:
- Зарегистрироваться здесь.
- Сохранить конфигурационный файлы отсюда.
- Зайти в настройки сети и выбрать «добавить VPN».
- Импортировать из файла (указываем скачанный файл с конфигурациями).
- Указать логин и пароль для подключения (даны на вкладке «how to connect»).
- Подключаемся к VPN и пингуем шлюз 192.168.101.1. Если пинг проходит, то вы успешно подключились к лаборатории.
Поиск цели
Нам доступна сеть 192.168.101.X с маской 255.255.255.0. Первым делом необходимо найти «живые хосты» в сети. Сделать это легко можно с помощью утилиты nmap:
nmap -sn 192.168.101.0/24
ip/mask – адрес сети / маска
5 open-source систем управления событиями безопасности
Чем хороший безопасник в ИТ-сфере отличается от обычного? Нет, не тем, что он в любой момент времени по памяти назовёт количество сообщений, которые менеджер Игорь отправил вчера коллеге Марии. Хороший безопасник старается выявить возможные нарушения заранее и отлавливать их в режиме реального времени, прилагая все силы, чтобы не было продолжения инцидента. Системы управления событиями безопасности (SIEM, от Security information and event management) значительно упрощают задачу быстрой фиксации и блокировки любых попыток нарушений.