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

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

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

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

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

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

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

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

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

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

Внедрение

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

Оценка

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

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

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

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

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

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

Поддержка

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

Контроль

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

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

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

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

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

Отчетность

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