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

Friday, October 6, 2017

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

С одной стороны, мы дома сидим,
С другой стороны, мы едем!
Александр Аронов "Полный вперед!"

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

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

Sunday, September 24, 2017

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

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

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

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

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

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


Monday, August 21, 2017

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

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

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


Saturday, August 19, 2017

После взлома

Есть цель? Иди к ней!
Не получается? Ползи к ней!
Не можешь? Ляг и лежи в ее направлении!

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

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

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