Iso 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 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.

Четвертая стадия эмоционального реагирования на изменения депрессия. В этой статье мы расскажем вам о нашем опыте прохождения самой затяжной и малоприятной стадии об изменениях бизнес-процессов компании с целью достижения их соответствия стандарту 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 сертификации. Принятие.

Привет! Меня зовут Саша, и уже полтора года я периодически промышляю фишингом. Только не ради наживы, а для повышения киберграмотности коллег. Такие рассылки помогают нам проверить, насколько вероятна утечка из-за человеческого фактора, кому и какое обучение порекомендовать по основам кибербезопасности. В итоге грамотность сотрудников повышается: к концу года доля попавшихся снизилась с 17% до 2%.

Это помогает проходить аудит по стандарту ISO/IEC 27001. Такая рассылка со сбором статистики и последующим обучением встраивается в систему внутреннего аудита по требованиям стандарта.

В посте покажу примеры, как мы проводили внутреннюю фишинговую рассылку и какие результаты она дает.

С чего начать

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

1. Придумать сценарий фишинга.
   
2. Зарегистрировать домен, настроить почту.
   
3. Создать письмо с привлекательной ссылкой.
   
4. Создать правдоподобный лэндинг, где пользователи оставят свои данные.
   
5. Собрать базу для рассылки. Можно сделать выборку по внутренней адресной книге. А можно собрать базу из открытых источников и проверить более уязвимых пользователей с засвеченными учетками.
   
6. Сделать рассылку и собрать статистику, кто и как отреагировал.
   
7. Провести обучение для пользователей по итогам.
   

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

Опыт коллеги: письмо про икру

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

Не забыли добавить в текст орфографические ошибки и смайлы.

Многие стали обращаться к сотруднице лично. Предупреждать ее заранее об этом не стали, чтобы было реалистичнее. Но икра по цене 400 рублей за кг была интересна такому количеству людей, что потребовалось опровержение от Василия, директора центра киберзащиты:

Мне тогда запомнилась реакция одного из менеджеров: он перешел по ссылке в письме, ввел свои данные и только после этого осознал ошибку. Его громкий крик: Ваааася! услышали мы все.

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

Рассылка от сервиса видеоконференций

C переходом на удаленку мы обнаружили рост фишинговых атак, связанных с темой COVID-19. В апреле всем сотрудникам отправили рассылку-предупреждение:


В мае решили протестировать, как усвоилась информация. Идею ковидных рассылок отмели как слишком очевидную. Придумали другой заход: в марте всем сотрудникам установили Webex систему для веб-конференций. За пару месяцев все к ней привыкли, пора проверить бдительность.

Мы посмотрели на стандартную рассылку от Webex и создали похожее письмо:


Кнопка вела на подставной домен с формой для ввода логина и пароля:

Почта пользователя сразу подставилась в приветствие и поле с логином.

После ввода пароля шел редирект на реальный ресурс Cisco, чтобы пользователь ничего не заподозрил (часто так и бывает!).

Всего мы отправили 88 писем, по ссылке перешел 21 пользователь. Ввели данные 15 сотрудников это 17% от всей рассылки. После этого снова отправили всей компании напоминание про фишинг: раскрыли карты, разобрали пример нашей рассылки, объяснили, что делать.

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

За лето мы отправили сотрудникам целую серию обучающих писем с примерами фишинга из нашей практики. Следующий тест решили провести осенью в предновогодний сезон.

Рассылка в честь киберпонедельника

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

В этот раз я создал отдельный домен dataline-cybermonday.ru. Взял дизайн одного популярного сайта и сверстал письмо посимпатичнее:

Для правдоподобия добавил социальные кнопки, они ведут на официальные аккаунты.

Сайт тоже получился максимально правдоподобным:


Но сотрудники стали бдительнее: логин и пароль ввели только двое.

Рассылка от мэрии Москвы

С этой рассылкой я заморочился еще сильнее и решил провести фейковый опрос жителей Москвы о новогодних праздниках. Сначала создал домен opros-mos.ru. Прототипом для письма стала муниципальная рассылка в честь Дня города. Взял из нее фото и подпись мэра, герб города, ссылки на страницы в соцсетях. Получилось очень похоже:

Стишок взял первый попавшийся на странице поиска.

Так выглядела страница для ввода логина и пароля. Тоже использовал изображения и кнопки с официального сайта:


На это письмо реагировали еще меньше: открыли письмо 14 человек, перешли по ссылке пятеро. Делаем вывод, что рассылки на нерабочие темы для пользователей корпоративной почты не так интересны.

Немного статистики и ссылок на инструментарий

Отдельно покажу, как мы считаем данные по рассылкам. Для всех писем отслеживаем, какая доля пользователей открыла письмо, перешла по ссылке и ввела свои данные. Разослать и зафиксировать данные по переходам помогает GoPhish опенсорсный фреймворк для фишинга.

Рассылку делаем не по всей компании, а по группе от 50 до 100 сотрудников, так что считаем долю от общего числа отправленных писем.

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

Отдельно отмечаем тех пользователей, которые сообщают в центр киберзащиты о подозрительном письме. По 4 письмам за год статистика такая:



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

В ближайшее время напишем про другие составляющие этого сервиса: проверку паролей и разведку по открытым источникам (OSINT).