«Внедрение новых подходов часто сталкивается не с техническими барьерами, а с человеческим инерционным мышлением. Победа над фразой «у меня всё работает» требует не убеждения, а демонстрации, как старый подход уже создаёт уязвимости, которые остаются невидимыми, пока не произойдёт инцидент. Наша задача — сделать эти риски осязаемыми, переведя абстрактную угрозу в конкретные операционные потери, которые затрагивают личную ответственность.»
Почему «всё работает» — самый опасный аргумент
Инерция — мощнейшая сила в любой организации. Когда система функционирует без явных сбоев, у её операторов и владельцев формируется ложное чувство безопасности. Заявление «всё работает» технически может быть правдой: услуги доступны, пользователи работают, отчётность формируется. Однако этот аргумент игнорирует фундаментальный принцип информационной безопасности: отсутствие видимых инцидентов не равно отсутствию уязвимостей. Такое мышление эквивалентно утверждению, что замок на двери надёжен, потому что её ещё не взломали.
В контексте регуляторики, особенно 152-ФЗ и требований ФСТЭК, подобная позиция становится критически рискованной. Регуляторные требования часто предписывают проактивные меры: анализ угроз, аудит, периодическую оценку эффективности. Ожидание сбоя как единственного триггера для изменений прямо противоречит превентивной логике этих стандартов. «Работающая» система может годами накапливать технический долг, несоответствия политикам и скрытые векторы атак, которые обнаруживаются только при целенаправленной проверке или, что хуже, после успешного нарушения.
Корни сопротивления: что на самом деле стоит за фразой
Чтобы эффективно противодействовать, нужно понимать, что скрывается за этим кажущимся простым отказом.
- Страх неизвестности и ответственности. Любые изменения несут риски. Если новая конфигурация или инструмент вызовут сбой, виноватым окажется инициатор изменений. Статус-кво воспринимается как безопасная гавань, где личная ответственность за сбои уже размыта временем.
- Когнитивная перегрузка. Для специалиста, который годами поддерживал текущую конфигурацию, изучение новой модели (например, переход от периметровой безопасности к Zero Trust) требует значительных умственных затрат. Проще отмахнуться, чем признать необходимость переучиваться.
- Отрицание риска. Пока не случилось масштабного инцидента с материальными потерями или вниманием регулятора, угроза кажется гипотетической. Люди плохо оценивают вероятности редких, но высокоимпактных событий.
- Ресурсные ограничения. Часто за фразой скрывается реальная нехватка времени, людей или бюджета. «Всё работает» становится эвфемизмом для «у нас нет ресурсов на ваш проект, и мы не хотим это обсуждать».
Тактика убеждения: от абстрактных угроз к конкретным потерям
Бороться с общими фразами общими фразами бесполезно. Нужно смещать фокус обсуждения с технического функционирования на управление рисками и операционную эффективность.
1. Говорить на языке бизнеса, а не ИТ
Вместо «нам нужно внедрить сегментацию сети» говорить: «Сейчас любой скомпрометированный рабочий компьютер в бухгалтерии потенциально имеет доступ к серверу с персональными данными. При утечке это прямая ответственность руководителя по 152-ФЗ и многомиллионные штрафы. Сегментация исключает этот риск, ограничивая перемещение внутри сети». Связывайте техническую меру с конкретными последствиями: финансовые потери, репутационный ущерб, административная ответственность.
2. Использовать данные, а не мнения
«Всё работает», это субъективное мнение. Ему нужно противопоставить объективные данные:
- Результаты автоматизированного сканирования уязвимостей на критичных системах.
- Отчёты СОВ о подозрительных активностях, которые были заблокированы, но указывают на попытки атак.
- Сравнительный анализ текущей конфигурации с базовыми уровнями безопасности ФСТЭК.
Наглядная демонстрация, например, через дашборд, как много событий безопасности фильтруется на подступах, помогает показать, что система работает не «просто так», а благодаря постоянно преодолеваемым угрозам. Отсутствие изменений может означать, что фильтры устарели.
3. Превратить угрозу в историю
Приводите не абстрактные сценарии, а кейсы из новостного поля российского ИТ или смежных отраслей. «В прошлом месяце у компании-конкурента произошёл инцидент, схожий с нашим потенциальным сценарием. Из-за отсутствия контроля привилегированных доступов злоумышленник получил права администратора и шифровальщиком парализовал работу. СМИ писали об этом неделю. Проверка ФСТЭК после инцидента выявила десятки нарушений. Вот отчёт о мерах, которые они теперь вынуждены срочно внедрять под давлением регулятора и на неблагоприятных условиях».
4. Предложить пилот, а не революцию
Запрос на глобальные изменения пугает. Предложите минимально жизнеспособный шаг: «Давайте не будем менять всё сразу. Выделим один не самый критичный сегмент или одну группу пользователей. Внедрим новую модель (например, контроль доступа на основе ролей) там. Оценим результаты, сложности, реальный эффект за три месяца. Если не сработает — откатим. Это позволит нам получить факты для принятия решений, а не спорить на основе предположений». Это снижает воспринимаемый риск.
Инструменты и артефакты для демонстрации «неработы»
Создавайте документальные свидетельства, которые сложно игнорировать.
- Матрица соответствия. Таблица, где в одной колонке — требование регулятора (например, пункт приказа ФСТЭК №239), в другой — текущее состояние в системе, в третьей — статус (соответствует/частично/не соответствует), в четвёртой — выявленный риск. Такой документ формализует разговор.
- Карта рисков. Визуализация, где по осям «вероятность» и «влияние» размещены сценарии инцидентов. Текущее состояние системы можно отметить на этой карте, показав, какие риски находятся в «красной» зоне.
. - Сравнительная смета. Расчёт двух сценариев: стоимость постепенного планового внедрения улучшений против ориентировочной стоимости реагирования на инцидент (включая простои, восстановление, штрафы, работу с регулятором). Цифры часто оказываются красноречивее любых слов.
Когда «всё работает» — не отговорка, а диагноз
Иногда эта фраза сигнализирует о более глубоких проблемах в организации.
- Отсутствие метрик безопасности. Если нет показателей, кроме «работает/не работает», значит, безопасность не управляется, а администрируется. Нужно вводить KPI: время обнаружения инцидентов, процент систем, соответствующих базовому уровню, количество непроверенных исключений в правилах доступа.
- Разрыв между ИТ и безопасностью. Команда эксплуатации может искренне не знать о требованиях и угрозах, с которыми работает служба информационной безопасности. Здесь нужны регулярные кросс-функциональные воркшопы, где на тестовых стендах демонстрируется, как эксплуатационная конфигурация может быть использована для атаки.
- Культура избегания ответственности. В такой среде любое изменение — угроза. Работать нужно не с конкретным аргументом, а с культурой, внедряя практики blameless postmortem (разбор инцидентов без поиска виноватых) и поощряя эксперименты в контролируемой среде.
Заключение: перевод стрелки
Ключевая задача — изменить сам вопрос. Не «почему мы должны это поменять, если всё работает?», а «как мы можем доказать, что текущее состояние действительно безопасно и соответствует требованиям?». Переложите бремя доказательства на сторонников статус-кво. Попросите их документально подтвердить, что система не только функционирует, но и устойчива к актуальным угрозам и проходит по всем пунктам требований регулятора. В большинстве случаев такого подтверждения не найдётся, и разговор автоматически сместится в плоскость того, какие изменения необходимы для получения этих доказательств. Таким образом, борьба превращается не в конфронтацию, а в совместный поиск аргументов для внутренних и внешних проверяющих.