Оценка уровня зрелости кибербезопасности компании по методике Группы Сбер

Уровень 1

1.1

Назначен ответственный за КБ, имеющий трудовые отношения с компанией (как минимум выполняет роль по совместительству, может быть назначен специалист, не имеющий руководящего опыта).

1.2

Определён круг обязанностей ответственного за КБ, например, в трудовом договоре и/или должностной инструкции.

Уровень 2

2.1

Создана роль CISO (руководитель подразделения кибербезопасности), документально определены обязанности CISO.

2.2

Руководитель подразделения кибербезопасности (CISO) подчиняется непосредственно руководителю компании (CEO).

2.3

Для работников, ответственных за обеспечение КБ, документально определены должностные обязанности и ответственность за их исполнение. С должностными обязанностями ознакомлены под подпись все работники, ответственные за обеспечение КБ.

2.4

Распределена ответственность за обеспечение КБ по всем направлениям, включая обеспечение КБ при работе с третьими сторонами.

2.5

Внедрена матрица кадровых решений за нарушения в области КБ, обеспечено применение дисциплинарных взысканий за нарушение требований КБ.

Уровень 3

3.1

Создано самостоятельное структурное подразделение, ответственное за обеспечение КБ, определены его функции и задачи. 

3.2

Организационно-штатная структура подразделения КБ сформирована с учётом направлений деятельности компании, модели угроз компании.

3.3

Определена ответственность и обязанности всех подразделений компании в части соблюдения требований КБ.

Уровень 4

4.1

CISO имеет полномочия принимать решения об отключении ИТ-сервисов (в том числе — влияющих на бизнес-процессы) после уведомления владельцев бизнес-процессов. Соответствующие полномочия документально определены. CISO имеет право вето при согласовании новых или модификации существующих информационных потоков, АС, сервисов. Для контроля подразделение КБ включено в соответствующие процессы компании.

4.2

CISO взаимодействует с руководителями бизнес-подразделений компании, поддерживая взаимную осведомленность. Обеспечено понимание подразделением КБ бизнес-процессов, а также понимание бизнесом задач, функций и процессов КБ компании.

4.3

Штатная численность подразделения КБ планируется долгосрочно, с учётом стратегии бизнеса, стратегий ИТ и КБ.

4.4

В компании утверждена матрица компетенций КБ для работников, ролей в подразделении КБ. Для работников, не соответствующих требованиям, планируется и реализуется обучение и/или применяются кадровые решения.

Уровень 5

5.1

Подразделение КБ участвует в разработке и обновлении корпоративной стратегии и стратегии развития ИТ компании.

5.2

CISO обладает полномочиями на отключение любых ИТ-сервисов без согласования с владельцами бизнес-процессов, в том числе сервисов, влияющих на бизнес-процессы компании.

Уровень 1

1.1

Ведётся реестр АРМ, в том числе виртуальных, при этом определены правила наименования АРМ.

1.2

Ведётся реестр серверов, в том числе виртуальных, при этом определены правила наименования серверов.

1.3

Ведётся реестр сетевого оборудования, в том числе виртуального, при этом определены правила наименования сетевого оборудования.

1.4

Установка ПО осуществляется из определённых источников дистрибутивов ПО для всех АРМ, серверов и сетевых устройств. Перечень источников управляется, согласовывается с подразделением КБ.

1.5

Средствами автоматизации обеспечена возможность сбора сведений об установленном ПО для всех АРМ и серверов.

1.6

Определены ИТ-администраторы для каждого ИТ-актива: конкретные работники или группа администрирования ИТ-актива.

Уровень 2

2.1

Используются инструменты актуализации реестра ИТ-активов (автоматизированные — для АРМ и серверов, а для сетевого оборудования допускается обогащение реестра в ручном режиме).

В компании используется автоматизированное решение для ведения реестра ИТ-активов:

Реестры ИТ-активов содержат следующую информацию:

имя устройства (hostname);

физический адрес размещения устройства;

IP адреса, присвоенные устройству;

идентификатор устройства (серийный/инвентарный номер);

статус эксплуатации;

ИТ-администратор актива;

владелец ИТ-актива;

URL (если применимо);

доступность из сети интернет;

критичность ИТ-актива;

(для сетевого оборудования, АРМ, серверов, иного оборудования, подключаемого к сети).

2.2

Используются инструменты актуализации реестра ИТ-активов (автоматизированные — для АРМ и серверов, а для сетевого оборудования допускается обогащение реестра в ручном режиме).

2.3

Разработан и внедрён перечень разрешённого и/или запрещённого ПО, изменение перечней согласовывается с подразделением КБ.

Формализованы процессы установки ПО и управления исключениями.

Уровень 1

1.1

Определены актуальные угрозы КБ для компании, как минимум в виде рабочих документов.

1.2

Определены работники КБ, ответственные за выявление актуальных угроз и рисков КБ.

Уровень 2

2.1

Разработана и утверждена общая модель угроз и нарушителя КБ.

2.2

Проводится регулярная (не реже 1 раза в год) оценка рисков КБ для компании (возможно, используется экспертная оценка), методика экспертной оценки рисков КБ разработана и утверждена.

2.3

Выявленные риски КБ регистрируются в едином реестре рисков, описываются митигирующие меры, условия пересмотра и владелец риска. Руководитель компании информируется о выявленных рисках.

2.4

Для выявленных рисков КБ (как минимум для наиболее критичных) назначаются владельцы. Определены функции и обязанности владельцев рисков, возможно, неформально.

Уровень 3

3.1

Процесс управления рисками КБ полностью регламентирован. Определены функции и обязанности владельцев рисков КБ.

3.2

Разработаны частные модели угроз для критичных АС и сервисов.

3.3

Разработана и используется методика качественной/количественной оценки рисков КБ, учитывающая определение вероятности реализации риска КБ и возможное влияние от реализации события.

3.4

Обработка рисков КБ производится в соответствии с параметрами, зафиксированными в реестре рисков. Отклонения фиксируются, по ним принимаются и документально оформляются решения.

Уровень 4

4.1

Управление рисками КБ интегрировано в корпоративную систему управления рисками.

4.2

Создан коллегиальный орган для рассмотрения вопросов и принятия решений по управлению рисками КБ, обеспечивающий баланс между развитием бизнеса и достаточным уровнем КБ.

4.3

Установлен аппетит к рискам КБ.

Уровень 5

5.1

Разработана и внедрена методика проведения сценарного анализа риска КБ для оценки возможных последствий от реализации потенциальных событий риска КБ, методика разработки и мониторинга ключевых индикаторов риска КБ.

5.2

Внедрена и используется система GRC, интегрированная с решением для управления ИТ-активами. Выявленные риски КБ регистрируются с учётом взаимосвязи с конкретными ИТ-активами, уязвимостями в ИТ-активах. Риск КБ отслеживается в режиме реального времени с учётом изменений в ИТ-активах.

Уровень 1

1.1

Разработаны схемы сетей компании с отображением и описанием СЗИ и компонентов инфраструктуры.

1.2

Требования КБ предъявляются при внедрении отдельных АС, сервисов. Требования определены как минимум в виде рабочих документов.

Уровень 2

2.1

Регламентировано управление жизненным циклом АС, включая этап проработки архитектуры КБ. Существует роль архитектора КБ, формализованы его функции и обязанности (возможно, роль выполняется по совместительству).

2.2

Разработаны архитектуры ИТ и КБ компании со схемами информационных потоков.

2.3

Разработаны критерии для определения критичности АС и приложений/сервисов компании.

2.4

Произведена и поддерживается в актуальном состоянии классификация АС и приложений в соответствии с критериями критичности.

Уровень 3

3.1

Разработаны типовые требования КБ к АС и приложениям/сервисам с учётом их критичности. Требования применяются при разработке архитектуры.

3.2

Создан архитектурный совет, формализованы его функции, представитель подразделения КБ — участник с правом вето.

3.3

Все разрабатываемые архитектуры проходят согласование на архитектурном совете.

3.4

Разработаны инструкции для подразделения ИТ по безопасному конфигурированию всех компонентов инфраструктуры.

Уровень 4

4.1

Требования КБ к ИТ-архитектуре регулярно пересматриваются компанией, являются актуальными по отношению к текущей ИТ-инфраструктуре компании. При планировании изменений ИТ-архитектуры кроме функциональных требований определяются также требования КБ.

Уровень 5

5.1

В компании разработаны и используются архитектурные паттерны КБ для проектирования любых элементов ИТ-инфраструктуры. 

Уровень 1

1.1

В компании выполняется планирование развития КБ (возможно, не полностью формализовано).

1.2

Выделяются ресурсы на обеспечение КБ, как минимум, на ФОТ и/или отдельные технические средства и услуги.

Уровень 2

2.1

План развития КБ компании разработан и утверждён советом директоров (или эквивалентным органом управления).

2.2

Выделен бюджет на обеспечение и развитие КБ, учитывающий все мероприятия плана развития КБ (возможно, используются не КБ-статьи расходов).

2.3

План развития КБ регулярно обновляется при существенных изменениях в бизнесе и ландшафте угроз.

Уровень 3

3.1

План развития КБ компании учитывает цели бизнеса и подразделения ИТ.

3.2

Бюджет на КБ является выделенным бюджетом подразделения и/или статьи расходов КБ формально и фактически защищены (невозможно их расходование на задачи, не связанные с КБ).

3.3

Разработана и утверждена стратегия КБ, определяющая долгосрочные задачи и соответствующий план развития КБ (на перспективу не менее двух лет).

Уровень 4

4.1

Стратегия КБ обновляется при существенных изменениях в стратегиях бизнеса и ИТ, в ландшафте угроз.

4.2

Производится регулярная оценка эффективности реализации стратегии КБ (как минимум ежегодно), план реализации стратегии корректируется (при необходимости).

Уровень 5

5.1

Стратегическое планирование КБ интегрировано с системой управления риском КБ компании.

Уровень 1

1.1

Отчётность по КБ предоставляется руководству компании — по запросу, по отдельным проектам, по инцидентам КБ.

Уровень 2

2.1

Обеспечено регулярное (не реже 1 раза в квартал) предоставление отчетности по КБ руководству компании: как минимум по инцидентам КБ, ключевым проектам КБ, выполнению плана развития КБ, а также по выполнению KPI (ключевого показателя эффективности) в области КБ, установленного для CEO советом директоров компании (или эквивалентным ему высшим коллегиальным органом управления).

2.2

В состав показателей эффективности деятельности руководителя компании входит ключевой показатель эффективности по КБ.

2.3

Определены ключевые показатели эффективности для руководителя подразделения КБ.

2.4

Используются метрики для оценки покрытия техническими средствами и контролями КБ инфраструктуры/работников компании.

2.5

Используются метрики для оценки обучения, повышения осведомлённости КБ работников компании (в т. ч. связанные с проведением киберучений).

Уровень 3

3.1

Используются метрики для оценки эффективности процессов КБ (возможно, не всех), расчёт метрик регламентирован.

3.2

Метрики для процессов КБ включаются в регулярную отчётность для руководства компании.

3.3

Используются показатели эффективности для CISO, индивидуальные цели, показатели эффективности формируются руководством компании с учётом плана развития КБ (как минимум — ежеквартальные цели, показатели). CISO выполняет защиту индивидуальных целей. 

Уровень 4

4.1

Используются метрики оценки эффективности для всех процессов КБ.

4.2

Внедрены средства автоматизации расчёта метрик и визуализации отчётности по КБ.

4.3

Используются показатели эффективности для всех работников подразделения КБ.

4.4

Внедрены средства автоматизации для расчёта показателей эффективности подразделения КБ.

Уровень 5

5.1

Сформирован единый дашборд для высшего руководства, он отражает эффективность работы подразделения КБ. 

Уровень 1

1.1

Определён (возможно, только в виде рабочих документов) перечень ключевых изменений в ИТ-инфраструктуре, требующих согласования с ответственным за КБ в компании.

1.2

Требования по согласованию изменений доведены до ответственных лиц.

Уровень 2

2.1

Все ключевые изменения в ИТ-инфраструктуре согласовываются с подразделением КБ.

2.2

Определён (возможно, в виде рабочих документов) полный перечень ключевых изменений в ИТ-инфраструктуре, требующих согласования с подразделением КБ. Определены маршруты, приоритеты согласования изменений.

Уровень 3

3.1

Регламентирован процесс управления изменениями в ИТ-инфраструктуре, определено участие подразделения КБ в процессе.

3.2

Ведётся реестр ключевых изменений с отображением затронутых активов и инициаторов изменений. 

3.3

Используется автоматизированная система для обработки и согласования заявок на изменения. Все изменения регистрируются в системе.

3.4

Для изменений в ИТ-инфраструктуре регистрируется «карточка» включающая:

критичность/степень влияния изменения;

перечень затрагиваемых ИТ-активов;

ответственных за вносимые изменения;

уведомляемых об изменениях лиц;

сценарии отката изменения.

Уровень 4

4.1

Сформирован комитет по управлению ключевыми изменениями в ИТ-инфраструктуре компании. Подразделение КБ — в составе комитета.

Уровень 5

5.1

Сформирована единая система управления изменениями в компании с отслеживанием влияния изменений на бизнес-процессы, процессы ИТ и КБ. 

Уровень 1

1.1

Предъявляются требования к парольной защите (требования сформулированы, как минимум, в виде рабочих документов).

1.2

Осуществляется контроль доступа к АС (согласование предоставления доступа подразделением КБ) как минимум для отдельных систем.

1.3

Контролируется использование непривилегированными пользователями административных прав в системах.

1.4

Используются системы централизованного управления учётными записями (создание, изменение, блокирование, восстановление учётных записей) для АРМ, например, служба каталогов.

Уровень 2

2.1

Определена парольная политика. Настройки систем компании сконфигурированы в соответствии с требованиями парольной политики.

2.2

Разработана политика управления доступом. Определена процедура согласования доступов.

2.3

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

2.4

Назначены ответственные за процесс предоставления доступов (создание, изменение, блокирование, восстановление учётных записей).

2.5

Внедрена автоматизированная система для согласования заявок на доступы.

2.6

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

2.7

Используются системы централизованного управления учётными записями (создание, изменение, блокирование, восстановление) для серверных платформ (например, служба каталогов).

2.8

Разработаны ролевые модели доступа для критичных АС компании. Ролевые модели используются при согласовании доступов.

2.9

Внедрены процедуры контроля удалённого доступа. Производится согласование удалённого доступа и контроль подключений. 

Уровень 3

3.1

Внедрены процедуры аудита привилегированных учётных записей на предмет актуальности и легитимности прав (проводится не реже 1 раза в квартал).

3.2

Внедрена система централизованного хранения и управления учётными записями для сетевого оборудования.

3.3

Внедрена система многофакторной аутентификации (2FA) при использовании привилегированных учётных записей.

3.4

Внедрён выделенный изолированный шлюз (сервер для доступа к ИТ-инфраструктуре компании из сети интернет с расширенными политиками безопасности и мониторинга) для доступа подрядчиков/партнёров и иных третьих сторон.

3.5

Осуществляется регулярный пересмотр ролевых моделей доступа совместно с владельцами систем (как минимум ежегодно).

3.6

Внедрена система управления жизненным циклом учётных записей (IDM, как минимум, ведёт создание, изменение, учёт, блокировку УЗ и контроль прав доступа). Покрытие не менее 50% учётных записей и систем. 

3.7

Внедрена автоматизированная система контроля за действиями привилегированных пользователей, например, PAM-система. Обеспечено ограничение по исполняемым командам, журналирование и ограничение доступа к учётными данным (как минимум, для критичных систем).

3.8

Разработаны ролевые модели доступа для АС компании. Ролевые модели используются при согласовании доступов.

Уровень 4

4.1

Внедрена система управления жизненным циклом учётных записей (например, IDM-система). Покрытие не менее 90% учётных записей и систем. 

4.2

Внедрена автоматизированная система контроля за действиями привилегированных пользователей (PAM), обеспечено полное покрытие всех серверов и АС.

4.3

Внедрены процедуры аудита пользовательских учётных записей на предмет актуальности и легитимности прав (не реже 1 раза в квартал), соответствия фактических доступов заявленным, а также фактических полномочий ролевым моделям.

Уровень 5

5.1

Полностью реализована трехуровневая система учётных записей для администрирования ИТ-инфраструктуры (разные учётные записи для разных типов систем). Внедрены и автоматизированы (возможно частично) процессы выявления конфликта полномочий (SoD).

Уровень 1

1.1

Используются средства защиты периметра сети (как минимум, с функционалом МСЭ), настроенные по принципу white-list. Выполняется контроль избыточных сетевых доступов.

1.2

Используются средства защиты почтового трафика от вирусов и спама.

1.3

Сеть сегментирована по функциональному признаку. Например: DMZ, сегмент разработки, сегмент тестирования, промышленный сегмент, пользовательский сегмент, сегмент управления, гостевой сегмент.

1.4

Используются средства защиты удалённого доступа, как минимум, VPN с возможностью идентификации, аутентификации и шифрования данных.

1.5

Обеспечена защита от DDoS-атак на инфраструктуру, как минимум, настроены лимиты на периметровых средствах защиты сети.

1.6

Выполнена конфигурация взаимной аутентификации на почтовых серверах (DKIM/DMARC/SPF).

1.7

Заблокирована отправка и получение неразрешённых типов файлов во вложениях.

1.8

Администрирование инфраструктуры осуществляется из выделенной защищённой сети/сегмента сети.

1.9

Критичные web-приложения/сайты защищены МСЭ для защиты веб-приложений (WAF), решение покрывает OWASP ТОР-10 в режиме блокировки, есть возможность формирования индивидуальных правил.

Уровень 2

2.1

Для защиты периметра сети используются средства класса NGFW/UTM, как минимум, функционал потокового антивируса, IDS/IPS, регулярного обновления БД сигнатур, контроля сетевых приложений на уровне L7 модели OSI. 

2.2

Произведена сегментация сети на уровне отдельных сервисов. Используются правила доступа между сервисами и группами сервисов.  Межсетевые правила взаимодействия составляются по принципам минимизации полномочий и запрещения всего, что явно не разрешено (default to deny).

2.3

Гостевая беспроводная сеть отделена от корпоративной сети.

2.4

Используется комплексное решение для защиты от DDoS-атак на инфраструктуру и приложения (L3/L4 и L7). 

2.5

Применяется многофакторная аутентификация для всех подключений удалённого доступа.

2.6

Используются средства контроля доступа к корпоративной сети для проводных, беспроводных и удалённых подключений, например, реализация протокола 802.1х (возможно, контролируется только часть подключений).

2.7

Производится сбор и анализ журналов событий со средств защиты сети в SIEM/SOC.

2.8

Пользовательский доступ в интернет осуществляется исключительно через узел фильтрации веб-трафика (web proxy) с функцией TLS/SSL inspection. Правила фильтрации обновляются автоматически. Фильтрация — по категории, репутации домена или с помощью чёрных списков адресов.

2.9

Веб-трафик всех серверов с сетью интернет проходит исключительно через узел фильтрации веб-трафика (web proxy) с функцией TLS/SSL inspection (возможно, правила обновляются вручную).

2.10

Производится безопасная конфигурация беспроводных точек доступа/контроллеров беспроводной сети, включающая в себя:

настройку безопасных протоколов (не ниже WPA2-PSK) и криптостойких алгоритмов;

настройку изоляции клиентов беспроводной сети;

отключение/блокировку небезопасных протоколов управления;

осуществление сканирования беспроводной сети на предмет выявление фишинговых точек доступа;

ограничение зоны покрытия радиовещания.

Уровень 3

3.1

Требования к сетевой безопасности регламентированы и учитывают, как минимум, требования к:

защите периметра (внешнего и внутреннего);

сегментации сети (включая критерии сегментации);

беспроводным сетям;

управлению доступом к корпоративной сети;

удалённому доступу.

3.2

Используется система централизованного управления конфигурациями сетевых устройств (подключено не менее 90% сетевых устройств).

3.3

Для всех удалённых подключений к сети компании производится проверка соответствия политикам безопасности, как минимум, в отношении АВПО, обновления ОС, и, если применимо, проверки статуса устройства в домене, агента DLP при доступе к сети и агента EDR. Неавторизованные или не соответствующие политикам устройства перенаправляются в изолированную сеть или блокируются.

3.4

Используется решение класса «песочница» для входящего трафика, в том числе почтового (как минимум, потоковое решение, без возможности ручного управления).

Уровень 4

4.1

Контроль межсегментного взаимодействия производится на уровне NGFW (возможно, применяется не весь функционал NGFW).

4.2

Используется решение класса «песочница» с возможностью ручного выноса вердиктов и ручной загрузкой файлов.

Уровень 5

5.1

Используются инструменты для анализа аномалий в сетевом трафике (NTA), выявления скрытых и сложных атак.

5.2

 Инструменты для анализа сетевого трафика (NTA) интегрированы с системами мониторинга и реагирования на события КБ.

Уровень 1

1.1

Конфигурирование АРМ производится с учётом базовых требований КБ (требования КБ по безопасному конфигурированию АРМ могут быть в виде рабочих документов):

отключены/удалены неиспользуемые сервисы, протоколы и модули;

изменены или заблокированы все встроенные учётные записи, включая административные;

изменены пароли, назначенные (по умолчанию) производителем;

для пользователей ограничен доступ к BIOS и загрузчикам ОС.

1.2

Конфигурирование серверов производится с учётом базовых требований КБ (требования КБ по безопасному конфигурированию серверов должны существовать как минимум в виде рабочих документов):

отключены/удалены неиспользуемые сервисы, протоколы и модули;

изменены или заблокированы все встроенные учётные записи, включая административные;

изменены пароли, назначенные (по умолчанию) производителем;

для пользователей ограничен доступ к BIOS и загрузчикам ОС.

1.3

Конфигурирование корпоративных мобильных устройств производится с учётом базовых требований КБ (требования КБ по безопасному конфигурированию мобильных устройств должны существовать как минимум в виде рабочих документов):

отключены\удалены неиспользуемые сервисы и ПО;

заблокирована возможность установки приложений из недоверенных источников;

установлен пароль для аутентификации на устройстве;

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

1.4

Конфигурирование микросервисной архитектуры производится с учётом базовых требований КБ (требования КБ по безопасному конфигурированию микросервисной инфраструктуры могут быть в виде рабочих документов):

контейнеры запускаются с минимально необходимыми привилегиями;

используются доверенные образы (источники для образов);

настроены и контролируются сетевые взаимодействия в микросервисной инфраструктуре.

1.5

Конфигурирование сетевого оборудования производится с учётом базовых требований КБ (требования КБ по безопасному конфигурированию сетевого оборудования могут быть в виде рабочих документов или используются готовые решения):

изменены или заблокированы встроенные учётные записи, включая административные;

изменены пароли, назначенные (по умолчанию) производителем;

отключены неиспользуемые модули и протоколы;

настроены безопасные протоколы администрирования.

1.6

Конфигурации безопасности для серверов централизованно управляются (например, при помощи доменных политик).

1.7

Конфигурации безопасности для АРМ централизованно управляются (например, при помощи доменных политик). 

1.8

Используется АВПО для защиты рабочих станций (покрытие не менее 90%).

1.9

Используется АВПО для защиты серверов под управлением ОС Windows (покрытие не менее 90%).

1.10

Осуществляется централизованное управление АВПО и централизованное обновление баз АВПО.

1.11

Прямой доступ в ИТ-инфраструктуру с личных устройств (BYOD) запрещён. Запрет реализован техническими мерами.

Уровень 2

2.1

Разработаны и доведены до ответственных подразделений инструкции по безопасному конфигурированию устройств (возможно, не учитывают отдельные платформы). Инструкции разработаны с использованием, как минимум, рекомендаций вендоров. 

2.2

Для подготовки АРМ и серверов используется система хранения и применения базовых (золотых) образов, преднастроенных с учётом требований КБ. 

2.3

Обеспечено полное покрытие АРМ и серверов (под управлением ОС Windows) АВПО. Отклонения отслеживаются и управляются.

2.4

Осуществляется контроль обновлений баз АВПО. Отклонения отслеживаются и управляются.

2.5

Используются локальные хостовые МСЭ для АРМ и серверов. Обеспечено полное покрытие.

2.6

Используется решение класса MDM, как минимум, геолокация устройства, возможность блокировки/очистки устройства и удалённое применение политик безопасности для контроля мобильных устройств (покрытие не менее 90%).

2.7

Используется полнодисковое шифрование АРМ пользователей (выбор АРМ осуществляется на основании риск-ориентированного подхода).

2.8

Доступ в инфраструктуру с личных устройств (BYOD) осуществляется через выделенный шлюз (VDI, jump host). Настроены расширенные политики безопасности (как минимум: мониторинг, блокировка буфера обмена и проброса портов).

2.9

Используется АВПО для защиты серверов под управлением ОС *nix (покрытие не менее 90%).

2.10

Используются решения класса EDR/XDR (как минимум, сбор телеметрических данных хоста, реагирование на триггеры по результатам анализа телеметрии, возможность удалённого подключения для управления хостом) для защиты АРМ и серверов. Обеспечено полное покрытие. Отклонения выявляются и управляются.

2.11

Решение EDR/XDR интегрировано с системой анализа и корреляции событий КБ.

Уровень 3

3.1

Разработаны и внедрены стандарты безопасного конфигурирования для всех применяемых в компании платформ, включая АРМ, серверы, мобильные устройства, сетевое оборудования и т. п. Требования учитывают функциональное назначение и критичность конечных устройств.

Уровень 4

4.1

Производится регулярный пересмотр (не реже 1 раза в полгода) требований КБ к безопасности конечных устройств.

4.2

Золотые образы ОС регулярно актуализируются. В рамках актуализации осуществляется сканирование образов на наличие уязвимостей и соответствия требованиям безопасной конфигурации.

Уровень 5

5.1

Золотые образы используются для всех новых развертываний ОС. Отклонения от конфигураций золотого образа фиксируются и управляются.

Уровень 1

1.1

Определён состав защищаемой информации, определены места и способы её хранения.

1.2

Предъявляются и применяются требования КБ к защите данных при передаче за пределы периметра компании (например, в рамках договорных отношений, соглашений о неразглашении и т. п.). 

1.3

Осуществляется защита каналов связи и носителей при передаче информации ограниченного доступа за пределы периметра компании (шифрование носителей и каналов, двухсторонний TLS и т. п.).

1.4

Производится резервное копирование систем и информации, как минимум, ключевых активов, необходимость определяется экспертно.

1.5

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

Уровень 2

2.1

Определены категории информации ограниченного доступа в зависимости от состава и критичности.

2.2

Для критичных АС определены категории и состав обрабатываемой информации. Определены владельцы данных в разрезе АС. 

2.3

Для мониторинга доступа к критичным данным используются автоматизированные решения (например, встроенные решения или DAG).

2.4

Использование съёмных носителей контролируется с использованием СЗИ и/или штатного функционала ОС. 

2.5

Используются решения класса DLP в режиме мониторинга, как минимум, для почтового трафика, веб-приложений, записи на съёмные носители, сетевых папок и печати. Покрытие не менее 25% пользователей, выбор контролируемых пользователей осуществляется на основании риск-ориентированного подхода.

2.6

Для резервного копирования информации используется централизованное решение. Резервное копирование планируется и выполняется с учётом критичности систем и информации в них, оценки возможного влияния на бизнес компании в случае полной потери информации и/или длительного простоя систем.

2.7

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

Уровень 3

3.1

Регламентирован жизненный цикл управления данными и требования КБ к нему.

3.2

Регламентированы правила взаимодействия с третьими сторонами. Определены типы договоров, требующих согласования со службой КБ, а также перечень необходимых соглашений в зависимости от типов взаимодействия.

3.3

Регулярно, как минимум, ежегодно, пересматривается (актуализируется) подход к категорированию информации. 

3.4

Перед началом взаимодействий с контрагентами выполняется анализ общедоступных данных о кибербезопасности контрагента.

3.5

Для обнаружения и классификации данных «at rest» используются автоматизированные решения (например, DCAP).

3.6

Используется решение класса DLP, покрыто не менее 90% пользователей и каналов взаимодействия.

Уровень 4

4.1

Автоматизированные решения для защиты данных интегрированы с SIEM/внешним SOC.

4.2

Проводится регулярный (не реже 1 раза в год) аудит выполнения требований КБ по жизненному циклу данных.

Уровень 5

5.1

Реестр информационных потоков обновляется ежедневно, доступен для всех авторизованных лиц.

Уровень 1

1.1

Настроены политики журналирования событий КБ на средствах защиты информации и в критичных системах.

1.2

Производится анализ журналов событий КБ со средств защиты. 

Уровень 2

2.1

Средства защиты и критичные системы подключены к системе сбора событий КБ.

2.2

Настроены оповещения в случае возникновения критичного события КБ.

2.3

Регламентированы требования к настройкам журналирования событий КБ в системах (в том числе, событий ИТ, важных с точки зрения КБ).

2.4

Используется SIEM-система/внешний SOC. Сбор событий производится со всех АРМ и серверов.

Уровень 3

3.1

Определены и классифицированы возможные типы инцидентов КБ и критерии их возникновения. Разработаны playbook’и по выявлению различных инцидентов.

3.2

Разработаны правила нормализации данных и корреляции событий КБ, индивидуальные правила для критичных систем.

3.3

Производится регулярная оценка и пересмотр правил корреляции событий КБ.

Уровень 4

4.1

Используется решение для поведенческого анализа пользователей и формирования поведенческих профилей работников (например, UEBA).

4.2

Производится обогащение правил мониторинга событий КБ на основе данных c TI (источников информации Threat Intelligence).

Уровень 5

5.1

Производится корреляция событий КБ из нескольких источников (цепочка правил) для обнаружения сложных атак.

Уровень 1

1.1

Используются автоматизированные решения для выявления уязвимостей на внешнем периметре для всех интернет-ресурсов.

1.2

Производится своевременное устранение уязвимостей критического и высокого уровней, выявленных в результате сканирований.

1.3

Производится своевременное устранение уязвимостей критического и высокого уровней, информация о которых получена из открытых источников, от материнской компании, партнёров, государственных органов.

Уровень 2

2.1

Применяются автоматизированные инструменты для сканирования всей ИТ-инфраструктуры (внешний периметр и корпоративная сеть).

2.2

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

2.3

Осуществляется сканирование конфигураций критичных конечных и сетевых устройств ИТ-инфраструктуры.

2.4

Настроено расписание сканирований. Сканирования (внутренние и внешние) производятся не реже раза в месяц. Осуществляется контроль успешного завершения сканирования по расписанию.

2.5

Используются автоматизированные решения для управления обновлениями. Управление обновлениями для всех критичных систем осуществляется при помощи данных решений.

2.6

Производится тестирование обновлений перед установкой (например, используются тестовые стенды и сплит-тестирование).

2.7

Информация о выявленных уязвимостях доводится до владельцев систем. Производится контроль сроков устранения уязвимостей.

2.8

Устранение уязвимостей подтверждается подразделением КБ только по результатам анализа данных повторного сканирования.

Уровень 3

3.1

Осуществляется сканирование конфигураций всех конечных и сетевых устройств ИТ-инфраструктуры.

3.2

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

3.3

Процесс управления уязвимостями и патч-менеджмента регламентирован.

3.4

Сформированы SLA (service level agreement) для подразделений и работников, ответственных за устранение уязвимостей. 

3.5

Задачи на устранение уязвимостей закрываются только по предъявлению артефактов, подтверждающих устранение уязвимости или принятие риска.

Уровень 4

4.1

Используется решение класса TI для анализа выявленных уязвимостей.

4.2

Сканеры уязвимостей компании интегрированы с SIEM/SOC.

Уровень 5

5.1

Производится корреляция событий КБ из нескольких источников (цепочка правил) для обнаружения сложных атак.

Уровень 1

1.1

Производится ежегодное независимое тестирование на проникновение внешней сети. Тестирование проводится в соответствии с планом. 

1.2

Производится ежегодный независимый анализ защищённости критичных приложений и АС компании. Тестирование проводится в соответствии с планом.

1.3

Формируются планы устранения уязвимостей с назначением сроков и ответственных.

Уровень 2

2.1

Производится ежегодное независимое тестирование внутренней сети на проникновение. Тестирование проводятся в соответствии с планом. 

Уровень 3

3.1

В компании подключена частная и/или публичная программа Bug Bounty для критичных приложений.

Уровень 4

4.1

Программа Bug Bounty развёрнута в публичном пространстве.

4.2

В компании действует служба Red team. Производится непрерывное тестирование защищённости компании. 

Уровень 5

5.1

Организовано взаимодействие Red team и Blue team. Выявленные уязвимости оперативно устраняются.

Уровень 1

1.1

Определён (как минимум в виде рабочих документов) перечень инцидентов КБ (или событий, классифицированных как инцидент), на которые необходимо реагировать.

1.2

Все инциденты фиксируются, документируются результаты реагирования на инцидент и причины возникновения инцидента.

Уровень 2

2.1

Разработан план реагирования на инциденты КБ, включающий описание этапов реагирования. 

2.2

Определены требования к регистрации и приоритизации инцидентов.

2.3

Определены критерии инцидентов КБ, требующих расследования.

2.4

Используется автоматизированная система для регистрации инцидентов КБ.

2.5

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

·         статус инцидента;

·         затрагиваемый актив;

·         тип инцидента;

·         приоритет/значимость.

Уровень 3

3.1

Процесс управления инцидентами регламентирован. Регламентированы этапы процесса, включая этап расследования. 

3.2

Разработаны playbook’и по реагированию на различные типы инцидентов КБ. 

3.3

Используется решение класса IRP (как минимум автоматизированная локализация угроз) для управления инцидентами.

3.4

Разработаны и соблюдаются SLA по реагированию на инциденты для всех участников процесса в соответствии с уровнем критичности инцидента.

3.5

В результате расследования инцидентов формируется post-mortem и план устранения недостатков.

Уровень 4

4.1

Система IRP интегрирована с системой анализа и корреляции событий КБ. Производится автоматизированная регистрация инцидентов КБ на основе классификации.

Уровень 5

5.1

Производится регулярное тестирование и улучшение playbook'ов по реагированию с привлечением Red team.

Уровень 1

1.1

Производится ознакомление работников с правилами КБ (ВНД, ОРД, памятки) при заключении трудового договора, а также периодически.

1.2

Осуществляется повышение осведомлённости работников, как минимум, в области фишинга, противодействия социальной инженерии.

Уровень 2

2.1

Организована единая точка для обращений работников компании по вопросам КБ, набор контактов для разных каналов коммуникации и правила обращения доведены до работников компании.

2.2

В компании проводятся регулярные киберучения. Отчёты о киберучениях предоставляются руководителю компании, по результатам киберучений принимаются решения (в т. ч. по обучению работников компании).

2.3

Создана библиотека обучающих материалов, а также ВНД и РД по КБ (база знаний), доступная всем работникам компании.

2.4

Производится специализированное обучение по КБ работников подразделения КБ (возможно, не системно).

Уровень 3

3.1

Регламентирован процесс обучения и повышения осведомлённости в области КБ, определены роли, назначены ответственные.

3.2

Осуществляется повышение осведомлённости в области КБ для клиентов компании.

3.3

Осуществляется повышение осведомлённости в области КБ для контрагентов, имеющих доступ в инфраструктуру компании или к данным компании.

3.4

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

3.5

Проводятся дополнительные обучающие мероприятия для работников по результатам анализа инцидентов КБ (как минимум подразделений КБ и ИТ).

3.6

Осуществляется регулярный пересмотр учебных материалов (не реже 1 раза в год), с учётом результатов обучения и обратной связи.

3.7

Внедрена практика горизонтального обмена опытом в подразделении КБ (практика взаимного обучения работниками КБ).

3.8

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

Уровень 4

4.1

Всем работникам доступны дистанционные курсы по КБ, с функционалом выполнения упражнений, с централизованной отчётностью о результатах обучения работников компании.

4.2

Поддержание, развитие культуры КБ во всех процессах включено в стратегические цели компании.

4.3

Внедрена практика горизонтального обмена опытом между подразделениями КБ и ИТ (практика взаимного обучения).

Уровень 5

5.1

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

5.2

Процесс обучения и повышения осведомлённости, учебные материалы непрерывно пересматриваются (как минимум раз в полгода) с учётом анализа результатов, обратной связи, появления новых подходов, знаний в области КБ.