Мифы об информационной защите: что правда, а что маркетинг

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

Миф № 1. «Антивирус нас защитит»

Классический антивирус на сигнатурах ловит известное вредоносное ПО — и только его. Новых образцов появляется быстрее, чем вендоры успевают выпускать обновления: по статистике AV-TEST, речь идёт о сотнях тысяч новых файлов в день. Плюс современные атаки всё чаще идут через легитимные инструменты администратора (подход living off the land): здесь антивирусу ловить нечего, потому что команды выглядят как обычная работа системного администратора.

Показательный кейс — уязвимость Log4Shell (CVE-2021-44228) в популярной Java-библиотеке. Никакой антивирус от неё не спасал: помогали только патчи, правила WAF и поиск скомпрометированных серверов в логах. Вывод простой: антивирус — это базовая гигиена, а не щит. Реальную защиту дают управление обновлениями, ограничение прав и сегментация сети.

Миф № 2. «Мы маленькие, нас никто не атакует»

Атаки давно автоматизированы. Сканеры круглосуточно прочёсывают интернет в поисках открытого RDP, старого Exchange, непропатченных VPN-шлюзов — им неважно, кто вы и сколько у вас сотрудников. Более того, малый и средний бизнес — любимая цель шифровальщиков: там нет отдельного ИБ-специалиста, а выкуп заплатить проще, чем восстанавливать всё с нуля.

Отчёты вроде Verizon DBIR из года в год показывают: значительная доля взломов приходится именно на небольшие компании. Работает не аргумент «нас никто не тронет», а закрытый наружу RDP (доступ только через VPN с двухфакторкой), резервные копии и обученные сотрудники.

Миф № 3. «Сложный пароль плюс регулярная смена — это безопасность»

Совет менять пароль каждые 90 дней тянется из руководств начала 2000-х. NIST SP 800-63B прямо признал: принудительная регулярная смена скорее вредит — люди просто дописывают цифру к старому паролю. Реальная защита — длинные парольные фразы, менеджер паролей, уникальный пароль для каждого сервиса и включённая двухфакторная аутентификация.

Тут есть нюанс, о котором редко говорят: обычные одноразовые коды из SMS и приложений-аутентификаторов обходят фишинговые наборы вроде Evilginx, которые перехватывают сессию в реальном времени. Поэтому для критичных систем и административных доступов правильный выбор — аппаратные ключи стандарта FIDO2/WebAuthn, устойчивые к фишингу по своей архитектуре.

Миф № 4. «SIEM с ИИ сам всё найдёт»

«Искусственный интеллект» в ИБ-маркетинге чаще всего означает модель, которая умеет отличать один типовой алерт от другого. Без настройки источников, корреляционных правил и — главное — человека, который смотрит на события, SIEM превращается в дорогой сборщик логов и генератор алерт-шторма, где настоящее предупреждение тонет среди ложных срабатываний.

Для малого и среднего бизнеса честнее смотреть не на коробку SIEM, а на сервисы MDR (managed detection and response): за вашей инфраструктурой наблюдают живые аналитики, а вы платите за результат, а не за железо и лицензии. Инструмент без процесса и владельца — просто расходы.

Миф № 5. «Мы прошли пентест — значит, защищены»

Пентест — это фотография инфраструктуры на конкретную дату. Через месяц после теста выходит критическая CVE в вашем VPN-шлюзе или библиотеке, и отчёт о прошедшем тесте перестаёт иметь значение. Безопасность — это процесс, а не разовое мероприятие.

Работает конвейер: регулярное сканирование уязвимостей, контроль зависимостей и обновлений, автоматические проверки кода (SAST/DAST) на каждом изменении в CI/CD. Пентест при этом полезен как независимая проверка раз в год-два — но не как страховка от всего.

Миф № 6. «Своё железо надёжнее облака»

У облачных провайдеров есть модель разделения ответственности: провайдер отвечает за физику, ЦОД и гипервизор, а вы — за доступы, конфигурацию и данные. Миф «мы в изолированном контуре, значит, в безопасности» разбивается о реальность: большинство утечек происходит из-за ошибочных настроек, украденных ключей и забытых тестовых серверов — и в собственном ЦОД это работает точно так же.

Главный вопрос не в том, где лежат данные, а в том, кто и как к ним получает доступ, как вы отслеживаете изменения и как быстро реагируете на инцидент. И на «своём» железе, и в облаке эти процессы приходится выстраивать самостоятельно.

Миф № 7 (российская специфика). «Сертифицированный продукт = защищённый продукт»

Сертификат ФСТЭК или ФСБ подтверждает, что продукт соответствует формальным требованиям регулятора — не больше. Это не гарантия отсутствия уязвимостей и не гарантия того, что вендор оперативно выпустит исправление. Я не раз видел «сертифицированные» решения с критическими CVE и месяцами ожидания обновления, потому что процедура сертификации занимает больше времени, чем жизненный цикл уязвимости.

Выполнение требований 152-ФЗ и ФСТЭК — необходимое условие для бизнеса, но не достаточное для безопасности. Документы и процессы — это про соответствие регуляторике, а не про то, что атака не случится. Относитесь к сертификату как к пропуску на рынок, а не как к щиту.

Что реально работает вместо магии

  • Патчи и управление обновлениями — автоматизированно, включая библиотеки в коде, а не только операционки.
  • Двухфакторная аутентификация на всём, что смотрит в интернет; для администраторов — аппаратные ключи FIDO2.
  • Резервные копии по схеме 3-2-1 (три копии, два носителя, одна офлайн) и регулярные проверки восстановления — единственная рабочая защита от шифровальщиков.
  • Принцип наименьших привилегий и сегментация сети: сотрудник не должен видеть бухгалтерию, а гостевая сеть — не должна доставать до серверов.
  • Секреты и ключи — только в секрет-менеджере, никогда в коде и конфигах в Git.
  • Мониторинг, у которого есть владелец: хотя бы один человек, который смотрит алерты и реально реагирует.
  • Регулярный разбор инцидентов: подозрительные входы, фишинговые письма, неожиданные изменения конфигураций.

Готовой защиты, которую можно купить и забыть, не существует. Вендоры продают инструменты, а безопасность делают процессы: обновления, доступы, резервные копии и люди, отвечающие за реакцию. Начните с чек-листа выше — это даст больше, чем очередной «модуль ИИ» за несколько миллионов рублей.

guest

0 Комментарий