Постоянные читатели моего канала, которые со мной с самого начала, наверняка уже заметили что я достаточно негативно отношусь к таким вещам как предопределенные правила, сигнатуры, строгие чеклисты в виду их возникновения только лишь на знаниях о ТЕКУЩИХ возможностях атакующего. Все эти вещи ассоциируются у меня с предопределенностью, линейностью, некоторой неоспоримой, постоянной последовательностью. Но нет ничего более постоянного, чем временное. Особенно того что касается Agile разработки, развития микросервисов и подходов атакующих ;)
На эту мысль меня натолкнула еще несколько лет назад замечательная статья "The Dangers Of Linear Thinking and Why Security Analysts Should Defend in Graphs".
В статье в качестве примера приводится Incident Response активность, но это применимо и для построения безопасности в целом на мой взгляд это подходит. При построении системы безопасности также появляется подобный граф только разветвления там: А что мы защищаем? А что самое критичное? А какие модели нарушителей для нас актуальны в первую очередь? А как и где мы хотим обнаружить атакующего? А какой attack surface нужно закрыть в первую очередь? и т.д.
В виде списка это выглядит так: Для нашей инфраструктуры существуют такие требования, проблемы - начнем закрывать их по темам.
На пример, многие из тех же проверок CIS benchmark актуальны в основном для внутреннего атакующего, который уже проник на pod/контейнер. Хотя внешний атакующий еще должен стать этим внутренним атакующим. Поэтому слепое следование по списку, чеклистам, бенчмаркам, методикам может оставить более критичные вопросы без внимания.
Не думайте прямолинейно, а думайте в графах в соответствии с вашими приложениями, сервисами, инфраструктурой и бизнесом.
На эту мысль меня натолкнула еще несколько лет назад замечательная статья "The Dangers Of Linear Thinking and Why Security Analysts Should Defend in Graphs".
В статье в качестве примера приводится Incident Response активность, но это применимо и для построения безопасности в целом на мой взгляд это подходит. При построении системы безопасности также появляется подобный граф только разветвления там: А что мы защищаем? А что самое критичное? А какие модели нарушителей для нас актуальны в первую очередь? А как и где мы хотим обнаружить атакующего? А какой attack surface нужно закрыть в первую очередь? и т.д.
В виде списка это выглядит так: Для нашей инфраструктуры существуют такие требования, проблемы - начнем закрывать их по темам.
На пример, многие из тех же проверок CIS benchmark актуальны в основном для внутреннего атакующего, который уже проник на pod/контейнер. Хотя внешний атакующий еще должен стать этим внутренним атакующим. Поэтому слепое следование по списку, чеклистам, бенчмаркам, методикам может оставить более критичные вопросы без внимания.
Не думайте прямолинейно, а думайте в графах в соответствии с вашими приложениями, сервисами, инфраструктурой и бизнесом.