Управление безопасностью ITIL - Википедия - ITIL security management
 | Эта статья нужны дополнительные цитаты для проверка. (Август 2016 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
Управление безопасностью ITIL описывает структурированное приспособление безопасности к организации. ITIL управление безопасностью основано на стандарте ISO 27001. «ISO / IEC 27001: 2005 охватывает все типы организаций (например, коммерческие предприятия, государственные учреждения, некоммерческие организации).[1] ISO / IEC 27001: 2005 определяет требования для создания, внедрения, эксплуатации, мониторинга, анализа, поддержки и улучшения документированной системы управления информационной безопасностью в контексте общих бизнес-рисков организации. Он определяет требования к реализации мер безопасности, адаптированных к потребностям отдельных организаций или их частей. ISO / IEC 27001: 2005 разработан для обеспечения выбора адекватных и соразмерных мер безопасности, которые защищают информационные активы и вселяют уверенность в заинтересованные стороны ».
Базовая концепция управления безопасностью: информационная безопасность. Основная цель информационной безопасности - контролировать доступ к информации. Ценность информации - это то, что необходимо защищать. Эти значения включают конфиденциальность, честность и доступность. Предполагаемые аспекты - это конфиденциальность, анонимность и проверяемость.
Задача управления безопасностью состоит из двух частей:
- Безопасность требования, определенные в соглашения об уровне обслуживания (SLA) и другие внешние требования, указанные в подкрепляющих договорах, законодательстве и возможных внутренних или внешних навязанных политиках.
- Базовая безопасность, гарантирующая непрерывность управления. Это необходимо для достижения упрощенного управления уровнем обслуживания для информационной безопасности.
SLA определяют требования безопасности, а также законодательство (если применимо) и другие контракты. Эти требования могут действовать как ключевые показатели эффективности (KPI), которые могут использоваться для управления процессами и для интерпретации результатов процесса управления безопасностью.
Процесс управления безопасностью относится к другим ITIL-процессам. Однако именно в этом разделе наиболее очевидными отношениями являются отношения к управление уровнем обслуживания, управление происшествиями и управление изменениями процессы.
Управление безопасностью
Управление безопасностью - это непрерывный процесс, который можно сравнить с У. Эдвардс Деминг Круг качества (Планируйте, делайте, проверяйте, действуйте ).
Входы - это требования клиентов. Требования переводятся в сервисы безопасности и показатели безопасности. И клиент, и подпроцесс плана влияют на SLA. SLA - это вход как для клиента, так и для процесса. Провайдер разрабатывает планы безопасности для организации. Эти планы содержат политики и соглашения об уровне эксплуатации. Затем планы безопасности (План) реализуются (Выполнить), и реализация затем оценивается (Проверка). После оценки планы и выполнение плана сохраняются (Акт).
Действия, результаты / продукты и процесс документируются. Внешние отчеты пишутся и отправляются клиентам. После этого клиенты могут адаптировать свои требования на основе информации, полученной через отчеты. Кроме того, поставщик услуг может скорректировать свой план или реализацию на основе своих выводов, чтобы удовлетворить все требования, изложенные в SLA (включая новые требования).
Контроль
Первым действием в процессе управления безопасностью является подпроцесс «Контроль». Подпроцесс управления организует и управляет процессом управления безопасностью. Подпроцесс управления определяет процессы, распределение ответственности за заявления о политике и структуру управления.
Структура управления безопасностью определяет подпроцессы для разработки, внедрения и оценки в планы действий. Кроме того, структура управления определяет, как результаты должны сообщаться клиентам.
| Деятельность | Под-мероприятия | Описания |
|---|---|---|
| Контроль | Реализуйте политики | В этом процессе излагаются определенные требования и правила, которые должны быть соблюдены для реализации управления безопасностью. Процесс заканчивается заявление о политике. |
| Настроить охранную организацию | Этот процесс настраивает организации для информационная безопасность. Например, в этом процессе устанавливается структура ответственности. Этот процесс заканчивается структура управления безопасностью. | |
| Составление отчетов | В этом процессе определенным образом документируется весь процесс нацеливания. Этот процесс заканчивается отчеты. |
Модель метапроцесса подпроцесса управления основана на UML диаграмма деятельности и дает обзор деятельности подпроцесса управления. Серый прямоугольник представляет подпроцесс управления, а меньшие формы лучей внутри него представляют действия, которые происходят внутри него.
| Концепция | Описание |
|---|---|
| Контрольные документы | Контроль - это описание того, как организовано управление безопасностью и как им управляют. |
| Заявления о политике | В заявлениях о политике излагаются конкретные требования или правила, которые необходимо соблюдать. в информационная безопасность области политики обычно привязаны к конкретным точкам, охватывая одну область. Например, политика «допустимого использования» охватывает правила и положения для надлежащего использования вычислительных средств. |
| Структура управления безопасностью | Структура управления безопасностью - это установленная структура управления для инициирования и контроля внедрения информационной безопасности в организации, а также для управления текущим обеспечением информационной безопасности. |
Модель метаданных подпроцесса управления основана на UML. диаграмма классов. На рисунке 2.1.2 показана метамодель подпроцесса управления.
Рисунок 2.1.2: Подпроцесс управления моделью метапроцесса
Прямоугольник CONTROL с белой тенью - открытая сложная концепция. Это означает, что прямоугольник Control состоит из набора (под) концепций.
На рисунке 2.1.3 представлена модель данных процесса подпроцесса управления. Он показывает интеграцию двух моделей. Пунктирные стрелки указывают на концепции, которые создаются или корректируются в соответствующих действиях.
Рисунок 2.1.3: Подпроцесс управления моделью данных процесса
Строить планы
Подпроцесс плана содержит действия, которые в сотрудничестве с управление уровнем обслуживания перейдите в раздел (информационная) Безопасность в SLA. Более того, подпроцесс «Планирование» содержит действия, связанные с базовыми контрактами, которые относятся к (информационной) безопасности.
В подпроцессе «Планирование» цели, сформулированные в SLA, указываются в форме соглашений об операционном уровне (OLA). Эти OLA могут быть определены как планы безопасности для определенного внутреннего организационного объекта поставщика услуг.
Помимо ввода SLA, подпроцесс Plan также работает с заявлениями о политике самого поставщика услуг. Как было сказано ранее, эти заявления политики определяются в подпроцессе управления.
Соглашения об операционном уровне для информационная безопасность созданы и внедрены на основе процесса 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: Модель данных процесса Подпроцесс реализации
Оценка
Оценка необходима для измерения успешности реализации планов безопасности. Оценка важна для клиентов (и, возможно, третьих лиц). Результаты подпроцесса оценки используются для поддержания согласованных мер и выполнения. Результаты оценки могут привести к новым требованиям и соответствующему Запрос на изменение. Затем определяется запрос на изменение и отправляется в Управление изменениями.
Есть три вида оценки: самооценка, внутренний аудит и внешний аудит.
Самооценка в основном проводится при организации процессов. Внутренний аудит проводят внутренние IT-аудиторы. Внешний аудит проводится внешними независимыми IT-аудиторами. Помимо уже упомянутых, выполняется оценка на основе сообщенных инцидентов безопасности. Наиболее важными действиями для этой оценки являются мониторинг безопасности ИТ-систем; проверка соблюдения законодательства о безопасности и выполнения плана безопасности; отслеживать и реагировать на нежелательное использование ИТ-материалов.
| Деятельность | Под-мероприятия | Описания |
|---|---|---|
| Оценивать | Самооценка | Изучите выполненные соглашения о безопасности. Результатом этого процесса является документы самооценки. |
| Внутренняя ревизия | Изучите выполненные соглашения о безопасности внутренним аудитором 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.
Сформирована группа управления безопасностью, сформулированы руководящие принципы процесса и доведены до сведения всех сотрудников и поставщиков. Эти действия выполняются на этапе управления.
На следующем этапе планирования формулируются политики. Политики, относящиеся к безопасности электронной почты, формулируются и добавляются в соглашения об уровне обслуживания. В конце этого этапа весь план готов к реализации.
Реализация осуществляется по плану.
После внедрения политики оцениваются либо как самооценка, либо через внутренних или внешних аудиторов.
На этапе обслуживания электронные политики корректируются на основе оценки. Необходимые изменения обрабатываются через запросы на изменение.
Смотрите также
- Услуги по управлению инфраструктурой
- ITIL v3
- Microsoft Operations Framework
- Система управления информационной безопасностью
- COBIT
- Модель зрелости возможностей
- ISPL
Смотрите также
Рекомендации
Источники
- Бон ван, Дж. (2004). Управление ИТ-услугами: введение на основе ITIL. Издательство Ван Харен
- Cazemier, Jacques A .; Overbeek, Paul L .; Питерс, Лук М. (2000). Управление безопасностью, канцелярские принадлежности.
- Управление безопасностью. (1 февраля 2005 г.). Microsoft
- Це, Д. (2005). Безопасность в современном бизнесе: модель оценки безопасности практик информационной безопасности. Гонконг: Университет Гонконга.