Киберзащита без собственного отдела ИБ: кто отвечает и как проверить результат

Начать с того, что остановит работу компании

У двух компаний с одинаковым оборотом могут быть разные приоритеты защиты. Для интернет-магазина критичны доступность сайта, оформление заказов и оплата. Для небольшой оптовой компании — почта, учётная система и возможность продолжить отгрузки. Покупка одинакового набора средств без понимания этих различий не даёт понятного результата.

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

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

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

• NIST Cybersecurity Framework2.0: Small Business Quick-Start Guide

Проверять работу бизнеса, а не только счётчики защиты

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

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

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

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

• NIST Cybersecurity Framework2.0: Small Business Quick-Start Guide

Разделить обязанности до первого инцидента

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

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

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

Первый ответ поддержки, начало работ и восстановление — разные события. Обещание ответить за 15 минут нельзя автоматически читать как обещание восстановить сервис за те же 15 минут. Нужно уточнить конкретное действие, срок и условия обслуживания.

• NIST Cybersecurity Framework2.0: Small Business Quick-Start Guide

Выяснить, что именно входит в услугу

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

Например, документация Yandex Cloud разделяет базовую защиту на сетевом и транспортном уровнях и сценарии с корректными HTTP-запросами, которые используют узкие места приложения. Этот пример показывает, почему доступность канала сама по себе не подтверждает защиту корзины или авторизации.

Я работаю директором продукта Solar Space ГК «Солар». На примере нашего сервиса также важно различать задачи: AntiDDoS, AntiBot и WAF Lite входят в разные уровни веб-защиты. Их наличие не отменяет защиту учётных записей, исправление приложения и проверку резервных копий. Подробные ограничения бесплатного уровня разобраны в отдельной статье на сайте.

Автоматическая обработка трафика и доступность специалиста — отдельные характеристики. На публичной странице Solar Space указана базовая поддержка 8/5, расширенная круглосуточная — по запросу. Поэтому ночное реагирование и сроки восстановления нужно обсуждать применительно к выбранному уровню обслуживания, а не выводить из наличия самого сервиса.

• Yandex DDoS Protection в Virtual Private Cloud
• Подключение сервисов
• WEB AntiDDoS

Посчитать обычный месяц, сезонный пик и инцидент

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

Важно выяснить, за что берётся плата: ресурсы, пользователи, объём трафика, запросы или хранение журналов. Кто предупредит о приближении к лимиту? При превышении появится дополнительный счёт, ограничение или согласованное изменение тарифа? В документации Solar Space, например, предусмотрена дополнительная оплата при превышении параметров. Это повод проверить условия своего договора, а не обещать неизменный счёт при любой нагрузке.

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

• Тарификация и оплата

Пять вопросов, с которых можно начать завтра

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

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