PlastilinovayaVorona 7 дек 2021 в 23:37

От 1FA к Zero-Trust через рынок ИБ

19 мин

2.9K

Информационная безопасность*Математика*

Из песочницы

+22

Комментарии 8

Protos 8 дек 2021 в 01:54

Очень подробно описаны алгоритмы, которые известны уже много лет, а вот про алгоритмы или конкретные решения именно zero-trust не сказано ничего. Последний раздел звучит красиво, но так ли легок к реализации на самом деле? Что если злоумышленник получил полное владение ПК сотрудника, поможет ли zero-trust?

Почему сотрудник изображен именно в недоверенной сети, а если я включаю ПК который находится в доверенной сети, для него никакого zero-trust не будет, он сразу будет иметь полный доступ Или как в данном случае предполагается?

Почему по тексту используется термин субъект, но если идет объяснение, то становится понятнее, что речь идет о ПК пользователя. Zero-trust для доступа серверов к серверам плохо применим? Или точнее он совсем не применим так как рассмотрены алгоритмы аутентификации людей, а не программ при доступе к программам?

PlastilinovayaVorona 8 дек 2021 в 06:50

Доброе утро ;)

PlastilinovayaVorona 8 дек 2021 в 08:36

Доброе утро, спасибо за ваше внимание к статье ;)

[Прошу прощения - предыдущий комментарий отправился случайно, и я не успел его исправить]

Подробные описание алгоритмов, именно в таком формате, были включены в статью для того, чтобы читатель в случае первичного знакомства с предметной тематикой, без труда составил для себя представление о иных подходах к построению аутентификации, не загоняя себя в рамки Push и уже привычных SMS, которые, кстати, NIST примерно с Q1 2016 перестал рекомендовать для использования при аутентификации.

Zero-Trust это концепция в организации инфраструктуры безопасности, и построить её можно самыми разными способами - доказательством этого, служит тот факт, что есть довольно большое число вендоров, предлагающих свои решения в этой парадигме. Тут вопрос уже больше к архитекторам, потому что, например, вместо шлюза аутентификации можно использовать VPN, в рамках IDP выбирать факторы, по которым будет осуществляется проверка подлинности, а на контроллере доступа собирать свой набор политик.

ZT хорош как раз своей гибкостью, поэтому, отвечая на ваш вопрос:

"Почему сотрудник изображен именно в недоверенной сети, а если я включаю ПК который находится в доверенной сети, для него никакого zero-trust не будет, он сразу будет иметь полный доступ Или как в данном случае предполагается?"

Хотелось бы уточнить, что в рамках подхода, выбор фрагмента сети, который вы будете считать доверенным или публичным, зависит сугубо от вашего решения – вы можете, например, в рамках метода, полностью упразднить доверенную сеть (фактически ваш defined perimeter, разумеется, останется таким же, каким и был до этого) [получается что в данном случае мы строим ZT внутри привычного периметра, доверенной сети, которую мы доверенной считать перестали]. Тогда каждый пользователь будет проходить через все процедуры ZT, регулируемые вашими политиками, даже в том случае, если он находится внутри периметра организации.

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

Что если злоумышленник получил полное владение ПК сотрудника, поможет ли zero-trust?

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

itsoft 8 дек 2021 в 09:25

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

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

styugin 10 дек 2021 в 10:55

Мне остался непонятен индекс эффективности EFF (с ходу загуглить не удалось). Почему EFF растет с ростом значения вероятности проникновения и стоимости решения? Разве он не должен быть обратно зависим от этих величин? И почему по вашей же формуле у вас EFF смартфона больше чем EFF сканера сетчатки?

PlastilinovayaVorona 11 дек 2021 в 20:56

Михаил, добрый вечер, спасибо за это важное дополнение :)

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

Эта небольшая моделька, включающая в себя EFF , строилась лично мной для того, чтобы обобщить, в нулевом приближении, и представить наглядную, хоть сколько-нибудь ощутимую количественную интерпретацию происходящего, описывающую процессы совершения выбора в пользу тех или иных программных/аппаратных продуктов в рамках корпоративных систем. Поскольку подобные решения в бизнесе принимаются, преимущественно, двумя отделами организации: Закупки + ИБ, то целесообразно сопоставить каждому из игроков свою величину, которая, будучи включенной в индекс, описывала “пожелания” каждой из сторон - тогда, можно, в рамках упомянутых абстрактных допущений предположить:

1) Закупки решают задачу дискретной оптимизации $S_{implementation}$ , руководствуясь своим набором критериев

2) ИБ в рамках своих компетенций оценивает $P_{penetration}$

С $S_{implementation}$ , все ещё хоть как-то понятно, хотя бы потому, что её область значений допустимо задавать как подмножество множества натуральных чисел , и, можно, например, предположить, что она для каждого из решений будет вычисляться пропорционально объему осуществленных “внедрений”.

С $P_{penetration}$ все уже несколько сложнее, во-первых, нужно определиться руководствуясь каким из возможных подходов будет производиться её оценка:

1) Можно анализировать самую разную публичную статистику по атакам на организации размера/типа идентичных рассматриваемой – её объемы достаточно велики, и, в этом случае, придётся проявить осмотрительность при формировании выборки, содержащей в себе данные о успехах/неудачах киберпреступников, пытающихся преодолеть средства защиты организаций, обладающих сколько-нибудь схожей инфраструктурой. Одним из основных недостатков подобного подхода является довольно большая погрешность, обусловленная тем, что у многих компаний, в особенности у крупных, инфраструктура безопасности может быть крайне разнородной и аналогии будет произвести затруднительно, более того, скорее всего не будет учтён вклад успешно завершённых атак, которые, попросту, не были и не будут никогда обнаружены, из-за того, что злоумышленники перед тем как покинуть пределы киберпространства организации, тщательно избавили его от “следов” своей активности.

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

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

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

Если же абстрагироваться от всех этих проблем и допустить, что $P_{penetration}$ мы как-то уже оценили, то, возвращаясь к вашему вопросу:

Почему EFF растет с ростом значения вероятности проникновения и стоимости решения?

Остается, пожалуй, только сделать уточнение о том, что P должно возвращать для какого-то набора своих параметров значение, принадлежащее отрезку [0;1] тогда для предельных случаев, соответственно, будем иметь:

1) $P_{penetration} \approx 0$

(Вероятность того, что атака будет произведена по этому вектору ничтожно мала, а значит, для того, чтобы он был "закрыт" вообще не требуется "расставлять" средства защиты)

Тогда, при ограниченной $S_{impementation}$ , для индекса эффективности получим:

$EFF \sim 0$

(Эффективность принятия такого решения почти нулевая)

2) $P_{penetration} \approx 1$

(Вероятность атаки по этому вектору близка к единице - в организацию почти наверное будут пытаться по нему проникнуть}

$S_{imlementation}$ по-прежнему будем считать ограниченной, тогда для индекса получим:

$EFF\ \sim \frac{1}{S_{implementation}}$ или $EFF\ =\frac{Const}{S_{implementation}}$

(Иными словами - чем больше теперь будет стоимость внедрения, тем ниже будет наша итоговая эффективность)

В случае сравнения смартфона со сканером сетчатки у нас будут иметь место соотношения:

$P_{penetration_{smartphone\ }}>\ P_{penetration_{retinascanner}}$

(Вероятность атаки "по смартфону" "ближе к единице", чем вероятность атаки "по сканнеру сетчатки")

$S_{implementation_{retinascanner}}>\ S_{implementation_{smartphone}}$

Учитывая это в рамках:

$\begin{array}{l}P_{penetration\ }\cdot\ \left(S_{implementation}\right)^{-1}\end{array}\sim EFF$

И получим наш конечный результат : )

$EFF_{smartphone} > EFF_{retinascanner}$

smke 31 мар 2023 в 10:20

Zero Trust - это buzzword.

Любая попытка в уже существующей инфраструктуре проделать такие штуки, как правило, обречена на провал.

Голубая мечта безопасника - сегментация сети, на границе каждого сегмента стоит ngfw, на который приходит аутентифицированный трафик. Пускаем мы в эту сеть после того, как отработал posture на эндпоинте. Эндпоинт защищён по самые яйца, эталон - PAW.

Красиво звучит, только за всем этим в реальной жизни стоит примерно следующее:

Как правило, нужно очень серьёзно переработать архитектуру сети
Современные файрволы не умеют отличать какой процесс в каком контексте инициировал коннект. Максимум что будет - это таблица UserID, как у F5. Вроде бы есть у фортигадов концепция с агентами, которые в это умеют, но агент это просто ПО, со всеми вытекающими.
Стоимость всего этого добра даже просто на оборудование - космическая. Я уже не говорю про то, что нужны люди.
В основе хорошего Zero Trust лежит современный IdP. Практически во всем тырпрайзе есть AD, которое не заточено под эту концепцию. Вы не задумывались, почему все практические реализации этого нулевого доступа - облачные? С EvoSTS в Azure ты можешь идти смелой дорогой в zero trust, с AD уже не так все радужно.
В РФ ситуация осложняется тем, что у основных вендоров, кто в это умеет, нет своего ДЦ, а значит надо принять соответствующие риски.

В общем, тема интересная, дискуссионная, но искусственно раздутая, как по мне.

Работать надо, а не про zero trust мечтать (с)

mayorovp 31 мар 2023 в 13:43

Эм, а чего в AD не хватает?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий