Два инцидента за полгода: переходим на ежеквартальный аудит безопасности

После Shellshock у нас состоялся разговор с несколькими клиентами, который давно напрашивался. Не про bash, не про CGI - про то, как часто вообще имеет смысл проводить аудит безопасности инфраструктуры.

Классический ответ на этот вопрос - раз в год. Годовой аудит прописан в куче регламентов, его легко запланировать, легко обосновать бюджет. Выглядит разумно. Но 2014 год наглядно показал, что между двумя ежегодными аудитами может произойти очень много всего.

Что случилось за эти полгода

Апрель - Heartbleed (CVE-2014-0160). Уязвимость в OpenSSL, которая позволяет читать память сервера по 64 КБ за раз без аутентификации. Закрытые ключи, сессионные токены, пароли - всё, что лежало в памяти процесса openssl, потенциально доступно. Масштаб затронутых серверов - колоссальный, потому что OpenSSL стоит везде.

Сентябрь - Shellshock (CVE-2014-6271). Bash, который тоже стоит везде. Remote code execution через переменные окружения, эксплуатируется через CGI без аутентификации за несколько минут.

Два разных компонента базовой инфраструктуры, два раза за шесть месяцев. Причём оба раза - не «нашли теоретическую уязвимость в экзотическом конфиге», а «критическая, активно эксплуатируется, патч немедленно». Про реакцию на Shellshock мы писали отдельно, как и про аудит SSL после Heartbleed.

Почему годовой аудит не справляется

Проблема не в том, что аудит плохо делается. Проблема в том, что его результаты протухают быстрее, чем наступает следующий.

Годовой аудит фиксирует состояние на момент проведения. Если через три месяца выходит Heartbleed - аудит про это ничего не знает. Ещё через три - Shellshock. К моменту следующего планового аудита прошлогодние выводы про «SSL-конфигурация соответствует требованиям» уже давно устарели.

Это не претензия к аудиторам - за год меняется всё. Выходят новые версии ПО с новыми уязвимостями. Появляются новые серверы, которых в прошлогодней проверке не было. Меняются конфигурации - где-то включили новый виртуальный хост, где-то обновили PHP и он подтянул другие зависимости. Прошлогодний аудит и текущее состояние инфраструктуры - это два разных объекта.

Что предложили клиентам

Разговор был примерно такой: вот два инцидента за полгода, вот что мы делали каждый раз в пожарном режиме, вот что было бы, если бы мы смотрели на состояние инфраструктуры регулярно, а не по событию.

Предложили перейти на ежеквартальный аудит безопасности вместо годового. Четыре раза в год - это не паранойя, это просто другая частота. Конкретный состав каждого квартального прохода:

• SSL/TLS. Конфигурация, сертификаты, актуальность шифров. После Heartbleed мы прошлись по всем клиентам с ssllabs - это разовая работа. Квартальный прогон - это проверка, что ничего не съехало и новые серверы не пропущены.
• Версии ПО. Nginx, Apache, OpenSSL, PHP, MySQL/PostgreSQL, ядро Linux. Не «последняя версия в репозитории», а «нет известных CVE с CVSS 7+ для установленной версии».
• Поверхность атаки. Открытые порты, доступные снаружи сервисы, включённые модули Apache, которые никто не использует. Shellshock сделал больно через CGI, который был включён по дефолту и забыт.
• Учётные записи и доступы. Кто имеет доступ, какие ключи выпущены, есть ли истёкшие или лишние. Раз в квартал - нормальная гигиена.
• Конфигурация файрвола. Есть ли правила, которые открывают больше, чем нужно.

Это не глубокий penetration test - это систематическая проверка известных точек риска. Глубокий pentest - отдельная история, отдельный бюджет, отдельная периодичность. Но и без него квартальный проход даёт другое качество понимания текущего состояния.

Как отреагировали клиенты

По-разному. Часть сразу согласилась - Heartbleed и Shellshock уже убедили. Некоторые спросили про стоимость и попросили посчитать, что входит в квартальный объём. Пара клиентов сказали «подумаем» - что обычно означает «нет, но неудобно так сразу отвечать».

Один клиент задал хороший вопрос: «А если за квартал ничего критического не найдёте - это хорошо или плохо?» Хорошо, очевидно. Но даже «всё в порядке» - это результат, который стоит иметь задокументированным. Разница между «у нас не было инцидентов» и «мы проверяли, у нас не было инцидентов» - существенная, особенно когда приходит время объяснять руководству или регулятору.

Что изменили в процессе

Помимо самой периодичности, договорились о том, что каждый квартальный аудит заканчивается не просто устным разбором, а коротким письменным отчётом: что проверено, что найдено, что исправлено, что оставлено осознанно. Последний пункт важен - «мы знаем про эту настройку и приняли решение не менять» принципиально отличается от «мы не смотрели».

Шаблон отчёта сделали простым - несколько страниц, без воды. Клиент должен за 15 минут понять состояние своей инфраструктуры, не будучи инженером.

По итогам двух инцидентов за полгода это звучит как минимально разумная точка. Посмотрим, как пойдёт дальше.