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