Что такое управление информационной безопасностью в ИТ-службе

Зачем управление информационной безопасностью

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 защищает сведения, которые нужны организации, чтобы вести дело: понимает и снижает риски для их конфиденциальности, целостности и доступности, а заодно отвечает за подлинность и неотказуемость 1.

ГОСТ Р ИСО/МЭК 20000-1 требует того же обязанностями. Политику утверждает руководство, она записана и доведена до всех: людей организации, потребителей, пользователей, внешних и внутренних поставщиков. Риски оценивают в заранее назначенные сроки. Средства управления определены, внедрены и работают, а решения по ним записаны 2.

Трудность практики описана без прикрас: рост цифровых услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation, облачные решения и связки с системами партнёров и потребителей создают новые зависимости, где возможности контролировать сбор, хранение и использование сведений ограничены 1. Партнёры вкладываются в защиту не меньше — но нехватка согласованности между организациями сама создаёт новые уязвимости 1.

Неверные сведения бывают хуже, чем их отсутствие: если банк ошибочно считает, что на счёте клиента есть крупная сумма, и позволяет её снять, потери реальны 1.

Когда практика работает

Три вопроса, ответы на которые видны в поведении людей, а не в наличии политики.

Политика известна тем, кого касается. Как проверить: сотрудники, подрядчики и партнёры знают правила, относящиеся к их работе, — стандарт требует доводить это до всех перечисленных сторон 2.

Меры выбраны под риски, а не куплены по каталогу. Как проверить: по каждой значимой мере видно, какой риск она снижает 2.

Инциденты безопасности ведутся как отдельный поток. Как проверить: их регистрируют, размечают, расставляют по приоритету с учётом рисков, эскалируют, решают и закрывают 2.

Что входит и что рядом

Пять свойств, за которые отвечает практика

Определения, которые полезно держать в одном месте 1.

Конфиденциальность — сведения не раскрываются и не становятся доступными тем, кому не положено.

Целостность — сведения верны, и менять их могут только те, кому это разрешено, и только разрешёнными действиями.

Доступность — сведениями можно воспользоваться, когда они нужны. Отдельно оговорено: это не то же самое, что доступность услуги: там своя мера, здесь речь именно о сведениях 1.

Подлинность — подтверждение того, что заявленное свойство или признак действительно таков; так устанавливают, что человек или система — те, за кого себя выдают.

Неотказуемость — неопровержимое доказательство, что событие произошло или действие было выполнено, и выполнено именно этим участником. До появления ИТ ту же роль играла подпись, а при необходимости — заверенная нотариусом 1.

Последние два свойства обычно вспоминают позже остальных, а именно они делают возможными сделки и обязательства.

Что на входе и что на выходе

Практика получает сведения о ценностях, угрозах и уязвимостях, отдаёт правила и требования, которые становятся частью чужой работы. Согласованные меры безопасности часто внедряются в составе других практик 1.

Отсюда главный признак зрелости: требования безопасности появляются в проектировании и разработке, а не в виде замечаний на приёмке.

Ценности, угрозы и уязвимости

ЦенностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation определена просто: всё, что представляет ценность для организации, — техника, программы, сети, сведения, люди, процессы, услуги, здания 1. Практика защищает их, чтобы организация могла вести дело 1.

Дальше работают три вопроса, на которые отвечает оценка рисков:

• что мы защищаем — какие сведения и системы важны и почему;
• от кого и от чего — какие угрозы реальны для нас, а не вообще;
• где мы уязвимы — какие слабости позволяют угрозе сработать.

ГОСТ Р ИСО/МЭК 20000-1 требует оценивать риски в заранее назначенные сроки и записывать оценку 2 — то есть это не разовая работа при внедрении, а повторяющийся цикл.

Что делают с риском

Способов четыре, и они одинаковы для безопасности и для рисков вообще 1:

Ключевое слово в последней строке — «сознательно». Стандарт требует документировать решения по мерам управления 2; принятый риск, о котором нигде не записано, отличается от непринятого только тем, что кто-то однажды о нём подумал.

Как это работает

Цвет шага: техническая работа решение и полномочия проверка, разбор, улучшение работа с людьми и сторонами

Два места стоит объяснить отдельно.

Четвёртый шаг определяет всё. Названо встраивание безопасности во все части системы создания ценности отдельным фактором успеха 1. Практика, живущая отдельной службой с правом вето, получает обходные путиОбходное решениеСпособ снизить или устранить последствия инцидента, когда полного решения ещё нет.ITIL 4, практическое руководство по управлению инцидентами вместо соблюдения.

Седьмой шаг почти всегда пропускают. Выделена проверку и испытание планов в отдельный фактор успеха 1: план реагирования, который никто не проверял, в день инцидентаИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами работает примерно как ненастроенный откат.

Инциденты безопасности

Стандарт задаёт им отдельный порядок и называет шаги: регистрация и классификация, расстановка приоритетов с учётом рисков безопасности, эскалация при необходимости, разрешение, закрытие 2. Плюс требование анализировать их по типу, объёму и воздействию на систему управления, услуги и заинтересованные стороны, отчитываться и искать возможности для улучшения 2.

Практический смысл отдельного порядка: у инцидента безопасности другой набор участников, другие сроки уведомления и часто внешние обязательства — от требований регуляторов до условий договоров.

Что с чем путают

Безопасность сведений и доступность услуги. ITIL оговаривает это прямо: доступность сведений — не то же самое, что доступность услуги, и меры у них разные 1.

Безопасность и управление доступом. Права в системах — техническая часть; практика отвечает за то, какие правила этих прав и почему.

Безопасность и риски вообще. Понятия и способы обработки общие 1, но предмет разный: здесь риски для сведений, там — для целей организации.

Политика и соблюдение. Написанная политика — условие; работающая практика начинается там, где люди знают её и следуют ей в повседневной работе 2.

Кто участвует

Как измерять

Рядом держат две меры: число инцидентов и время обнаружения. Спокойная картина при долгом обнаружении означает не безопасность, а слепоту.

Мало найденных рисков — плохая новость, а не хорошая. У Брукса число найденных за период рисков и новых угроз идёт с целью 10 при тревоге в 5 5: опасное значение ниже целевого, потому что тревожит недобор. Оговорка у него честная: выдумать риск там, где его нет, нельзя; но в сколько-нибудь сложной среде новые находятся каждую неделю или хотя бы раз в месяц, и тишина означает, что их просто не ищут. Тем же устроены решённые находки проверок: цель 8, тревога 5.

Раздел о безопасности в договоре проверяется сравнением, а не наличием. Доля соглашений об уровне услуг, где вопросы безопасности оговорены явно: цель 100%, тревога 70; у внешних договоров — те же 100% при тревоге в 75 5. Ключевое в спецификации: пункты не должны быть шаблонными, и проверяется это сличением текстов между договорами. Там же оговорка, снимающая соблазн: если соглашения не меняются, метрика бесполезна — считать её имеет смысл на потоке новых и перезаключаемых.

Откат по соображениям безопасности — не победа контроля, а его провал. Число изменений, отменённых с возвратом системы в исходное состояние: цель 0 при тревоге в 5 5. Логика прямая — раз до этого дошло, значит изменение плохо спланировали и проверили. Рядом стоит требование, которое стоит перенести целиком: каждое такое изменение положено исследовать всесторонне, чтобы исключить преднамеренную атаку. Столько же — ноль при тревоге в пять — у проблемПроблемаПричина одного или нескольких инцидентов.ITIL безопасности, которые нашлись уже в релизах. Выпуск Брукс называет самым уязвимым местом, особенно когда он срочный: RLSУправление релизами.

У скорости установки исправлений есть срок. От выпуска патча поставщиком до его установки в промышленной среде: цель два дня, тревога неделя 5. Это тот редкий случай, когда число из книги 2008 года читается сегодня почти без поправки. Остальные её значения Брукс сам называет образцами для настройки и советует уточнять их сравнением с другими: они зависят от уровня контроля и от качества программ.

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

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Политика есть, о ней не знают. Стандарт требует доводить её до организации, потребителей, пользователей и поставщиков 2.

Меры куплены до оценки рисков. Средства защиты выбраны по каталогу, а связь с реальными угрозами не прослеживается 2.

Безопасность приходит на приёмке. Требования появляются, когда решение построено, и превращаются в доработки 1.

Планы не проверялись. Реагирование описано, учений не было 1.

Инциденты безопасности растворены в общем потоке. Приоритет ставится по влиянию на услугу, а не по риску для сведений 2.

Поставщики вне периметра. Требования к внешним организациям не согласованы, хотя стандарт этого требует 2.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит безопасность отдельной практикой с четырьмя факторами успеха: политика и планы, снижение рисков, проверка планов учениями и встраивание безопасности во все части работы 1.

ГОСТ Р ИСО/МЭК 20000-1 требует политики, оценки рисков через интервалы, документированных решений по мерам, согласования требований с внешними организациями, наблюдения за результативностью и отдельного порядка для инцидентов безопасности 2. Он же отсылает к семейству стандартов по системам управления информационной безопасностью 2.

COBIT выделяет управление безопасностью отдельной целью 3.

FitSM укладывает то же в несколько требований к политике, рискам и мерам 4.

Вывод для практики: своды управления услугами задают рамку, а содержание мер берётся из специализированных стандартов безопасности — ITIL прямо на них ссылается 1.

Где описано

Что почитать дальше

Три соседние практики, с которыми безопасность работает вплотную: RSKУправление рисками — общий язык рисков, CONУправление непрерывностью услуг — что делать при катастрофе, IAMУправление ИТ-активами — учёт того, что защищаем.