Третья стадия эмоционального реагирования на изменения – торг. Разобравшись со своим гневом и эмоциональной составляющей, мы начали думать о том, что реально нужно сделать для того, что у нас всё заработало. Настало время изучить стандарт более детально, применить его к нашей текущей ситуации и адаптировать его требования под нашу компанию. Здесь важно было при соблюдении требований стандарта обойтись «малой кровью». Любые изменения должны были быть адекватными – то есть соизмеримыми с соответствующим риском. Затраты на защиту не должны были превышать возможный ущерб от реализации риска.
На этом пути нам пришлось решить множество вопросов, с которыми мы никогда не сталкивались ранее:
Первый (казалось бы, очень простой) вопрос, с которым мы столкнулись – где создавать и как хранить все необходимые документы системы менеджмента информационной безопасности? Для нас было крайне важно сохранять версионность документов и иметь возможность «откатить» версию политики на несколько редакций назад. Изучив предложения на рынке, мы остановились на вики-системе Confluence – и используем её по сей день.
В качестве системы версионирования (контроля версий) мы могли использовать git, но для удобства пользователей мы выбрали портальное решение (Confluence). Мы сумели ограничиться бесплатной версией (до 10 авторизованных пользователей): больше нам и не понадобилось, так как неавторизованные могли просматривать библиотеку.
Здесь мы не стали применять какие-то креативные методики – просто запросили у нашего консультанта перечень необходимых политик, назначили ответственных за их написание и согласование, проставили ключевые даты и оформили это всё в виде диаграммы Ганта (которая также была подгружена в Confluence).
Очевидно, что для выбора средств защиты нам нужно было оценить риски (чтобы тратить ресурсы только туда, где это реально нужно). Для этого мы создали перечень активов компании, которые мы планируем защищать – в него входили как физические активы (рабочие станции, сервера, бумажные документы и т.д.), так и нематериальные (клиентская информация в электронном виде, пароли и т.д.).
С помощью экспертной группы каждому активу была присвоена определенная ценность. Далее мы привязали к каждому активу один или несколько рисков, к которому данный актив может быть подвержен (например, бумажные документы могут быть украдены, уничтожены и т.д.). Потом мы оценили значимость каждого риска как произведение двух параметров: вероятность риска и значимость последствий реализации риска.
После того, как риски были разнесены по группам, мы поняли, с какими из них нам следует работать в первую очередь:
1. Пробелы в знаниях сотрудников
Наиболее распространённым риском стал человеческий фактор. К тому же мы проходили сертификацию впервые, поэтому у нас встал вопрос обучения основам ИБ. Уже разработав программу, мы столкнулись с проблемой автоматизации данного процесса и контроля остаточных знаний. В результате мы стали использовать систему тестирования, которую встроили в наш корпоративный портал.
2. Отсутствие резервных вычислительных мощностей
Данная проблема требовала больших финансовых и человеческих ресурсов, поэтому оставлять ее на конец было неправильно. Мы подобрали площадку для резервирования наших основных сервисов: на первоначальном этапе мы пользовались IaaS (инфраструктура как сервис), которая позволила нам быстро и бюджетно настроить резерв основных сервисов компании; в дальнейшем мы закупили дополнительное оборудование и настроили резерв в отдельном ЦОДе (co-location). Впоследствии мы отказались от “облачного” решения в пользу ЦОДа ввиду большого объема данных.
3. Контроль за “супер-пользователями”, а также за теми, кто работает с “особой, чувствительной” информацией
Другими словами, нам необходимо было установить контроль за пользователями, которые имеют обширный доступ к конфиденциальной информации. Эту проблемы мы решили с помощью DLP системы. Мы выбрали отечественное ПО StaffCop благодаря приемлемой цене и хорошей технической поддержке.
Здесь мы подключили все возможные ресурсы:
Очевидно, что не все эти политики реально были необходимыми нашим сотрудникам в ежедневной работе. Чтобы не заставлять их читать лишнее, мы сделали следующее: присвоили каждому сотруднику одну или несколько ролей в СМИБ. Всего их было 5 штук:
Абсолютно у всех сотрудников была как минимум одна роль – «пользователь».
В паспорте каждой роли мы прописали соответствующие обязанности в области ИБ с приложением списка политик, которые сотрудник, имеющий ту или иную роль, должен был соблюдать. Также для удобства мы сделали графическую организационную структуру компании с указанием ролей каждого сотрудника на ней.
К оценке рисков и описанию требований заинтересованных сторон помимо менеджера проекта и Руководителя отдела ИТ/ИБ был привлечен Операционный директор компании. Потребовалось существенное вовлечение и Руководителя отдела HR – ей требовалось описать в политике полный жизненный цикл сотрудника: от заявки на вакансию до периода после его увольнения. К счастью, все коллеги понимали важность сертификации и шли нам навстречу.
В процессе подготовки мы поняли, что для выполнения требований стандарта нам потребуется как минимум следующее:
Таким образом, для адаптации требований стандарта под нашу компанию нам пришлось проделать довольно существенное количество работы.
В предыдущих материалах:
5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Отрицание: заблуждения о сертификации ISO 27001:2013, целесообразность получения сертификата/
5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.
На этом пути нам пришлось решить множество вопросов, с которыми мы никогда не сталкивались ранее:
Выбор средства для работы над библиотекой политик
Первый (казалось бы, очень простой) вопрос, с которым мы столкнулись – где создавать и как хранить все необходимые документы системы менеджмента информационной безопасности? Для нас было крайне важно сохранять версионность документов и иметь возможность «откатить» версию политики на несколько редакций назад. Изучив предложения на рынке, мы остановились на вики-системе 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 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.
