Управление безопасностью ITIL
Управление безопасностью ITIL описывает структурированную установку безопасности в организации. Управление безопасностью ITIL основано на стандарте ISO 27001. "ISO/IEC 27001:2005 охватывает все типы организаций (например, коммерческие предприятия, государственные учреждения, некоммерческие организации). [1] ISO/IEC 27001:2005 определяет требования к созданию, внедрению, эксплуатации, мониторингу, обзору, поддержанию и улучшению документированной системы управления информационной безопасностью в контексте общих бизнес-рисков организации. Он определяет требования к внедрению средств управления безопасностью, настроенных под нужды отдельных организаций или их частей. ISO/IEC 27001:2005 разработан для обеспечения выбора адекватных и соразмерных средств управления безопасностью, которые защищают информационные активы и вселяют уверенность заинтересованным сторонам".
Базовая концепция управления безопасностью — информационная безопасность . Основная цель информационной безопасности — контроль доступа к информации. Ценность информации — это то, что должно быть защищено. Эти ценности включают конфиденциальность , целостность и доступность . Предполагаемые аспекты — это конфиденциальность, анонимность и проверяемость.
Цель управления безопасностью состоит из двух частей:
- Требования безопасности , определенные в соглашениях об уровне обслуживания (SLA), и другие внешние требования, указанные в базовых контрактах, законодательстве и возможных внутренних или внешних политиках.
- Базовая безопасность, гарантирующая непрерывность управления. Это необходимо для достижения упрощенного управления уровнем обслуживания для информационной безопасности.
SLA определяют требования безопасности, а также законодательство (если применимо) и другие контракты. Эти требования могут выступать в качестве ключевых показателей эффективности (KPI), которые могут использоваться для управления процессами и для интерпретации результатов процесса управления безопасностью.
Процесс управления безопасностью связан с другими процессами ITIL. Однако в этом конкретном разделе наиболее очевидными являются отношения с процессами управления уровнем обслуживания , управления инцидентами и управления изменениями .
Управление безопасностью
Управление безопасностью — это непрерывный процесс, который можно сравнить с Кругом качества У. Эдвардса Деминга ( Планируй, Делай, Проверяй, Действуй ).
Входные данные — это требования клиентов. Требования преобразуются в службы безопасности и показатели безопасности. И клиент, и подпроцесс плана влияют на SLA. SLA — это входные данные как для клиента, так и для процесса. Поставщик разрабатывает планы безопасности для организации. Эти планы содержат политики и соглашения об уровне эксплуатации. Затем планы безопасности (Plan) внедряются (Do), а затем внедрение оценивается (Check). После оценки планы и внедрение плана поддерживаются (Act).
Действия, результаты/продукты и процесс документируются. Внешние отчеты пишутся и отправляются клиентам. Затем клиенты могут адаптировать свои требования на основе информации, полученной через отчеты. Кроме того, поставщик услуг может скорректировать свой план или реализацию на основе своих выводов, чтобы удовлетворить все требования, указанные в SLA (включая новые требования).
Контроль
Первым действием в процессе управления безопасностью является подпроцесс «Управление». Подпроцесс управления организует и управляет процессом управления безопасностью. Подпроцесс управления определяет процессы, распределение ответственности за заявления политики и структуру управления.
Структура управления безопасностью определяет подпроцессы для разработки, внедрения и оценки в планы действий. Кроме того, структура управления определяет, как результаты должны быть сообщены клиентам.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Контроль | Внедрение политик | Этот процесс описывает конкретные требования и правила, которые должны быть выполнены для внедрения управления безопасностью. Процесс заканчивается заявлением о политике . |
| Создание организации безопасности | Этот процесс устанавливает организации для информационной безопасности . Например, в этом процессе устанавливается структура, обязанности. Этот процесс заканчивается структурой управления безопасностью . | |
| Отчетность | В этом процессе весь процесс нацеливания документируется определенным образом. Этот процесс завершается отчетами . |
Модель метапроцесса подпроцесса управления основана на диаграмме активности UML и дает обзор действий подпроцесса управления. Серый прямоугольник представляет подпроцесс управления, а меньшие лучи внутри него представляют действия, которые происходят внутри него.
| Концепция | Описание |
|---|---|
| Контрольные документы | Контроль — это описание того, как организовано управление безопасностью и как оно осуществляется. |
| Заявления о политике | Заявления о политике описывают конкретные требования или правила, которые должны быть выполнены. В сфере информационной безопасности политики обычно точечно-специфичны, охватывая одну область. Например, политики «допустимого использования» охватывают правила и положения для надлежащего использования вычислительных мощностей. |
| Структура управления безопасностью | Структура управления безопасностью — это устоявшаяся структура управления, позволяющая инициировать и контролировать реализацию мер информационной безопасности в организации, а также управлять текущим обеспечением информационной безопасности. |
Модель метаданных подпроцесса управления основана на диаграмме классов UML . На рисунке 2.1.2 показана метамодель подпроцесса управления.
Рисунок 2.1.2: Подпроцесс управления моделью метапроцесса
Прямоугольник CONTROL с белой тенью — это открытая сложная концепция. Это означает, что прямоугольник Control состоит из набора (под)концепций.
Рисунок 2.1.3 представляет собой модель данных процесса подпроцесса управления. Она показывает интеграцию двух моделей. Пунктирные стрелки указывают на концепции, которые создаются или корректируются в соответствующих действиях.
Рисунок 2.1.3: Подпроцесс управления моделью данных процесса
План
Подпроцесс «План» содержит действия, которые в сотрудничестве с управлением уровнем обслуживания ведут к разделу (информационной) безопасности в SLA. Кроме того, подпроцесс «План» содержит действия, которые связаны с базовыми контрактами, которые являются специфическими для (информационной) безопасности.
В подпроцессе «План» сформулированные в SLA цели указываются в форме соглашений об уровне эксплуатации (OLA). Эти OLA можно определить как планы безопасности для конкретной внутренней организационной единицы поставщика услуг.
Помимо ввода SLA, подпроцесс Plan также работает с заявлениями о политике самого поставщика услуг. Как было сказано ранее, эти заявления о политике определяются в подпроцессе Control.
Соглашения об уровне эксплуатации для информационной безопасности устанавливаются и внедряются на основе процесса ITIL. Это требует сотрудничества с другими процессами ITIL. Например, если управление безопасностью хочет изменить ИТ-инфраструктуру для повышения безопасности, эти изменения будут выполнены через процесс управления изменениями . Управление безопасностью предоставляет входные данные (запрос на изменение) для этого изменения. Менеджер по изменениям отвечает за процесс управления изменениями.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| План | Создать раздел «Безопасность» для SLA | Этот процесс содержит действия, которые ведут к параграфу соглашений о безопасности в соглашениях об уровне обслуживания. В конце этого процесса создается раздел «Безопасность» соглашения об уровне обслуживания. |
| Создание базовых контрактов | Этот процесс содержит действия, которые ведут к базовым контрактам. Эти контракты специфичны для безопасности. | |
| Создание соглашений на операционном уровне | Общие сформулированные цели в SLA определяются в соглашениях операционного уровня. Эти соглашения можно рассматривать как планы безопасности для конкретных организационных подразделений. | |
| Отчетность | В этом процессе весь процесс создания плана документируется определенным образом. Этот процесс завершается отчетами. |
План состоит из комбинации неупорядоченных и упорядоченных (под)действий. Подпроцесс содержит три сложных действия, которые все являются закрытыми действиями, и одно стандартное действие.
| Концепция | Описание |
|---|---|
| План | Сформулированы схемы соглашений о безопасности. |
| Раздел «Безопасность» соглашений об уровне безопасности | Пункт соглашения о безопасности в письменных соглашениях между поставщиком услуг и заказчиком(ами), в котором документируются согласованные уровни обслуживания для услуги. |
| Подкрепляющие контракты | Договор с внешним поставщиком, охватывающий предоставление услуг, которые поддерживают ИТ-организацию в предоставлении услуг. |
| Соглашения об операционном уровне | Внутреннее соглашение, охватывающее предоставление услуг, которые поддерживают ИТ-организацию в предоставлении услуг. |
Так же, как и подпроцесс Control, подпроцесс Plan моделируется с использованием техники метамоделирования. Левая сторона рисунка 2.2.1 представляет собой модель метаданных подпроцесса Plan.
Прямоугольник Плана — это открытая (комплексная) концепция, которая имеет тип агрегации отношений с двумя закрытыми (комплексными) концепциями и одной стандартной концепцией. Две закрытые концепции не раскрываются в этом конкретном контексте.
Следующая картинка (рисунок 2.2.1) представляет собой диаграмму процесса-данных подпроцесса Планирования. Эта картинка показывает интеграцию двух моделей. Пунктирные стрелки указывают, какие концепции создаются или корректируются в соответствующих действиях подпроцесса Планирования.
Рисунок 2.2.1: Модель процесса-данных План подпроцесса
Выполнение
Подпроцесс «Внедрение» обеспечивает надлежащую реализацию всех мер, указанных в планах. В ходе подпроцесса «Внедрение» никакие меры не определяются и не изменяются. Определение или изменение мер происходит в подпроцессе «План» совместно с процессом «Управление изменениями».
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Осуществлять | Классификация и управление ИТ-приложениями | Процесс формальной группировки элементов конфигурации по типу, например, программное обеспечение, оборудование, документация, среда и приложение. Процесс формальной идентификации изменений по типу, например, запрос на изменение объема проекта, запрос на изменение проверки, запрос на изменение инфраструктуры, этот процесс приводит к классификации активов и контрольным документам . |
| Обеспечить безопасность персонала | Принимаются меры по обеспечению безопасности и уверенности персонала, а также меры по предотвращению преступления/мошенничества. Процесс завершается обеспечением безопасности персонала . | |
| Внедрение управления безопасностью | Конкретные требования безопасности и/или правила безопасности, которые должны быть выполнены, изложены и документированы. Процесс завершается политиками безопасности . | |
| Внедрить контроль доступа | Конкретные требования безопасности доступа и/или правила безопасности доступа, которые должны быть соблюдены, изложены и задокументированы. Процесс завершается контролем доступа . | |
| Отчетность | Весь процесс внедрения по плану документируется определенным образом. Этот процесс завершается отчетами . |
Левая часть рисунка 2.3.1 — это модель метапроцесса фазы «Реализация». Четыре метки с черной тенью означают, что эти действия являются закрытыми концепциями и не раскрываются в этом контексте. Никакие стрелки не соединяют эти четыре действия, что означает, что эти действия не упорядочены и отчетность будет предоставлена после завершения всех четырех действий.
На этапе внедрения создаются и/или корректируются концепции.
| Концепция | Описание |
|---|---|
| Выполнение | Осуществление управления безопасностью в соответствии с планом управления безопасностью. |
| Документы по классификации и контролю активов | Комплексная инвентаризация активов с распределением ответственности за обеспечение эффективной защиты безопасности. |
| Безопасность персонала | Четко определенные должностные инструкции для всех сотрудников, описывающие роли и обязанности по обеспечению безопасности. |
| Политика безопасности | Документы, в которых изложены конкретные требования безопасности или правила безопасности, которые необходимо соблюдать. |
| Контроль доступа | Управление сетью, гарантирующее, что доступ к информации в сетях имеют только те, кто имеет соответствующую ответственность, а также защита поддерживающей инфраструктуры. |
Концепции, созданные и/или скорректированные, моделируются с использованием техники метамоделирования. Правая сторона рисунка 2.3.1 представляет собой модель метаданных подпроцесса внедрения.
Документы по внедрению являются открытой концепцией и расширяются в этом контексте. Он состоит из четырех закрытых концепций, которые не расширяются, поскольку они не имеют отношения к данному конкретному контексту.
Для того, чтобы сделать отношения между двумя моделями более понятными, интеграция двух моделей проиллюстрирована на рисунке 2.3.1. Пунктирные стрелки, идущие от действий к концепциям, иллюстрируют, какие концепции создаются/корректируются в соответствующих действиях.
Рисунок 2.3.1: Модель процесса-данных. Подпроцесс внедрения
Оценка
Оценка необходима для измерения успешности планов внедрения и безопасности. Оценка важна для клиентов (и, возможно, третьих лиц). Результаты подпроцесса оценки используются для поддержания согласованных мер и внедрения. Результаты оценки могут привести к новым требованиям и соответствующему Запросу на изменение . Затем запрос на изменение определяется и отправляется в Управление изменениями.
Три вида оценки — это самооценка, внутренний аудит и внешний аудит.
Самооценка в основном проводится в организации процессов. Внутренние аудиты проводятся внутренними ИТ-аудиторами. Внешние аудиты проводятся внешними, независимыми ИТ-аудиторами. Помимо уже упомянутых, проводится оценка на основе сообщенных инцидентов безопасности. Наиболее важными видами деятельности для этой оценки являются мониторинг безопасности ИТ-систем; проверка законодательства по безопасности и реализация плана безопасности; отслеживание и реагирование на нежелательное использование ИТ-ресурсов.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Оценивать | Самооценка | Изучить реализованные соглашения по безопасности. Результатом этого процесса являются документы самооценки . |
| Внутренний аудит | Проверка внедренных соглашений о безопасности внутренним аудитором EDP. Результатом этого процесса является внутренний аудит . | |
| Внешний аудит | Проверка внедренных соглашений о безопасности внешним аудитором EDP. Результатом этого процесса является внешний аудит . | |
| Оценка на основе инцидентов безопасности | Изучить реализованные соглашения по безопасности на основе событий безопасности, которые не являются частью стандартной работы сервиса и которые вызывают или могут вызвать прерывание или снижение качества этого сервиса. Результатом этого процесса являются инциденты безопасности . | |
| Отчетность | Документируйте процесс внедрения Evaluate определенным образом. Этот процесс заканчивается отчетами . |
Рисунок 2.4.1: Модель процесса-данных. Подпроцесс оценки
Диаграмма процесса-данных, показанная на рисунке 2.4.1, состоит из модели метапроцесса и модели метаданных. Подпроцесс оценки был смоделирован с использованием техники метамоделирования. Пунктирные стрелки, идущие от диаграммы метапроцесса (слева) к диаграмме метаданных (справа), указывают, какие концепции создаются/корректируются в соответствующих действиях. Все действия на этапе оценки являются стандартными действиями. Краткое описание концепций этапа оценки см. в таблице 2.4.2, где перечислены и определены концепции.
| Концепция | Описание |
|---|---|
| ОЦЕНКА | Оцененная/проверенная реализация. |
| РЕЗУЛЬТАТЫ | Результат оцениваемой реализации. |
| ДОКУМЕНТЫ САМООЦЕНКИ | Результат проверки управления безопасностью организацией самого процесса. |
| ВНУТРЕННИЙ АУДИТ | Результат проверки управления безопасностью внутренним аудитором EDP. |
| ВНЕШНИЙ АУДИТ | Результат проверки управления безопасностью внешним аудитором EDP. |
| ДОКУМЕНТЫ ПО ИНЦИДЕНТАМ БЕЗОПАСНОСТИ | Результаты оценки событий безопасности, которые не являются частью стандартной работы сервиса и которые вызывают или могут вызвать прерывание или снижение качества этого сервиса. |
Таблица 2.4.2: Подпроцесс оценки концепции и определения Управление безопасностью
Обслуживание
Из-за изменений в организационной и ИТ-инфраструктуре риски безопасности со временем меняются, что требует пересмотра раздела безопасности соглашений об уровне обслуживания и планов безопасности.
Техническое обслуживание основано на результатах подпроцесса оценки и понимании изменяющихся рисков. Эти действия дадут предложения. Предложения либо служат входными данными для подпроцесса плана и проходят через цикл, либо могут быть приняты как часть поддержания соглашений об уровне обслуживания. В обоих случаях предложения могут привести к действиям в плане действий. Фактические изменения вносятся процессом управления изменениями.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Поддерживать | Поддержание соглашений об уровне обслуживания | Это поддерживает соглашения об уровне обслуживания в надлежащем состоянии. Процесс заканчивается поддерживаемыми соглашениями об уровне обслуживания . |
| Поддержание соглашений об уровне эксплуатации | Это поддерживает соглашения об уровне эксплуатации в надлежащем состоянии. Процесс заканчивается поддерживаемыми соглашениями об уровне эксплуатации . | |
| Запрос на изменение SLA и/или OLA | Формулируется запрос на изменение SLA и/или OLA. Этот процесс завершается запросом на изменение . | |
| Отчетность | Процесс внедрения политик безопасности документируется определенным образом. Этот процесс завершается отчетами . |
Рисунок 2.5.1 представляет собой диаграмму процесса-данных подпроцесса внедрения. На этом рисунке показана интеграция модели метапроцесса (слева) и модели метаданных (справа). Пунктирные стрелки указывают, какие концепции создаются или корректируются в ходе действий фазы внедрения.
Рисунок 2.5.1: Модель процесса-данных Подпроцесс обслуживания
Подпроцесс обслуживания начинается с обслуживания соглашений об уровне обслуживания и обслуживания соглашений об уровне эксплуатации. После выполнения этих действий (в произвольном порядке) и поступления запроса на изменение будет выполнено действие запроса на изменение, а после завершения действия запроса на изменение начнется действие по отчетности. Если запроса на изменение нет, то действие по отчетности начнется сразу после первых двух действий. Концепции в модели метаданных создаются/корректируются на этапе обслуживания. Список концепций и их определение см. в таблице 2.5.2.
| Концепция | Описание |
|---|---|
| ДОКУМЕНТЫ ПО ОБСЛУЖИВАНИЮ | Соглашения поддерживаются в надлежащем состоянии. |
| СОГЛАШЕНИЯ ОБ УРОВНЕ ОБСЛУЖИВАНИЯ | Соглашения об уровне обслуживания (пункт безопасности) поддерживаются в надлежащем состоянии. |
| СОГЛАШЕНИЯ ОБ ОПЕРАЦИОННОМ УРОВНЕ ПОДДЕРЖИВАЮТСЯ | Соглашения об уровне эксплуатации поддерживаются в надлежащем состоянии. |
| ЗАПРОС НА ИЗМЕНЕНИЕ | Форма или экран, используемый для записи сведений о запросе на внесение изменений в SLA/OLA. |
Таблица 2.5.2: Концепция и определение План подпроцесса Управление безопасностью
Полная модель процесса-данных
Рисунок 2.6.1: Полная модель процесса-данных Процесс управления безопасностью
Связь с другими процессами ITIL
Процесс управления безопасностью, как указано во введении, имеет связь практически со всеми другими процессами ITIL. Этими процессами являются:
- Управление взаимоотношениями с клиентами в сфере ИТ
- Управление уровнем обслуживания
- Управление доступностью
- Управление мощностью
- Управление непрерывностью ИТ-услуг
- Управление конфигурацией
- Управление релизами
- Управление инцидентами и служба поддержки
- Управление проблемами
- Управление изменениями (ITSM)
В рамках этих процессов требуются действия, касающиеся безопасности. За эти действия отвечают соответствующий процесс и его менеджер процесса. Однако Управление безопасностью дает указания соответствующему процессу о том, как структурировать эти действия.
Пример: внутренняя политика электронной почты
Внутренняя электронная почта подвержена многочисленным рискам безопасности, требующим соответствующего плана и политик безопасности. В этом примере для внедрения политик электронной почты используется подход ITIL Security Management.
Формируется группа управления безопасностью, формулируются и доводятся до сведения всех сотрудников и поставщиков руководства по процессу. Эти действия выполняются на этапе контроля.
На следующем этапе планирования формулируются политики. Формулируются политики, специфичные для безопасности электронной почты, и добавляются в соглашения об уровне обслуживания. В конце этого этапа весь план готов к внедрению.
Реализация осуществляется в соответствии с планом.
После внедрения политики оцениваются либо путем самооценки, либо с помощью внутренних или внешних аудиторов.
На этапе обслуживания электронные политики корректируются на основе оценки. Необходимые изменения обрабатываются через запросы на изменение.
Смотрите также
- Услуги по управлению инфраструктурой
- ITIL v3
- Microsoft Операционная Структура
- Система управления информационной безопасностью
- КОБИТ
- Модель зрелости возможностей
- ИСПЛ
Смотрите также
Ссылки
- ^ "ISO/IEC 27001:2005 - Информационные технологии - Методы обеспечения безопасности - Системы управления информационной безопасностью - Требования".
Источники
- Бон ван, Дж. (2004). Управление ИТ-услугами: введение в основы ITIL. Издательство Ван Харен
- Каземье, Жак А.; Овербик, Пол Л.; Питерс, Лук М. (2000). Управление безопасностью, канцелярия.
- Управление безопасностью. (1 февраля 2005 г.). Microsoft
- Це, Д. (2005). Безопасность в современном бизнесе: модель оценки безопасности для практики информационной безопасности. Гонконг: Университет Гонконга.
