Выстраиваем ключевые операционные процессы ИБ — управление инцидентами, уязвимостями и доступами — в единую управляемую систему. Определяем, кто за что отвечает, по какому регламенту действует и как это измеряется. Порядок вместо набора средств защиты, живущих каждое своей жизнью.
Средства защиты можно купить, а процессы — нельзя. Именно из-за отсутствия процессов инциденты разбираются как попало, уязвимости копятся, а у уволившихся остаётся доступ. Мы проектируем процессы так, чтобы система работала, а не только состояла из инструментов.
Организация может иметь антивирус, сканер уязвимостей, SIEM и систему управления доступом — и всё равно оставаться уязвимой. Потому что инструмент без процесса не работает: сканер находит уязвимости, но их никто не устраняет по правилам; SIEM фиксирует инцидент, но неясно, кто и как на него реагирует; система доступа есть, но права раздают и не отзывают вручную и бессистемно.
Процесс — это то, что связывает людей, регламенты и инструменты в работающий механизм: понятно, кто что делает, в какой последовательности, в какие сроки и с каким результатом. Без процессов ИБ держится на отдельных людях и их памяти, а с уходом сотрудника рассыпается.
Проектирование процессов ИБ отвечает на вопрос не «что купить», а «как это должно работать».
GRC — это управление, риск и соответствие (Governance, Risk, Compliance): рамка, в которой ИБ управляется как система, а не как набор разрозненных действий. На операционном уровне эта рамка держится на нескольких ключевых процессах. Три из них — базовые, с них выстраивают управляемость:
Как событие превращается в инцидент и доводится до закрытия: категории и критичность, порядок обнаружения и регистрации, реагирование и эскалация, роли и ответственность, взаимодействие с ИТ и руководством, разбор после инцидента. Отдельно закладываем сроки и порядок уведомлений: для субъектов КИИ — взаимодействие с ГосСОПКА и НКЦКИ, при утечках персональных данных — уведомление Роскомнадзора в установленные сроки (24 и 72 часа).
Как уязвимости находятся и устраняются на регулярной основе: инвентаризация активов, порядок сканирования, приоритизация по реальному риску, сроки устранения (SLA) по уровням критичности, контроль исполнения и эскалация просроченного, порядок работы с уязвимостями, которые нельзя закрыть сразу, — через компенсирующие меры.
Как права выдаются, изменяются и отзываются в течение всего жизненного цикла: ролевая модель на принципе минимальных привилегий, порядок предоставления и согласования, обязательный отзыв при увольнении и смене должности, регулярный пересмотр (ресертификация) прав, контроль и отдельный порядок для привилегированных учётных записей, работа с доступом подрядчиков и сервисных учётных записей.
Смотрим, как процессы работают сейчас — даже если они нигде не описаны. Как реально разбираются инциденты, что происходит с уязвимостями, как раздаются и отзываются доступы. Выявляем разрывы и узкие места.
Проектируем, как процессы должны работать: этапы, входы и выходы, точки принятия решений, сроки. Под ваш масштаб и требования, без переусложнения.
Определяем, кто за что отвечает в каждом процессе. Роли привязываем к функциям, а не к конкретным людям, чтобы процесс переживал кадровые изменения.
Разрабатываем регламенты процессов, порядки действий, шаблоны. Так, чтобы по ним можно было работать, а не положить в стол для проверяющего.
Определяем, как измерять, что процесс работает: сроки реагирования и устранения, охват, доля просроченного. Метрики делают процесс управляемым.
Увязываем процессы между собой и с существующими средствами и процессами: мониторингом, управлением рисками, документацией. Определяем требования к инструментам автоматизации, если они нужны.
Готовим план перехода от текущего состояния к целевому: что менять в первую очередь, как внедрять без остановки текущей работы, как обучить сотрудников.
Сведения о том, как процессы устроены сейчас, даже если не формализованы
Организационная структура: кто занимается ИБ, ИТ, кто принимает решения
Действующие средства защиты и мониторинга
Имеющиеся регламенты и организационно-распорядительные документы, если есть
Применимые требования: КИИ, ГИС, отраслевые, корпоративные
Проблемы, которые хочется решить в первую очередь
Ограничения: штат, бюджет, сроки
Изучаем, как процессы работают фактически, и выявляем разрывы.
Проектируем целевые процессы, роли, метрики, согласуем подход.
Разрабатываем регламенты и документацию, увязываем процессы в контур.
Проходим проект с вами, при необходимости с учётом требований регулятора, дорабатываем.
Передаём комплект и план. При необходимости сопровождаем внедрение и обучаем сотрудников.
Карту текущего состояния процессов с выявленными разрывами
Целевые модели процессов управления инцидентами, уязвимостями и доступами
Ролевую модель: кто за что отвечает, привязка к функциям, а не к людям
Регламенты и порядки действий по каждому процессу
Шаблоны документов: карточки инцидентов, заявки на доступ, реестры
Метрики для контроля работы процессов
Схему увязки процессов в единый GRC-контур
Требования к средствам автоматизации, если они нужны
План перехода от текущего состояния к целевому
Материалы для прохождения аудитов и проверок в части процессов
Зависят от числа процессов и масштаба организации. На объём влияет:
Сколько процессов проектируется: один, два или все три и их связки
Масштаб организации и число площадок
Есть ли что-то формализованное или проектирование с нуля
Нужна ли интеграция с действующими средствами и процессами
Нужно ли сопровождение внедрения и обучение
Разработка ОРД — это документы: политики, положения, приказы. Проектирование процессов — это то, как работа реально устроена: этапы, роли, решения, сроки. Регламенты рождаются из процессов, а не наоборот. Мы делаем и то, и другое, но начинаем с процесса, иначе получаются документы, по которым невозможно работать.
Процессы масштабируются. Маленькой организации не нужен громоздкий регламент, но нужно, чтобы инциденты не терялись, уязвимости устранялись, а у уволившихся отзывали доступ. Проектируем под ваш масштаб — без переусложнения.
Да. Процессы независимы, можно взять один, самый болезненный. Часто начинают с управления доступами или инцидентами. Связки с остальными можно спроектировать позже.
Не обязательно. Процессы могут работать и на простых средствах, а полноценная GRC-платформа оправдана при определённом масштабе. Мы проектируем процесс независимо от инструмента и, если автоматизация нужна, формулируем требования к ней — но не начинаем с покупки платформы.
По метрикам. Для каждого процесса мы задаём измеримые показатели: время реагирования на инцидент, доля уязвимостей, устранённых в срок, доля вовремя отозванных доступов, объём просроченного. Если показатели собираются и держатся в целевых значениях — процесс работает; если регламент есть, а метрики никто не считает, это документ, а не процесс.
В этом и смысл: роли привязаны к функциям, а не к людям, действия описаны в регламентах. При уходе сотрудника его роль передаётся другому без потери процесса. Это одна из главных причин формализовать процессы.
Расскажите, что болит — инциденты разбираются как попало, уязвимости копятся, доступы никто не пересматривает или всё вместе. Проведём обследование и предложим целевую модель и план.