Многие видят стабильность в том, чтобы ничего не трогать. Но в российской IT-регуляторике именно в «неприкосновенности» скрывается самый большой риск. Стабильная работа сегодня, это не гарантия, а временное затишье перед штормом, который ты не видишь, потому что мониторишь только зелёные лампочки. https://seberd.ru/5086
Когда «работает» — не значит «защищено»
В ИБ-отрасли сложился парад and#1079; представлений, где техническая исправность системы приравнивается к её безопасности. Если сервис отвечает на запросы, логи пишутся, а пользователи не жалуются, то всё в порядке. Это опасная иллюзия, которая особенно критична в контексте выполнения требований 152-ФЗ и документов ФСТЭК. Работающее приложение может годами содержать уязвимости, эксплуатировать устаревшие и неподдерживаемые библиотеки или передавать персональные данные по незашифрованным каналам. Всё это время оно будет «работать» для конечного пользователя, но при первой же проверке или целевой атаке обернётся миллионными штрафами и репутационными потерями.
Культура «не трогать, если не сломалось» часто идёт из эксплуатации, где главный KPI — uptime. Однако в безопасной разработке и сопровождении главный KPI, это управляемый и понятный уровень риска. Стабильность, достигнутая за счёт заморозки конфигураций и отказа от обновлений,, это мина замедленного действия.
Что скрывается за аргументом «зачем менять?»
За этим вопросом обычно стоят не лень или глупость, а конкретные, часто рациональные страхи. Их нужно не отметать, а понимать и адресовать.
Страх неизвестности и сбоев
Любое изменение, это риск. Разработчик или сисadmin опасается, что обновление библиотеки сломает совместимость, новая конфигурация межсетевого экрана заблокирует легитимный трафик, а переход на другой метод шифрования приведёт к потере данных. Этот страх подпитывается предыдущим негативным опытом, когда «улучшения» заканчивались ночными авралами.
Недостаток ресурсов
Внедрение требует времени: на изучение, тестирование, rollout и откат в случае проблем. В условиях цейтнота и загруженности операционными задачами проще отложить «профилактику» на потом. Особенно если прямая выгода от изменений (например, от установки патча безопасности) неочевидна для бизнеса.
Отсутствие метрик и обратной связи
Сложно аргументировать необходимость изменений, если нет данных. Как доказать, что текущая версия web-сервера опасна, если он «просто работает»? Как показать, что новый метод контроля целостности предотвратит инцидент, которого ещё не было? Без понятных метрик безопасности (например, уровень покрытия средств защиты, время обнаружения уязвимостей) разговор сводится к абстрактным «лучшим практикам», которые легко проигнорировать.
Конфликт приоритетов между отделами
Для бизнеса приоритет — новые функции и скорость выхода на рынок. Для службы безопасности — снижение рисков и compliance. Для эксплуатации — стабильность. Часто отдел разработки, которому говорят «зачем менять, если всё работает», оказывается между молотом требований регулятора и наковальней дедлайнов по продукту.
Тактика перевода разговора с эмоций на факты
Чтобы преодолеть сопротивление, нужна не агрессия, а стратегия. Ваша цель — не доказать свою правоту, а совместно с коллегами перевести обсуждение из плоскости «работает/не работает» в плоскость «риск/приемлемость риска».
Говорите на языке бизнес-рисков, а не технических страшилок
Вместо фразы «у нас устаревшая CMS, в ней CVE-2023-12345» говорите: «Платформа управления контентом, на которой работает наш публичный портал, содержит критическую уязвимость. Её эксплуатация позволяет удалённо выполнить код. В случае реализации угрозы мы можем столкнуться с компрометацией персональных данных 100К пользователей, что является нарушением ст. 15 152-ФЗ. Потенциальный штраф для юрлица — до 6 млн рублей, плюс возможное приостановление обработки. Риск оценивается как высокий. Патч доступен, его установка займёт 2 часа downtime в ночное время.»
Такая формулировка связывает техническую деталь с юридическими, финансовыми и репутационными последствиями.
Визуализируйте технический долг в безопасности
Создайте и поддерживайте панель (dashboard), которая наглядно показывает «задолженность»:
- Количество систем на неподдерживаемых ОС или со EOL software.
- Список критических и высоких уязвимостей, отсортированный по сроку жизни.
- Уровень покрытия средств защиты информации (СЗИ) относительно требований ФСТЭК для данного класса ИС.
- График «старения» криптографических ключей и сертификатов.
Такой дашборд превращает абстрактную проблему в конкретные, измеримые задачи. Он же служит железным аргументом при общении с руководством о необходимости ресурсов.
Внедряйте изменения через пилоты и постепенный rollout
Предложите не менять всё и сразу, а начать с наименее критичного сервиса или test-среды. Например: «Давайте обновим библиотеку logging в одном из внутренних микросервисов, который не затронут SLA. Протестируем, посмотрим на логи, оценим влияние. Если всё ок — составим план ротации для остальных.» Это снижает perceived risk для команды эксплуатации.
Автоматизируйте сбор доказательной базы
Используйте инструменты, которые сами находят аргументы за изменения. Не вы приходите и говорите «надо», а система формирует отчёт.
- SAST/DAST-сканирование в CI/CD пайплайне не просто блокирует сборку, но и создаёт тикеты с конкретными уязвимостями, их CVSS-оценкой и рекомендациями по исправлению.
- SCA-инструменты (Software Composition Analysis) автоматически обнаруживают устаревшие и уязвимые зависимости в проектах, привязывая их к кодовой базе.
- Скрипты конфигурационного аудита могут регулярно проверять настройки инфраструктуры на соответствие стандартам (например, CIS Benchmarks) и генерировать дельту.
Когда проблема и путь её решения документированы автоматически, это не личное мнение security-инженера, а объективный вывод системы.
Интеграция безопасности в процессы, а не в борьбу
Конечная цель — сделать вопросы безопасности естественной частью рабочего процесса, а не внешним раздражителем.
Shift Left, но не как лозунг, а как процесс
Принцип «сдвига безопасности влево» означает вовлечение security-специалистов на самых ранних этапах проектирования архитектуры и выбора технологического стека. На этом этапе легче заложить правильные решения (например, выбрать поддерживаемый фреймwork, спланировать схему разграничения доступа), чем потом переделывать «работающую» систему. Проводите threat modeling-сессии для новых сервисов вместе с архитекторами и разработчиками.
Понятные и выполнимые требования
Внутренние стандарты кодирования, требования к конфигурации и политики должны быть не 100-страничными PDF, а интегрированными в рабочие инструменты. Например, набор правил для линтера (ESLint с security-плагинами), pre-commit хуки, проверяющие на наличие секретов в коде, или Terraform-модули с уже «зашитыми» безопасными настройками по умолчанию.
[КОД: пример pre-commit hook с вызовом truffleHog для поиска секретов]
Культура не «кого винить», а «как решить»
Критически важно, чтобы обнаружение уязвимости не превращалось в поиск виноватого. Внедряйте практику blameless postmortem для security-инцидентов. Фокус должен быть на том, почему процесс позволил уязвимости попасть в продуктив, и как улучшить процесс, чтобы предотвратить подобное в будущем. Это снимает защитную реакцию у разработчиков и encourages прозрачность.
Что делать, если сопротивление исходит сверху?
Самый сложный сценарий — когда аргумент «всё работает» звучит от руководства, которое не хочет выделять бюджет или время на «невидимые» улучшения.
- Свяжите с конкретными KPI руководства. Говорите не о CVE, а о риске срыва госконтракта из-за несоответствия требованиям регулятора, о потенциальных штрафах по 152-ФЗ, которые отразятся на финансовых отчётах, о репутационных рисках, которые повлияют на стоимость компании.
- Предложите roadmap, а не разовую задачу. Покажите поэтапный план модернизации, привязанный к бизнес-циклам. Например, «обновление ядра ОС на всех web-серверах мы можем провести параллельно с запланированным на Q3 обновлением аппаратного парка».
- Используйте внешние триггеры. Иногда лучшим аргументом становится не ваше внутреннее исследование, а новость об инциденте у прямого конкурента или ужесточение требований ФСТЭК в новой редакции методического документа. Это переводит тему из разряда гипотетических рисков в категорию актуальных угроз.
Работающее — значит управляемое
Бороться с установкой «зачем менять работающее», это не техническая, а в первую очередь коммуникативная и процессная задача. Ключ в переходе от субъективных ощущений к объективным метрикам риска, от тактики устрашения к стратегии постепенной интеграции безопасности в ДНК процессов разработки и эксплуатации.
Цель достигается, когда команда сама начинает видеть в устаревшей зависимости или неконфигурированном сервере не стабильный элемент, а источник неопределённости и потенциальных проблем, управлять которым нужно proactively. В условиях российского регулирования это уже не вопрос лучших практик, а обязательное условие survival в долгосрочной перспективе.