Самопроверка ИБ между аудитами: как CISO не потерять контроль над доступами, подрядчиками и резервным копированием

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

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

Для CISO это прежде всего инструмент текущего контроля: не отдельный большой проект, а регулярная проверка того, соответствует ли фактическое состояние инфраструктуры тому, что команда считает защищенным.

Самопроверка и аудит отвечают на разные управленческие вопросы

Аудит информационной безопасности оценивает реализацию мер и выполнение установленных требований в заданном периметре. Он может быть внутренним или внешним, а результатом становится зафиксированная картина состояния ИБ в конкретной информационной системе или инфраструктуре.

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

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

Для CISO различие можно сформулировать так:

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

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

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

Начинать нужно с инвентаризации, а не с чек-листа защитных мер

Самая слабая отправная точка — сразу проверять пароли, MFA, резервные копии или правила межсетевого экранирования, не имея актуального перечня систем.

Сначала нужно определить, что именно входит в контролируемый контур.

Для каждой информационной системы полезно зафиксировать как минимум:

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

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

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

Для CISO результат инвентаризации — не просто список активов. Это основание для следующего вопроса: есть ли для каждого значимого элемента инфраструктуры владелец, понятный способ доступа и соответствующий набор мер защиты.

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

Доступы: временные исключения быстро становятся постоянными

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

Нужно проверить:

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

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

Для CISO здесь важна не только разовая очистка. Процесс выдачи и отзыва прав должен позволять ответить на три вопроса: кто согласовал доступ, зачем он еще нужен и когда его должны пересмотреть.

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

В исходной модели самопроверки такой контроль предлагается проводить как минимум ежеквартально.

Облачные сервисы и подрядчики нужно включать в тот же контур контроля

Передача части инфраструктуры облачному провайдеру, ЦОД или внешнему подрядчику меняет распределение ответственности, но не отменяет необходимость контролировать защиту информации.

Во время самопроверки нужно установить:

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

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

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

Локальные документы стоит проверять по фактическим процессам

Самопроверка организационных мер не должна сводиться к вопросу «есть ли политика ИБ?».

Нужно проверить, соответствует ли документация текущей модели работы:

• назначен ли ответственный за ИБ;
• актуальны ли действующие ЛНА;
• проводятся ли предусмотренные инструктажи;
• соответствуют ли закрепленные роли фактическому распределению ответственности;
• отражают ли документы изменения инфраструктуры и процессов.

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

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

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

Резервное копирование нужно проверять восстановлением, а не наличием задания

Одна из самых простых и одновременно показательных самопроверок — восстановить конкретный файл из резервной копии.

Наличие успешно завершенного задания backup еще не отвечает на вопросы:

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

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

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

Пять проверок, которые дают быстрый сигнал о состоянии контура

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

1. Проверить административные и неактивные учетные записи.
Запросить у ИТ список пользователей с повышенными правами и учетных записей, которыми давно не пользуются. Отдельно сопоставить их с бывшими сотрудниками и завершенными подрядными работами.

2. Выполнить тестовое восстановление.
Выбрать один файл и пройти весь процесс восстановления из резервной копии. Если операция не работает или требует неоправданно сложной ручной процедуры, это уже конкретный разрыв.

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

4. Проверить MFA на критичных точках доступа.
В первую очередь корпоративную почту, VPN и используемые облачные сервисы.

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

Ценность этих действий не в том, что они заменяют глубокую оценку. Они дают CISO быстро проверяемые сигналы: где базовые процессы контроля работают, а где защита держится на предположениях.

Периодичность лучше привязать к характеру контроля

Универсальной частоты для всех элементов самопроверки нет.

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

Общий принцип для CISO полезнее календаря: проверка должна запускаться не только по расписанию, но и при изменении контролируемого объекта.

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

Иначе ежеквартальная процедура быстро превращается в фотографию прошлого состояния.

Когда самопроверка перестает быть достаточной

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

Полноценный аудит требуется, когда:

• инфраструктура существенно меняется, например при переходе в облако, внедрении новой системы или изменении архитектуры;
• компания готовится к регуляторной проверке;
• требуется подтверждение мер защиты для тендера;
• необходимо оценить соответствие установленным нормативным требованиям, включая требования 152-ФЗ и приказа ФСТЭК № 21, с оформлением соответствующего результата.

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

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

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

Что это значит для CISO

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

Начинать стоит с актуального контура: систем, данных, СЗИ, владельцев и доступов. Затем регулярно проверять наиболее подвижные области — административные права, подрядчиков, внешние сервисы, резервное копирование и организационные процедуры.

Главный результат такой работы — не количество закрытых пунктов. CISO должен понимать, какие изменения произошли в инфраструктуре с момента последней оценки, где появились новые допуски или исключения и какие из обнаруженных разрывов уже требуют отдельного аудита.

Если результаты самопроверки показывают системные проблемы и нужна независимая оценка их критичности и приоритетов устранения, задачу можно обсудить со специалистами Б-152.