Сертификация ISO27001
Похожая ситуация в ИТ. Любая компания может сказать: «мы защищаем свои системы и следим за безопасностью передачи данных. Но так ли это? И насколько хорошо защищают? Cертификация ISO 27001 отвечает на эти вопросы за вас, и позволяет сэкономить время на доказательствах. Под катом пример подготовки к сертификации ISO 27001 одной маленькой, европейской ИТ компании.
Предыстория
ISO 27001 — это международный стандарт, в котором собраны требования для создания и развития системы менеджмента информационной безопасности. Сертификация ISO 27001 особенно актуальна для крупных компаний, но в последнее время его стали требовать от маленьких компаний на этапе обсуждения контракта.
Раньше было так: Заказчик предоставляет альтернативу: либо у подрядчика есть сертификат ISO 27001, либо если компания не прошла сертификацию, можно продемонстрировать в соответствии с официальными договорными обязательствами, что у компании есть «план безопасности».
Сегодня альтернатива становится сложной, все больше и больше компаний выбирая между двумя разными подрядчиками, остановятся на тех, у кого уже есть ISO сертификат.
Компания, в которой проходила подготовка к сертификации, продает услуги по информационной безопасности, поэтому здесь вопрос получения сертификата стал по сути вопросом сохранения своего места на рынке:
- возможность сохранить за компанией будущие контракты и упростить подачу на новые тендеры;
Скорее надо спросить почему компания раньше не озаботилась этой сертификацией. Ко всему прочему кризис 2020 года ускорил происходящие процессы и стал стал самым актуальным годом, чтобы начать сертификацию ISO27001:
- Европа погрузилась в самоизоляцию — основное место работы сотрудника стал его дом, а не офис. В этой связи необходимо было заново оценить риски в ИТ процессах. Например стало гораздо менее важно обеспечивать надежное шифрование wi-fi в офисе — им попросту никто не пользовался целый год.
- Главные инструменты работы и места хранения данных — сместились в облачное пространство. По сути главный офис «испарился» в облако, локация компании потеряла смысл, фокус лег на суть сервисов которые компания использует и продает.
Коротко о стандарте
ISO 27001 состоит из двух частей — Body (основная часть стандарта, своего рода стратегия) и Annex A (114 потенциально применимых контролей).
Body of the Standard:
- p.4 Context of the organization
- p.5 Leadership
- p.6 Planning
- p.7 Support
- p.8 Operation
- p.9 Performance evaluation
- p.10 Improvement
Annex A
- Information security policies (2 controls)
- Organization of Information security (7 controls)
- Human resource security (6 controls)
- Asset management (10 controls)
- Access control (14 controls)
- Cryptography (2 controls)
- Physical and environmental security (15 controls)
- Operations security (14 controls)
- System acquisition, development, and maintenance (13 controls)
- Supplier relationships (5 controls)
- Information security incident management (7 controls)
- Information security aspects of business continuity management (4 controls)
- Compliance (8 controls)
Нужно соответствовать всем частями основной части стандарта, и выборочно контролям, но выбор естественно необходимо обосновать. Если какие-то контроли считаются не применимыми, нужно предоставить либо объяснение, либо альтернативу.
О компании, которая получает сертификацию:
ИТ консалтинг, всего 25 человек сотрудников, из которых двое это топ менеджмент и двое это администрация. Основные данные хранятся на внешних облачных серверах. В процессе 2020 года администрация (бухгалтерия, учет времени сотрудников) также переехали с внутренних серверов на внешние сервисы.
Из поставщиков — внешние услуги техподдержки, а также все «физические» поставщики, охрана офиса, уничтожение старого оборудования, документов.
В команду проекта по подготовке к сертификации вошли старший консультант, он же внутренний сотрудник, который понятия не имел о том, как устроены информационные системы компании и внешний консультант по информационной безопасности и законодательству. И, конечно, топ менеджмент.
С чего начать и чем закончить
Вот здесь хорошо описаны стадии принятия сертификации. Особенно остро отрицание, гнев, ярость проходят в маленькой и уютной компании. Здесь любая бюрократическая новация наталкивается на стену непонимания, документация устаревает раньше чем ее успеваешь дописать, а основная сложность это объяснить сотруднику-старожилу зачем ему вдруг нужно менять годами устоявшиеся практики.
Зато именно в маленьких компаниях нагляднее всего видны результаты подготовки.
Несколько практических советов на этапе старта проекта:
- Нарисуйте схему информационных систем компании.
Стандарт диктует: «определите границы и сферы информационных систем».
Это можно сделать либо простым изложением на бумаге, но для нас по-настоящему все началось с нарисованной схемы информационных систем. Это кажется очень просто, и в маленькой компании даже лишним — и так все все понимают, — но, удивительное дело, картинка меняет все.
Первая кривоватая схема где были обозначены ноутбуки, сервера, VPN и Firewalls была встречена на ура и указала на много не замеченных деталей: протоколы VPN, backups, позже добавились облачные серверы, etc.
- Создайте общую папку для документации по ISO
Самый простой инструмент работы и самый эффективный — общая папка в SharePoint, где под каждый контроль и пункт стандарта есть отдельная подпапка с соответствующим названием, где сохраняется вся документация.
- Пишите политики исходя с запасом гибкости
Все политики нужно писать, предварительно прочитав стандарт ISO27002, он дает направление по тому, что именно требуется и будет проверяться аудитором. Любой документ можно написать по-разному. На примере политики по паролям — можно либо прописать письменно что пароль должен быть минимум 8 символов, либо написать что пароль должен быть «сложным» и отражать требованиям информационных систем.
- Написали? Переписывайте.
В нашем случае то, что мы давали «отлежаться» нашим политикам и потом возвращались к ним и переписывали, сказалось на качестве только лучшим образом. Они получились своего рода «выдержанным». Все лишнее стало нагляднее отследить, к тому же за год, то, что мы начинали писать в начале 2020 уже потеряло актуальность. Но слегка изменить политику всегда проще, чем заново ее написать.
План vs реальность
План подготовки к ISO 27001 был следующий:
- Купить официальный текст (да, до сих пор не понимаю почему официальные стандарты надо покупать) и изучить стандарт.
→ Планировали неделю, заняло 2 недели
- Внешний консультант помогает с написанием Body (первой части соответствия стандарту, основных постановлений о стратегии, требованиях, оценке рисков компании), на основании своего опыта.
→ Планировали месяц, заняло 2 месяца
- Внутренний сотрудник составляет схему информационных систем компании.
→ Первая схема была сделана за неделю, но далее она менялась целый год
- Совместно изучается Annex A — список потенциально применимых контролей, из которых отбираются те, которые актуальны для нашей фирмы.
→ Планировали за неделю, заняло 2 месяца
- Под выбранные контроли из Annex A находится или пишется необходимая документация, и дополнительные политики.
→ Планировали месяц, ушло почти полгода
- Когда документация готова, она высылается топ менеджменту для валидации, для удобства разбитая на блоки по смыслу.
→ Планировали за месяц, но валидация как раз прошла относительно быстро — 3 недели
- После одобрения документации, для всех сотрудников компании проводится информационная.
→ Нужен всего один день, но две недели ушло на подготовку
- После этого приглашается сертифицирующий орган для проведения аудита
▍Из положительного:
- Внешний консультант задавал правильные и своевременные вопросы, чем ускорял процесс подготовки.
- Компания маленькая и прозрачная.
- Нет необходимости фокусироваться на технических данных firewall или сервера, т.к. почти все что касается железа аутсорсится.
▍Из отрицательного:
- Иногда вопросов от консультанта было СЛИШКОМ много и мы ходили по кругу, от одного к другому, возвращаясь и углубляясь в детали. Например консультант предложил создать схему под каждый вариант работы сотрудника — из дома, из офиса, от клиента, и.т.д., тогда как подобная схема уже была отражена в главной схеме инф.системы. Кончилось это просто лишней неделей работы, детальные схемы потом не потребовались.
- В маленькой компании каждый сам себе админстратор. В компании нет центральной AD для компьютеров сотрудников, все максимально гибко, это же наталкивается на то, что очень сложно найти создать единые для всех правила, но еще сложнее заставить им следовать.
▍Из практических результатов:
- После уточняющих вопросов о патчинге наших серверов, поставщик изменил политику патчинга;
- Компания решила полностью перенести все системы и хранилища данных в облако;
- Были формализованные следующие процессы:
- Политика проверки кандидата перед приемом на работу
- Политика работы из дома (teleworking)
- Политика безопасности мобильных устройств
- Политика действий в случае инцидентов с безопасностью
- Политика предоставления и удаления доступа
- Матрица ответственности
- Политика инвентаризации
- Роли и обязанности в отношениях с поставщиками (конкретно по каждому поставщику)
- Политика в отношении персональных данных
- Проектный менеджмент
- Политика бэкапов и архивирования
И конечно венцом всего стала обновленная политика информационной безопасности компании.
Оповещение сотрудников
Оповещение сотрудников о подготовке к сертификации это одновременно и возможность закрыть пункт A_7.2.2 Awareness, а также получить обратную связь на все написанные политики и процедуры.
В нашем случае удачной находкой стал чеклист для сотрудников. Политик много, и часто уже после прочтения первой появляется сонливость и уверенность в том, что все всему соответствует и нет необходимости читать дальше.
Загвоздка в том, что сертифицирующий орган будет спрашивать с сотрудников чтобы их действия соответствовали формальным процедурам написанным в документах. И желательно чтобы все отвечали примерно одно и то же.
Чеклист это просто список вопросов, разбитых по темам, например:
Тема: Безопасность офиса
— Я знаю, как активировать систему сигнализации
— Я знаю, как действовать в случае утери входного баджа
И т.д., такой чеклист сильно упрощает коммуникацию и снимает головную боль, появляется что-то практическое, с чем можно работать.
Что было дальше
Подготовка к сертификации не означает саму сертификацию. Впереди аудит сертифицирующего органа, интервью, предоставление доказательств действующих контролей. Кроме того, когда все пройдет успешно, надо будет подтверждать сертификацию каждый год. Но со временем это перестает казаться чем-то сложным или необычным. Совсем как простой финансовый аудит.
