Смиб

Третья стадия эмоционального реагирования на изменения торг. Разобравшись со своим гневом и эмоциональной составляющей, мы начали думать о том, что реально нужно сделать для того, что у нас всё заработало. Настало время изучить стандарт более детально, применить его к нашей текущей ситуации и адаптировать его требования под нашу компанию. Здесь важно было при соблюдении требований стандарта обойтись малой кровью. Любые изменения должны были быть адекватными то есть соизмеримыми с соответствующим риском. Затраты на защиту не должны были превышать возможный ущерб от реализации риска.



На этом пути нам пришлось решить множество вопросов, с которыми мы никогда не сталкивались ранее:

Выбор средства для работы над библиотекой политик

Первый (казалось бы, очень простой) вопрос, с которым мы столкнулись где создавать и как хранить все необходимые документы системы менеджмента информационной безопасности? Для нас было крайне важно сохранять версионность документов и иметь возможность откатить версию политики на несколько редакций назад. Изучив предложения на рынке, мы остановились на вики-системе Confluence и используем её по сей день.

В качестве системы версионирования (контроля версий) мы могли использовать git, но для удобства пользователей мы выбрали портальное решение (Confluence). Мы сумели ограничиться бесплатной версией (до 10 авторизованных пользователей): больше нам и не понадобилось, так как неавторизованные могли просматривать библиотеку.

Подготовка плана внедрения

Здесь мы не стали применять какие-то креативные методики просто запросили у нашего консультанта перечень необходимых политик, назначили ответственных за их написание и согласование, проставили ключевые даты и оформили это всё в виде диаграммы Ганта (которая также была подгружена в Confluence).

Оценка рисков компании

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

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

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

1. Пробелы в знаниях сотрудников
Наиболее распространённым риском стал человеческий фактор. К тому же мы проходили сертификацию впервые, поэтому у нас встал вопрос обучения основам ИБ. Уже разработав программу, мы столкнулись с проблемой автоматизации данного процесса и контроля остаточных знаний. В результате мы стали использовать систему тестирования, которую встроили в наш корпоративный портал.

2. Отсутствие резервных вычислительных мощностей
Данная проблема требовала больших финансовых и человеческих ресурсов, поэтому оставлять ее на конец было неправильно. Мы подобрали площадку для резервирования наших основных сервисов: на первоначальном этапе мы пользовались IaaS (инфраструктура как сервис), которая позволила нам быстро и бюджетно настроить резерв основных сервисов компании; в дальнейшем мы закупили дополнительное оборудование и настроили резерв в отдельном ЦОДе (co-location). Впоследствии мы отказались от облачного решения в пользу ЦОДа ввиду большого объема данных.

3. Контроль за супер-пользователями, а также за теми, кто работает с особой, чувствительной информацией
Другими словами, нам необходимо было установить контроль за пользователями, которые имеют обширный доступ к конфиденциальной информации. Эту проблемы мы решили с помощью DLP системы. Мы выбрали отечественное ПО StaffCop благодаря приемлемой цене и хорошей технической поддержке.

Написание политик

Здесь мы подключили все возможные ресурсы:

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

В итоге лучше всего сработал именно третий (самый сложный путь). Это было довольно долго, но зато на выходе мы получили хорошо составленные именно для нашей компании документы. Так на выходе у нас получилось 36 основных политик Системы Менеджмента Информационной Безопасности.

Распределение ролей

Очевидно, что не все эти политики реально были необходимыми нашим сотрудникам в ежедневной работе. Чтобы не заставлять их читать лишнее, мы сделали следующее: присвоили каждому сотруднику одну или несколько ролей в СМИБ. Всего их было 5 штук:

Абсолютно у всех сотрудников была как минимум одна роль пользователь.

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

Вовлечение коллег

К оценке рисков и описанию требований заинтересованных сторон помимо менеджера проекта и Руководителя отдела ИТ/ИБ был привлечен Операционный директор компании. Потребовалось существенное вовлечение и Руководителя отдела HR ей требовалось описать в политике полный жизненный цикл сотрудника: от заявки на вакансию до периода после его увольнения. К счастью, все коллеги понимали важность сертификации и шли нам навстречу.

Технические аспекты

В процессе подготовки мы поняли, что для выполнения требований стандарта нам потребуется как минимум следующее:

Перенести сервера во внешний дата-центр;
Оборудовать все офисы СКУД (система контроля и управления доступом).

В дальнейшем к этим двум пунктам добавилось множество других вещей: внедрение DLP-системы, запуск резервного дата-центра, введение двухфакторной авторизации и т.д.

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

В предыдущих материалах:

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Отрицание: заблуждения о сертификации ISO 27001:2013, целесообразность получения сертификата/
5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.

Четвертая стадия эмоционального реагирования на изменения депрессия. В этой статье мы расскажем вам о нашем опыте прохождения самой затяжной и малоприятной стадии об изменениях бизнес-процессов компании с целью достижения их соответствия стандарту ISO 27001.

Ожидание

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

Изначальный план работ был расписан так, что мы должны были уложиться за 3 месяца.



Всё выглядело просто: необходимо было написать пару десятков политик и слегка поменять наши внутренние процессы; затем обучить изменениям коллег и подождать еще 3 месяца (чтобы появились записи, то есть доказательства функционирования политик). Казалось, что на этом всё и сертификат у нас в кармане.

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

В результате этих умозаключений мы заложили на подготовку каждой политики по 3 дня.

Технические изменения также не выглядели устрашающими: необходимо было настроить сбор и хранение событий, проверить, соответствуют ли бэкапы политике, которую мы написали, дооснастить, где это необходимо, кабинеты СКУДом и еще немного разного по мелочи.
Команда, готовящая все необходимое для сертификации, состояла из двух человек. Мы планировали, что они будут заниматься внедрением параллельно со своими основными обязанностями, и у каждого это будет отнимать максимум 1,5-2 часа в день.
Резюмируя, можно сказать, что наш взгляд на предстоящий объем работ был довольно оптимистичным.

Реальность

На самом деле всё, естественно, было иначе: шаблоны политик, предоставленные консультантом, оказались преимущественно неприменимыми к нашей компании; в Интернете почти не было понятной информации по поводу того, что и как нужно делать. Как вы понимаете, план писать одну политику за 3 дня с треском провалился. Так мы перестали укладываться в сроки практически с самого начала проекта, а градус настроения начал медленно падать.



Экспертизы команды было катастрофически мало настолько, что её не хватало даже на то, чтобы задавать правильные вопросы консультанту (который, к слову, не проявлял большого количества инициативы). Дело стало продвигаться еще медленнее, так как через 3 месяца после старта внедрения (то есть в тот момент, когда всё уже должно было быть готово), команду покинул один из двух ключевых участников. На его место пришел новый руководитель IT-службы, которому предстояло в короткий срок завершить процесс внедрения и обеспечить систему менеджмента информационной безопасности всем самым необходимым с технической точки зрения. Задача выглядела сложной Ответственные начали впадать в депрессию.

К тому же техническая сторона вопроса также оказалась с нюансами. Мы встали перед задачей глобальной модернизации ПО как на рабочих станциях, так и на серверном оборудовании. В ходе настройки системы для сбора событий (логов) выяснилось, что нам не хватает аппаратных ресурсов для нормального функционирования системы. Да и ПО для резервного копирования также нуждалось в модернизации.

Спойлер: В итоге СМИБ была героически внедрена за 6 месяцев. И даже никто не умер!

Что изменилось больше всего?

Безусловно, в процессе внедрения стандарта в процессах компании произошло большое количество мелких изменений. Для вас мы выделили самые существенные изменения:

• Формализация процесса оценки рисков

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

• Контроль над съемными носителями информации

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

• Контроль за суперпользователями

Одной из основных проблем был тот факт, что все сотрудники IT-отдела имели абсолютные права во всех системах компании обладали доступом ко всей информации. При этом их при этом никто толком не контролировал.

Мы внедрили систему Data Loss Prevention (DLP) программа для контроля действий сотрудников, которая занимается анализом, блокировкой и оповещениями об опасной и непродуктивной деятельности. Сейчас оповещения о действиях сотрудников ИТ-отдела приходят на почту Операционному Директору компании.

• Подход к организации информационной инфраструктуры

Сертификация потребовала глобальных изменений и подходов. Да, нам пришлось модернизировать ряд серверного оборудования, в связи с увеличившейся нагрузкой. В частности, мы выделили отдельный сервер под системы сбора событий. Сервер был укомплектован объемными и быстрыми накопителями SSD. Мы отказались от ПО для бэкапов и сделали выбор в пользу систем хранения, которые из коробки имеют весь необходимый функционал. Сделали несколько больших шагов в сторону концепции инфраструктура как код, что позволило сэкономить много дискового пространства, за счет отказа от резервного копирования ряда серверов. В кратчайшие сроки (1 неделя) было модернизировано все ПО на рабочих станциях до Win10. Один из вопросов, который решила модернизация возможность включения шифрации (в версии Pro).

• Контроль за бумажными документами

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

• Аренда резервного дата-центра

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

• Тестирование непрерывности бизнеса

В нашей компании уже несколько лет действовала Политика непрерывности бизнеса (BCP), описывающая порядок действий сотрудников при различных негативных сценариях (потеря доступа к офису, эпидемия, отключение электричества и так далее). Однако, мы никогда не проводили тестирование непрерывности то есть, никогда не замеряли, какое количество времени займет восстановление бизнеса в каждой из этих ситуаций. В рамках подготовки к сертификационному аудиту мы не только сделали это, но и разработали план тестирования непрерывности бизнеса на ближайший год. Стоит отметить, что спустя год, когда мы столкнулись с необходимостью полного перехода на дистанционный режим работы, мы справились с этой задачей за три дня.



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

Реакция сотрудников на изменения

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

• Все ключевые сотрудники понимали важность и неизбежность этого мероприятия;
• Все прочие сотрудники равнялись на ключевых сотрудников.

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

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

Таким образом, мы прошли самую болезненную стадию депрессии связанную с изменениями наших бизнес-процессов. Это было тяжело и сложно, но результат в итоге превзошел все самые смелые ожидания.

Читайте предыдущие материалы из цикла:

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Отрицание: заблуждения о сертификации ISO 27001:2013, целесообразность получения сертификата.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Торг: подготовка плана внедрения, оценка рисков, написание политик.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Депрессия.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Принятие.