Вместо того чтобы постоянно устранять уязвимости в системе безопасности, организациям следует проактивно создавать надежные основы, которые позволят бизнесу двигаться быстрее, снижая риски, пишет на портале Dark Reading Энди Эллис, партнер YL Ventures, используя метафору дорожного ремонта.

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

Поиск «выбоин» в системе безопасности

Команды безопасности находятся в бесконечном стремлении документировать, инвентаризировать и определять приоритеты каждой проблемы, которая остается нерешенной из-за бешеного темпа. Инженерные команды имеют так мало возможностей для устранения проблем, что выбор лучшего решения становится самой важной задачей для команды безопасности. И индустрия отреагировала на это: инструменты управления состоянием безопасности (Security Posture Management) наводнили рынок, обещая помочь CISO выявить то, что имеет значение, — от неправильной конфигурации облачных систем безопасности до уязвимостей в цепочке поставок ПО и SaaS.

Поиск «выбоин» в системе безопасности был отличной стратегией, когда у команд безопасности было время. Действительно, раньше у них хватало времени, чтобы вклиниться в процесс разработки ПО. Помните водопадную модель? Команды разработчиков, используя бюрократически медленный процесс проектирования, разработки и развертывания, тратили, казалось, целую вечность на то, чтобы отправить ПО в продакшн. Команды безопасности могли выявлять проблемы и устранять их еще до того, как системы были готовы к развертыванию. Такой подход быстрого реагирования — быстрее, чем действуют команды разработчиков, — прочно вошел в философию безопасности, даже когда команды разработчиков внедрили гибкие методы непрерывного развертывания, которые ускорили их настолько, что они стали опережать команды безопасности.

Предотвращение «выбоин»

В современных подходах к безопасности заложена идея поиска проблем. Подобно местному органу власти с горячей линией по ремонту дорог, который направляет (иногда) бригаду для заделывания выбоин, мы организованы таким образом, чтобы реагировать на сбои. Муниципалитеты, придерживающиеся стратегии «просто замостить дороги», тратят меньше времени на выбоины. Что, если бы мы использовали аналогичную стратегию и сосредоточились на том, чтобы предотвращать проблемы заранее? Если бы мы могли «мостить дороги», по которым хотят «ездить» наши инженеры, мы могли бы избавиться от необходимости выявлять или приоритизировать большинство «выбоин», оставив командам безопасности меньший набор проблем, с которыми они должны справляться.

Шаг первый: минимизация объема

Что если вместо того чтобы минимизировать поверхность атаки, вы могли бы уменьшить объем того, что вам нужно защищать? Сегодня большинство ПО поставляется с большим количеством программных компонентов, так как в проектах необходимо учитывать всевозможные способы использования ПО. Но для подавляющего большинства сценариев использования лучше использовать чистую, минималистичную сборку, отправляя на серверы или в контейнеры только необходимое ПО. Зачем пытаться защитить случайные части ПО, которые вам никогда не понадобятся? А если речь идет о необходимом ПО, то из-за задержки в деревьях зависимостей подкомпоненты часто могут быть сильно устаревшими (представьте: пакет ПО, собранный в пятницу, будет включать все подпакеты четверга, которые будут включать подпакеты среды, которые будут включать подпакеты вторника, и т. д.). Сборка контейнеров с актуальными пакетами уменьшает временную задержку, из-за которой возникает бóльшая часть объема риска, поскольку ваши системы остаются актуальными.

Шаг второй: настройка нативных инструментов

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

Шаг третий: заглушите шум паролей в среде ваших машин

В то время как пользователи все больше переходят на беспарольную аутентификацию, не связанные с людьми идентификаторы (non-human identities, NHI), такие как ключи API, межсерверные пароли, и другие учетные данные, за которыми не стоит человек, остаются позади. Согласно отчету Astrix «The State of Non-Human Identity Security», на долю NHI приходится около 95% аутентификаторов в корпоративной среде, однако современное состояние управления NHI обычно сводится к усовершенствованной форме «шифрования в состоянии покоя». Мы должны сосредоточиться на предоставлении для NHI эквивалента современных менеджеров паролей, обеспечивающих доступ к идентификационной информации только в момент ее использования. Для этого необходимо найти секреты не только в цепочке поставок ПО, но и во время выполнения приложений, определить, где они используются неправильно (часто потому, что они появляются в нескольких местах), а затем предоставить инструменты управления, чтобы исключить идентификационные данные из жизненного цикла разработки ПО и предоставить приложениям доступ к NHI точно в срок.

«Мостить дороги» не просто возможно. Это правильная идея, потому что мы можем позволить нашим предприятиям двигаться быстрее и безопаснее, минимизируя отложенные риски и максимизируя производительность разработчиков. Мы не можем замостить все дороги (пока), но мы можем начать уже сейчас и сосредоточиться на тех дорогах, которые ускорят развитие бизнеса.