Аккумуляция опыта или боты на последней линии

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

Идея на поверхности: обрабатывать последовательность действий, выполняемых опытными аналитиками при расследовании инцидентов, ML-моделькой, которая впоследствии будет "подсказывать" следующие шаги менее опытным членам команды и обучающимся на производстве. Действительно, запросы\отчеты, которые просматривает аналитик при расследовании инцидента по логам в зависимости от ситуации, неплохо поддаются профилированию, как минимум, есть наборы запросов, которые по-любому надо отработать в соответствующей ситуации, чем двигаться дальше, да и разброс уникальных идей аналитика также не безграничен. Машина может запоминать последовательность действий, характерную для определенных начальных условий, а при повторении похожей ситуации - выдавать другому аналитику эту последовательность действий в качестве подсказок. Пассивные "подсказки" никак не влияют на рабочий процесс, так как аналитик имеет полное право проигнорировать мнение машины, однако, для новичков - это может быть хорошим помощником и даже наставником. Со временем моделька будет самообучаться  и эффективность ее будет увеличиваться. Едва ли машина полностью заменит когда-либо аналитика, искусство невозможно автоматизировать, но вполне может стать аккумулятором бесценного опыта.

API для гибкой интеграции в коммерческих продуктах

В мягкое и податливое можно так глубоко влезть, что уже никогда не вылезешь

(Ассоциация)

На секции Сбербанка SOC-Форума 2017 единодушным пожеланием пользователей производителям систем ИБ было наличие открытых API с целью максимально гибкой адаптации решения под свои нужды. А нужно ли это? Если вы - не технологическая компания, то, скорее, нет.

1. Не надо распыляться. Если вы работаете в производственной компании, в реальном секторе экономики, то ваш ключевой бизнес - не ИТ, тем более, не ИБ, а ИБ для вас - операционные косты, которые всячески стремятся снижать. А раз так, то и менеджеру ИБ в этом случае следует приоритезироваться на наиболее важные задачи. Здесь не до перфекционизма, не до построения стратегии ИБ на 10 лет в течение года, не до многолетних проектов построения супер-эффективной СУИБ, не до "допиливания" коммерческих продуктов до соответствия какому-то ощущению прекрасного, - правильно взять готовое решение и, по-максимуму используя его возможности из коробки, с минимальными затратами на адаптацию насколько возможно быстро начать его использовать.
2. Не надо желать от коммерческого продукта свойств opensource. Если вы хотите бесконечные возможности по доработке - возьмите opensource - зачастую это хороший компромисс между коммерческой коробкой и собственной разработкой. Не надо требовать от коммерческого продукта гибкости opensource - это невозможно, так как чем больше возможностей вендоры вам предоставляют, тем больше их риск получить от вас конфигурацию, которая будет несовместима со стабильностью\надежностью\функциональностью продукта, которые вендоры должны поддерживать. Производители ПО не могут и не должны отвечать за то, что полет вашей фантазии сломает их продукт, поэтому они вынуждены ограничивать вас в возможностях.
3. Коммерческая компания всегда имеет задачу заработать. Незначительно, но все же здесь прослеживается и коммерческая составляющая: вендоры лучше интегрируются со своими продуктами или с продуктами своих партнеров, чтобы мотивировать потребителя приобретать их продукты, и иметь возможность продемонстрировать, что ценность интегрированного комплексного решения превышает ценность суммы составных частей.
4. Чем больше инвестируете в решение, тем меньше шансов сменить вендора. Чем больше вы инвестируете в кастомизацию дефолтного функционала, тем меньше шансов, что вы когда-нибудь уйдете с этого вендора и\или партнера. Действительно, неразумно вложить столько в подготовительные работы, потратив на них N лет, а затем - сменить решение. И вот тут-то из вас все соки деньги и выдавят. Причем, чем глубже вы влезете, тем сложнее будет спрыгнуть, поэтому, вендору\партнеру выгодно подсадить вас на эту иглу с которой вы уже не спрыгнете.
5. Инвестиции в "обвес" увеличивают OpEx, а их надо снижать + куча других "неожиданностей". Не стоит забывать о законе сохранения, о гибкости и сложности, и о том, что глубокая кастомизация может очень близко граничить с заказной разработкой. Вы уверены, что вы этого хотите?

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

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

О комфорте транспорта лучше спросить пассажиров, а не конструкторов, тем более, не технологов

Изучая спрос на рынке труда обнаружил, что требование №1 к позиции, отвечающей за продуктовую стратегию - огромный опыт разработки (звучать может примерно так "N+ years of experience in software engineering"), Причем, это - повсеместная практика (есть ощущение, что компании Job description списывают друг у друга), и именно поэтому хочется на этом остановиться в заметке.

Основной задачей продуктовой стратегии является придумывание продуктов, которые будут востребованы на рынке. Чтобы этим заниматься нужно очень хорошо понимать целевого потребителя, а самой простой способ этого достичь - быть самому опытным потребителем. А раз так, то, например, для стратега корпоративных продуктов безопасности требованием №1 должен быть опыт работы в корпоративной безопасности, а не "software engineering", так как человек, который всегда занимался разработкой софта и никогда им не пользовался не способен определить потребности пользователя. Да и вообще, разработка ПО или даже разработка алгоритмов\моделей\схем\архитектуры ПО едва ли могут относиться к стратегии, где больше оперируют концепциями и не углубляются в детали проектирования и реализации.

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

Безопасность приложений

На рынке технологического аудита прослеживается выделение двух основных направлений - безопасность инфраструктуры и безопасность приложений. Чтобы совсем все просто: первые - ломают домен Windows, получают root-а в UNIX или админов в сетевом оборудовании или СУБД, вторые - делают НСД в приложениях, говоря жаргонизмом, занимаются AppSec-ом.

В целом, действительно, умения инфраструктурного пентестера отличаются от скилов AppSec-овца, однако, не меньшие различия можно проследить между спецом по Web-у (причем, внутри Web-а тоже можно подробить) и, скажем, по SAP-у (где, кстати, тоже приложения сильно различаются и спец по HR не сразу подхватит FI или MM, а еще есть деление на R/3 и Java и много чего другого), хотя оба относятся к AppSec-овцам.

С позиции Заказчика это разделение на AppSec и инфраструктуру также выглядит искусственным, придуманным для удобства Поставщика и не нужным для Заказчика. И объяснение этому очень простое: инфраструктура не несет в себе бизнес-ценности. Ее назначение - обеспечение работы приложений (конечно же с достижением должного уровня сервиса), которые уже, в свою очередь, автоматизируют процессы Заказчика, а следовательно, имеют бизнес-ценность. И в общем-то, если мы говорим о Безопасности, как о функции защиты бизнес-процессов предприятия, логичный приоритет Безопасности - AppSec, обеспечение безопасности приложений, поддерживающих бизнес-процессы предприятия.

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

Поэтому, конечная цель Безопасность приложения, очевидно, не достигается только контролем безопасности на уровне самого приложения и, решая, казалось бы исключительно AppSec-ную задачу, всегда надо проверять весь стек технологий (следует заметить, что, конечно же, корректно привязываться не уровням модели OSI и стеку технологий по ней распределенному, а к модели потенциального нарушителя, однако, практически всегда, инфраструктурный вектор компрометации приложения имеется в наличии), а, следовательно, желающему получить более или менее комплексное решение задачи контроля безопасности приложения, необходимо включать в объем работ инфраструктурную часть, релевантную исследуемому приложению.

EPP и EDR с позиции Заказчика

- Вам чай или кофе?

- Чай.

- Вам черный или зеленый?

- Черный!

- Вам с бергамотом или без?

- Без!!

- Вам с сахаром или без?

- С сахаром!!!

- Вам сахар коричневый или простой?

- Уважаемая, дай мне уж, пожалуйста, хоть что-нибудь!!!!

(личный опыт общения в ресторане гостиницы)

Очевидно, что любую атаку прежде всего желательно остановить, причем, максимально быстро, т.е. автоматически. Этим занимаются Endpoint protection platforms - EPP. Однако, понятны и принципиальны ограничения превентивного автомата: а) у него нет права на ошибку, поэтому обречен убивать только 100% зло, и поэтому плохо работает против атак без применения гарантированно вредоносных инструментов (== атак без применения ВПО), да и вообще, убивать только инструменты дело неблагодарное, ибо их несложно сделать великое множество; б) человек всегда может обмануть автомат; в) подход все же реактивен.

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

Отступая еще дальше с целью находить атаки, для которых нет автоматической, даже детектирующей, логики, мы попадаем в еще более широкую область Threat hunting-а. По сути своей - это такое же исследование атак, как это делает любой вендор решений безопасности, но перенесенное в инфраструктуру конкретного заказчика, потому что целевые атаки едва ли можно найти 'in the wild' и поэтому их надо уметь искать в конкретной сети. В стремлении не делать одну и ту же работу более одного раза, успешные трофеи после каждой охоты запиливаются либо в детекты ЕРР, ну, а если это тяжело\невозможно автоматически обезвредить, - в детекты, которые будет подхватывать в работу операционная безопасность (SOC). Концептуально понятно, что Threat hunting делается руками, поскольку наличие автоматизированных алертов любой степени "интеллектуальности" возвращает нас к детектирующим системам.

Все сказанное выше можно отобразить на простенькой схемке.

С точки зрения Заказчика, решающего одну задачу защиты от атак, понятно, что надо убивать все 100%-ное зло, там где все также есть индикаторы, но есть сомнения - сначала посрасследовать, а затем, если подтвердилась нефолса, убивать, ну а где и индикаторов нет - искать, искать и искать, подтверждения, что меня поломали.
Однако, исследователи рынка разбивают эту одну задачу, на разные, решаемые разными классами продуктов - EPP, EDR + всякие NG-*. Такое разделение культивирует в корне неправильное мнение об некой отсталости ЕРР от новых продвинутых технологий в составе EDR, тогда как любому здравомыслящему понятно, что оба подхода - звенья одной цепи, дающие результат только в совокупности. Такое искусственное дробление, где каждая из частей не дает желаемого результата напоминает историю о развешивании лейблов на различные типы ВПО с последующим выпуском многокомпонентных решений по защите.
Лично я против сложности и сторонник интеграции. Поэтому если в какой-то момент времени изменились ландшафт угроз\типы атак, надо не делать новый продукт, а обеспечивать чтобы существующий продолжал решать поставленные изначально перед ним задачи. Т.е. если EPP изначально придумывался для защиты от атак, то он и должен проходить по всем линиям "отступления" от автоматического лечения, через автоматическое обнаружение до Threat hunting-платформы, а не дробиться на части, эффективно работающие только на каком-то подмножестве проблематики, давая пищу для маркетинговых лозунгов о "legacy", "file-based AV" и пр. Ни EPP, ни EDR, ни NG-* по отдельности не решат задачу Заказчика защиты от [старых, новых, целевых] атак, а, следовательно, нужно предлагать и оценивать комплексные решения, эффективно работающие как против старых, так и против новых TTP, успешно детектирующие по всей "Пирамиде боли" на всех этапах.

Новая эра технологических продуктов

Никогда не противопоставлял Культуру и Цивилизацию, более того, считаю эти два понятия разными перспективами одного и того же.

Со времен Сноудена, робких порывов РФ к импортозамещению, шквала различных обвинений в недокументированных возможностях, сделанных "по ошибке", которой успешно пользовались госхакеры и все остальные, или умышленно, а также загадочных публикаций и событий, становится очевидным тренд, подрывающий глобализацию.
В обществе постепенно культивируется мнение о тотальной слежке, и через какие-нибудь 10 лет продать высокотехнологичное СЗИ в виде "коробки" в другое, заботящееся о национальной безопасности государство, будет крайне сложно.
Описанное явление - обычная трансформация взглядов потребителей, происходящая не первый раз в истории, вызванная, в нашем случае - изменениями модели угроз и нарушителя (что важно для ИБ-продуктов, хотя и звучит как-то академично\бумажно), конъюнктурой рынка, и пр. проявлениями культурно-цивилизационной эволюции. Изменение спроса требует изменения предложения, - подумаем что можно предложить...

Ключевым, и самым ресурсоемким, компонентом любого технологического продукта являются исследования, поскольку основной характеристикой СЗИ является, собственно, качество защиты, которое требует серьезных глубоких исследований атак с целью выработки наиболее эффективных способов защиты от них. Исследования заворачиваются математиками\теоретиками в алгоритмы, которые затем архитекторами превращаются в технологические компоненты, которые, в свою очередь, другими архитекторами заворачиваются в продукты\"коробки", поставляемые конечному потребителю. Да простят меня разработчики за столь простое изложение реально сложных процессов. Очевидно, что на протяжении этой длинной цепочки от идеи до "коробки" есть много полуфабрикатов и запчастей, которые не являются конечными потребительскими продуктами, но, безусловно, имеют ценность, так как аккумулируют в себе исследования.

Далеко не каждая компания может позволить себе исследования, ибо это требует инвестиций прямо сейчас, а окупаемость придет только потом, да и то с вероятностью. Более того, поскольку детектирующая атаки логика является весьма скоропортящимся товаром, исследования внутри продукта ИБ имеют ярко выраженный операционный характер с уровнем качества сервиса, напрямую влияющим на ценность этого исследования. В качестве ремарки, хочется отметить, что системные операционные исследования имеют мало общего с ad-hoc ресерчами, возможно, даже выстрелевшими в какие-либо громкие публикации, так как приоритет operations-исследований - неизменно высокое качество детекта во времении, а не "вау-эффект" от ad-hoc.
А вот написать код, продуктивизирующий исследования - радикально проще.
Учитывая, что недоверие и закладки относятся именно к конечному продукту, а не к исследованиям внутри него, логичным изменением предложения является смещение фокуса с "коробок" на технологии и запчасти. Причем продажи технологий и запчастей с сопутствующим операционным ресерчем (чтобы запчасти продолжали оставаться эффективными) при правильной организации может оказаться еще и более выгодной - как бонус к уходу от возможных претензий в недокументированных возможностях.
Идея совсем не нова. Все то же мы наблюдаем с российским автопромом, когда иномарки ввозят в страну по запчастям и, будучи собранной на территории РФ, иномарка чудесным образом превращается в отечественный автомобиль.

В целом, понятно, что надо делать, но все-таки, позволю в последнем абзаце явно написать алгоритм.

1. Модифицировать стратегию, отдав больше внимания исследованиям, технологиям и запчастям-компонентам, которые можно удобно\дешево встраивать в другие продукты и\или разрабатывать вокруг них необходимую обвязку.
2. Искать и входить в партнерство с локальными производителями программных продуктов (== "сборочных конвейеров"), которые смогут из компонент п.1 сделать локальную сборку и обязательно протащить ее через все возможные местные сертификации.
3. Находить локальных производителей и строить им "производственные мощности" и "сборочные конвейеры", на которых они уже от своего имени смогут делать  продукты и сервисы, удовлетворяющие всевозможным требованиям и условиям.
4. Не расслабляться, помните, что как любая палка имеет, как минимум, два конца, так и любое изменение ситуации можно с одинаковым успехом трансформировать как в убыток, так и в выгоду, и наша менеджерская задача здесь - искать и находить тот правильный ответ обстоятельствам, идти "в ногу" с культурно-цивилизационными изменениями, постоянно эволюционируя.

Проактивная реактивность

С одной стороны, мы дома сидим,

С другой стороны, мы едем!

Александр Аронов "Полный вперед!"

Мы не раз говорили о том, что TH - проактивный подход, поскольку не полагается на заблаговременно подготовленные сигнатуры. Слово "проактивность" имеет смысл некоторого упреждения, а поскольку мы говорим об обнаружении атак, может сложится ощущение "упреждения обнаружения", т.е. "предотвращения". Это не так.

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

Политика Безопасности

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

Я ни в коем случае не хочу оскорбить американских производителей, но, исходя из происходящих событий, приходится верить в слова Сноудена, в экономическое оружие и прямое влияние политики на частный бизнес.

Намедни слушал маркетинговую презентацию решений по защите от целевых атак одного из американских производителей. Возник вопрос, который очень хотелось уточнить, однако, поскольку ответ едва ли может быть быстрым и, что самое главное, объективным, решил не спрашивать.

Целевые атаки - персонализированы под конкретного заказчика, следовательно, они персонализированы, как минимум, под страну. Вот интересно, насколько американская компания может быть компетентна в атаках, характерных для РФ? Целевые атаки - это прежде всего исследования, практика расследования инцидентов. Много ли американские компании расследуют инцидентов в РФ? Вообще, многие ли американские компании, разрабатывающие решения по защите от целевых атак, имеют в РФ широкую сервисную практику и\или исследовательские подразделения R&D ? Весьма немногие, в основном, - какие-то партнеры, умеющие привозить и продавать.
Но пойдем далее, известный факт, что некоторые\многие американские фирмы не рассматривают РФ как свой важный рынок и даже не имеют здесь офиса, что уж там говорить о глубоко-технических инженерах, способных на месте решать вопросы, тем более принимать запросы на новый функционал\исправления, ставить их в планы и реализовывать с желаемыми заказчиками из РФ приоритетами.
Но вернемся к целевым атакам. Как вы думаете, имея РФ в качестве неперспективного рынка, будет ли американская компания инвестировать в исследования целевых атак, специфичных для РФ?  Но все еще хуже: американские коллеги рассматривают Россию и ее технологические компании, как чуть ли не основного киберпротивника. Будет ли в этом случае американская компания заниматься киберобороной своего киберпротивника? А как насчет state-sponsored?
Пойдем еще дальше. Кто-то может возразить, что я неправ смешивая политику и частный бизнес. А вот и нет! Национальный бизнес - это тоже оружие, экономическое. Доминирование национальных компаний на мировом рынке дает преимущества, важность которых сложно переоценить, ставя целые государства в бесконечную экономическую зависимость. Об этом написана масса книг, например, можно ознакомиться с "Исповедь экономического убийцы" Джона Перкинса. Одновременно, с уничтожением национальных экономик своих жертв, ведется и борьба по подрыву того, что еще осталось эффективного и результативного, и об этом даже есть методические указания. В общем, системная работа ведется по всем направлениям.
Многочисленные факты игнорирования явной абсурдности всех обвинений и поразительная настойчивость в продолжении "линии партии" показывает лишь то, что никакой демократии нет, "наши американские партнеры" не остановятся ни перед чем, и никакие обязательства перед заказчиками не остановят американского производителя, если это будет угодно их родине - выбор между "выйти из бизнеса вовсе" и "потерять бизнес в РФ" - очевиден.

Но мы ушли в космос... Что же выбрать российскому потребителю для защиты от целевых атак?
1. Производитель должен иметь обширную практику расследования инцидентов целевых атак в именно в РФ - это специфика целенаправленности атак.
2. Для производителя рынок РФ должен быть важным, занимать значительный % в структуре дохода - это определяет приоритеты.
3. (добавка к п.1) Производитель должен проводить исследования целевых атак в РФ - не могу придумать ничего более объективного, чем наличие русских людей R&D, занимающихся исследованиями целевых атак.
4. Тучи сгущаются, новые санкции сменяют старые, и чем более суверенными мы будем пытаться быть, тем больнее нас будут пытаться задеть во всех возможных сферах. Поэтому, ведя успешный бизнес в РФ, по меньшей мере недальновидно увеличивать степень своей уязвимости от ухудшения политического климата, проще говоря, санкций. Более того, совсем необязательно поддерживать санкции, можно просто валять дурака, мягко саботировать процесс.

Критерий успеха

В одну реку нельзя войти дважды

Как писали ранее, тишина - это страшный звук. И уж тем более не критерий успеха для корпоративной безопасности. Но как же понять, что зачистка была успешна? Практика показывает косвенный рабочий критерий успешного избавления: радикальное увеличения интенсивности попыток проинфектить через характерные для конкретной атаки векторы и техники. Действительно, если бы закрепление сохранилось, предпринимать новые попытки пробива было бы не за чем. Ну, а поскольку оно было утрачено, + согласно 1-ому тезису, ребята не отстанут, - успешная чистка провоцирует активацию попыток новой компрометации. Не думаю, что возобновление забрасывания "плохими" письмами по почте служит исключительно для целей сохранения среднестатистического спам-фишинг-шума, так как попытки пробива с характерными нагрузками\атрибутикой - вынужденное палево для всех "новинок". Поэтому, несмотря на заметное осложнение ситуации на периметре, вывод здесь все-таки напрашивается позитивный: они пока не попали внутрь, раз так усиленно пытаются это сделать.

После взлома

Есть цель? Иди к ней!

Не получается? Ползи к ней!

Не можешь? Ляг и лежи в ее направлении!

Уже писал об оперативности обнаружения, однако, заметна потребность в более системном объяснении, попробую здесь.

Любую атаку хочется предвидеть и предотвратить. Если не получилось предотвратить, то минимизировать ущерб. Минимизировать ущерб можно пытаясь обнаружить успешную атаку как можно раньше и прервать "работу" ребят, пока атакующий не достиг своих целей полностью. Если брать во внимание целевые атаки, планируемые с учетом используемых у Цели средств безопасности, а, следовательно, успешно их обходящие, и выполняемые людьми, и поэтому крайне проблематичны для обезвреживания исключительно автоматическими средствами, то такие атаки гарантировано будут пропущены. И здесь мы как раз попадаем на тот случай, когда предотвратить не получилось и надо обнаружить, расследовать и почиститься. Для достижения этих целей и служит TH, который включается уже после взлома. Поскольку любая атака - это трата ресурсов, а тратить ресурсы впустую - глупо, и атакующие это понимают, постепенно сбывается то, что писал: "в перспективе нас ожидают исключительно таргетированные атаки". Как следствие - повышенное внимание к TH, как подходу, эффективно работающему после взлома.
Ну а что же работает до взлома? Как прежде - все те же автоматические превентивные меры: IPS-ы, WAF-ы, антивирусы и пр. И, если у них не получилось, включается ТН. Печальная очевидная правда в том, что для того, чтобы отличить плохое поведение от хорошего, нужно чтобы это поведение случилось, т.е. придется дозволить допустить сделать плохо, поскольку это (выполненное плохое действие) - единственный индикатор. Но, с дугой стороны, не надо рефлексировать относительно этого вынужденного дозволения, поскольку пока плохое не сделано, ущерба нет и, можно сказать, нет и инцидента.

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

Next-gen

Старый конь борозды не испортит

(Поговорка)

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

Примерно к таким же мыслям прихожу, когда читаю некоторые маркетинговые листовки о защитах нового поколения, включающих в себя все новомодные базворды: machine learning, artificial intelligence, deep learning, behavioral monitoring,..., next-generation. В этих же публикациях, как правило, не брезгают и покидаться грязью в "legacy AV", "signature-based" и т.п.

Что не так? Продолжим серию разоблачений...
Во-первых, по моему мнению "signature-based legacy AV" уже просто нет (если они еще остались, то скоро вымрут как динозавры). Против современных этак это не работает, это понятно, и надо быть полным невеждой, думая, что антималварные вендоры, кто всю свою историю занимаются поиском новых атак, чтобы в сложнейшей конкурентной борьбе, обеспечить свой detect rate, этого не понимают. Очевидно, производители АВЗ первыми сталкивались с новыми атаками и соответствующим образом развивали свои детектирующие технологии. Весной 2015, когда я работал еще в Заказчике, для меня эта логика была очевидной догадкой, сейчас, работая в Поставщике, я могу с уверенностью сказать - все, что можно продетектить и пролечить автоматически - продетекчивается и пролечивается автоматически, и, безусловно, "legacy" здесь недостаточно, поэтому ими все не ограничивается. Правда, не все можно обнаружить исключительно автоматически - но об этом дальше...

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

В-третьих, есть масса фактов (раз, два, три, четыре, пять и т.п.) демонстрирующих, недостаточность, исключительно новомодных технологий. Тут масса причин: и то, что грань межу "целевой" и "обычной" атакой размыта (писали - вот подтверждение), и то, что и в целевых атаках используется "обычная" malware, и то, что есть миллион+1 вариант, когда никакими анализаторами аномалий нет возможности различить вредоносное поведение файла, и несравненно дешевле сделать детект на семейство файликов, чем стрелять по воробьям сложными математическими вычислениями (даже если они выполняются исключительно в облаке и не грузят endpoint), ... в общем, думаю, не надо быть гениальным, чтобы поверить, что разные технологии показывают разную эффективность в различных сценариях. Поскольку сценариев атак может быть великое множество, для обеспечения эффективности нужно иметь великое множество технологий и только их комбинация может дать желаемый результат. А все эти потуги возвышения "нового" за счет унижения "старого" - дешевый "технологический" маркетинг, попытки хоть чем-то обосновать "революционность" своего решения, что, на мой взгляд, в глазах думающего и понимающего потребителя имеет обратный эффект.

Именно поэтому новые технологии, использующие большие данные, машинное обучение, распределенные вычисления, облака - не вытесняют "легаси", а гармонично дополняют. А "новое поколение" - это не то, что реализует только новые подходы, а то, что реализует все, что показывает максимальную эффективность и результативность на современном ландшафте угроз.

Но даже и этого мало! Современные атаки реализуются людьми и противостоять им исключительно автоматически - невозможно, - все та же проблема с обходом средств защиты (новые навороченные автоматы, да, они более продвинуты, но, в любому случае, они - автоматы) и, поэтому, они [всегда, всегда, всегда] могут быть обойдены. И этот сценарий - компенсируется работой команды, не менее квалифицированной, чем атакующие, и использующей все эти новомодные средства не как стену за которую можно спрятаться, но как инструменты (оружие, если хотите) для активного обнаружения и противодействия.

Лес за деревьями

Когда  кариес - гигиена уже на поможет.

(Личный опыт)

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

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

После одного из пилотов, где количество выявленной альтернативной жизни красноречиво подтвердило прежде слабые догадки существования множества возможностей компрометации, а также, факты многократных взломов, и, в конечном счете, необходимость экстренной стимуляции кибериммунитета, было удивительно услышать, что Заказчик решил сначала сосредоточиться на более важных задачах обеспечения ИБ: контроль доступа, управление уязвимостями и выполнение требований комплайенса. Даже в обычных условиях список первоочередных мер вызывает улыбку умиления. Истерический смех вызывает этот список в совокупности со осознанием, что там были ребята (которые, возможно, и не ушли), а легковесная чистка на пилоте едва ли компенсирует отсутствие систематического подхода: поиск-расследование-реагирование-адаптация.

Как по-вашему, зачем ИБ? Какова прямая цель? Сохранение прежней эффективности и результативности бизнеса! КЦД информации - одна из перспектив достижения этой цели, но не сама цель. Контроль доступа - это одно из средств сохранения КЦД информации, так же и управление уязвимостями, тем более - комплайенс - это вообще способ измерения эффективности применяемых средств - ничто из перечисленного не годится в первостепенные меры, так как не закрывает цель, а лишь частично приближает к ней: решите вопрос с контролем доступа - атакуют через уязвимость в ПО, решите вопрос с уязвимостями - атакуют через целевой фишинг или зеродей, решение вопроса с комплайенсом - не является достаточным условием состояния безопасности вовсе. А, на самом деле, логическая цепочка очень проста: для сохранения прежних effectiveness и efficiency бизнеса нужно научиться противостоять атакам (это банально просто: любое покушение на бизнес - это  атака) -- чтобы атакам противостоять надо, как минимум научиться их обнаруживать, обнаруживать любые атаки, и реагировать на них. Получается примитивно простая формула: цель ИБ - защита от атак. Именно защиту от атак мы и предлагали, понимая что это - покроет цель, но Клиент предпочел средства: ставить патчи, управлять доступом, делать комплайнс - одним словом, заниматься гигиеной в то время, когда уже нужно лечить кариес.

Кибериммунитет

Уверен, что на определенном уровне абстракции все науки пользуются одними принципами

Очевидное поведение: если тебя стали разыскивать, надо "лечь на дно", пока ситуация не успокоится. И, тем не менее, удивился, когда столкнулся с этим на практике. Ребята (для упрощения можно считать APT), которых мы отслеживали в одном из пилотов, вероятно, легли на дно, поэтому пособирав все beacon-ы, вытащив оттуда все C&C-шки, позакрывав все их на периметре, почистив все, что на них отстукивалось, а также все, где были обнаружены другие, найденные в рамках чистки IoC-и, мы, было, успокоились - поддержка с воздуха не наблюдала ничего аномального...
Но к окончанию пилота Ребята вернулись. Причем, с большой степенью уверенности это не был новый пробив, - периметр хорошо просматривался и ничего эксплуатабельного не пролетало. Т.е., они сохранили persistence, просто приостановили свою работу и стали чуть менее заметны, и наш расслабленный подход, заключающийся в фиксации уже выявленного поведения и артефактов перестал давать результат, и отсутствие прежнего шума было расценено нами как победа над атакой, а это было - прекращение, временное.
Поначалу я немного сокрушался о такой нашей "оплошности" - увлеченные своим успехом, мы не заметили как нас переиграли. Но позднее понял то, что хочу донести в этой заметке - они никогда не остановятся. Они будут всегда возвращаться, и не важно как - через новый пробив периметра или используя старые бэкдоры. Задача ИБ - бороться с ущербом, при этом все равно как достигается, что его нет - Ребята не проникли в инфраструктуру или они пробились, но как только начинают активничать их сразу выявляют и они уходят, путь на время, чтобы затем вернуться, но результат достигнут - ущерба нет.

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

Как иммунитет постоянно в работе, так и ИБ - это бесконечный процесс выявления, расследования и чистки, причем, может, и не важно, что зачищено не все, важно, что ущерба нет, проявится активность - зачистим еще раз, главное - иметь возможность своевременно выявить и расследовать, до того, как активность обратится в профит для Ребят, и в ущерб для вас.

Закончить хочется краткими тезисами, суммирующими опыт, который я пытался максимально интересно изложить сегодня:
1. Ребята не отстанут - они будут приходить снова и снова
2. Не надейтесь на периметр, есть масса способов попасть внутрь, руководствуйтесь принципом, что Ребята уже внутри
3. Шансов обнаружить Ребят внутри значительно больше, так как закрепление, горизонтальные перемещения, внутренняя рекогносцировка,  сбор данных, эксфильтрация, удаленное управление и т.п. - намного более продолжительные и шумные операции, чем пролет неведомого эксплоита через периметр.
4. Не надо стремиться победить все зло (недостижимость совершенства - закон диалектики), надо стремиться победить материальное зло, несущее ущерб. Про приоритезацию есть книжный термин - триаж, но думаю на уровне здравого смысла, и без книжек, смысл понятен.
5. Никогда не расслабляйтесь - "тишина - страшный звук" - возможно Ребята сменили тактику, сменили инструменты, временно затихли - ищите с еще большим вниманием, охотьтесь постоянно, помните п.1
6. Квалификация и осведомленность Ребят - очень высокая, они знают вас и как вы их ищете, за вас здесь только старая аксиоматическая поговорка криминалистов о том, что любое преступление всегда оставляет улики - ищите эти улики, постоянно, а кто ищет - тот находит.
7. ИБ (Threat hunting, в частности) - это кибериммунитет корпорации, контролирующий ситуацию, не позволяющий ей дойти до ущерба.

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

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

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

На слайде 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 функцией поиска атак, обошедших используемые средства защиты.

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

Наблюдая то, как бодро 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 - отличный быстрый старт, который позволит вам уже сейчас работать в режиме, аналогичном наличию Центра компетенции по ИБ, находясь еще в условиях сетевой "феодальной раздробленности".

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

Зри в корень!

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Несомненна важность авиационной поддержки наземных операций.

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

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

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

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

Threat hunting как процесс SOC

Сегодня на 7-ом собрании SOC Club-а "SOC в России" рассказывал о Threat hunting-e в рамках работы SOC. Вот презентация:

Threat hunting as SOC process from Sergey Soldatov

Технически получилось немного смазано, так как я не совсем уложился во время, поэтому в этом посте перечислю основные тезисы, которые я хотел донести:
1. Переход "защиты от ВПО" в "защиту от целевых атак" - очевидная эволюция ландшафта угроз.
2. Эволюции п.1 соответствует очевидное развитие подходов к защите: от Alerting-а, как реакции на предопределенные сигнатуры, до Hunting-а, как поиска новых угроз.
3. Современные атаки обладают рядом свойств, которые надо брать во внимание при планировании СЗИ (слайд 5)
3. История с Vault7 полностью добила веру в эффективность превентивных средств защиты и сместила приоритеты развития СЗИ именно в сторону своевременного обнаружения и быстрого восстановления (слайд 6)
7. Слайд 7 - концептуальные различия подходов. Слайд "пропал", так как я забыл его сделать видимым в pptx ;), однако, попереживав несколько секунд, решил, что в этом нет ничего страшного, так как уже неоднократно его показывал и рассказывал, например, здесь.
8. Threat hunting не исключает подходы классического мониторинга, а дополняет. На слайде 8 показано это взаимное дополнение, разложенное по процессу управления инцидентами.
9. Для TH нужны исходные данные и технологии. Это представлено на слайде 9. Расскажу по аббревиатурам - это наши внутренние подразделения-поставщики знаний для нас: Global Research and Analysis team (GReAT), Anti-Malware research (AMR), Targeted Attack Research Group (TARG), Security Operations Center (SOC) - имеется в виду наша внутренняя практика обнаружения, коей больше с каждым инцидентом, не являющемся фолсой, Security Services Research (SSR) - наш внутренний ИБ ресеч; сервисы расследования инцидентов - Incident response (IR), Digital forensics (DF), Malware analysis (MA); ну а поставщиком на сырых нотификаций на низком уровне выступает - Endpoint (EP).
Важным моментом в этом слайде является стрелочка "Постоянное совершенствование", означающая, что мы реализуем новые детектирующие и микрокорреляционные логики на уровне ЕР, - можно считать, аналогично, созданию сигнатур.
В качестве иллюстрации дана картинка все с той же презентации, где показана максимально упрощенно текущая процессная модель ТН.
10. Последний слайд - действительно последний, отражающий где в общем списке процессов SOC (список процессов взят из ГосСОПКИ) ТН и на что он в основном нацелен.

Надеюсь, что доклад (в совокупности с этим постом) будет полезен аудитории.

Оружие массового поражения для всех

- Безопасность - это когда стоимость взлома превышает стоимость выгод атакующего.

- Вы уверены?

Новости про ЦРУ уже не произвели такого фурора, как товарищ Сноуден, в свое время. Все привыкли, что за нами следят и вендоры бывают на госконтрактах и их терзают смутные сомнения. Очевидна нерентабельность усилий противостояния гражданина армии, что объясняет наличие соответствующих по возможностям подразделений. 

Но, тем не менее, лично мне эта публикация все равно расширила кругозор, цитаты:
1. "Securing such 'weapons' is particularly difficult since the same people who develop and use them have the skills to exfiltrate copies without leaving traces — sometimes by using the very same 'weapons' against the organizations that contain them. There are substantial price incentives for government hackers and consultants to obtain copies since there is a global "vulnerability market" that will pay hundreds of thousands to millions of dollars for copies of such 'weapons'. Similarly, contractors and companies who obtain such 'weapons' sometimes use them for their own purposes, obtaining advantage over their competitors in selling 'hacking' services."

2. "In what is surely one of the most astounding intelligence own goals in living memory, the CIA structured its classification regime such that for the most market valuable part of "Vault 7" — the CIA's weaponized malware (implants + zero days), Listening Posts (LP), and Command and Control (C2) systems — the agency has little legal recourse.

The CIA made these systems unclassified.

Why the CIA chose to make its cyberarsenal unclassified reveals how concepts developed for military use do not easily crossover to the 'battlefield' of cyber 'war'.

To attack its targets, the CIA usually requires that its implants communicate with their control programs over the internet. If CIA implants, Command & Control and Listening Post software were classified, then CIA officers could be prosecuted or dismissed for violating rules that prohibit placing classified information onto the Internet. Consequently the CIA has secretly made most of its cyber spying/war code unclassified. The U.S. government is not able to assert copyright either, due to restrictions in the U.S. Constitution. This means that cyber 'arms' manufactures and computer hackers can freely "pirate" these 'weapons' if they are obtained. The CIA has primarily had to rely on obfuscation to protect its malware secrets."

В целом, текст достаточно красноречив, и не нуждается в моих комментариях... Но вы только вдумайтесь: все мои инвестиции в проактивную безопасность - это повышение стоимости взлома, потому что, очевидно, взломать можно все и вопрос только в ресурсах на это потраченных. Но в сложившейся ситуации аксиома о том, что я могу чувствовать себя в безопасности, когда стоимость моей компрометации достаточно высока - уже не работает, потому что есть некоторая организация с бесконечными ресурсами, инвестирующая в технологии нападения и никак не ограничивающая и не контролирующая их использование! Даже, выкинув из внимания вопросы этики, морали и глобальной информационной безопасности, - ситуация выглядит аналогично, как если бы некая контора делала атомные бомбы (или оружие массового поражения (ОМП) вообще) и разбрасывала их по миру для всеобщего использования. Конечно же, оно при этом может попадать в руки террористов и прочего криминала, а пытаться что-то со всем этим делать приходится нам.
Вспоминается, как подозрение в наличии ОМП послужило причиной лишения государства суверенитета, как аргумента для спасения Человечества. Здесь же кибероружие разрабатывают и практически публикуют, и это "считается" нормальным, все по комплайенсу.
Так что, уважаемые коллеги, интерпрайзные безопасники, вот у нас с вами новое обстоятельство, которое надо брать во внимание.