Задачей подпроцесса реализации (внедрения) является выполнение всех мероприятий, определенных в планах. Этот подпроцесс может поддерживаться следующим контрольным списком действий.
Классификация и Управление ИТ-ресурсами:
- предоставление входных данных для поддержки Конфигурационных Единиц (CI) в базе CMDB;
- классификация ИТ-ресурсов в соответствии с согласованными принципами.
Безопасность персонала:
- задачи и ответственности в описании работ;
- отбор персонала;
- соглашения о конфиденциальности для персонала;
- обучение персонала;
- руководства для персонала по разрешению инцидентов, связанных с безопасностью, и устранению обнаруженных дефектов защиты;
- дисциплинарные меры;
- улучшение осведомленности по вопросам безопасности.
Управление Безопасностью:
- внедрение видов ответственности и распределение обязанностей;
- письменные рабочие инструкции;
- внутренние правила;
- меры безопасности должны охватывать весь жизненный цикл систем; должны существовать руководства по безопасности для разработки систем, их тестирования, приемки, операционного использования, обслуживания и выведения из операционной среды;
- отделение среды разработки и тестирования от операционной (рабочей) среды;
- процедуры обработки инцидентов (осуществляемые Процессом Управления Инцидентами);
- использование средств восстановления;
- предоставление входной информации для Процесса Управления Изменениями;
- внедрение мер защиты от вирусов;
- внедрение методов управления для компьютеров, приложений, сетей и сетевых услуг;
- правильное обращение с носителями данных и их защита.
Контроль доступа:
- внедрение политики доступа и контроля доступа;
- поддержка привилегий доступа пользователей и приложений к сетям, сетевым услугам, компьютерам и приложениям;
- поддержка барьеров сетевой защиты (фаервол, услуги доступа по телефонной линии, мосты и маршрутизаторы);
- внедрение методов идентификации и авторизации компьютерных систем, рабочих станций и ПК в сети
Существенное значение имеет независимая оценка реализации запланированных мероприятий. Такая оценка необходима для определения эффективности, ее выполнение также требуют заказчики и третьи стороны. Результаты подпроцесса оценки могут использоваться для корректировки согласованных с заказчиком мер, а также для их реализации. По результатам оценки могут быть предложены изменения, в случае чего формулируется Запрос на изменения (RFC), направляемый в Процесс Управления Изменениями.
Существует три вида оценки:
- самостоятельная оценка: проводится в первую очередь линейными подразделениями организации;
- внутренний аудит: проводится внутренними ИТ-аудиторами;
- внешний аудит: проводится внешними ИТ-аудиторами.
В отличие от самостоятельной оценки аудит не проводится тем же персоналом, который участвует в других подпроцессах. Это необходимо для обеспечения разделения ответственностей. Аудит может проводиться отделом внутреннего аудита.
Оценка также проводится как ответное действие в случае возникновения инцидентов.
Основными видами деятельности являются:
- проверка соответствия политике безопасности и реализация Планов по безопасности;
- проведение аудита безопасности ИТ-систем;
- определение и принятие мер несоответствующего использования ИТ-ресурсов;
- проверка аспектов безопасности в других видах ИТ-аудита.
В связи с изменением рисков при изменениях в ИТ-инфраструктуре, в компании и в бизнес-процессах необходимо обеспечить должную поддержку мер безопасности. Поддержка мер безопасности включает поддержку соответствующих разделов по безопасности соглашений SLA и поддержку подробных Планов по безопасности (на Уровне Операционных Соглашений об Уровне Услуг).
Поддержание эффективного функционирования системы безопасности проводится на основе результатов подпроцесса Оценки и анализа изменений рисков. Предложения могут быть внедрены или в подпроцессе планирования, или в ходе обеспечения поддержки всего соглашения SLA. В любом случае внесенные предложения могут привести ко включению дополнительных инициатив в годовой План по безопасности. Любые изменения подлежат обработке в рамках обычного Процесса Управления Изменениями.
Составление отчетов является видом деятельности по предоставлению информации из других подпроцессов. Отчеты составляются для предоставления информации о достигнутых характеристиках безопасности и для информирования заказчиков о проблемах безопасности. Вопросы предоставления отчетов обычно согласовываются с заказчиком.
Составление отчетов является важным как для заказчика, так и для поставщика услуг. Заказчики должны иметь точную информацию об эффективности работы (например, по реализации мер безопасности) и о принимаемых мерах безопасности. Заказчик также информируется о любых инцидентах, связанных с безопасностью. Ниже даются предложения по составлению отчетов.
Примеры регулярных отчетов и включаемых в них событий:
Подпроцесс планирования:
- отчеты о степени соответствия соглашению SLA и согласованным ключевым показателям качества по вопросам безопасности;
- отчеты о внешних договорах и связанных с ними проблемах;
- отчеты об Операционных Соглашениях об Уровне Услуг (внутренние Планы по безопасности) и собственных принципах безопасности поставщика (например, по базовому Уровню Безопасности);
- отчеты о годовых планах по безопасности и планах действий.
Подпроцесс внедрения:
- отчеты о состоянии дел в информационной безопасности. Сюда входят отчет о выполнении годового плана по безопасности, перечень осуществленных или намеченных мер, информация об обучении, результаты дополнительного анализа рисков и т. д.;
- перечень инцидентов, связанных с безопасностью и ответных мер, возможно, в сравнении с предыдущим отчетным периодом;
- определение тенденций возникновения инцидентов;
- состояние программы оповещения.
Подпроцесс оценки:
- отчеты об эффективности подпроцессов;
- результаты аудиторских проверок, анализа и внутренних оценок;
- предупреждения, определение новых угроз.
Специальные отчеты:
Для сообщений об определенных в соглашении SLA инцидентах, связанных с безопасностью, поставщик услуг должен иметь прямой канал связи с представителем заказчика (возможно, инспектором информационной безопасности предприятия) через Руководителей Процессов Управления Уровнем Услуг, Управления Инцидентами или Управления Информационной Безопасностью. Должна быть также определена процедура для связи в особых случаях. За исключением особых обстоятельств, отчеты передаются через Процесс Управления Уровнем Услуг.
Критическими факторами успеха являются:
- полное понимание необходимости процесса со стороны руководства и его привлечение к процессу;
- привлечение пользователей к разработке процесса;
- точное определение и разделение ответственностей.
Показатели эффективности Процесса Управления Информационной Безопасностью соответствуют таким же показателям Процесса Управления Уровнем Сервиса в той степени, в которой последние связаны с затрагиваемыми в SLA вопросами безопасности.
В небольших ИТ-организациях один человек может руководить несколькими процессами. В крупных же организациях несколько человек работают над одним процессом, например, таким как Управление Информационной Безопасностью. В таких случаях обычно назначается один руководитель Процесса Управления Информационной Безопасностью. Этот руководитель несет ответственность за эффективное функционирование процесса. Его коллегой в организации заказчика является инспектор информационной безопасности.
Следующие аспекты имеют существенное значение для успешной реализации Процесса Управления Информационной Безопасностью:
- Понимание необходимости процесса (понимание со стороны участников): меры безопасности редко встречают быстрое положительное понимание со стороны персонала; чаще встречается сопротивление, а не одобрение. Пользователи возмущаются потерей определенных привилегий из-за введения мер безопасности, даже если эти возможности не являются существенными для их работы. Это объясняется тем, что привилегии дают им определенный статус. Поэтому необходима специальная работа по мотивации пользователей и получению согласия руководства на введение мер безопасности. Особенно в области Управления Информационной Безопасностью руководство должно показать пример ("разъяснять курс" и "вести за собой"). При отсутствии инцидентов по безопасности у руководства может возникнуть искушение сократить расходы на Управление Безопасностью.
- Отношение: информационные системы небезопасны не из-за их технического несовершенства, а из-за ошибок при использовании технологии. Обычно это связано с человеческим отношением и поведением. Это означает, что процедуры безопасности должны быть интегрированы в рутинные операции.
- Осведомленность: осведомленность или, скорее, коммуникации является ключевым понятием. Между коммуникациями и безопасностью иногда возникает конфликт интересов: коммуникации мостят дорогу, а безопасность создает препятствия. Это означает, что реализация мер безопасности требует использования всех способов коммуникаций для того, чтобы пользователи приняли необходимый стиль поведения.