Wednesday, May 24, 2017

Hunting Lateral Movement in Windows Infrastructure

Today at the PHD conference colleague from our threat hunting team gave a talk on windows lateral movement hunting. Here are the slides.


Originally we were planning this speech together and for 40 minutes, but orgs proposed Fast Track as the only opportunity that's why I decided to opt out because it's huge and important topic that hardly could be covered within 20 min time frame. However, Teymur did his best to shrink materials and in the end it took 17 min. That's why I'd like to thank my colleague Teymur greatly as he did almost impossible! To my mind this was one of the greatest talks at conference despite the fact that a lot of worthy topics were presented in the main program.
To my mind lateral movement is very important topic and this talk can be treated as kind of our internal research on this that we'd like to share to help enterprises to spot advanced threats presence within their Windows environments. Hope, you'll enjoy this work and find it also useful. Original talk was in Russian, but taking into account previous years experience video and good english simultaneous translation will be available as well.



Sunday, May 21, 2017

Кто, если не Вы?

Развивайте свои сильные стороны, и аутсорсите слабые. 
Тем более развивай то, что невозможно зааутсорсить.

Очевидна необходимость приоритезации усилий, поскольку безопасности едва ли может быть когда-нибудь достаточно, а необъятное, как известно, не объять. Поэтому надо уметь правильно расставлять приоритеты задачам и целям, которые будут адекватны окружению и контексту.
Однако, вместе с тем, если вы работаете в Заказчике (==интерпрайзный безопасник), в реальном секторе, есть задачи, которые никто кроме вас не сделает, и именно поэтому они должны попадать в первый приоритет. Напротив, другие, хорошо проработанные задачи, по которым существует зрелое предложение на рынке, в условиях недостатка ресурсов разумно аутсорсить. Как же их найти, эти и те задачи?


Любой бизнес-процесс в Компании, будучи рассмотренным под призмой автоматизации, может быть представлен в виде двух составляющих - Бизнес и ИТ. Бизнес - это совокупность отношений между участниками данного конкретного бизнес-процесса, ИТ - это та самая автоматизация бизнес-процесса.
Безопасность - дисциплина на стыке Бизнеса и ИТ - совокупность заплаток безопасности, как технологических (Тех-контроли), так и организационных (Бизнес/орг-контроли), поскольку программа обеспечения безопасности бизнес-процесса будет состоять из некоторых бизнесовых контролей, реализуемых на уровне взаимоотношений между участниками бизнес-процесса (например, Корпоративный стандарт, требования в должностных инструкциях и т.п.), и некоторых технических контролей, реализуемых в области ИТ (например, парольная политика, настроенная в корпоративном каталоге, криптографическая подпись логов транзакций и т.п.).
ИТ, грубо можно поделить на две составляющие: Общие ИТ и Кастомные ИТ. Общие ИТ - это ИТ, построенное на базе стандартных решений, доступных на рынке, относительно которых сложилось зрелое рыночное предложение сопровождения и развития (например, СКС, ЛВС, инфраструктура Microsoft Active Directory, т.п.). Кастомные ИТ - это вся ваша\заказная разработка, выполненная исключительно  под Вас, по вашим ТЗ, соответственно, рынка сопровождения таких ИТ - не существует (например, ваша самостоятельно разработанная АСУТП, или автоматизация продаж или ваш самописный Интернет-портал).

В целом, думаю, уважаемый читатель, вам уже понятно чем следует заниматься интерпрайзному безопаснику, - есть такие области, которые никто кроме него не сделает. Никто не будет заниматься безопасностью вашего самописного софта, это - ваша задача. Если его достаточно много и он динамично развивается, следует подумать о собственной продуктовой безопасности, которая может быть эффективнее внешнего AppSec-а, поскольку в Контексте. Поэтому, первый технологический приоритет для интерпрайзного безопасника - это ваши Кастомные ИТ.
Неоднократно писал о том, что, если вы не разбираетесь в своих бизнес-процессах сами, нет оснований верить, что придет умный консалтинг и научит вас защищать ваши бизнес-процессы. Это невозможно по множеству причин, одна из которых - если вы сами не смогли погрузиться в Контекст, то за время проекта консультант это сделать тоже не сможет\не успеет, и тем более - вы ему не помощник. Поэтому вторая область для приложения усилий интерпрайзного бизопасника - это Бизнес/орг-контроли.
За какие безнес-процессы браться в первую очередь? Очевидно, за ключевые. Если вы - нефтяная компания, то ваша кора - добыча, транспортировка, переработка и сбыт нефтепродуктов - вот бизнес-процессы первого приоритета, где следует заняться бизнесовой безопасностью и безопасностью кастомного ИТ.
Если вы - компания которая пишет софт, то процесс проектирования, разработки, поставки и поддержки вашего ПО - вот ваша кора, где вся безопасность бизнес-процессов и безопасность вашей кастомной инфраструктуры - ваши первые приоритеты.
Сразу хочу предупредить возможную критику тех, для кого ИТ-безопасность ограничивается ИТ-инфраструктурой - конечно, этим можно заниматься, просто не в первую очередь + поддержка ЛВС на Cisco или виртуализации на VMWare - понятные вещи, в которых можно быстро разобраться имея понятный бэкграунд (Контекста там либо мало, либо его нет вовсе), словом, это можно просто зааутсорсить. Тогда как разобраться с автоматизированной системой вашей розницы будет проблематично хотя бы потому что ваши программисты на работе тоже не скучают и постоянно дописывают\допиливают\докручивают, короче, развивают. Схожая ситуация с ИБ бизнес-процесса, где только вам известно как вы учитываете приходы и расходы, как вы реализуете разделение полномочий, как согласуете изменение доступа к информационным ресурсам, как боретесь с злоупотреблениями и как все это отслеживаете.
Таким образом, то что интерпрайному безопаснику на  схеме Надо делать самому, никто за него не сделает, а это очень важно, так как мы привязывались к ключевым бизнес-процессам.
Тогда как оставшееся - можно задвинуть\заАутсорсить.


Sunday, May 14, 2017

Спички детям - не игрушка!

Мы прячем спички\ножи\пистолеты от детей, чтобы они не покалечили окружающих, однако то же самое, но кибер-, - разбрасываем непотребнейшим образом - совсем недавно мы писали, и вот получили.

Но ситуация не только в этом, - мы все увлеклись погоней за защитой от 0-day, от APT и прочих advanced-, targeted-, sophisticated-, а надо - просто ставить патчи!

Tuesday, May 9, 2017

Трудовые будни охотника на угрозы

Лучше поздно, чем никогда. Выкладываю свою презентацию с CISO Forum-а. Вот и я уже дошел до повторного использования некоторых слайдов в своих презентациях... Все возможнее падение до недопустимого - повторного рассказа одного и того же, но будем оптимистами!




Наибольшая ценность начинается со слайда 11 (но, конечно, предыдущее тоже не бессмысленны). Где приведены реальные Карточки выявленных инцидентов, дающие понимание как работают атакующие и как их можно обнаружить.

Основная мысль всего доклада сосредоточена на слайде 21 "Послесловие". Здесь говорилось о том, что целевые атаки являются результатом эволюции "обычной малвары", что, в свою очередь, требует развития подходов безопасности:
- на смену AV приходят решения Anti-APT и Threat hunting
- вместо "продетектить точно и сразу" - "неточно (== зафиксировать аномалии) и спустя время (== предварительно понаблюдав, поскольку чтобы обнаружить атаки с использованием легальных инструментов нужно время)
- вместо полностью автоматически - с участием человека, как минимум, по причине необходимости анализа контекста (==situational awareness), - недостатки автоматики компенсируются преимуществами сервиса (работы людей)
- ну и наконец, надо сражаться не с применяемыми инструментами, коих великое множество и все чаще применяются лекальные, которые нельзя просто продетектить, а с конкретными шаблонами поведения, ТТР.

Огромную признательность выражаю моим коллегам по отделу SOC, которые, все это обнаружили и, где было необходимо, - скорректировали соответствующую автоматику для большего удобства работы в будущем :)


Поддержка с воздуха


Берясь за реагирование на инцидент ИБ, очень важно понимать последствия. Прежде чем удалять persistance, сбивать и зачищать инструменты, используемые атакующими, необходимо вычислить все C2, и, по возможности, одновременно их закрыть. Получив уверенность в том, что атакующий потерял удаленное управление, можно спокойно вычищаться.

Но и этого мало. Усиленный мониторинг, а точнее TH, должны сохраниться до окончания IR - чтобы проследить, что ни уже выявленные ТТР, ни какие-то новые не пытаются быть примененными, а также, что не осталось что-то, чего по какой-то причине не заметили, в рамках проводимого перед IR расследования, и что стало проявляться только в "экстренной ситуации", когда атакующий понял, что им занимаются.

Но есть еще момент, который всегда иногда выпадает из внимания: если вас уже ломали, скорее всего, поломают еще раз. Чтобы быть готовым к этому, TH и IR должны стать операционными процессами по выявлению, расследованию, устранению, корректировке политик превентивных и детектирующих инструментов и процедур. Примитивный таймлайн - на картинке :).


Именно поэтому, исключительно IR без поддержки TH представляется менее эффективным, верно и обратно - только TH - мало, ибо кто-то должен реагировать на выявленные инциденты. Что, в целом, и подтверждается практикой.