SOC --> SOC-MDR --> MDR

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

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

В статье автор выделяет три вида SOC:

• Классический SOC. Для упрощения понимания - это операционное подразделение занимающееся разбором предопределенных автоматически сгенеренных системами обнаружения\обработки событий\корреляции инцидентов - алертингом.
• MDR. Упрощенно - сервис по обнаружению и расследованию продвинутых атак, неизбежно связанный с подходом Threat hunting.
• SOC-MDR, - который комбинирует модели первого и второго.

Создается впечатление, что в статье эти модели разделяются - это некорректно, а поскольку момент принципиальный о нем и поговорим в этой заметке\статье.

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

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

Но вернемся к обсуждаемой статье на Anti-Malware. Приведенные выше модели - это одни и те же подразделения операционной безопасности, но на разных этапах зрелости. Классический SOC, разгребающий события неправильной аутентификации, алерты сетевых систем обнаружения вторжений - то, что было раньше, и сейчас, очевидно, этого недостаточно, чтобы обнаруживать современные техники проведения атак. Если мы говорим о целевых атаках, когда и применяемые атакующими техники и, тем более инструменты, никогда ранее не были известны производителям используемых систем обнаружения, то здесь нужны возможности по проведению исследований. И эту проблему решает, пользуясь терминологией статьи, как раз модель MDR. С точки зрения сервиса SOC Обнаружение атак - MDR на текущий момент времени наивысшая ступень зрелости, так как его подходы являются наиболее комплексными для противодействия современным атакам, при этом, безусловно, не игнорируя "классические", так как, как отмечено выше, продвинутый атакующий будет использовать те подходы, которые будут давать результат и при этом являться наиболее дешевыми. Два понятия "Обнаружение атак" и "Исследования" я выделил курсивом потому что их надо пояснить.

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

• Инвентаризация активов - для понимания, что может быть атаковано
• Управление уязвимостями - для понимания есть ли явные возможности для атаки
• Анализ угроз - для понимания, откуда может прийти атака
• Повышение осведомленности - то же, что и управление уязвимостями, так как латать дырки нужно не только в железе и софте, но и в сознании пользователей
• Управление инцидентами - операционная поддержка процесса обнаружения атак
• Реагирование на инциденты - часть Управления инцидентами
• Анализ результатов и совершенствование - часть Управления инцидентами
• ...

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

Про исследования я много где говорил, еще даже до того, как стал работать в компании, в которой бОльшая часть сотрудников занимается исключительно исследованиями. По-моему очевидно, что если мы претендуем на способность обнаружения уникальных атак, мы обязаны иметь зрелую практику проведения уникальных исследований. Потому что Threat hunting - это не что иное как перенос этой практики уникальных исследований в инфраструктура заказчика. Прошло то время, когда любую атаку можно заблаговременно найти в Интернете, выпустить детект и защитить клиентов. Целевую атаку можно найти только в целевой инфраструктуре, а значит те же подходы, применяемые при поиске в Интернете надо повторить в кастомизированном клиентском окружении. Собственные исследования - ключевой момент, дающий возможность заниматься Threat hunting-ом. Все очень просто: если поставщик за всю свою историю не выявил не одной АРТ, на чем основано утверждение, что он обнаружит целевую атаку в инфраструктуре заказчика? Наличие собственной зрелой практики глубоких исследований - наиболее объективное подтверждение компетентности в выполнении активного поиска угроз (Threat hunting). Кроме того, надо понимать, что любая АРТ с момента выявления становится операционной историей, требующей постоянного отслеживания - за АРТ стоят конкретные группы людей, которые изобретают новые техники, инструменты, у них меняется сфера интересов, мотивация ... жизнь кипит... - эти изменения должны своевременно отслеживаться и должным образом адресовываться технологически-продуктово и организационно-сервисно. Поэтому упомянутые здесь исследования целевых атак должны быть не ad-hoc - что-то нашел, сделал публичный отчет, получил свой квант славы и забыл, а систематические - постоянное отслеживание известных группировок и их деятельности. Отсюда следует вторая важная характеристика способностей по Threat hunting-у - количество отслеживаемых АРТ-кампаний в настоящее время. 

Поговорим об инструментарии. Исследования атак - основа для придумывания логики обнаружения атак, гипотез (если быть точным, то Исследования - один из источников TI, а уже TI - основа для построения гипотез и детектов, это важно, будет время, сделаю про это отдельны пост, но для этой статьи не принципиально). На базе знаний об угрозах мы придумываем как обнаружить и обезвредить. Для этого нам, если сильно упрощенно, нужны: сенсоры (поставщики событий) и инфраструктура, выполняющая обработку этих событий. Очень важно, и совсем несложно это понять, что номенклатура событий сенсора определяет возможности по детекту, которые в свою очередь полностью определяют можем мы обнаружить ту или иную угрозу или нет. Как я отметил ранее, Исследования - первичны, так как они дают полное представление об угрозах, а следовательно исследования определяют требуемую номенклатуру событий - их типы, поля для каждого типа, интенсивность, методы сбора и т.п. Нам не выгодно собирать больше, поскольку это сопряжено с необоснованными инфраструктурными затратами, но нельзя и меньше, так как это не позволит выполнять детектирование эффективно или вообще что-либо обнаруживать. Поскольку атаки мутируют, это требует изменений в номенклатуре событий, поэтому чтобы оперативно и эффективно адресовать самые современные атаки, нужно уметь оперативно вносить изменения в сенсоры. Аналогичная ситуация с инфраструктурой обработки событий сенсоров. Принципиальный момент, который надо вынести: Исследования определяют какие сенсоры нам нужны, какие события с какими полями они должны генерить, какая обработка для этих событий требуется, и как ее оптимально перераспределить между самим сенсором, облаком и аналитиком. В итоге получается многоэтапный эшелонированный подход. Теперь, я думаю, понятно почему MDR обычно стремится использовать собственные инструментальные средства. Использование других конечно же возможно, но это может иметь негативные последствия на качество сервиса. Принцип Алана Кэя, который лично я услышал от не менее выдающегося Стива Джобса, работает и здесь:  если вы хотите искать уникальные атаки (== делать Threat hunting), вам нужны собственные уникальные исследования, которые вы трансформируете в уникальные инструменты, которые в сочетании с квалифицированной командой позволят вам это делать эффективно и результативно. Из сборной солянки, когда исследования от одних поставщиков, тулсет - от других, команда - от третьих тоже можно составить предложение MDR, но оно, по моему мнению. не сможет работать столь же эффективно, как от провайдера с собственными исследованиями, инструментарием и экспертизой.

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

Из картинки важно запомнить очень простую вещь: любой функционально полный MDR должен иметь минимум 14 выделенных сотрудников, не беря во внимание внешние по отношению к SOC подразделения разработки и исследований - программистов сенсорных и инфраструктурных компонентов, исследователей угроз и целевых атак, администраторов и автоматизаторов инфраструктур исследователей угроз и пр.

Но вернемся к первоначально обсуждаемому исследованию и коснемся модели SOC-MDR.

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

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

Карьера карьериста

Каждый растет до уровня своей некомпетентности

(Принцип Питера)

Вынужден признаться я не очень хорошо отношусь к карьеристам. Наверно, это неверно, но у меня есть на этот счет предположения и предрассудки, которые попробую изложить в этой заметке.
Прежде чем о чем-то рассуждать, надо синхронизоваться по терминологии. Карьерист в моем понимании - это тот, кто делает все для того, чтобы его позиция изменялась быстро, в результате наблюдался карьерный рост.
Что такое "быстро"? Мой опыт показывает, что придя на новое место (если это, например, не сборочный конвейер, где задачи понятны просто из наблюдения за соседями, а показатели эффективности четко определены), нужно в среднем полгода, чтобы разобраться что к чему. Т.е. только в среднем через полгода новичок научится работать на уровне не нарушения ожиданий от него. Если наша работа имеет творческую составляющую (а любая должна иметь, иначе могла бы выполняться машинами), то возможности по оптимизации/инноваторству также появятся не раньше чем через полгода (пока не будем обсуждать тот сценарий, когда, напротив, требуется свежий взгляд на процессы, лишенный предубеждений, чтобы предложить улучшения). Пойдем дальше: через полгода становится понятно что надо поменять\улучшить. Но на реализацию этих улучшений также нужно время, причем, чем "революционнее" изменения, тем больше требуется времени на их реализацию. Если мы говорим о карьерном продвижении в рамках компании, то логично предположить, что реализуемые инновационные идеи также должны быть заметны в масштабах компании. В зависимости от размеров компании и масштабов изменений, реализация последних может занять от полугода до бесконечности. Теперь мы получили представление о минимальном сроке нахождения в одной позиции, в течение которого можно реализовать что-то, способствующее продвижению как в рамках компании, так и за ее пределами, - это один год. На практике, я бы полагался на срок - два года, минимум, а, беря во внимание, размер компании, предметную область изменений и их масштабность, - этот срок "зарабатывания звезд\орденов\медалей" значительно больше.
При стремительном карьерном росте продолжительной работы в одной позиции не наблюдается, поэтому добиться даже состояния эффективной работы в текущей позиции не всегда удается (выше мы разобрали, что нужно минимум полгода, чтобы просто научиться работать и минимум год, чтобы сделать что-то значимое). Поэтому мы получаем, что из плохих сотрудников службы поддержки пользователей вырастают плохие сисадмины, которые потом становятся плохими архитекторами или начальниками отделов, которые, в свою очередь, становятся плохими директорами департаментов. При этом эффективность сотрудника при столь стремительном карьерном росте весьма невелика: он просто не успевает стать эффективным - нет у него этих год-два, за которые можно научиться работать, понять как изменить[ся] к лучшему и реализовать изменения. Беря во внимание принцип Питера, который в упрощенном виде я вынес с эпиграф, мы получаем, что достигнув карьерных высот, ограничивающихся исключительно возможностями и способностями карьериста, его эффективность также остается нулевой, так как на вершине карьеры не хватает самого главного - компетентности.
Я всегда ценил профессионализм, а он, на мой взгляд, - фактически, опыт, который приобретается за долгие годы работы на одном месте. В любой творческой позиции всегда есть что оптимизировать и нормальные руководители всегда поощряют инициативу, поэтому, для того, чтобы делать что-то выдающееся, совсем не обязательно постоянно сремиться менять круг обязанностей. Постоянное прыгание с позиции на позицию размывает ответственность (этой проблеме стоило бы посветить, как минимум, отдельный абзац, но и так уже много написал, не буду утомлять занудством), в итоге мы получаем кучу проблем, в которых, вроде как, никто и не виноват.
В завершении, хочу отметить, что, конечно же, я не против карьерного роста, в его гармоничном проявлении: реализовал один проект, перешел к другому и т.п., при этом не один из реализованных проектов не загнулся (опять же, по опыту, успешные проекты превращаются в операционную историю, поэтому по завершении проекта ситуация, когда данная сфера деятельности уже не требует внимания, часто не наблюдается; решение - более комплексный подход: реализовать успешно не только проект, но и построить его операционную модель, при которой проект мог бы успешно продолжать жить без нашего с вами внимания, а мы могли бы переключиться на новые задачи ). С каждым проектом - новые знания, навыки, опыт, профессионализм, что позволяет браться за новые проекты, более сложные, чем предыдущие, требующие большей компетентности... Но все начатое нужно доводить до успешного конца, а на это нужно время, чего нет в рамках стремительной карьеры карьериста.

Практика обнаружения атак, использующих легальные инструменты @BIS Summit 2018

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

Выкладываю презентацию.

Практика обнаружения атак, использующих легальные инструменты from Sergey Soldatov

Времени было 15 минут, а рассказать хотелось о многом, поэтому говорил быстро. Вполне возможно, что что-то не отложилось на слух, поэтому привожу в этом посте кратко драфт скрипта к слайдам.

О чем речь?

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

Инфраструктура – первый эшелон

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

Анатомия современной таки

Если рассмотреть анатомию современной атаки, то можно сделать следующие выводы.

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

Инфраструктура

Рассмотрим более детально, что творится в инфраструктуре

Мотивация

Как показывает практика, на уровне инфраструктуры тоже можно обойтись без аномалий и вредоносного ПО. На слайде представлена ссылка на выступление от 2013 года, демонстрирующее подход "Living off the land" – выполнение вредоносных действий без использования вредоносного ПО и генерации аномалий. Мотивация понятна: оставаться как можно дольше незамеченным (мы помним, что чем дольше атакующий сидит в инфраструктуре, тем сложнее его оттуда вычистить), во-вторых, не надо тащить с собой инструменты, что само по себе может и не получиться сделать незаметно.

Некоторые примеры нестандартного использования

Здесь, во-первых, на помощь приходят возможности альтернативного использования штатных утилит операционной системы. В целом, такое использование – нестандартно, и это может быть подозрительной аномалией.

Некоторые примеры стандартного использования

Однако, если посмотреть на инструменты, которые можно применять для вредоносных целей, не выходя за рамки их типового использования – их гораздо больше! Если на это использование делать детекты, то ложных срабатываний будет очень и очень много.

За что зацепиться à Детекты/Ханты, Алерты

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

Во-вторых, нужно как-то обеспечивать и контролировать полноту покрытия всех возможных техник нашими детекторами.

В-третьих, нам нужна инфраструктура, способная эффективно обработать собираемые данные. И здесь обязательно встанет вопрос оптимизации.

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

Конверсия детектов/хантов = NTP/(NTP + NFP)%

Если говорить о поиске и обнаружении атак, основанных на использовании только легальных инструментов, то неизбежен высокий процент ложных срабатываний для детекторов. Для управления ложными срабатываниями хорошей метрикой является конверсия детекта, выраженная в процентах. На основании ее можно определять

• приоритет взятия детектов в работу,
• порядок использования (алерт, который сразу надо расследовать; разметка событий, на которые надо обратить внимание или как обогащение для событий, требующих рассмотрения в совокупности с другими событиями – пример разбивки приведен на слайде)
• ну и, конечно, метрика показывает эффективность детекта – можно сразу определять неэффективные и дорабатывать их.

Приложения и Бизнес-процессы

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

Использование легальных возможностей приложений

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

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

Следующий пример – субъект, не имеющий сам прав, но имеющий права на назначение прав. Ярким примером здесь является Агент регистрации УЦ (Enrolment agent), который, как правило, не является админом в домене, но может зарегистрировать в УЦ (Enrol) сертификат для учетной записи админа и аутентифицироваться им. Ну и банально, если мы говорим о ERP, например, SAP, то данные, хранящиеся в приложении могут увидеть: админы базиса SAP – если прав нет, могут себе легко дать, админы СУБД – прямо в таблицах базы (в SAP есть функционал шифрования данных в базе, но я не видел, чтобы так кто-то делал), админы ОС, которые могут увидеть данные СУБД.

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

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

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

Атаки на бизнес-процессы («лайф-хаки» с оттенками грязи)

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

Итак, есть лоукостеры, которые предлагают весьма выгодные условия перелета, при условии отсутствия багажа. С учетом того, что ручная кладь может достигать 10 кг, а вес чемодана не должен превышать 23 килограмма, получаем, что семья из шести человек в ручной клади может провести багажа на 3 чемодана, что по вещам вполне достаточно на две недели.

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

Что касается схем мошенничества, то их великое множество. На слайде я привел два, скорее, классы, чем конкретные сценарии: карты лояльности и компенсацию расходов по чекам.

Что делать?

Ответ на вопрос что делать очевиден. Понять свои бизнес-процессы – исследовать схемы атак – придумать контроли – построить операционные сервисы управлениям придуманными контролями – анализ метрик этих сервисов позволит совершенствовать весь процесс.

Эпилог 1(2). Безопасность – это компромисс

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

Эпилог 2(2). Комбинируй эшелоны

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

Из зала был один вопрос: "Где в вашем докладе про конвергенцию? Тема нашей секции "Конвергенция последней линии...". Этот же вопрос потом повторился еще к одному докладчику, я решил, что это - критерий неформатности доклада, поскольку остальным спикерам такой вопрос не задавался, полагаю, в их докладах было как раз про конвергенцию. С нетерпением жду записи всех докладов, чтобы повнимательнее ознакомиться с материалом.
Я попытался ответить на этот вопрос, но, по-моему, спрашивающий не был удовлетворен. Что ж, давайте попробуем разобраться здесь, и, если среди читающих мои заметки, есть автор вопроса, надеюсь, мой ответ устроит.
По определению: Конвергенция - это объединение, сближение, схождение. В докладе я рассказывал о том, как на разных уровнях абстракции (инфраструктуре, приложении, бизнес-процессах) мы имеем объекты, объединяющие в себе функционал различного назначения в зависимости от контекста - одна и та же утилита операционной системы, или функция приложения, или свойство бизнес-процесса может нести в себе в одних условиях - желаемое благо (хорошо), а в других - недопустимый ущерб (плохо). Нож - хорошо для нарезки хлеба, но плохо, что им можно убить; вообще, любое оружие - это хорошо для защиты, но плохо, что с его использованием можно совершать преступления. SSO - это хорошо для удобства, но плохо, так как неизбежно приводит к доступности аутентификационных данных из памяти. Программы лояльности - это хорошо, так как это позаоляет привлекать клиентов, но плохо, так как с ними можно придумать много схем мошенничества и, связанные с этим риски, придется как-то адресовать.... В общем, думаю понятно.

Инерция

Инерция – это физическое явление сохранения скорости тела постоянной, если на него не действуют другие тела или их действие скомпенсировано

(Из учебника Физики за 7 класс)

Уже писал о том, что требование использования различных СЗИ от ВПО в инфраструктуре не добаляет безопасности. Однако, это требование по-прежнему есть в СТО БР ИББС и 382-П, вот, например, цитата из последнего:
"2.7.3. Оператор по переводу денежных средств, банковский платежный агент (субагент), оператор услуг платежной инфраструктуры обеспечивают использование технических средств защиты информации от воздействия вредоносного кода различных производителей и их раздельную установку на персональных электронных вычислительных машинах и серверах, используемых для осуществления переводов денежных средств, а также на межсетевых экранах, задействованных в осуществлении переводов денежных средств, при наличии технической возможности."
Согласен, что Положение устаревшее, написано в 2012 году, но проблема в том, что и сейчас, на закате 2018, его по-прежнему пытаются исполнять, продолжая увеличивать энтропию там, где, напротив, требуется порядок.

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

Боль в том, что уже понимая низкую эффективность автоматически привентивных средств защиты, мы на уровне регулятора продолжаем культивировать веру в них.

Но нет смысла писать про то же самое, если дело только создании неправильных стереорипов. Основная проблема в том, что требование использования гетерогенного покрытия инфраструктуры средствами защиты - снижает возможности по обнаружению сложных атак, проще говоря, - вредит безопасности. Логика эта на поверхности. Если говорить о целевых атаках, то они тщательно готовятся, безусловно, беря во внимание испльзуемые средства защиты, поэтому предотвратить такую атаку исключительно превентивными автоматами практически невозможно. В этих условиях мы вынуждены отступать, сдвигая приоритеты от предотвращения в сторону обнаружения, поиска и реагирования. Ключевым моментом для эффективного обнаружения является - visibility (попробую перевести это как "наглядность-обзорность") - надо в едином месте обозревать все данные со всей инфраструктуры. Если говорить о endpoint-е, то поставщиком таких данных является EPP-EDR. Все нормальные EPP-вендоры это уже давно поняли это и оснастили свои автоматические Anti-malware-движки агентами EDR и сервисным предложением над ними, потому что только такой полный стек обеспечивает более-менее высокую эффективность.
Требование наличия решений разных роизводителей на разных частях инфраструктуры (например, один вендор - на рабочих станциях, другой - на серверах) приводит к раздроблению наглядности-обзорности на части, что снижает возможности по обнаружению атаки после взлома. Ну, или, как минимум, значительно усложняет обнаружение и активный поиск угроз (Threat hunting).

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

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

Снижение киберрисков в эпоху цифровой трансформации

Отступая, отстреливайтесь!

В начале июля делал доклад на Конгрессе по кибербезопасности Сбербанка. Трансляции всех выступлений, в том числе и моего, доступны здесь.

Отдельно выкладываю презентацию.

Reducing cyber risks in the era of digital transformation from Sergey Soldatov

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

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

Оперативность и Релевантность

У меня создалось впечатление, что вера среди широких масс в то, что IoC-и  - это основа  современной безопасности, достигла своего апогея. Уже вполне толковые ребята со сцены всерьез (хотя, может, шутил, но я шутку не почувствовал) заявляют о том, что они у себя выкинули антивирус и заменили его на EDR с хешевым фидом, и это - революционный подход к безопасности. Удивительно?!
В целом, любому здравомыслящему человеку понятно, что даже файловая антивирусная сигнатура - куда более продвинутая технология детектированя, чем хеш, как минимум, потому, что одна сигнатрура может детектить одно и то же зло с разными хешами, а современный EPP еще имеет кучу других технологий, в том числе, и по поведению (кстати, единственный способ детекта malware less атак). Если рассмотреть Пирамиду Боли, то статические индикторы - низшие в иерархии. Ниже я раскрасил где о чем написано.

Да и EDR - не панацея сама по себе, но только в связке с EPP. А вообще, нужна целая совокупность технологий и сервисов, и только тогда, может быть, будет возможность эффектино обнаруживать и реагировать.

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

Для решения этой задачи можно немного поколхозить. Раз выше упоминался коллега с хешовыми фидами, продолжим эту же тему (хотя подход может быть растянут на любые другие индикторы). Нормальные EPP умеют создавать кастомизированные черные списки по хешам (ну уж EDR-ы - точно умеют, любой современный EPP и EDR тоже - вон, Гарнтер, их уже и различать перестал). В целом, можно этот Черный список формировать скриптами. Тогда компенсация проблем с Оперативностью и Релевантностью может выглядеть как-то так.

1. Я каким-то образом обнаружил вредоносных хеш, который пока не обнаруживается вендорским ЕРР.

2. Добавляю этот хеш в мой кастомизированный Черный спискок.

3. Сэмпл добавляю в папочку, которая постоянно сканируется моим вендорским EPP в применяемой у меня комплектации (я бы порекомендовал использовать полную комплектацию - с облаком, с поведенческими и эвристирческими движками и т.п.) - это будет моя "лаборатория постоянной проверки детекта"

4. Как только сэмпл стал обезвреживаться используемым у меня ЕРР, его можно удалить из Черного списка, чтобы список не был бесконечно большим, но содержал ровно то, что для меня релевантно, но пока не покрывается вендором ЕРР.

Не раз писал, что я фанат схемок, поэтому ниже картинка про эти 4 пункта. Черными буквами на синем фоне отражено описание ситуации в указанной точке, белыми буквами на синем фоне - мои действия.

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

Инструкция по применению

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

Любые инструменты появляются под потребность, т.е. сначала возникает какая-то проблема, затем появляется решение, затем - инструменты, где придуманное решение уже реализуется. Если решаемая проблема понятна, то достаточно обойтись исключительно инструкцией по применению инструмента. Например, проблематика, адресуемая лопатой - понятна, поэтому исключительно инструкции ( шутка, :) ) - достаточно.

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

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

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