Новата рамка на заместник CISO на Microsoft поставя фокус върху „прекалено мощните“ токени и пропуските в инженерните среди
Microsoft публикува нов набор от препоръчителни практики за CISO екипи и инженерингови среди, които променят традиционния подход към оценката на риска. Вместо стандартен чеклист модел, рамката поставя акцент върху това какво реално иска един атакуващ, какъв достъп може да получи и колко мащабни могат да бъдат последствията от компрометиране на един-единствен токен.
Автор на модела е Рико Мариани, който през първите си шест месеца като заместник CISO за Microsoft Security Products, Research Infrastructure и Engineering Systems разработва осемстепенна методология за преглед на риска в инженерните системи.
Рамката е публикувана в официалния блог на Microsoft и се базира както на инженерния опит на Мариани, така и на практиките на по-широката група заместник CISO ръководители в компанията.
Microsoft обработва 100 трилиона сигнала дневно
Според данните на Microsoft, между април 2024 г. и април 2025 г. компанията е предотвратила измами за приблизително 4 милиарда долара и ежедневно анализира около 100 трилиона сигнала за сигурност – с 40% повече спрямо 2023 г.
Този мащаб на телеметрията позволява на компанията да наблюдава повтарящи се модели при пробиви, злоупотреби с идентичности и компрометирани инфраструктури. Именно от тези наблюдения произлиза и новият подход към CISO оценките.
Осемте стъпки – от активите до „нещата, които обикновено се пропускат“
Моделът на Microsoft започва с два фундаментални въпроса:
- Какви активи реално биха били интересни за атакуващ?
- Кои приложения имат достъп до тях?
След това следват четирите основни слоя за контрол:
- удостоверяване (authentication);
- оторизация (authorization);
- мрежова изолация;
- механизми за откриване на заплахи.
Финалните две категории са:
- одит и проследимост;
- „неща, които не трябва да бъдат пропускани“.
Ключовата идея е, че това не са отделни чеклист отметки, а взаимосвързан процес. Всеки следващ слой зависи от слабостите или ограниченията на предходния.
Най-опасният проблем: „fungible“ токени с прекомерни права
Най-сериозният акцент в рамката е поставен върху т.нар. fungible tokens – токени, които предоставят прекалено широки и универсални права.
Според Мариани, много организации проверяват дали токените се издават от надеждна система като Microsoft Entra и приемат, че това е достатъчно. Реалният риск обаче често идва не от издателя, а от самия обхват на правата.
Токен, който работи „за всеки, отвсякъде и за всичко“, се превръща в критична точка на компрометиране.
Ако подобен токен попадне в:
- кеш;
- лог файл;
- телеметричен запис;
- debugging среда;
- support система,
той може да предостави достъп до огромен обем клиентски данни и вътрешни ресурси.
Microsoft препоръчва токените да бъдат максимално ограничени:
- за конкретен клиент;
- за конкретен потребител;
- за конкретен набор от данни;
- с кратък жизнен цикъл;
- с минимален необходим обхват.
Authorization логиката често е по-слабата точка
Втората критична тема е начинът, по който се реализира оторизацията в приложенията.
Мариани предупреждава, че ръчно написаните проверки, разпръснати из API handler-и и отделни функции, са един от най-честите източници на пробиви.
Вместо това Microsoft препоръчва:
- декларативни authorization модели;
- унифицирани библиотеки;
- централизирана проверка на claims;
- автоматизирано валидиране на достъпа.
Тезата е проста – колкото по-разнородна е authorization логиката, толкова повече грешки се натрупват.
Това е и причината мрежовата изолация да бъде следващата стъпка в модела – дори компрометиран токен трябва да срещне допълнителни бариери пред придвижването в инфраструктурата.
Backup системите остават една от най-пренебрегваните цели
Особено внимание рамката отделя на системите, които организациите традиционно пропускат при оценки на риска.
Сред тях Microsoft изрично посочва:
- backup инфраструктури;
- support системи;
- development среди;
- test среди.
Според компанията именно backup платформите често имат по-слаба защита от основните production системи.
Атакуващ, който не може да достигне основните данни, често се насочва към резервните копия.
Microsoft препоръчва backup инфраструктурата да преминава през същите проверки за:
- удостоверяване;
- authorization;
- auditing;
- мрежова сегментация;
- откриване на аномалии.
Development средите трябва да се третират като високорискови production системи
Документът обръща специално внимание и на development/testing инфраструктурите.
Причината е, че:
- development кодът съдържа повече грешки;
- authorization механизмите често са непълни;
- debugging функциите остават активни;
- тестовите среди нерядко имат връзка към production ресурси.
Microsoft препоръчва тези среди да бъдат изолирани на мрежово ниво и да бъдат наблюдавани със същото внимание като production системите.
Detection и auditing не са едно и също
Един от по-интересните аспекти на рамката е ясното разграничение между detection и auditing.
Според Microsoft:
- detection системите трябва да откриват активна атака в реално време;
- auditing механизмите трябва да позволяват реконструкция на действията след пробив.
Организациите често смесват двете функции, което води или до бърза, но непълна реакция, или до детайлен, но закъснял анализ.
Microsoft променя фокуса – от compliance към реална blast radius оценка
Новият подход показва постепенно изместване на фокуса от формалните compliance checklist модели към реална оценка на възможния „blast radius“ при пробив.
Вместо въпроса:
„Използвате ли SSO и MFA?“
Microsoft поставя далеч по-практичен такъв:
„Какъв е най-големият достъп, който един компрометиран токен може да предостави?“
Именно този подход вероятно ще се превърне в една от водещите тенденции при модерните enterprise security архитектури, особено в среди с мащабни cloud, DevOps и multi-tenant инфраструктури.
