Аудит ИТ-безопасности: как выбрать подрядчика

Молдавские компании обычно приходят к внешнему аудиту ИТ-безопасности по одной из трёх причин: более крупный клиент или партнёр требует его договором перед подписанием; киберстраховка ставит его условием полиса; либо компания уже прошла базовую гигиену — двухфакторную аутентификацию, пароли, firewall — и хочет независимую проверку, а не просто предположение, что меры работают. В всех трёх случаях практический вопрос один: что на деле означает серьёзный аудит и как выбрать подрядчика, который проводит именно его, а не формальность, заполненную к концу рабочего дня.

Внутренний аудит и внешний аудит: это не взаимозаменяемые вещи

Чек-лист, пройденный собственной ИТ-командой — один такой, из семи пунктов, мы описали в гиде по кибербезопасности для бизнеса, и ещё один, для сети, в гиде про firewall — полезен и необходим, но имеет структурное ограничение: человек, настроивший систему, как правило, тот же человек, что её проверяет, а ошибку конфигурации, которую он не заметил при установке, редко замечает и при проверке. Внешний аудит добавляет именно то, чего не хватает: взгляд того, кто не строил систему и не заинтересован считать её «достаточно хорошей». Разница не в объёме усилий, а в независимости.

Что конкретно оценивает аудит ИТ-безопасности

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

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

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

Аудит и тест на проникновение: термины не синонимы

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

Тесты на проникновение делятся, в свою очередь, по объёму информации, предоставленной подрядчику заранее: black box (без какой-либо предварительной информации об инфраструктуре, точно как у внешнего неизвестного атакующего), gray box (с уровнем доступа, аналогичным обычному сотруднику, чтобы проверить, что можно сделать изнутри с ограниченными правами), и white box (с полным доступом к конфигурациям и, где это уместно, к исходному коду, для максимально детальной проверки). Ни один вариант не является универсально «лучшим» — выбор зависит от того, какой сценарий риска вы хотите проверить, и серьёзный подрядчик спросит об этом явно, а не предложит автоматически самый дешёвый для себя вариант.

Как проходит, на практике, внешний аудит

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

• 1. Определение охвата — письменно устанавливается, что именно тестируется, что явно исключено (например, системы партнёра, не одобрившего тестирование) и в каком временном окне.
• 2. Соглашение о конфиденциальности — подписывается перед тем, как предоставить подрядчику какой-либо доступ к системам, а не после.
• 3. Собственно выполнение, в окне, заранее сообщённом внутренней команде, чтобы его не спутали с реальной атакой в процессе.
• 4. Предварительный отчёт с найденными уязвимостями, классифицированными по серьёзности и потенциальному влиянию на бизнес, а не только по чисто техническим критериям.
• 5. Окно устранения, в течение которого внутренняя команда или подрядчик по ИТ-обслуживанию исправляет найденные проблемы.
• 6. Повторное тестирование, которое явно подтверждает, что устранение сработало — шаг, который пропускают чаще всего, и именно он превращает аудит в теоретическое упражнение при отсутствии.
• 7. Итоговый отчёт, документирующий весь процесс для партнёра, страховщика или будущего аудита.

Что должен содержать, в итоге, серьёзный отчёт

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

Как выбрать подрядчика: вопросы, которые делают разницу

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

• Какой точный охват включён — количество систем, приложений и локаций, протестированных, письменно, а не на словах.
• Какие сертификаты есть у команды, выполняющей тестирование — международно признанные сертификаты в этой области, например OSCP или CEH, являются релевантным индикатором, но не абсолютной гарантией.
• Включено ли повторное тестирование после устранения в цену или оно оплачивается отдельно — стоит уточнить до подписания, а не после первого отчёта.
• Какое покрытие ответственности и конфиденциальности предлагает подрядчик, учитывая, что у него будет временный доступ к чувствительным системам компании.
• Сколько времени отведено на само выполнение — серьёзный аудит или тест на проникновение на реальном охвате редко завершается за несколько часов.

Как часто компании нужен внешний аудит

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

Частые ошибки, которых стоит избегать

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

Что сделать конкретно перед обращением к подрядчику

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

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

Частые вопросы

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

Сколько примерно стоит аудит ИТ-безопасности для небольшой компании? Во многом зависит от охвата — сколько систем, приложений и локаций проверяется и как часто. Здесь нет стандартного рыночного тарифа, который можно привести без риска ввести в заблуждение; запросите предложения хотя бы у двух подрядчиков с одинаково описанным охватом.

Нужен ли внешний аудит, если у нас уже настроены firewall, MFA и политика паролей? Базовая гигиена снижает риск, но не подтверждает независимо, что всё работает правильно, полностью и без недокументированных исключений. Внешний аудит проверяет именно это.

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

Подрядчик, который проводит аудит, сам исправляет найденные уязвимости? Как правило, не автоматически. Стандартный аудит даёт отчёт с рекомендациями; само устранение берёт на себя либо внутренняя команда, либо подрядчик по ИТ-обслуживанию, по отдельному договору. Повторная проверка после устранения должна быть явно включена или согласована в изначальном предложении.

Проверяйте, а не предполагайте

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

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