Процесс управления безопасностью в ITIL

Основной проблемой безопасности на текущий момент является не аппаратная или программная часть, и даже не средства мониторинга безопасности. Основной проблемой является менеджмент безопасности, а точнее его отсутствие…

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

Возможен ли компромисс?

Основным тезисом должнобыть то, что бизнес определяеттребования физической безопасности. После того, как требования будутхотя бы приблизительно сформированы, отдел ИБ может подготовить решение (типичноеили нетипичное) для выполнения поставленных задач. Послеэтого к стоимости работы сервиса (она должна быть описана
в SLA) прибавляется стоимость, а безопасность говорит, как их выполнить. Оченьчасто руководство не может поставить четкие требования, исоветы отдела ИБ необходимы,но также необходим компрообеспечения безопасности нажелаемом уровне.
Для менеджмента все становится понятно – вот сервис, вототделы, которые его потребляют, вот бизнес-процессы, которые опираются на этот сервис,вот его стоимость и дополнительная стоимость безопасности… После этого «мяч переходит на поле» менеджмента иони решают, могут ли они себеэто позволить или нет. При таком подходе отпадают вопросы: что такое IPS и почему онатак дорого стоит, или зачем нам
еще одна Cisco ASA, у нас ужеесть 3…. Сомнения исчезают,поскольку решения о приоб-
ретении железа и софта остается вопросом исключительнойкомпетенции внутри отдела
ИБ. Отдел безопасности решаеткак гарантировать выполненииSLA и при этом минимизировать затраты, иначе предоставление сервиса для них же будетневыгодным.

Если руководство не формулирует требования, то за основуможно взять систему приоритетов сервисов, которая была заложена при составлении каталогасервисов. Каталога сервисовдаже при полном отсутствиивсех процессов ITIL не можетНЕ БЫТЬ. Без него управлениеИТ-инфраструктурой возможно только в «ручном» режиме спланированием вслепую.

Планирование

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

  • необходимость в программном и/или аппаратном обеспечении;
  • проектная документация;
  • обучение сотрудников ИБ;
  • программы бдительностибезопасности для пользователей;
  • создание процедур и других документов регулярногопользования;
  • планы реагирования на инциденты;
  • описание средств восстановления безопасности сервиса.

На выходе для каждого сервиса должен быть единый документ - План Безопасности
Сервиса, который необходимосогласовать с заказчиком. Длякаждого сервиса необходимосовместно с процессом управления Уровнем Сервисов разработать KPI для безопасности, длятого чтобы потом можно было,отталкиваясь от соответствующих замеров, информироватьзаказчика о том, насколько качественно ему предоставляется сервис с интегрированнойбезопасностью. После того, какбудут проанализированы потребность в работе, людях ирешениях для обеспечения безопасности, станет понятна общая стоимость, на основе которой необходимо взымать платуза предоставление безопасногосервиса. Кроме того, привязка ксервису позволит избежать «избыточных покупок» и покупатьдействительно только то, чтообосновано и необходимо.

Внедрение

На этапе внедрения необходимо привести План Безопасности в действие: купить и внедрить системы для обеспечениябезопасности, разработать инструкции, обучить персонал.Исходя из того, что управление Безопасностью – это постоянный процесс, а не конечныйрезультат, в процессе работыбудут возникать непредвиденные обстоятельства, инциденты и проблемы, появление которых не было запланировано
заранее.

Оценка

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

  • Самооценка – внутренний аудит по отношению к лучшимпрактикам, который прово-

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

Самооценка должна проводиться постоянно.

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

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

Поддержка

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

Контроль

Контроль должен присутствовать в каждой из остальных4-х фаз. Все фазы должны начинаться с контроля, так как внее входят основополагающиезадачи:

  • процедуры осуществленияконтроля;
  • расписание ответственности,функций и должностных инструкций;
  • описание остальных подпроцессов;
  • корреляция с политикой безопасности;
  • написание корпоративныхстандартов для предоставления безопасности;
  • создание точки отсчета безопасности сервиса;
  • учреждение Руководящего

Комитета по информационной безопасности;

  • организационная структурабезопасности;
  • правила документированияинформационных систем дляобеспечения безопасности.

Именно от этого подпроцесса зависит успех всех остальных. Если упустить формализацию систем и процедурконтроля, то остальные подпроцессы можно не внедрять.

Отчетность

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