Ну и накатали вы конечно текста Станислав! Хоть в отдельную статью оформляй. Искренне завидую количеству вашего свободного времени, раз вы успели еще и четыре аналитических отчета изучить. Но не могу не подметить вашу искреннюю любовь к иностранным продуктам, иностранным маркетинговым статьям и методологиям. В этом нет ничего плохого, но у нас и на Российском рынке есть потрясающие решения, которые зададут жару иностранным аналогам.
Все в ваших словах складно, но лично я предпочитаю опираться не на маркетинговые материалы, а на суровый практический опыт. Так уж вышло, что мне довелось попробовать и иностранные решения: в них есть немало интересных функций, но без сигнатурного движка их детекты заметно слабеют и ведут себя нестабильно. А предсказуемость системам защиты точно не помешает.
В системах NTA/NDR совершенно точно есть и поведенческий анализ и ML и сигнатурный движок, но кого там больше и кто из них главнее - это уже предмет манипуляций. Я все-таки останусь при своем, что поведенческие модули и ML-алгоритмы это очень круто и полезно, но такой точности в детектировании и предсказуемости, как у сигнатурного анализа - вы больше нигде не найдете (репсписки не считаем). И кстати, зашифрованный трафик хоть и усложняет дело, но его также прекрасно (и успешно) можно анализировать сигнатурами и находить в нем активность вредоносных программ. Могу написать об анализе побочного канала зашифрованных соединений другую статью, но лучше вы посмотрите наши исследования по анализу зашифрованных соединений SSH и VPN-протоколов в новом номере Positive Research который выйдет вот-вот совсем скоро. Очень горжусь нашими результатами.
Напоследок скажу еще свое личное мнение - вся индустрия анализа сетевого трафика как будто не раскрыла возможности сигнатур до конца и готовила его неправильно. Просто подумайте на досуге над той концепцией, что самый большой набор open source сигнатур в принципе разрабатывался для IDS систем. То есть для систем, где вы не сможете проверить фолз/не фолз и успешно/не успешно. В IDS нельзя посмотреть поля протоколов или скачать PCAP-файл и убедиться что там действительно что-то плохое. Ей можно только верить или не верить. Именно поэтому самый большой и открытый набор сигнатур ET Open так много и так часто срабатывает на все подряд - у них нет другого способа дать еще немного контекста вокруг одних алертов, кроме как другими алертами. И винить их в этом не стоит. А в системах NTA/NDR мы напротив можем позволить себе сделать упор на качество и срабатывать реже, но по делу. Именно поэтому набор наших собственных сигнатур в нашем NTA/NDR-решении кардинально отличается от всех остальных. А уже эти данные в том числе служат базой для ML и поведенческих алгоритмов анализа.
Вы затронули и много других тем, все это можно обсудить во время какого-нибудь прямого эфира :) Хороших вам выходных
Станислав. Благодарю. Но хотел бы подметить что теоретическая возможность обнаружения и построение качественного детекта атаки - совершенно разные вещи.
К сожалению, хотим мы того или нет, но выявление аномалий по слишком длительным сессиям, нехарактерному протоколу или увеличенному ответу хоста не даст ожидаемого результата и не будет приносить оператору СЗИ ничего, кроме головной боли по разгребанию фолзов. Интернет, сети и сами инфраструктуры - слишком живая среда, чтобы она подчинялась строгим правилам. А если такой детект и обнаружит какую-либо атаку, то скорее всего к тому моменту ему никто уже не будет верить. К тому же совершенно необязательно, что успешная эксплуатация уязвимости в целом вызовет такие аномалии.
Гораздо эффективнее в этом плане просто-напросто извлекать индикаторы компрометации из попыток эксплуатации уязвимостей и проверять обращения к ним. Такая простая логика позволит наверняка выявлять успешные попытки эксплуатации и операторам не придется разгребать фолзы. Такие детекты уже есть и они работают. Получается, что именно анализ содержимого сетевых пакетиков является как раз таки основной качественных детектов NTA/NDR/IDS/IPS систем. Пользователи будут отдавать предпочтение той системе, которая срабатывает только на хакера или вредоносное ПО, а не той, где необходимо разгребать тонны аномалий на слегка увеличившийся ответ сервера.
По поводу зеродей - я не утверждал что все зеродеи в мире можно гарантированно детектировать только сигнатурами. Но признаки успешной эксплуатации сетевых эксплоитов нулевого дня получается находить в большинстве случаев. И мы находим. А проникновение в сеть при помощи эксплуатации уязвимости на периметре составляет около 40% от общего числа инцидентов.
Вы как будто меня забайтили, но я все равно расскажу про другие средства: WAF гораздо лучше понимает тонкости работы разных веб-движков и гораздо лучше умеет обнаруживать веб-атаки типа SSRF, XSS, CSRF и SQL инъекции - традиционно слабое место IDS/NTA/NDR систем и в принципе их задача - защита именно веб-приложения, а не всей инфраструктуры. Sandbox в принципе анализирует поведение и детонацию вредоносных файлов, и кстати, IDS/NTA/NDR как раз и рекомендуется ставить с ними в паре. Системы анализа трафика в принципе не способны проанализировать локальные эксплоиты, зачем вы вообще об этом спросили. Пользователь может скачать по сети запароленный архив с эксплоитом - именно тут вам и нужны антивирусные средства, системы EDR и сендбоксы ...
Не очень понял о каких именно типах атак выше вы говорите, но в целом, анализ сетевых логов никоим образом не может заглянуть внутрь пакетов и проверить была там попытка эксплуатации хотя бы даже известной уязвимости. А между прочим - это база всех баз для сетевых систем защиты. Ведь даже в каждой системе NGFW существует модуль IPS, задача которого - именно блокировать эти попытки эксплуатации уязвимостей автоматически.
Вот что насчет 0day атак, тут я с вами не соглашусь. Существует немало признаков, которые прямо или косвенно помогают задетектировать 0day атаку, что многократно подтверждалось на практике. Если хотите - я напишу статью где расскажу об этом подробней. Один лайк и я начинаю писать.
О дальнейшей судьбе этой истории мне неизвестно. Но как правило компании все-таки способны восстановить свою работу после атак шифровальщиков, потратив какое-то время и ресурсы.
Хороший вопрос конечно, но ответа на него мы не узнаем, необходимо проводить полноценное расследование. Если точкой проникновения был SSH, то возможно креды были подобраны ранее или украдены из других источников. Но все это - не более чем догадки. Настоящая причина может быть в чем угодно - может их вообще украли стилером с компьютера администратора ?
В статье я писал те слова, которые мы используем сами. Мне лично больше нравится бикон, чем маяк. В любом случае, на техническое содержание статьи это никак не влияет, спасибо.
Детектор аномалий, будь то аномалия отдельных пакетов или системы в целом, предполагает предварительное обучение. Пороги, о которых вы говорите, различаются от конфигурации к конфигурации и, более того, время проверки пакетов также скачет, т.к. зависит от фоновой нагрузки. Поэтому автоматическое сравнение с неким фиксированным порогом неизбежно приведет к массе ложно-положительных срабатываний.
Думаю, что подобная фича может появиться, но если разработчики сочтут её необходимой :)
BadTunnel позволяет заспуфить NetBios имя из-за внешнего периметра фаервола или NAT, а спуфить можно много чего. Например, ISATAP, а ведь IP трафик это ~100% трафика жертвы. Случай нечастый, но таки позволяет контролировать всю сетевую активность операционной системы, никакого обмана.
Ну и накатали вы конечно текста Станислав! Хоть в отдельную статью оформляй. Искренне завидую количеству вашего свободного времени, раз вы успели еще и четыре аналитических отчета изучить. Но не могу не подметить вашу искреннюю любовь к иностранным продуктам, иностранным маркетинговым статьям и методологиям. В этом нет ничего плохого, но у нас и на Российском рынке есть потрясающие решения, которые зададут жару иностранным аналогам.
Все в ваших словах складно, но лично я предпочитаю опираться не на маркетинговые материалы, а на суровый практический опыт. Так уж вышло, что мне довелось попробовать и иностранные решения: в них есть немало интересных функций, но без сигнатурного движка их детекты заметно слабеют и ведут себя нестабильно. А предсказуемость системам защиты точно не помешает.
В системах NTA/NDR совершенно точно есть и поведенческий анализ и ML и сигнатурный движок, но кого там больше и кто из них главнее - это уже предмет манипуляций. Я все-таки останусь при своем, что поведенческие модули и ML-алгоритмы это очень круто и полезно, но такой точности в детектировании и предсказуемости, как у сигнатурного анализа - вы больше нигде не найдете (репсписки не считаем). И кстати, зашифрованный трафик хоть и усложняет дело, но его также прекрасно (и успешно) можно анализировать сигнатурами и находить в нем активность вредоносных программ. Могу написать об анализе побочного канала зашифрованных соединений другую статью, но лучше вы посмотрите наши исследования по анализу зашифрованных соединений SSH и VPN-протоколов в новом номере Positive Research который выйдет вот-вот совсем скоро. Очень горжусь нашими результатами.
Напоследок скажу еще свое личное мнение - вся индустрия анализа сетевого трафика как будто не раскрыла возможности сигнатур до конца и готовила его неправильно. Просто подумайте на досуге над той концепцией, что самый большой набор open source сигнатур в принципе разрабатывался для IDS систем. То есть для систем, где вы не сможете проверить фолз/не фолз и успешно/не успешно. В IDS нельзя посмотреть поля протоколов или скачать PCAP-файл и убедиться что там действительно что-то плохое. Ей можно только верить или не верить. Именно поэтому самый большой и открытый набор сигнатур ET Open так много и так часто срабатывает на все подряд - у них нет другого способа дать еще немного контекста вокруг одних алертов, кроме как другими алертами. И винить их в этом не стоит. А в системах NTA/NDR мы напротив можем позволить себе сделать упор на качество и срабатывать реже, но по делу. Именно поэтому набор наших собственных сигнатур в нашем NTA/NDR-решении кардинально отличается от всех остальных. А уже эти данные в том числе служат базой для ML и поведенческих алгоритмов анализа.
Вы затронули и много других тем, все это можно обсудить во время какого-нибудь прямого эфира :) Хороших вам выходных
Станислав. Благодарю. Но хотел бы подметить что теоретическая возможность обнаружения и построение качественного детекта атаки - совершенно разные вещи.
К сожалению, хотим мы того или нет, но выявление аномалий по слишком длительным сессиям, нехарактерному протоколу или увеличенному ответу хоста не даст ожидаемого результата и не будет приносить оператору СЗИ ничего, кроме головной боли по разгребанию фолзов. Интернет, сети и сами инфраструктуры - слишком живая среда, чтобы она подчинялась строгим правилам. А если такой детект и обнаружит какую-либо атаку, то скорее всего к тому моменту ему никто уже не будет верить. К тому же совершенно необязательно, что успешная эксплуатация уязвимости в целом вызовет такие аномалии.
Гораздо эффективнее в этом плане просто-напросто извлекать индикаторы компрометации из попыток эксплуатации уязвимостей и проверять обращения к ним. Такая простая логика позволит наверняка выявлять успешные попытки эксплуатации и операторам не придется разгребать фолзы. Такие детекты уже есть и они работают. Получается, что именно анализ содержимого сетевых пакетиков является как раз таки основной качественных детектов NTA/NDR/IDS/IPS систем. Пользователи будут отдавать предпочтение той системе, которая срабатывает только на хакера или вредоносное ПО, а не той, где необходимо разгребать тонны аномалий на слегка увеличившийся ответ сервера.
По поводу зеродей - я не утверждал что все зеродеи в мире можно гарантированно детектировать только сигнатурами. Но признаки успешной эксплуатации сетевых эксплоитов нулевого дня получается находить в большинстве случаев. И мы находим. А проникновение в сеть при помощи эксплуатации уязвимости на периметре составляет около 40% от общего числа инцидентов.
Вы как будто меня забайтили, но я все равно расскажу про другие средства: WAF гораздо лучше понимает тонкости работы разных веб-движков и гораздо лучше умеет обнаруживать веб-атаки типа SSRF, XSS, CSRF и SQL инъекции - традиционно слабое место IDS/NTA/NDR систем и в принципе их задача - защита именно веб-приложения, а не всей инфраструктуры. Sandbox в принципе анализирует поведение и детонацию вредоносных файлов, и кстати, IDS/NTA/NDR как раз и рекомендуется ставить с ними в паре. Системы анализа трафика в принципе не способны проанализировать локальные эксплоиты, зачем вы вообще об этом спросили. Пользователь может скачать по сети запароленный архив с эксплоитом - именно тут вам и нужны антивирусные средства, системы EDR и сендбоксы ...
Старался быть максимально конкретным, извините
Не очень понял о каких именно типах атак выше вы говорите, но в целом, анализ сетевых логов никоим образом не может заглянуть внутрь пакетов и проверить была там попытка эксплуатации хотя бы даже известной уязвимости. А между прочим - это база всех баз для сетевых систем защиты. Ведь даже в каждой системе NGFW существует модуль IPS, задача которого - именно блокировать эти попытки эксплуатации уязвимостей автоматически.
Вот что насчет 0day атак, тут я с вами не соглашусь. Существует немало признаков, которые прямо или косвенно помогают задетектировать 0day атаку, что многократно подтверждалось на практике. Если хотите - я напишу статью где расскажу об этом подробней. Один лайк и я начинаю писать.
Сможет ли анализ сетевой телеметрии netflow выявить попытку эксплуатации уязвимости на веб сервере в dmz?
Это реклама впн? Какой лучше то в итоге, Planet или Hola?
Хорошая статья !
Ого, какой вы умный! Все знали заранее. А я вот не знал, статья супер, Алексей спасибо
очень хорошо !
Если зайти в любую СЗИ, там будет миллион разных алертов и это прям проблема. Как с этим жить? Или это уже стало нормой?
В следующем году введем запреты на маленькие MTU у участников, будем проверять на входе
И спасибо за участие!
А как же хиросима? А карты затопления во время цунами? Японцы живут в параллельной вселенной
Спасибо за статью. Кибершеф крутой у вас получился!
О дальнейшей судьбе этой истории мне неизвестно. Но как правило компании все-таки способны восстановить свою работу после атак шифровальщиков, потратив какое-то время и ресурсы.
Хороший вопрос конечно, но ответа на него мы не узнаем, необходимо проводить полноценное расследование. Если точкой проникновения был SSH, то возможно креды были подобраны ранее или украдены из других источников. Но все это - не более чем догадки. Настоящая причина может быть в чем угодно - может их вообще украли стилером с компьютера администратора ?
Она крутая, но требует специальных условий. Волны атак с ее использованием мы не видели.
В статье я писал те слова, которые мы используем сами. Мне лично больше нравится бикон, чем маяк. В любом случае, на техническое содержание статьи это никак не влияет, спасибо.
Думаю, что подобная фича может появиться, но если разработчики сочтут её необходимой :)