Хмм, вы канешн меня извините, но статья, которую вы привели в качестве референса, датируется 2005 годом и описывает метод MiTM, где есть явное условие, что PKINIT должен работать в public-key encryption mode. Это уже давно пофиксили + на данный момент имплеметация PKINIT от MS в основном использует Diffie-Hellman mode, ибо perfect forward secrecy и всё такое
PKInit Freshness Extension же был разработан в 2017 году и там упор как раз на митигацию replay атак в Diffie-Hellman mode
Я всё еще не совсем понимаю, каким образом повышая FFL до 2016 левела и, используя PKInit Freshness Extension, мы, в итоге, делаем AD менее безопасной по сравнению с 2012 FFL
Так что за особенности такие, которыми можно злоупетребить, включив PKInit Freshness Extension? Можно какие-то сслыки на PoC, тулы и тд?
Домен заказчика работал на версии 2012 года. Это ограничивало возможности PKINIT, например, мы не могли получить TGT билет Kerberos с помощью сертификата
Либо я чего-то не понял, либо это звучит как бред
Единственное различие между 2012 FFL и 2016 в контексте PKINIT это поддержка PKInit Freshness Extension
Любая попытка в уже существующей инфраструктуре проделать такие штуки, как правило, обречена на провал.
Голубая мечта безопасника - сегментация сети, на границе каждого сегмента стоит ngfw, на который приходит аутентифицированный трафик. Пускаем мы в эту сеть после того, как отработал posture на эндпоинте. Эндпоинт защищён по самые яйца, эталон - PAW.
Красиво звучит, только за всем этим в реальной жизни стоит примерно следующее:
Как правило, нужно очень серьёзно переработать архитектуру сети
Современные файрволы не умеют отличать какой процесс в каком контексте инициировал коннект. Максимум что будет - это таблица UserID, как у F5. Вроде бы есть у фортигадов концепция с агентами, которые в это умеют, но агент это просто ПО, со всеми вытекающими.
Стоимость всего этого добра даже просто на оборудование - космическая. Я уже не говорю про то, что нужны люди.
В основе хорошего Zero Trust лежит современный IdP. Практически во всем тырпрайзе есть AD, которое не заточено под эту концепцию. Вы не задумывались, почему все практические реализации этого нулевого доступа - облачные? С EvoSTS в Azure ты можешь идти смелой дорогой в zero trust, с AD уже не так все радужно.
В РФ ситуация осложняется тем, что у основных вендоров, кто в это умеет, нет своего ДЦ, а значит надо принять соответствующие риски.
В общем, тема интересная, дискуссионная, но искусственно раздутая, как по мне.
У вас ссылка на authN Policies, это немного про другое. Точнее, совсем про другое. Это про то, что к определённым политикой сервисам контроллер выдаёт tgs определённому пулу security principals.
Наверное, вы имели ввиду вот это про словари и пароли.
Расскажи это phishing resistant MFA
Всё зависит от конкретных реализаций в конкретных продуктах
Блин, я понимаю, праздник, все дела, но шо ж так жирно то накидывать на вентилятор?
Хмм, вы канешн меня извините, но статья, которую вы привели в качестве референса, датируется 2005 годом и описывает метод MiTM, где есть явное условие, что PKINIT должен работать в public-key encryption mode. Это уже давно пофиксили + на данный момент имплеметация PKINIT от MS в основном использует Diffie-Hellman mode, ибо perfect forward secrecy и всё такое
PKInit Freshness Extension же был разработан в 2017 году и там упор как раз на митигацию replay атак в Diffie-Hellman mode
Я всё еще не совсем понимаю, каким образом повышая FFL до 2016 левела и, используя PKInit Freshness Extension, мы, в итоге, делаем AD менее безопасной по сравнению с 2012 FFL
Так что за особенности такие, которыми можно злоупетребить, включив PKInit Freshness Extension? Можно какие-то сслыки на PoC, тулы и тд?
Либо я чего-то не понял, либо это звучит как бред
Единственное различие между 2012 FFL и 2016 в контексте PKINIT это поддержка PKInit Freshness Extension
Объясните, что имели ввиду?
Zero Trust - это buzzword.
Любая попытка в уже существующей инфраструктуре проделать такие штуки, как правило, обречена на провал.
Голубая мечта безопасника - сегментация сети, на границе каждого сегмента стоит ngfw, на который приходит аутентифицированный трафик. Пускаем мы в эту сеть после того, как отработал posture на эндпоинте. Эндпоинт защищён по самые яйца, эталон - PAW.
Красиво звучит, только за всем этим в реальной жизни стоит примерно следующее:
Как правило, нужно очень серьёзно переработать архитектуру сети
Современные файрволы не умеют отличать какой процесс в каком контексте инициировал коннект. Максимум что будет - это таблица UserID, как у F5. Вроде бы есть у фортигадов концепция с агентами, которые в это умеют, но агент это просто ПО, со всеми вытекающими.
Стоимость всего этого добра даже просто на оборудование - космическая. Я уже не говорю про то, что нужны люди.
В основе хорошего Zero Trust лежит современный IdP. Практически во всем тырпрайзе есть AD, которое не заточено под эту концепцию. Вы не задумывались, почему все практические реализации этого нулевого доступа - облачные? С EvoSTS в Azure ты можешь идти смелой дорогой в zero trust, с AD уже не так все радужно.
В РФ ситуация осложняется тем, что у основных вендоров, кто в это умеет, нет своего ДЦ, а значит надо принять соответствующие риски.
В общем, тема интересная, дискуссионная, но искусственно раздутая, как по мне.
Работать надо, а не про zero trust мечтать (с)
Например, подобную систему использует Microsoft.
У вас ссылка на authN Policies, это немного про другое. Точнее, совсем про другое. Это про то, что к определённым политикой сервисам контроллер выдаёт tgs определённому пулу security principals.
Наверное, вы имели ввиду вот это про словари и пароли.