Антивирусы и Песочницы

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

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

Anti-malware (АМ) движки - напротив, представляют собой реальную среду исполнения ВПО и поэтому дают максимально достоверные сведения об исполнении ПО в фактическом окружении. Реальные рабочие станции предоставляют более достоверную информацию для анализа. Но, поскольку реальные системы должны выполнять реальные задачи, а не функцию исследовательской инфраструктуры, возможно наличие ресурсных ограничений, не позволяющих "дотянуться" до всех интересующих компонентов. Ну и, конечно, ни о каких нестабильных перехватах речи идти не может.

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

Истина по косвенным признакам

По плодам их узнаете их

(Матф.7:16)

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

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

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

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

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

Пробы

Вероятно оттого, что много лет своей практики я потратил на сетевой мониторинг, я верю в 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 "шум") будут крайне полезны при сетевой форенсике, расследовании инцидента.

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

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

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