ISO 27001: gap-анализ по 133 контролям - 41% не выполнен, и это ещё оптимистично

На прошлой неделе к нам пришёл клиент с запросом, которого раньше не было: «Нас просят пройти ISO 27001. Что это и с чего начать?» Производственная компания с несколькими сотнями человек, собственная ИТ-служба из трёх человек, инфраструктура без особых экзотик. Западный партнёр выдвинул сертификацию как условие для подписания долгосрочного контракта.

ISO/IEC 27001:2005 - международный стандарт управления информационной безопасностью. Сертификацию по нему в России уже прошли несколько компаний в этом году, в основном крупные банки и телеком. Для среднего бизнеса это пока непривычная история - и понятно, почему: стандарт объёмный, Annex A содержит 133 контроля, распределённых по 11 доменам, и без внятной карты приоритетов работа с ним превращается в хаос.

С чего начали

Первый шаг - не читать стандарт с первой страницы до последней, а провести gap-анализ: понять, что уже есть, чего нет совсем, что есть частично. Мы взяли Annex A как чек-лист, прошлись по каждому из 133 контролей и проставили статус: выполнен, частично выполнен, отсутствует. Работали два дня - интервью с ИТ-службой, просмотр документации, беглый технический осмотр.

Итог: полностью выполнен примерно 41% контролей. Остальные - либо частичные, либо отсутствуют вовсе. Честно говоря, это не катастрофа - примерно такой результат ожидаешь от компании, которая строила ИТ-инфраструктуру органически, без явной привязки к какому-либо фреймворку безопасности.

Три главных пробела

По итогам анализа выявились три домена, которые тянут сертификацию вниз сильнее всего.

Управление активами (домен A.7). В компании нет актуального реестра информационных активов. Есть таблица инвентаря оборудования, есть лицензионный учёт - но нет документа, который связывает активы с их ценностью для бизнеса, ответственными лицами и требованиями к защите. ISO 27001 требует именно этого: без инвентаря активов непонятно, что вообще защищать. Несколько контролей этого домена отсутствуют полностью.

Управление инцидентами (домен A.13). Инциденты безопасности в компании происходят - как везде. Но процесса их регистрации, классификации и разбора нет. Если что-то случается, ИТ-служба чинит и идёт дальше. Никакого журнала, никакой эскалации, никакого анализа повторяемости. Для ISO 27001 это критичный пробел: стандарт требует не только реагировать, но и учиться на инцидентах и улучшать контроли по результатам.

Непрерывность бизнеса (домен A.14). Вот тут интереснее всего. Формально у клиента есть бэкапы и даже DR-план на бумаге - мы с похожей темой работали недавно у другого клиента. Но ISO 27001 смотрит шире: нужны не просто технические процедуры восстановления, а Business Continuity Plan, охватывающий бизнес-процессы, роли и коммуникации при инциденте. Технической части что-то есть, организационной - нет совсем. Стандарт принимает оба компонента в комплекте.

Что с остальным

Картина по другим доменам неоднородная. Физическая безопасность (A.9) - вполне прилично: серверная с замком, СКУД на входе, кондиционирование. Контроль доступа (A.11) - частично: Active Directory настроен, парольная политика есть, но принцип минимальных привилегий соблюдается не везде, а управление учётными записями уволенных сотрудников регламентировано слабо. Управление коммуникациями и операциями (A.10) - разброс: антивирус и патч-менеджмент есть, документированных операционных процедур для критичных задач почти нет.

Документация в целом - системная слабость. Многие технические контроли реализованы, но нигде не зафиксированы. С точки зрения аудитора ISO 27001 «не задокументировано» равно «не существует».

Roadmap на 18 месяцев

Составили план по фазам. Логика: сначала фундамент, потом надстройка.

• Месяцы 1-3. Реестр активов, политика классификации информации, базовая документация операционных процедур. Это то, без чего остальные контроли теряют опору.
• Месяцы 4-6. Процесс управления инцидентами: форма регистрации, процедура эскалации, ежеквартальный разбор. Параллельно - аудит управления доступом, закрытие очевидных дыр.
• Месяцы 7-10. Business Continuity Plan. Тут нужно вовлекать бизнес-стороны, а не только ИТ: кто принимает решения при инциденте, как коммуницируют с клиентами, какие процессы критичны. Это самая медленная часть - не из-за технической сложности, а из-за организационной.
• Месяцы 11-14. Внутренний аудит СУИБ, проверка выполнения контролей, доработка по результатам. Это репетиция перед внешним аудитором.
• Месяцы 15-18. Выбор органа по сертификации, предварительный аудит, устранение замечаний, основной аудит.

18 месяцев - не минималистичный срок, но реалистичный для компании, которая параллельно ведёт основной бизнес. Видели оценки «6 месяцев до сертификации» - это либо про компанию с уже зрелой ИБ, либо про документы, которые пишутся ради документов, а не ради реального контроля.

Несколько наблюдений

Работа с ISO 27001 после опыта с PCI DSS интересная: у PCI DSS жёсткие технические требования с конкретными параметрами, у ISO 27001 больше организационного и процессного. PCI DSS спрашивает «что у тебя настроено», ISO 27001 - «как ты управляешь безопасностью». Это разные вещи, и компании, которые привыкли мыслить через технические контроли, иногда удивляются, что написать процедуру управления инцидентами сложнее, чем настроить firewall.

Ещё наблюдение: Scope - один из ключевых решений в ISO 27001. Стандарт сертифицирует не компанию целиком, а СУИБ в определённых границах. Если грамотно определить scope, можно сертифицировать конкретное подразделение или сервис, а не всю организацию. Для первой сертификации это разумно.

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