В любой компании незаметно раскручивается старая пластинка: админы жалуются, что защитники «глушат» сервера агентами, безопасники парируют обвинением «вы сами открыли дверь в инфраструктуру». При этом обе команды, если смотреть сверху, строят один и тот же продукт — живой сервис, который должен и работать быстро, и не превращаться в точку входа для чужих рук. Просто исторически их мерили разными линейками.
Интересно наблюдать, как вопросы меняют краску, когда речь идёт о проекте «с нуля». Стоит архитектору позвать безопасника за стол на этапе выбора стеков, и большинство конфликтов исчезает ещё до того, как успели родиться. Учитывается формат логов, включается MFA в предполагаемом SSO, в бюджет сразу попадает песочница для почтового шлюза. Никому не нужно потом объяснять, почему «доработать» обойдётся втрое дороже, чем вписать требование в спецификацию. По странной иронии, именно тот, кто отвечает за защиту, часто первый предлагает самый быстрый способ развернуть новый сервис — просто потому, что у него на столе лежит карта будущих ограничений.
Совсем другая картина, когда отдел ИБ появляется в компании спустя годы спонтанного роста. Ожидание дирекции звучит как сценарий волшебной палочки: «Двое специалистов за квартал закроют десятилетний технический долг». Но унаследованные пароль «1234» в BIOS, устаревшие прошивки и единственный контроллер домена на физическом ящике двадцатилетней давности никуда не деваются от приказа «защитить». Тут уже не победить рывком; требуется спокойная инвентаризация, честный список приоритетов и долгий путь снижения рисков, где каждая маленькая победа важнее декларативной «тотальной защиты к концу месяца».
Любопытно, как меняется тон разговора, когда IT- и ИБ-команды получают общие метрики: простой сервиса, SLA для внутренних пользователей, время восстановления после инцидента. В этот момент вопрос «ставим ли мы EDR» перестаёт звучать как драка за ресурсы; он превращается в совместную задачу: как внедрить так, чтобы не увеличить задержку на диске и при этом закрыть окно угроз. Иногда оказывается, что агрессивные настройки сканирования можно перенести на ночное окно, а где-то производительность спасает кэш в RAM — компромисс находится быстрее, чем казалось.
Может быть, в конечном счёте вся история сводится к простой экономике: чем раньше риск заложен в проект, тем дешевле обходится его нейтрализация; чем сложнее и дороже становится атака, тем менее привлекательна цель. И если ИТ и ИБ двигаются в унисон, шансов у потенциального противника искать «более лёгкую добычу» заметно больше, чем поводов для внутренних баталий.
Добавить комментарий