Hunter po: Новая страница: «==Ошибка №1. ИБ живет отдельно от бизнеса== Файл:Ошибка №1. ИБ живет отдельно от бизнеса.jp...»

2025-12-20T16:46:42Z

Новая страница: «==Ошибка №1. ИБ живет отдельно от бизнеса== Файл:Ошибка №1. ИБ живет отдельно от бизнеса.jp...»

Новая страница

==Ошибка №1. ИБ живет отдельно от бизнеса==

[[Файл:Ошибка №1. ИБ живет отдельно от бизнеса.jpg|x250px]]

Когда безопасность не встроена в экономику и финансы, операционные процессы и стратегию, она превращается в "блокера" и бессмысленный набор запретов. В таких компаниях ИБ узнает о запуске продукта в день релиза, о новых подрядчиках – после начала работ, а о внедрениях – когда что-то ломается.

Например, один крупный ритейлер потерял миллионы из-за остановки нового мобильного приложения: ИБшники не участвовали в проекте, и API вышел в прод без даже базовых защитных мер, включая и банальную авторизацию. Утечка данных 200k пользователей стала следствием организационного разрыва между ИБ и DevOps.

Как исправить:

➡️ Встроить ИБ в жизненный цикл продукта, закупок, DevOps, изменения инфраструктуры.

➡️ Привязать риски безопасности к бизнес-метрикам (ну или пойти по пути недопустимых событий).

➡️ Сформировать у руководства понимание, что ИБ – функция управления бизнес-рисками, а не "технический отдел".

==Ошибка №2. Не работают политики и регламенты==

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

Например, в одной финансовой компании политика по управлению доступами требовала отключать доступ уволенного сотрудника в течение часа, но ИТ делала это "когда дойдут руки", а иногда и вовсе не узнавала о факте увольнения, так как HR "забывал" уведомить об этом соответствующие подразделения. Инсайдер, экс-сотрудник, воспользовавшись этим "окном" унес из облачной CRM десятки контрактов.

Как исправить:

➡️ Политики должны описывать реальные процессы, а не процессы должны подстраиваться под бумажные процессы.

➡️ Нормативы должны быть встроены в ITSM / DevOps-платформы.

➡️ Контроль исполнения – обязательная часть аудита.

==Ошибка №3. Неправильное распределение ответственности==

Классическая ошибка: "ИБ отвечает за все". На деле безопасность – распределенная функция (это вообще-то функция, а не подразделение). Когда ответственность не формализована, никто не отвечает за доступы, обновления, уязвимости, конфиги и мониторинг.

Например, в одной госструктуре ИТ-администраторы считали, что патчи ставит ИБ, а ИБ считала наоборот. Результат – эксплуатация старого RCE в Exchange и компрометация внутреннего домена.

Как исправить:

➡️ Составить матрицу RACI на ключевые процессы (не забывайте ее поддерживать в актуальном состоянии).

➡️ Декомпозировать зоны ответственности: ИТ, ИБ, DevOps.

➡️ Закрепить ответственность в форме KPI.

==Ошибка №4. Ориентация только на инструменты==

Руководство покупает "волшебные коробки", а процессы остаются прежними. SIEM без собственных, регулярно обновляемых правил корреляции, DLP без классификации информации согласно ее ценности и процессов обработки, EDR без реагирования – мертвые инвестиции.

Например, компания внедрила SIEM, но не выделила команду аналитиков, которые бы постоянно проводила анализ событий ИБ, адаптацию правил, написание корреляционных цепочек и т.п. Полгода SIEM работал "на запись", а атака через компрометацию VPN-доступа осталась незамеченной – хотя события были в логах.

Как исправить:

➡ Любой инструмент не может существовать без людей, процессов и интеграции.

➡ Начинать нужно с процессов, а не с закупок.

==Ошибка №5. Отсутствие стратегии развития ИБ==

Работа ведется хаотично, в режиме тушения пожаров. Нет целевой архитектуры, дорожной карты, метрик зрелости и и процесса ее оценки.

Например, у крупного холдинга SOC появился раньше, чем инвентаризация ресурсов. В результате SOC не видел 40% инфраструктуры.

Как исправить:

➡ Построить модель зрелости (NIST CSF, разные варианты CMM).

➡ Выработать 2–3-летнюю дорожную карту с приоритетами.

➡ Связать стратегию ИБ со стратегией цифровой трансформации и бизнес-стратегией.

==Ошибка №6. Пентесты раз в год вместо постоянного контроля==

Однократный пентест – иллюзия безопасности. Уязвимости появляются ежедневно.

Например, один банк прошел летом пентест в соответствие с требованиями Банка России и ФСТЭК. Осенью появилась критическая уязвимость в VPN-шлюзе – ее никто не заметил. Через нее APT-группировка получила доступ внутрь банковской инфраструктуры и месяц держалась внутри сети.

Как исправить:

➡ Внедрить постоянное сканирование уязвимостей, в том числе включая и внедрение решений класса BAS (Breach & Attack Simulation).

➡ Проводить периодические Red Team / Purple Team.

➡ Выставить компанию или ее ключевые системы на Bug Bounty и кибериспытания.

==Ошибка №7. Игнорирование «некритичных» уязвимостей==

Уязвимость CVSS 5.0 может быть идеальной точкой входа, если ее эксплуатация проста.

Например, в 2023–2024 годах сотни компаний пострадали от массовых атак через уязвимости в Confluence и MOVEit, имеющий невысокий CVSS.

Как исправить:

➡ Оценивать уязвимости по их эксплуатируемости/трендовости (EPSS, KEV), а не только по их базовому уровню CVSS.

➡ Учитывать бизнес-контекст и критичность систем, в которых найдены уязвимости.

➡ Строить процесс риск-ориентированного обновления.

==Ошибка №8. Нет отлаженного процесса реагирования==

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

Например, в медицинской организации SOC увидел расширение плацдарма (lateral movement) шифровальщиком, но не смог остановить атаку из-за отсутствия полномочий. Через 3 часа был зашифрованы сегменты с данными пациентов, электронными медицинскими записями и медицинским оборудованием.

Как исправить:

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

➡ Проводить регулярные киберучения (штабные и технические, на киберполигонах).

➡ Дать SOC привилегии осуществлять "срочные действия".

==Ошибка 9. Нет обучения и тренировки==

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

Например, на заводе оператор не знал, что делать при блокировке HMI шифровальщиком и в панике обесточил часть цеха, остановив производство и увеличив ущерб от атаки.

Как исправить:

➡ Регулярные штабные киберучения, а также иные формы сценарной геймификации процесса обучения.

➡ Практические тренировки реагирования на инциденты (как противопожарные тренировки).

➡ Обучение не только и не столько служб ИБ и ИТ, но и бизнес-подразделений.

==Ошибка №10. Нет реестра активов==

Нельзя защитить то, чего не знаешь. Замурованные в стены сервера (был у меня такой кейс как-то), виртуалки-"летучие голландцы", установленные для удобства Wi-Fi-точки доступа, забытые VPN-доступы, старые тестовые стенды – все это прекрасные входы внутрь инфраструктуры.

Например, в Colonial Pipeline одной из точек входа был старый VPN-аккаунт без MFA, невнесенный в список активов.

Как исправить:

➡ Формирование собственной базы CMDB или доступ к ИТшной, а также автоматическое обнаружение активов.

➡ Инвентаризация облаков, SaaS, теневых ИТ (shadow IT), включая теневые ML.

➡ Классификация данных и сервисов по критичности для бизнеса.

==Ошибка №11. Слабый контроль подрядчиков (supply chain)==

Внешние вендоры имеют доступ к вашей инфраструктуре, но вы не контролируете их безопасность и их доступы в вашу внутрянку.

Например, атаки на SolarWinds, MOVEit, 3CX – крупнейшие supply chain инциденты последних лет.

Как исправить:

➡ Внедрить процесс оценки вендоров.

➡ Требовать MFA, регистрации событий, ограничение доступов.

➡ Контролировать работу подрядчиков в реальном времени.

==Ошибка №12. Нет безопасной разработки и контроля изменений==

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

Например, в 2022 один финтех-стартап потерял десятки миллионов из-за ошибки в авторизации в API (IDOR). Ошибка появилась после "быстрого" релиза кода без его анализа.

Как исправить:

➡ Ввести в компании практику DevSecOps.

➡ Включение Security Gate в CI/CD.

➡ Внедрить статический и динамический анализ и проверка IaC.

==Ошибка №13. Резервные копии есть, но не тестируются==

Половина компаний узнает о том, что бэкапы нечитаемы и данные невосстановимы, исключительно во время инцидентов с шифровальщиками.

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

Как исправить:

➡ Тестировать восстановление из резервных копий регулярно.

➡ Хранить оффлайн-копии.

➡ Документировать процедуры восстановления.

==Ошибка №14. Ошибки конфигураций==

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

Например, открытые для общего доступа корзины Elasticsearch/S3/MinIO приводили к утечкам миллионов данных в компаниях Uber, Verizon и десятках других.

Как исправить:

➡ Применять автоматические сканеры конфигураций.

➡ Проверять соответствие политикам безопасности (например, CIS Benchmarks или предоставленные разработчиками сканеров безопасности).

➡ Обязательный анализ кода IaC.

==Ошибка №15. Отсутствие сегментации==

Плоская сеть – это рай для злоумышленников, расширяющих плацдарм внутри скомпрометированной инфраструктуры.

Например, WannaCry распространялся мгновенно именно в плоских сетях без сегментации. То же самое – Ryuk, Conti и другие шифровальщики.

Как исправить:

➡ Внедрять сетевую сегментацию, VLAN, микросегментацию.

➡ Внедрять Zero Trust Network Access.

➡ Ограничение межсервисных коммуникаций.

==Ошибка №16. Нет регистрации событий и мониторинга==

Компания может быть взломана месяцы назад – и не знать об этом, а хакеры орудуют внутри инфраструктуры, не боясь обнаружения.

Например, Equifax была скомпрометирована более двух месяцев прежде, чем заметила активность в системе.

Как исправить:

➡ Регистрация всех критичных для конкретной компании/процесса/системы событий.

➡ Централизация логов.

➡ Построение SOC с аналитикой и ML-корреляцией событий.

==Ошибка №17. Слабая или отсутствующая MFA==

Усталость от push'ей и запросов на подтверждение аутентификации, однофакторные протоколы, использование одноразовых кодов в SMS, отсутствие защиты сессий – и злоумышленник внутри.

Например, во время взлома Uber в 2022 атакующий использовал усталость от push-уведомлений и социальный инжиниринг для обхода MFA. Аналогичным образом взламывали Cisco, казино MGM Grand и многие другие компании.

Как исправить:

➡ Внедрение FIDO2.

➡ Контроль устройства и контекстный доступ.

➡ Защищенные каналы выдачи токенов.

==Ошибка №18. Legacy-системы==

Старые ОС, уже не поддерживаемые производителем компоненты, устаревшие сервера и оборудование – идеальная мишень для атак.

Например, WannaCry массово поражал Windows XP, которая продолжала использоваться в больницах и госучреждениях.

Как исправить:

➡ Разработать и реализовывать план миграции.

➡ Виртуализация и изоляция legacy.

➡ Мониторинг вокруг критичных legacy-узлов.

==Ошибка №19. Теневые ИТ и данные (shadow IT / data)==

Облака, личные Google Docs, неучтенные SaaS, тестовые базы с реальными данными, оплаченные личными картами GPT-сервисы – все это выходит за рамки привычного контроля ИБ и является точкой проникновения в компанию и утечки данных.

Например, сотрудник случайно оставил копию клиентской базы в личном Dropbox → утечка и большой штраф от регулятора.

Как исправить:

➡ Открыть "официальный" способ решать нужные для выполнения служебных обязанностей задачи или предложить работникам корпоративные лицензии на нужные сервисы.

➡ Обеспечить мониторинг теневых сервисов и потоков данных (вообще, иметь карту информационных потоков также полезно, как и базу активов).

➡ Разработать и контролировать политику хранения данных.

==Ошибка №20. Отсутствие сети контактов между специалистами==

Во время инцидентов часто теряется драгоценное время, потому что ИБ, ИТ, DevOps, юристы, PR, подрядчики или специалисты с иными нужными компетенциями просто не могут оперативно связаться друг с другом. Контакты устарели, лежат в недоступных системах, хранятся у одного человека или вовсе отсутствуют.

Например, в одном финтехе при компрометации CI/CD ИБ не смогла найти DevOps-лида – его контактов не было в актуальном списке. В результате восстановление задержалось на несколько часов, и злоумышленники успели распространить вредоносный код на продовый кластер.

Как исправить:

➡ Создать и обновлять единый перечень аварийных контактов.

➡ Хранить его в нескольких местах, включая офлайн.

➡ Включить коммуникационные сценарии в программу учений.

==Ошибка №21. Отсутствие культуры ненаказания==

Когда за ошибки карают – их скрывают. Инциденты растут, а цикл обнаружения увеличивается.

Например, на одном производстве сотрудник заметил подозрительные файлы, но боялся сообщить, "вдруг он что-то сделал не так". Через час началось массовое шифрование внутри инфраструктуры.

Как исправить:

➡ Формировать прозрачную систему поощрения за раннее предупреждение.

➡ Анализ инцидентов без поиска виноватого (не путать с анализом root cause).

➡ Публичные кейсы успешного поведения.

==Ошибка №22. Коммуникация ИБ на "птичьем техническом диалекте"==

Когда CISO говорит на языке CVE, SIEM, EDR, SOC и ATT&CK, бизнес слышит белый шум. В итоге нужные решения не принимаются.

Например, одна компания откладывала внедрение MFA три года, потому что "доклад ИБ непонятен". После демонстрации удачного бизнес-кейса внедрили за месяц.

Как исправить:

➡ Переводить риски на язык денег и последствий.

➡ Давать руководству понятные ему сценарии и альтернативы.

➡ Построить "CISO Dashboard" с бизнес-метриками.

==Ошибка №23. Невыполнение требований compliance==

Компания может годами игнорировать обязательные требования регуляторов или отраслевых стандартов, но в момент инцидента это может обернуться штрафами, проверками, ограничениями деятельности, потерей лицензий и серьезными репутационными последствиями. Нередко оказывается, что ущерб от невыполнения некоторых нормативных актов (не всех) куда выше стоимости его соблюдения.

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

Как исправить:

➡ Проводить регулярную оценку соответствия адекватным требованиям и устранять пробелы до проверок и инцидентов.

➡ Автоматизировать контроль выполнения адекватных требований по ключевым зонам (доступы, сегментация, журналы регистрации).

➡ Встраивать compliance в архитектуру процессов, а не оформлять в виде отчетов "для аудиторов", или пытаться выполнить все в авральном режиме.

==Ошибка №24. Выгорание специалистов ИБ==

Перегруженные специалисты совершают ошибки, принимают плохие решения и покидают команду.

Например, SOC-команда крупной авиакомпании пропустила ранние признаки атаки, потому что работала в режиме постоянных переработок.

Как исправить:

➡ Реалистичные и обоснованные нагрузки.

➡ Автоматизация рутинных операций

➡ Поддержка команды и программы благополучия (well-being).

(c) Алексей Лукацкий 2025

Евангелие от Луки - История изменений

Hunter po в 17:09, 20 декабря 2025

Hunter po: /* Ошибка 9. Нет обучения и тренировки */

Hunter po: Новая страница: «==Ошибка №1. ИБ живет отдельно от бизнеса== Файл:Ошибка №1. ИБ живет отдельно от бизнеса.jp...»

← Предыдущая		Версия 16:47, 20 декабря 2025
Строка 111:		Строка 111:
	➡ Дать SOC привилегии осуществлять "срочные действия".		➡ Дать SOC привилегии осуществлять "срочные действия".

	==Ошибка 9. Нет обучения и тренировки==		==Ошибка №9. Нет обучения и тренировки==

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