Thursday, July 6, 2017

А ваши СОКи готовы к жаждущим рыданий неПетям?

Активное действие требует активного противодействия

Последние два месяца окропили страницы истории событиями, заставившими поверить в существование информационной безопасности самых консервативных скептиков и даже людей, не связанных с ИБ и ИТ вообще (картинок с блокскрином в самых неожиданных местах полно в Сети).
На просторах Всемирной Паутины в великом избытке можно найти всевозможные технические детали этих атак, поэтому в этом посте мы поговорим о более "бумажных" аспектах ИБ, а именно требованиях к операционной безопасности, выставляемых практикой мониторинга и контроля подобных атак.

На слайде 4 я рассказывал о Контексте угрозы, о современных ТТР, с которыми приходится считаться, а далее, начиная со слайда 11, приводил примеры инцидентов, с использованием этих ТТР и рассказывал, как это обнаруживать. Возможно тогда, все эти "новомодные" подходы типа Threat hunting, обнаружение по ТТР и усиление классического SOC, казались какими-то теоритезированными и далекими, но безжалостная практика показала, что современность требует именно этого.

Рассмотрим поверхностно применяемые техники и как они могут быть обнаружены.

WannaCry (12.05.2017)
Распространение - эксплоит EthernalBlue. Патч был выпущен заблаговременно (14.03.2017), спустя месяц (14.04.2017) - слив, который сразу же был проанализирован, и все нормальные IPS/IDS его детектили уже, самое позднее, на следующий день.
Нагрузка детектировалась нормальными антивирусами эвристикой (по поведению), а затем и сигнатурой на тушки.
"Классических" подходов к ИБ - вполне достаточно:

  • патчи ставить, можно даже с опозданием на месяц,
  • сигнатуры антивируса, IPS/IDS - обновлять,
  • сеть сегментировать (так как после сканирования своей подсети, сканировались случайные адреса),
  • в антивирусе включить поведенческий детект.

В целом, если перечисленные контроли работают, никакой мониторинг/SOC и не нужен.
Однако успешность атаки показала, что даже эти, назовем их статические (типа, сделал и забыл, никакой адаптации не нужно) меры, далеко не всегда выполняются.
Положительный эффект - то, что MS17-010, наконец-то, только истинные обломовцы не поставили.

Очевидно, что статических мер - недостаточно (про это были первые два абзаца воды) и вот практика это показала...

exPetr (27.06.2017)
Распространительный функционал обогащен дополнительными возможностями:

  • эксплоит EternalRomance (направлен на XP/2003, тоже патчится MS17-010);
  • увод аккаунтов (функционал схожий с Mimikatz);
  • далее с этими аккаунтами - wmic и psexec по сети;
  • выбор жертвы:
    • просмотр своих интерфейсов --> сканирование их сетей по 139 и 445 --> доступным - эксплоит/соединение;
    • аналог netstat - с кем соединения established --> эксплоит/соединение;
    • перечень хостов из arp-кеша --> эксплоит/соединение;
    • перечисление компов в домене --> эксплоит/соединение;
    • если адрес хоста - динамический --> эксплоит/соединение DHCP-сервера --> получение всех клиентов DHCP-севера --> эксплоит/соединение клиентов DHCP-сервера.
Вынесем за скобки другие фичи, типа удаления логов (~антифоренсика) и т.п., разберемся хотя бы с выписанным.

Выделенные красным - как раз те техники, что требуют дополнительных мер операционной безопасности - мониторинга и даже несколько более глубокого, так как:
  1. дамп паролей из памяти по поведению надежно продетектить сложно, так как, в целом, инжект в память lsass может быть вызван и легальной работой какой-нибудь загадочной аутентификации или системы безопасности, поэтому, как правило, антивирус детектит конкретный инструмент (Mimikatz, WCE, pwdump и пр.), а не ТТР;
  2. горизонтальные перемещения - выполняются с использованием легальных и даже штатных инструментов, использование которых не представляет собой ничего вредоносного, более того, зачастую используются администраторами (в нормальных инфраструктурах, конечно, не используют psexec (поэтому красным он не выделен), поскольку есть более "интерпрайзные" решения и, исходя из принципа минимума функционала, следует ими и ограничиться, однако, использование WMI (wmic) - достаточно распространенная практика);
  3. тупое шумное сканирование (любая NIDS вполне эффективно обнаруживает сканирования и портсвипы) обогащено функционалом выявления хостов с которыми непосредственно сейчас или в недалеком прошлом уже было сетевое взаимодействие и поэтому вредоносное подключение к ним не будет радикально выделяться при анализе межхостовых взаимодействий;
  4. сканирований за рамки своего VLAN-а уже нет, поэтому пролет "подозрительного" трафика через маршрутизатор (потенциально - межсетевой экран) отсутствует.
1 - обнаруживатется по инжектам в lsass - при наличии достаточной репутационной базы (и коммуникации с админами), аналитик без особого труда из множества инжектов найдет те, которые следует поисследовать, и среди них будет угроза, за которой охотились.
Про 2 у любого охотника накоплен богатый опыт, который, в совокупности с информацией о процессах, участвующих в этой сетевой активности на эндпоинтах, позволит аналитику быстро составить недвусмысленную картину. 
3 связано с 2, да и вообще, отслеживать кто на какой машине логинится и обращать внимание на отклонения от накопленного статистического профиля - дело благодарное, а обогащенное знаниями, что из сессии сетевого логона запускаются еще какие-то процессы, - заслуживает внимание аналитика, особенно когда ранее подобное не наблюдалось.
Нормальные Охотники на угрозы анализируют сетевые соединения. Если у вас DHCP-сервер - маршрутизатор (или, во всяком случае, не windows), то обращение к нему по 445 будет выглядеть более чем странно и внимательный аналитик непременно решит докопаться что за процесс генерит столь странные обращения.

Не надо быть сильно смекалистым, чтобы из написанного выше не сделать выводы, почему SOC-а в его классическом текущем понимании мало. И, все-таки, кратко остановлюсь на этом:
  • нужны низкоуровневые события с эндпоинта - запуски процессов, их сетевые соединения, загрузки библиотек, инжекты в код других процессов и т.п.;
  • в дополнение к эндпоинту, нужны данные, как минимум, с сетевого периметра, крайне полезен результат анализа внутреннего трафика;
  • нужны механизмы контроля использования легитимных и штатных инструментов ОС с возможностью быстрого понимания что "нормально", а что - "подозрительно";
  • нужны хорошие справочники TI, как позволяющие автоматически маркировать объекты в логах с последующим использованием в корреляционной логике, так и служащие справочником для аналитика, выполняющего расследование подмеченной подозрительной активности;
  • ну и, конечно, инфраструктура быстрого (~ автоматического) проведения форенсики - песочницы, опять же обвешенной всевозможным TI, позволяющим что-то автоматически протеггировать и немного сократить задачу аналитика по поиску следов атаки или подозрительной активности.

В заключение отмечу, что практика последних успешных атак показала, что статических мер - не достаточно, не достаточно и классического мониторинга алертов (SOC) и пришло время задуматься об усилении SOC функцией поиска атак, обошедших используемые средства защиты.



Monday, June 5, 2017

Наверно они сотрудничают...

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

Облако объединяет

Безопасность - это искусство Компромисса

В прошлый раз мы узнали, что для построения своего Центра компетенции по ИБ (a.k.a. SOC) крайне полезно иметь, как минимум, сетевую доступность до всех обслуживаемых объектов, иначе, централизованно (не обязательно в одну географическую локацию) собрать все логи технически невозможно.
Тем не менее, в силу различных обстоятельств, многие территориально-распределенные корпорации разделяют не только расстояния, но и "воздушные зазоры", "однонаправленные шлюзы", "защищенные межсетевые экраны", "демилитаризованные зоны" и прочие контроли ИБ. Конечно же, резко рушить все эти старательно возведенные границы - неправильно, поскольку, действительно, более или менее без риска можно соединять только сети с одинаковым уровнем ИБ, а сети с разным уровнем ИБ рекомендуется соединять через что-то из указанного выше, например, ДМЗ. В "уровень ИБ", помимо всего прочего, следует включать и уровень сервисов ИБ, т.е. покрытие сервисами ИБ в соединяемых [без препон] сетях должно быть одинаковым. Также, в прошлый раз мы узнали, что одним из простых способов обеспечения единого уровня сервиса ИБ является реализация компонент этого сервиса одной командой. Конечно же, в каждый островок LAN можно высадить по локальной группе ИБ и всех их организовать в одну команду, но это не будет иметь экономической выгоды (ну, конечно же, не беря во внимание социальную ответственность по созданию множества рабочих мест) и едва ли сможет называться Центром компетенции по ИБ, о чем мы тоже узнали в прошлый раз.
И вот здесь - самое время на своем опыте убедиться в том, что Безопасность - это Компромисс - где для Вас больше риска: (1) в отсутствии какого-либо контроля ИБ в изолированных друг от друга островках LAN или (2) использовании облака любимого MSSP с подключением через Интернет? Несмотря на то, что выбор здесь, полагаю, для большинства очевиден, позволю себе все-таки пояснить. Поскольку в островке LAN по-любому есть Интернет, компрометация тамошних систем - риск более чем материальный, а достучаться до него со всей своей ИБ кроме как через Интернет - невозможно, следовательно, собирать логи будем через Интернет. В целом, ничего нового, - все коммерческие SOC-и так и работают - тащат логи к себе в инфраструктуру, где их всячески обрабатывают и рапортуют Заказчику инциденты. Но концептуально здесь наблюдается интересная вещь: различными способами изоляции мы вытеснили сервисы Бизнеса в Интернет, и вместе с ними - сервисы ИБ, а позже выяснили, что агрессивная среда Интернет стала для нашей инфраструктуры средой консолидации, позволяющей строить централизованные сервисы, а "Облако MSSP" - единственный быстрый вариант обеспечения одинакового уровня сервиса мониторинга ИБ для корпорации без единой инфраструктуры, состоящей из островков LAN без сетевой доступности между ними. Кроме этого, есть дополнительные "плюшки" (не беря во внимание, что единое информационное пространство надо еще построить, а на это могут уйти годы, с учетом количества задействованных участников-строителей - человеко-века):
1. Логи в Облако MSSP через Интернет уезжают быстрее, чем если бы они путешествовали по корпоративным WAN-каналам, до централизованного места сбора и анализа.
2. Если из этого же облака MSSP приезжает детектирующая логика, то из Интернет она приезжает быстрее, чем из централизованного места в корпоративной сети, проползая через все имеющиеся шлюзы и WAN-каналы.
3. Тут все преимущества MSSP, который видит не только вашу инфраструктуру, но и другие, поэтому у него тупо больше опыта - он ловит рыбу в разных частях Мирового океана, вы - только в одной своей заводи.
4. Не надо думать, что ваши логи у MSSP в больше опасности, чем у вас. Там люди не менее квалифицированы чем ваши ИТ\ИБ, дополнительно есть догворные обязательства, которые могут более полно отражать ваши риски, чем должностные инструкции ваших работников или работников на удаленных площадках.

В сухом остатке, если вы осознали необходимость операционной безопасности и даже Центра компетенции по ИБ (== SOC), но ИТ-инфраструктура не готова обеспечить вам желаемый уровень централизации, Облако MSSP - отличный быстрый старт, который позволит вам уже сейчас работать в режиме, аналогичном наличию Центра компетенции по ИБ, находясь еще в условиях сетевой "феодальной раздробленности".

Sunday, June 4, 2017

Разоблачение SOC

Зри в корень!
(Козьма Петрович Прутков)

Последнее время много говорят и пишут о SOC-ах. Что ж, с традиционным для себя опозданием, попробую тоже быть в формате каналов.

В, с каждым днем все более далеком, 2009-ом, я трудился в замечательной нефтяной компании, имеющей более 20-и региональных представительств. Достигнув определенной зрелости процессов и технологий ИБ, мы задумались над оптимизацией своих операционных затрат с одновременным усилением контроля ИБ... Тогда мы пришли к очевидному и одновременно гениальному в своей простоте решению: значительно дешевле посадить централизованное подразделение из ~10-и человек в одном из регионов, чем в каждом из ~20-и нанять на работу, минимум, по два безопасника. Это подразделение было названо Центром управления безопасностью (кстати, на слайде 65 фоном дан, немного обфусцированный, один из отчетов этого подразделения), и, постепенно, на него были переведены почти все операционные задачи ИБ: мониторинг и сопровождение СЗИ, управление инцидентами ИБ, контроль соответствия требованиям к стандартной операционной среде (стандарты АРМ), контроль доступа к информационным активам, управление уязвимостями, и пр.
Чем это не SOC? Все те же плюшки с концентрацией знаний и ответственности, обеспечением единого уровня операционной ИБ по всему интерпрайзу, что особенно важно в условиях единой инфраструктуры... Да, вот то, что выделено, является одновременно и требованием к такой централизации, поскольку единое ИТ требует единого уровня ИБ (помним, что ИБ - свойство ИТ), а самый простой способ обеспечения однообразия - сконцентрировать ответственность в одних руках - в созданном Центре [компетенции], а также - обязательным условием возможности реализации такой централизации, так как удаленное обслуживание трудноосуществимо в нецентрализованной инфраструктуре (~ нет единой аутентификации и авторизации, например, через единый домен AD, или, вообще, без сетевой доступности).
В целом, создание центров компетенции, и не только по ИБ (== SOC) - дело хорошее, как минимум, с позиции оптимизации затрат.
Таким образом, разговаривая про разные аспекты SOC, важно понимать следующие, очевидные и, на мой взгляд, логичные, вещи:
1. Если у вас нет операционной безопасности - желание построить SOC вас не спасет. Курсивом выделил не случайно, так как при таком раскладе сделать SOC, скорее, не получится (одного желания, к сожалению, не достаточно), - велик риск споткнуться на первом же этапе - определении выполняемых SOC-ом сервисов, поскольку эти сервисы - сервисы существующей операционной ИБ, а если ее нет, нет и ее сервисов.
2. SOC - не что иное как ваша операционная ИБ, или ее часть (трансформированные с целью оптимизации стоимости функции, с одновременным повышением эффективности, за счет сокращения затрат на внутренние коммуникации) - вопрос только в том, какие сервисы ИБ централизовать можно, а какие нельзя (ну, например, сопровождение железа ИБ (если это почему-то делают не ИТ) полностью делать удаленно не всегда получится, поэтому эта функция частично выпадет на локальных людей (не вижу причин почему это не могут быть коллеги из ИТ), аналогично - реагирование на инциденты, которое не всегда можно сделать исключительно удаленно и т.п.)
3. Для работы Центров компетенции вообще, и SOC, в частности, нужна зрелая ИТ-инфраструктура, хотя... , - но об этом поговорим в одном из следующих постов.
4. Наличие других Центров компетенции (в частности, в ИТ) упрощает схемы коммуникаций\эскалаций SOC в рамках работы над инцидентами.

В заключение хочется пожелать всем заниматься построением операционной безопасности, а не SOC. Достигнув определенного этапа в этой работе, SOC - будет для Вас одним из вариантов достижения компромисса между качеством и стоимостью.

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-, а надо - просто ставить патчи!