Когда речь идет о безопасности, роль команды ИТ-операций (ITOps) трудно переоценить. Независимый аналитик Кристофер Тоцци приводит на портале ITPro Today ряд советов по предотвращению некоторых наиболее распространенных рисков.

Команды ITOps обычно не отвечают за создание безопасного ПО (этим занимаются разработчики) или оценку общего уровня безопасности организации (этим занимаются эксперты по безопасности). Однако ITOps-инженеры часто находятся на передовой линии безопасности. Именно им приходится развертывать приложения, отслеживать риски и реагировать на них по мере их возникновения.

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

1. Отсутствие сквозного мониторинга безопасности

Большинство команд ITOps признают важность мониторинга безопасности. Однако распространенной ошибкой в этой области является мониторинг только определенных уровней стека.

Например, команда может отслеживать приложения и сеть на предмет аномалий, которые могут выявить риски безопасности или атаки. Но если они также не следят за хост-серверами, оркестраторами приложений, API-запросами и ресурсами хранения данных, им не будет хватать целостной видимости, необходимой для выявления всех типов рисков безопасности.

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

2. Игнорирование рисков безопасности в SaaS-приложениях

SaaS-приложения удобны тем, что ITOps-команды могут использовать их без необходимости развертывания или управления ими.

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

Уязвимости в сторонних приложениях, например, проблемы с безопасностью в SaaS-программах электронной почты или календаря, также могут привести к серьезным проблемам в вашем бизнесе, если вы не знаете о них и не предпримете шаги по их устранению до того, как хакеры доберутся до ваших пользователей.

Вот почему важно обеспечить, чтобы мониторинг и аудит безопасности распространялись на платформы SaaS и другие сторонние ресурсы, а не только на приложения и инфраструктуру, которые вы развертываете и управляете непосредственно.

3. Отсутствие планирования восстановления

Резервное копирование данных является одним из основных шагов по обеспечению защиты от программ-вымогателей.

Однако резервные копии данных не очень полезны, если у вас нет плана быстрого восстановления данных после взлома. Это основная ошибка в области кибербезопасности — считать, что вы защищены от атак только потому, что у вас есть резервные копии.

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

4. Недружественные требования к паролям

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

Большинство традиционных рекомендаций по паролям остаются в силе. Однако в последние годы было признано, что слишком строгие требования к паролям — это ошибка безопасности. Если вы неоправданно усложните пользователям работу с паролями, они начнут делать такие вещи, как написание паролей на стикерах, которые они наклеивают на монитор, что является прямо противоположным тому, чего вы добиваетесь.

Возможно вы не в курсе, но NIST пересмотрел свое руководство по паролям в 2020 г., чтобы поощрять удобные для пользователей политики паролей. Если ваша команда ITOps давно не пересматривала свои требования к паролям, сейчас самое время это сделать.

5. Чрезмерная уверенность в многофакторной аутентификации

Слишком большое доверие к многофакторной аутентификации (MFA) — еще одна распространенная ошибка безопасности, которую могут совершить команды ITOps.

Безусловно, требование MFA — это лучшая практика, которая может значительно снизить риск атак. Однако ошибка, которую могут совершить ITOps-инженеры, заключается в предположении, что системы практически неуязвимы для атак только потому, что защищены MFA.

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

Ключ к предотвращению ошибок в области безопасности: быть проактивным

От игнорирования рисков безопасности SaaS до слишком большого доверия к строгим паролям и многофакторной аутентификации, игнорирования критических требований мониторинга безопасности и т. д. — существует множество ошибок в области безопасности, которые могут совершить благонамеренные команды ITOps при управлении ИТ-системами. К счастью, при наличии проактивной стратегии безопасности этих рисков легко избежать или уменьшить.