Управление безопасностью ITIL
 | Эта статья нуждается в дополнительных цитатах для проверки . ( август 2016 г. ) |
Управление безопасностью ITIL описывает структурированную интеграцию безопасности в организацию. Управление безопасностью ITIL основано на стандарте ISO 27001. «ISO/IEC 27001:2005 охватывает все типы организаций (например, коммерческие предприятия, государственные учреждения, некоммерческие организации). [1] ISO/IEC 27001:2005 определяет требования к созданию, внедрению, эксплуатации, мониторингу, анализу, поддержанию и совершенствованию документированной системы управления информационной безопасностью в контексте общих бизнес-рисков организации. Он определяет требования к реализации мер безопасности, адаптированных к потребностям отдельных организаций или их частей. ISO/IEC 27001:2005 разработан для обеспечения выбора адекватных и соразмерных мер безопасности, которые защищают информационные активы и вселяют уверенность заинтересованным сторонам».
Базовой концепцией управления безопасностью является информационная безопасность . Основной целью информационной безопасности является контроль доступа к информации. Ценность информации – это то, что необходимо защищать. Эти ценности включают конфиденциальность , целостность и доступность . Предполагаемыми аспектами являются конфиденциальность, анонимность и проверяемость.
Цель управления безопасностью состоит из двух частей:
- Требования безопасности , определенные в соглашениях об уровне обслуживания (SLA), и других внешних требованиях, которые указаны в лежащих в основе контрактах, законодательстве и возможных внутренних или внешних навязанных политиках.
- Базовая безопасность, гарантирующая непрерывность управления. Это необходимо для достижения упрощенного управления уровнем обслуживания для информационной безопасности.
Соглашения об уровне обслуживания определяют требования безопасности, а также законодательство (если применимо) и другие контракты. Эти требования могут выступать в качестве ключевых показателей эффективности (KPI), которые можно использовать для управления процессами и для интерпретации результатов процесса управления безопасностью.
Процесс управления безопасностью связан с другими ITIL-процессами. Однако в этом конкретном разделе наиболее очевидными являются отношения к процессам управления уровнем обслуживания , управления инцидентами и управления изменениями .
Управление безопасностью [ править ]
Управление безопасностью — это непрерывный процесс, который можно сравнить с У. Эдвардса Деминга Кругом качества (« Планируй, делай, проверяй, действуй »).
Входные данные — это требования клиентов. Требования преобразуются в услуги безопасности и метрики безопасности. И клиент, и подпроцесс планирования влияют на SLA. SLA является исходной информацией как для клиента, так и для процесса. Провайдер разрабатывает планы обеспечения безопасности организации. Эти планы содержат политику и соглашения на оперативном уровне. Затем планы безопасности (План) реализуются (Выполнить), а затем их реализация оценивается (Проверить). После оценки планы и их выполнение сохраняются (Закон).
Деятельность, результаты/продукты и процесс документируются. Внешние отчеты пишутся и отправляются клиентам. Затем клиенты могут адаптировать свои требования на основе информации, полученной из отчетов. Более того, поставщик услуг может скорректировать свой план или реализацию на основе своих выводов, чтобы удовлетворить все требования, указанные в соглашении об уровне обслуживания (включая новые требования).
Контроль [ править ]
Первым действием в процессе управления безопасностью является подпроцесс «Контроль». Подпроцесс «Контроль» организует и управляет процессом управления безопасностью. Подпроцесс «Контроль» определяет процессы, распределение ответственности за политические заявления и структуру управления.
Структура управления безопасностью определяет подпроцессы разработки, внедрения и оценки планов действий. Кроме того, структура управления определяет, как результаты должны сообщаться клиентам.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Контроль | Реализация политик | В этом процессе описываются конкретные требования и правила, которые необходимо соблюдать для реализации управления безопасностью. Процесс заканчивается заявлением о политике . |
| Настроить охранную организацию | Этот процесс настраивает организации на информационную безопасность . Например, в этом процессе устанавливается структура ответственности. Этот процесс заканчивается структурой управления безопасностью . | |
| Отчетность | В этом процессе весь процесс определения цели документируется особым образом. Этот процесс завершается отчетами . |
Модель метапроцесса подпроцесса управления основана на UML диаграмме действий и дает обзор действий подпроцесса управления. Серый прямоугольник представляет подпроцесс управления, а меньшие формы лучей внутри него представляют действия, которые происходят внутри него.
| Концепция | Описание |
|---|---|
| Контрольные документы | Контроль – это описание того, как организовано управление безопасностью и как оно управляется. |
| Политические заявления | Политические заявления определяют конкретные требования или правила, которые должны соблюдаться. В сфере информационной безопасности политики обычно специфичны и охватывают одну область. Например, политика «приемлемого использования» охватывает правила и положения надлежащего использования вычислительных средств. |
| Структура управления безопасностью | Структура управления безопасностью — это установленная структура управления, позволяющая инициировать и контролировать реализацию информационной безопасности внутри организации, а также управлять текущим обеспечением информационной безопасности. |
Модель метаданных подпроцесса управления основана на диаграмме классов UML . На рисунке 2.1.2 показана метамодель подпроцесса управления.
Рисунок 2.1.2: Подпроцесс управления моделью метапроцесса
Прямоугольник CONTROL с белой тенью – это открытая комплексная концепция. Это означает, что прямоугольник управления состоит из набора (под)концепций.
На рисунке 2.1.3 представлена модель данных процесса подпроцесса управления. Это показывает интеграцию двух моделей. Пунктирные стрелки указывают концепции, которые создаются или корректируются в соответствующих видах деятельности.
Рисунок 2.1.3: Подпроцесс управления моделью данных процесса
План [ править ]
Подпроцесс «Планирование» содержит действия, которые в сочетании с управлением уровнем обслуживания приводят к разделу (информационной) безопасности в SLA. Кроме того, подпроцесс «Планирование» содержит действия, связанные с базовыми контрактами, специфичными для (информационной) безопасности.
В подпроцессе «Планирование» цели, сформулированные в SLA, конкретизируются в форме соглашений оперативного уровня (OLA). Эти OLA можно определить как планы безопасности для конкретной внутренней организации поставщика услуг.
Помимо ввода SLA, подпроцесс «Планирование» также работает с заявлениями о политике самого поставщика услуг. Как было сказано ранее, эти заявления политики определяются в подпроцессе управления.
Соглашения эксплуатационного уровня по информационной безопасности создаются и реализуются на основе процесса ITIL. Это требует сотрудничества с другими процессами ITIL. Например, если руководство безопасности желает изменить ИТ-инфраструктуру для повышения безопасности, эти изменения будут выполнены посредством процесса управления изменениями . Управление безопасностью предоставляет входные данные (запрос на изменение) для этого изменения. Менеджер по изменениям отвечает за процесс управления изменениями.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| План | Создать раздел «Безопасность» для SLA | Этот процесс содержит действия, которые приводят к параграфу соглашений о безопасности в соглашениях об уровне обслуживания. В конце этого процесса «Безопасность» создается раздел соглашения об уровне обслуживания. |
| Создайте подтверждающие контракты | Этот процесс включает в себя действия, которые приводят к заключению контрактов. Эти контракты предназначены для обеспечения безопасности. | |
| Создание соглашений на оперативном уровне | Общие сформулированные в SLA цели конкретизируются в соглашениях оперативного уровня. Эти соглашения можно рассматривать как планы безопасности для конкретных подразделений организации. | |
| Отчетность | В этом процессе весь процесс создания плана документируется особым образом. Этот процесс заканчивается отчетами. |
План состоит из комбинации неупорядоченных и упорядоченных (под) мероприятий. Подпроцесс содержит три сложных действия, которые являются закрытыми, и одно стандартное действие.
| Концепция | Описание |
|---|---|
| План | Сформулированы схемы соглашений об обеспечении. |
| Раздел безопасности соглашений об уровне безопасности | Параграф соглашений о безопасности в письменных соглашениях между поставщиком услуг и клиентом(ами), в которых документируется согласованный уровень обслуживания для услуги. |
| Подкрепление контрактов | Контракт с внешним поставщиком, охватывающий предоставление услуг, которые поддерживают ИТ-организацию в предоставлении услуг. |
| Соглашения оперативного уровня | Внутреннее соглашение, охватывающее предоставление услуг, которые поддерживают ИТ-организацию в предоставлении услуг. |
Как и подпроцесс «Контроль», подпроцесс «Планирование» моделируется с использованием метода метамоделирования. Левая часть рисунка 2.2.1 представляет собой модель метаданных подпроцесса «Планирование».
Прямоугольник Плана — это открытое (сложное) понятие, имеющее тип связи с двумя закрытыми (сложными) понятиями и одним стандартным понятием. Две закрытые концепции не расширяются в данном конкретном контексте.
На следующем рисунке (рис. 2.2.1) представлена диаграмма данных процесса подпроцесса «План». На этом рисунке показана интеграция двух моделей. Пунктирные стрелки указывают, какие концепции создаются или корректируются в соответствующих действиях подпроцесса «Планирование».
Рисунок 2.2.1: Подпроцесс «Планирование модели данных процесса»
Реализация [ править ]
Подпроцесс реализации гарантирует, что все меры, указанные в планах, реализуются должным образом. В ходе подпроцесса реализации никакие меры не определяются и не изменяются. Определение или изменение мер происходит в подпроцессе Планирования в сотрудничестве с Процессом управления изменениями.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Осуществлять | Классификация и управление ИТ-приложениями | Процесс формальной группировки элементов конфигурации по типу, например, программное обеспечение, аппаратное обеспечение, документация, среда и приложение. Процесс формальной идентификации изменений по типу, например, запрос на изменение содержания проекта, запрос на изменение проверки, запрос на изменение инфраструктуры. Этот процесс приводит к классификации активов и контрольным документам . |
| Внедрить кадровую безопасность | Принимаются меры по обеспечению безопасности и уверенности персонала, а также меры по предотвращению преступлений/мошенничества. Завершается процесс кадровой безопасностью . | |
| Внедрить управление безопасностью | Конкретные требования безопасности и/или правила безопасности, которые должны соблюдаться, изложены и документированы. Процесс завершается политикой безопасности . | |
| Внедрить контроль доступа | Конкретные требования безопасности доступа и/или правила безопасности доступа, которые должны соблюдаться, изложены и документированы. Процесс завершается контролем доступа . | |
| Отчетность | Весь запланированный процесс документируется определенным образом. Этот процесс завершается отчетами . |
Левая часть рисунка 2.3.1 представляет собой модель метапроцесса этапа реализации. Четыре метки с черной тенью означают, что эти виды деятельности представляют собой закрытые концепции и не расширяются в данном контексте. Никакие стрелки не соединяют эти четыре действия, а это означает, что эти действия не упорядочены, и отчетность будет осуществляться после завершения всех четырех действий.
На этапе реализации концепции создаются и/или корректируются.
| Концепция | Описание |
|---|---|
| Выполнение | Осуществление управления безопасностью согласно плану управления безопасностью. |
| Документы по классификации и контролю активов | Комплексная инвентаризация активов с назначением ответственности за обеспечение эффективной защиты безопасности. |
| Кадровая безопасность | Четко определенные должностные инструкции для всех сотрудников с указанием ролей и обязанностей в сфере безопасности. |
| Политики безопасности | Документы, в которых излагаются конкретные требования безопасности или правила безопасности, которые должны соблюдаться. |
| Контроль доступа | Управление сетью для обеспечения того, чтобы только те, кто несет соответствующую ответственность, имели доступ к информации в сетях и защиту поддерживающей инфраструктуры. |
Созданные и/или скорректированные концепции моделируются с использованием техники метамоделирования. Правая часть рисунка 2.3.1 представляет собой модель метаданных подпроцесса реализации.
Документы по реализации представляют собой открытую концепцию и в этом контексте расширяются. Он состоит из четырех закрытых понятий, которые не расширяются, поскольку неактуальны в данном конкретном контексте.
Чтобы сделать отношения между двумя моделями более ясными, интеграция двух моделей показана на рисунке 2.3.1. Пунктирные стрелки, идущие от действий к концепциям, показывают, какие концепции создаются/корректируются в соответствующих действиях.
Рисунок 2.3.1: Подпроцесс реализации модели данных процесса
Оценка [ править ]
Оценка необходима для измерения успешности планов реализации и обеспечения безопасности. Оценка важна для клиентов (и, возможно, третьих лиц). Результаты подпроцесса оценки используются для поддержания согласованных мер и их реализации. Результаты оценки могут привести к появлению новых требований и соответствующему запросу на изменение . Затем определяется запрос на изменение и отправляется в Управление изменениями.
Тремя видами оценки являются самооценка, внутренний аудит и внешний аудит.
Самооценка в основном осуществляется при организации процессов. Внутренние аудиты проводятся внутренними ИТ-аудиторами. Внешний аудит проводится внешними независимыми ИТ-аудиторами. Помимо уже упомянутых, проводится оценка на основе сообщенных инцидентов безопасности. Наиболее важными мероприятиями для этой оценки являются мониторинг безопасности ИТ-систем; проверять выполнение законодательства в области безопасности и плана обеспечения безопасности; отслеживать и реагировать на нежелательное использование ИТ-материалов.
| Деятельность | Подвиды деятельности | Описания |
|---|---|---|
| Оценивать | Самооценка | Изучите реализованные соглашения по безопасности. Результатом этого процесса являются документы самооценки . |
| Внутренний аудит | Проверка реализованных соглашений о безопасности внутренним аудитором EDP. Результатом этого процесса является внутренний аудит . | |
| Внешний аудит | Проверка реализованных соглашений о безопасности внешним аудитором EDP. Результатом этого процесса является внешний аудит . | |
| Оценка на основе инцидентов безопасности | Изучите реализованные соглашения о безопасности, основанные на событиях безопасности, которые не являются частью стандартной работы службы и которые вызывают или могут вызвать прерывание или снижение качества этой службы. Результатом этого процесса являются инциденты безопасности . | |
| Отчетность | Особым образом задокументируйте процесс реализации оценки. Этот процесс завершается отчетами . |
Рисунок 2.4.1: Подпроцесс оценки модели данных процесса
Диаграмма данных процесса, показанная на рисунке 2.4.1, состоит из модели метапроцесса и модели метаданных. Подпроцесс оценки был смоделирован с использованием метода метамоделирования.Пунктирные стрелки, идущие от диаграммы метапроцесса (слева) к диаграмме метаданных (справа), указывают, какие концепции создаются/корректируются в соответствующих действиях. Все действия на этапе оценки являются стандартными. Краткое описание концепций этапа оценки см. в Таблице 2.4.2, где эти концепции перечислены и определены.
| Концепция | Описание |
|---|---|
| ОЦЕНКА | Оценена/проверена реализация. |
| РЕЗУЛЬТАТЫ | Результат оцениваемой реализации. |
| ДОКУМЕНТЫ ДЛЯ САМООЦЕНКИ | Результат проверки управления безопасностью организацией самого процесса. |
| ВНУТРЕННИЙ АУДИТ | Результат проверки управления безопасностью внутренним аудитором 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. Эти процессы:
- Управление взаимоотношениями с ИТ-клиентами
- Управление уровнем обслуживания
- Управление доступностью
- Управление мощностями
- Управление непрерывностью ИТ-услуг
- Управление конфигурацией
- Управление релизами
- Управление инцидентами и служба поддержки
- Управление проблемами
- Управление изменениями (ИТСМ)
В рамках этих процессов необходимы действия, касающиеся безопасности. За эти действия несут ответственность соответствующий процесс и его менеджер процесса. Тем не менее, Управление безопасностью дает указания относительно того, как структурировать эту деятельность.
Пример: внутренние политики электронной почты [ править ]
Внутренняя электронная почта подвержена множеству рисков безопасности, требующих соответствующего плана и политик безопасности. В этом примере для реализации политик электронной почты используется подход управления безопасностью ITIL.
Формируется команда управления безопасностью, формулируются руководящие принципы процесса и доводятся до сведения всех сотрудников и поставщиков. Эти действия выполняются на этапе контроля.
На последующем этапе планирования формулируется политика. Политики безопасности электронной почты формулируются и добавляются в соглашения об уровне обслуживания. В конце этого этапа весь план готов к реализации.
Реализация осуществляется согласно плану.
После реализации политика оценивается либо путем самооценки, либо с помощью внутренних или внешних аудиторов.
На этапе обслуживания электронная политика корректируется на основе оценки. Необходимые изменения обрабатываются посредством запросов на изменение.
См. также
- Услуги по управлению инфраструктурой
- ИТИЛ v3
- Платформа операций Microsoft
- Система управления информационной безопасностью
- КОБИТ
- Модель зрелости возможностей
- ИСПЛ
См. также [ править ]
Ссылки [ править ]
Источники [ править ]
- Бон ван, Дж. (2004). Управление ИТ-услугами: введение на основе ITIL. Издательство Ван Харен
- Каземье, Жак А.; Овербек, Пол Л.; Питерс, Лук М. (2000). Управление безопасностью, Канцелярия.
- Управление безопасностью . (1 февраля 2005 г.). Майкрософт
- Це, Д. (2005). Безопасность в современном бизнесе: модель оценки безопасности для практики информационной безопасности. Гонконг: Университет Гонконга.