Saturday, January 13, 2018

Пробы

Вероятно оттого, что много лет своей практики я потратил на сетевой мониторинг, я верю в IDS, И после того, как они стали вытесняться IPS, и сейчас, когда пропали и последние, войдя в понятия NG-FW, WAF, App-level-FW и т.п.

Аргументы, которыми маркетанты препарируют IDS не состоятельны так же, как не состоятельна и вера в абсолютную эффективность превентивных средств защиты, поскольку у них есть, как минимум, одна большая проблема: если вероятность фолсы (false positive) более 0% существует риск остановить продуктивный сервис, и в этом случае ущерб возможен выше, чем от пропуска атаки (false negative). Поддерживая концепцию эшелонирования подходов: 1) предотвратить, 2) если нельзя - обнаружить, 3) если нельзя - искать и находить, - получаем, что наличие IPS не отменяет необходимости IDS (в общем-то, они обе нужны), тем более не отменяет необходимость IDS наличие *-FW или любой другой пакетной фильтрации (понятно, что технически это может быть как угодно: IDS на RSPAN-е, IPS в разрыве или *-FW с активированными не только блокирующими правилами, но детектирующими (как раз для сбора информации, фингерпринтинга хостов в сети и фолсящих сигнатур, - сюда же всякие ML - не думаю, что кто-то доверит ML\DL что-либо блокировать автоматически)  - это не предмет данной заметки). При генерации грамотных логов, IDS можно использовать и для Threat hunting-а, так как доступна, как минимум, следующая информация:

  • пассивный фингерпринтинг хостов в сети (версии ОС, версии приложений, известные уязвимости), 
  • по каким протоколам трафик ходит между какими хостами в каком объеме, поскольку разбирается трафик приложений, IDS может видеть пересылаемые файлы (некоторые могут эти файлы выкусывать и складывать),
  • всевозможные аномалии: 
    • отклонения от RFC, 
    • потери пакетов и обращения к несуществующим адресам или закрытым портам - пробы (причем, с контекстом: соединение отвалилось по таймауту, прилетел RST или ICMP unreachable), 
    • всевозможные сканирования (причем, нормальная IDS будет определять тип сканирования и в некоторых случаях сканер), бруты, фаззинги,
  • пролетающие по сети эксплоиты и нагрузки, в общем случае - все сетевые атаки.
Если даже у вас заблокирован доступ в подсеть, согласитесь, полезно знать кто туда хотел, но не смог, попасть по каким портам - отличный повод с этим поразбираться. Если на какой-то хост вы вдруг стали наблюдать кучу проб, это может означать, что на нем отъехала служба или до нее пропала сетевая доступность, Любопытно видеть попытки подключения к несуществующим хостам или закрытым портам... Тем более интересно видеть попытки отправить туда эксплоит. 

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

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


Sunday, December 3, 2017

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

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

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

Saturday, November 25, 2017

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

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


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

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

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

Sunday, November 19, 2017

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

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

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

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

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


Saturday, November 18, 2017

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

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

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

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

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

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

Thursday, November 2, 2017

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, успешно детектирующие по всей "Пирамиде боли" на всех этапах.


Friday, October 20, 2017

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

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

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

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

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

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

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