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

Tuesday, May 9, 2017

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

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




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

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

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