ГОСТ Р ИСО/МЭК 17799-2005: первый аудит по чеклисту за три дня

В начале мая позвонил клиент - средняя производственная компания, около ста двадцати человек, смешанная Windows/Linux-среда, один выделенный сисадмин. Запрос был неожиданно конкретным: «Нам нужен формальный аудит безопасности по ГОСТ. Партнёры из Европы просят документ, что у нас всё по стандарту».

ГОСТ Р ИСО/МЭК 17799-2005 - это российская адаптация ISO/IEC 17799:2005, принята и введена в действие в 2006 году. Документ описывает практику управления информационной безопасностью: 12 доменов, 133 контроля - от политики безопасности до управления непрерывностью бизнеса. Мы читали оригинальный ISO 17799 и несколько английских методичек по аудиту по нему, но вживую работать с этим чеклистом в таком режиме нам ещё не приходилось.

Сроки - три дня. Попробуем.

Как делили работу

Двенадцать доменов стандарта неравновесны по трудоёмкости и по тому, насколько они вообще проверяемы за короткий срок. Часть - документарная: политика безопасности, управление активами, соответствие требованиям. Здесь работа простая: запросить документ, убедиться, что он существует, прочитать. Другая часть - техническая: управление доступом, защита сети, мониторинг. Здесь нужно смотреть конфигурации.

Мы разбили по типу:

• Документарные домены - опрашивали ответственных, запрашивали регламенты, должностные инструкции, договоры с персоналом. Где документа нет - несоответствие.
• Организационные домены - смотрели, есть ли назначенные роли, проводятся ли инструктажи, что происходит при увольнении сотрудника.
• Технические домены - прямые проверки: конфигурации firewall, права в Active Directory, настройки антивируса, наличие резервных копий и результаты их тестирования.

Клиент выделил нам сисадмина на второй день - первый день мы работали в основном с руководством и документами.

Что нашли

Сорок несоответствий за три дня - это не финальная цифра, а то, что удалось зафиксировать уверенно. Часть вещей мы пометили «требует более глубокой проверки» - три дня физически не позволяют прощупать каждый контрол.

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

Несколько примеров, которые показались наиболее характерными:

• Управление доступом (домен 11) оказалось самым проблемным. Несколько учётных записей уволенных сотрудников в AD были активны. Одна - человека, ушедшего восемь месяцев назад - с почтой, к которой теоретически можно было зайти. Процедуры отзыва доступа при увольнении нет.
• Резервное копирование формально существует - скрипт на сервере делает бэкапы по расписанию. Но за последние полгода никто не проверял, можно ли из этих бэкапов что-то восстановить. Тест провели прямо при нас - один из трёх архивов не распаковался.
• Сетевой периметр закрыт firewall, но правила не пересматривались полтора года. Несколько разрешений, открытых под конкретные задачи, оставались активными после завершения этих задач. В том числе - RDP наружу на один из серверов.
• Политика паролей в AD есть, но минимальная длина - шесть символов, сложность не требуется. В стандарте это несоответствие очевидное.
• Физическая безопасность (домен 9) - серверная комната запирается, но ключ висит в незапертом шкафу рядом с дверью. В журнале доступа записи за последние три месяца только от сисадмина, хотя по факту туда заходил и электрик для обслуживания кондиционера.

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

О формате итогового документа

Европейские партнёры ожидали что-то похожее на отчёт по ISO 17799 gap analysis: перечень доменов, статус каждого контрола (соответствует / не соответствует / не применимо), приоритизация несоответствий, рекомендации по устранению. Мы сделали именно это.

Объём получился внушительным - двадцать страниц плюс приложение с деталями по каждому несоответствию. Клиент сказал, что ожидал что-то менее подробное, но был рад именно такому: «Теперь понятно, что делать дальше».

Что делать дальше - отдельный вопрос. Сорок несоответствий нельзя закрыть разом. Мы выделили первый приоритет: учётные записи уволенных, открытый RDP, тестирование бэкапов. Это работа на несколько дней без серьёзных вложений. Дальше - политика паролей, формализация процедур, соглашения с подрядчиками. Это уже недели.

Что вынесли для себя

Три дня - это реальный минимум для первичного аудита безопасности по 17799 в компании такого размера. Меньше - только поверхностный срез без возможности проверить технические конфигурации. Больше - нужно, если хочется покрыть все 133 контрола с доказательной базой, а не выборкой.

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

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