По данным IBM, средняя стоимость утечки данных в финансовом секторе - $5,9 млн. Красивая цифра для презентации. А вот что за ней: большинство банков узнают о компрометации не из алертов SOC, а из звонка регулятора или публикации в telegram-канале. Между точкой входа атакующего и обнаружением проходят недели, иногда месяцы. За это время группировки вроде Cobalt и Silence успевают пройти полный kill chain - от фишингового письма до управления SWIFT-терминалом.
Эта статья - карта всей предметной области: от конкретных векторов атак и техник пентеста до регуляторных требований и правил детекции. Каждый раздел - точка входа в детальный разбор, который привязан в отдельных материалах.
Карта темы: навигация по кластеру
| # | Подтема | Детальный разбор |
|---|---|---|
| 1 | Kill chain финансовых атак и методология пентеста | Пентест банка: векторы атак и техники проникновения |
| 2 | Атаки на SWIFT и процессинговые системы | Атаки на SWIFT и межбанковские системы |
| 3 | Уязвимости банковских API | Уязвимости банковских API: методология пентеста |
| 4 | Пентест банкоматов и POS-терминалов | Пентест банкоматов и POS-терминалов: jackpotting, shimming |
| 5 | Тестирование ДБО и мобильного банкинга | Пентест банковских приложений: от ДБО до detection-правил |
| 6 | Банковские трояны и вредоносное ПО | Банковский троян Casbaneiro: техники уклонения |
| 7 | Обход антифрод-систем | Обход антифрод систем: где защита слепа |
| 8 | Threat hunting и SOC в банке | Threat hunting в банке: IOC, SIEM-правила и APT-активность |
| 9 | Актуальные кибератаки 2025–2026 | Кибератаки на финансовый сектор 2025–2026: TTPs и detection |
| 10 | Взлом криптобирж | Утечка данных криптобиржи: предполагаемый взлом Grinex на $13,7 млн |
| 11 | Регуляторные требования и комплаенс | Требования ИБ: ГОСТ Р 57580, PCI DSS и Банк России |
Kill chain банковских атак: почему финансовый сектор теряет контроль за 4 шага
Атака на банк - не одномоментное событие. Это операция на недели, с чётким разделением на фазы. Группировки, работающие против финансового сектора, следуют устоявшемуся kill chain. Понимание каждого этапа - отправная точка и для пентеста, и для защиты.Фаза 1 - Initial Access. Точка входа почти всегда одна из двух: целевой фишинг (T1566.001 - Spearphishing Attachment по MITRE ATT&CK) или эксплуатация публично доступного приложения (T1190). По данным ФинЦЕРТ за 2024 год, фишинг составил около 8–9% от всех зарегистрированных атак на финансовый сектор, эксплуатация уязвимостей инфраструктуры - около 5–6%. В реальных проектах red team фишинг через поддельное письмо «от Центробанка» остаётся самым результативным вектором. Потому что люди верят бланкам.
Фаза 2 - Credential Access и Lateral Movement. После первичного закрепления атакующий собирает учётные данные: дамп LSASS (T1003.001), брутфорс сервисных учёток (T1110), перехват кредов через кейлоггер (T1056.001). Дальше - перемещение по сети через Pass the Hash (T1550.002) или использование легитимных аккаунтов (T1078). В банковской среде горизонтальное перемещение часто проходит через сегменты, которые формально изолированы, но на практике имеют маршрутизацию через management-VLAN. Формально - нельзя. Фактически - маршрут есть.
Фаза 3 - Доступ к целевым системам. Конечная цель зависит от группировки: SWIFT-терминал, процессинговый сервер, АБС (Diasoft, ЦФТ), HSM-интеграция. На этом этапе атакующий уже имеет привилегии доменного администратора или сервисного аккаунта критичной системы.
Фаза 4 - Financial Theft (T1657). Вывод средств: формирование платёжных поручений через SWIFT, манипуляция лимитами в процессинге, прямые переводы через скомпрометированные АРМ-ы КБР.
Каждая фаза - точка, где банк может обнаружить и остановить атаку. В реальности большинство банков детектируют вторжение только на фазе 4, когда деньги уже ушли.
Полный разбор kill chain с командами и детекшн-правилами - в гайде «Пентест банка: векторы атак и техники проникновения».
8 ключевых векторов атак на банки: что эксплуатируют в 2025–2026
Русскоязычные обзоры обычно ограничиваются «фишинг, DDoS, инсайдеры». На практике атаки на финансовый сектор значительно разнообразнее, и каждый вектор имеет свою специфику, отличную от атак на промышленность или ритейл.Фишинг и социальная инженерия
По данным IBM X-Force, генерация фишинговых писем с помощью GenAI стала быстрее в 11,4 раза при сопоставимом качестве. Для банков это означает рост объёма и правдоподобности атак: письма от «службы безопасности ЦБ», уведомления о «блокировке корсчёта», приглашения на «ФинЦЕРТ-вебинар» со вложенным документом. Атаки на клиентов через мессенджеры и звонки составили около 4% инцидентов по данным отчёта ФинЦЕРТ за 2024 год.Эксплуатация уязвимостей веб-приложений
Банковские API, интернет-банкинг, личные кабинеты - всё это публично доступные приложения. По OWASP Top 10 наиболее критичные риски: Broken Access Control (A01:2021 - протестирована в 94% приложений), Injection (A03:2021 - SQL/NoSQL/LDAP-инъекции) и Identification and Authentication Failures (A07:2021). В банковском контексте SQL-инъекция в форме перевода средств - это не утечка данных, а прямой вывод денег.Целевые многоэтапные атаки (APT)
ФинЦЕРТ в 2024 году зафиксировал случаи проникновения через подрядчиков: ИТ-провайдеров, внешние сервисы, интеграторов. По данным CrowdStrike Global Threat Report 2025, активность China-nexus adversaries выросла на 150% год к году. Для российского финансового сектора актуальны группировки с собственными TTP, детально описанными в MITRE ATT&CK.Supply Chain атаки
Атаки через цепочку поставок - попытка зайти в банк через доверенных поставщиков (OWASP A08:2021 - Software and Data Integrity Failures). Скомпрометированный подрядчик с VPN-доступом в банковский сегмент - это готовый backdoor, который не виден ни антивирусу, ни NGFW. На одном проекте мы видели ситуацию: интегратор с полным доступом к VLAN процессинга, а у него на рабочей станции - Windows 7 без патчей. Занавес.DDoS-атаки
DDoS остаётся самым массовым вектором: перегрузка серверов ДБО, процессинга, мобильного банкинга. Спланированная атака может длиться десятки часов силами ботнетов. Но DDoS часто служит дымовой завесой для параллельного проникновения через другие каналы - и вот это уже по-настоящему опасно.Инсайдерские угрозы
Выгрузка клиентских данных на USB, отправка отчётов в мессенджеры, продажа доступа в даркнете. Легитимные учётные записи (T1078 - Valid Accounts) - самый сложный для детекции вектор, потому что действия выглядят нормальными. Как отличить операциониста, который делает выгрузку по работе, от операциониста, который делает выгрузку на продажу? Вот именно.Атаки на криптовалютные операции
Криптобиржи и DeFi-сервисы работают в слабо регулируемых средах. Финтех-компании за пределами криптосектора тоже становятся мишенями: в 2026 году колумбийская BNPL-платформа Addi подверглась взлому с утечкой данных 34,5 млн пользователей. Подробный разбор предполагаемого взлома криптобиржи Grinex - в материале «Утечка данных криптобиржи: взлом Grinex на $13,7 млн».Ransomware
Группировки BlackByte, Play, DragonForce, Chaos активны против финансового сектора. По данным Picus Blue Report 2024, ряд ransomware-группировок показывает крайне низкий процент предотвращения в тестовых средах. Финансовые организации привлекательны для шифровальщиков из-за регуляторного давления: угроза публикации данных на DLS (data leak site) вынуждает банки платить выкуп быстрее, чем компании из других отраслей. Потому что штраф от ЦБ за утечку ПДн - это одно, а утечка реквизитов карт в паблик - совсем другое.Актуальные угрозы с TTP и detection-правилами разобраны в статье «Кибератаки на финансовый сектор 2025–2026».
Пентест банковских систем: 3 подхода и выбор вектора
Тестирование на проникновение в банке - не универсальный процесс. Выбор подхода зависит от цели, регуляторных требований и зрелости ИБ-функции заказчика.SWIFT-атаки и процессинг: где банк теряет миллионы
SWIFT-атаки - вершина kill chain. Группировки, которые добираются до SWIFT-терминала, уже прошли всё: получили доступ в сеть, достигли доменного администратора, нашли изолированный сегмент АРМ КБР.Типичный сценарий:
- Фишинговое письмо сотруднику операционного отдела → закрепление в пользовательском сегменте
- Lateral movement до контроллера домена → дамп NTDS.dit
- Обнаружение сегмента SWIFT (часто через VLAN-hopping или через management-интерфейс)
- Установка вредоносного модуля на SWIFT Alliance Lite2 или Alliance Access
- Формирование платёжного поручения MT103 с подменённым бенефициаром
- Вывод средств через сеть дропов до момента обнаружения
HSM (Hardware Security Module) - ещё одна критичная точка. Ошибки конфигурации в интеграции HSM с процессингом позволяют генерировать валидные ключи для подписи транзакций. На пентесте это проверяется через анализ PKCS#11-интерфейсов и аудит ACL на HSM-партициях.
Полный kill chain от фишинга до вывода средств с detection-правилами разобран в статье «Атаки на SWIFT и межбанковские системы».
Уязвимости банковских API: 5 точек, где ломается защита
Банковские API - рабочая лошадка современного финтеха: через них работают мобильные приложения, партнёрские интеграции, Open Banking. Но именно API оказываются самым слабым звеном.Пентест банковского API выявляет характерный набор проблем:
- BOLA/IDOR (Broken Object Level Authorization) - подмена идентификатора объекта в запросе. В банковском контексте: замена
accountIdв запросе/api/v1/accounts/{accountId}/balanceдаёт доступ к балансу чужого счёта. Это API1:2023 в OWASP API Security Top 10; для веб-приложений соответствует A01:2021 - Broken Access Control. Встречается чаще, чем хотелось бы. - Отсутствие rate limiting на критичных эндпоинтах - брутфорс OTP-кодов, подбор номеров карт через
GET /api/v1/cards/{PAN}. Без rate limiting четырёхзначный OTP подбирается за минуты. Четыре цифры, 10 000 комбинаций - математика простая. - Excessive Data Exposure - API возвращает полные данные объекта (включая PAN, CVV, ФИО), когда клиенту нужен только баланс. Логика «фильтровать на клиенте» проваливается при перехвате трафика.
- Инъекции (OWASP A03:2021) - SQL, NoSQL, LDAP. В банковских API инъекция в поле поиска транзакций позволяет не просто читать данные, а модифицировать записи о переводах.
- Broken Authentication (API2:2023 в OWASP API Security Top 10; соответствует A07:2021 для веб-приложений) - слабые реализации OAuth 2.0, предсказуемые JWT, отсутствие привязки токена к устройству. Перехваченный токен даёт полный доступ к сессии клиента.
/swagger.json). Второй - профилирование всех эндпоинтов в Burp Suite Pro с подключённым AuthMatrix для проверки авторизации.Детальная методология с примерами эксплуатации - в материале «Уязвимости банковских API: от разведки до эксплуатации».
Банкоматы и POS-терминалы: физический вектор, о котором забывают
Банкоматные сети - отдельный мир с собственными уязвимостями. Большинство ATM в российских банках работает под управлением Windows 7/10 Embedded (а встречается и Windows XP Embedded) с прямым подключением к процессинговому хосту.Основные техники атак
| Техника | Суть | Применимость |
|---|---|---|
| Jackpotting (Black Box) | Подключение внешнего устройства к диспенсеру для прямой выдачи наличных | ATM с доступным сервисным разъёмом, без шифрования XFS-команд |
| Shimming | Установка тонкого устройства в картоприёмник для перехвата данных чипа | POS/ATM без защиты EMV-протокола на уровне ядра |
| Malware-based Jackpotting | Установка вредоносного ПО через сеть или USB для управления диспенсером | ATM с сетевым доступом из корпоративного сегмента, отсутствие Whitelisting |
| Relay-атаки на NFC | Перехват и ретрансляция contactless-транзакций | POS-терминалы с NFC, без привязки к геолокации |
Для пентеста банкомата в grey box-сценарии нужен доступ к тестовому ATM в контуре разработки - работа с боевым банкоматом в продуктиве без согласования с процессингом недопустима. Это та ситуация, где «попробовать на проде» заканчивается уголовным делом, а не багбаунти.
Подробный разбор техник и detection-правил для SOC - в статье «Пентест банкоматов и POS-терминалов».
Банковские приложения и ДБО: 4 критичных слоя тестирования
Системы дистанционного банковского обслуживания - интернет-банкинг и мобильные приложения - основной цифровой канал взаимодействия банка с клиентами. Их компрометация - прямой путь к массовому хищению средств.Тестирование ДБО включает четыре слоя:
Слой 1 - Клиентское приложение. Мобильные приложения (Android/iOS): проверка обфускации, защиты от реверса (root/jailbreak detection), безопасности хранения данных (Keychain/Keystore), certificate pinning. На практике 70-80% банковских приложений содержат hardcoded-ключи или незащищённые SharedPreferences с токенами. Открываешь APK, грепаешь по «api_key» - и вот он, голенький.
Слой 2 - Транспортный уровень. TLS-конфигурация, поддержка устаревших протоколов (TLS 1.0/1.1), качество certificate pinning. Burp Suite Pro с настроенным прокси через мобильное устройство - стандартный инструмент для анализа трафика.
Слой 3 - Серверная логика. Бизнес-логика переводов, авторизации операций, управления лимитами. Здесь живут уязвимости типа race condition (одновременная отправка двух переводов для обхода проверки баланса), IDOR (доступ к чужим данным через подмену ID) и логические ошибки в workflow подтверждения операций.
Слой 4 - Интеграция с бэкендом. Взаимодействие ДБО с АБС, процессингом, антифрод-системой. Уязвимости на стыке систем: недостаточная валидация данных при передаче между ДБО и АБС, обход антифрод-правил через манипуляцию параметрами сессии.
Подробная методология тестирования ДБО - в гайде «Пентест банковских приложений: от тестирования ДБО до detection-правил SOC».
APT-группировки и банковские трояны: кто атакует и как детектить
Финансовый сектор атакуют не случайные хакеры, а организованные группировки с чёткой специализацией. Их TTP (Tactics, Techniques, Procedures) известны, задокументированы в MITRE ATT&CK и воспроизводимы на пентесте.Характеристики финансовых APT
Группировки, работающие против банков, отличаются от «обычных» APT:- Долгая фаза разведки. Изучение оргструктуры, идентификация операторов SWIFT, понимание бизнес-процессов переводов. Средний срок от первого фишинга до вывода средств - от нескольких недель до нескольких месяцев. Терпение у этих ребят железное.
- Использование легитимных инструментов. Cobalt Strike, PowerShell Empire, стандартные утилиты Windows - это затрудняет детекцию, потому что алерты на
powershell.exeгенерируют слишком много false positives в банковской среде. Попробуй отличи злонамеренный PowerShell от скрипта, который админ запускает каждое утро. - Горизонтальное перемещение через доверенные каналы. Атаки через подрядчиков (supply chain) зафиксированы ФинЦЕРТ в 2024 году как отдельный тренд.
Банковские трояны: Casbaneiro и аналоги
Банковские трояны - отдельный класс вредоносного ПО, заточенный на перехват банковских сессий, подмену реквизитов переводов и кражу учётных данных. Casbaneiro (Metamorfo) - характерный пример: DLL side-loading, living-off-the-land черезmshta.exe и certutil.exe, геозонирование по IP для таргетирования конкретных регионов. Зверь хитрый - сначала проверяет, в какой стране запущен, и только потом разворачивает полезную нагрузку.Детальный разбор техник уклонения и механизмов самораспространения - в статье «Банковский троян Casbaneiro: техники уклонения от детекции».
Обход антифрод-систем: слепые зоны банковского мониторинга
Антифрод - последний рубеж обороны банка. Когда периметр пробит, AD скомпрометирован и атакующий сформировал платёжное поручение, антифрод должен остановить транзакцию. Но у каждой системы есть слепые зоны, и атакующие их знают.Где антифрод не срабатывает
| Сценарий | Почему антифрод молчит | Что делает атакующий |
|---|---|---|
| Перевод в пределах установленного лимита | Транзакция не выходит за порог аномалии | Дробление суммы на множество мелких переводов |
| Операция с IP-адреса банковской сети | Источник - доверенный, алерт не генерируется | Работа через скомпрометированный хост внутри банка |
| Легитимный оператор выполняет перевод | Поведенческий профиль совпадает | Использование украденных кредов реального операциониста |
| Ночное окно обслуживания | Мониторинг снижает чувствительность в maintenance-окне | Тайминг атаки на период технологических работ |
На пентесте обход антифрод-системы проверяется в согласованном объёме: тестировщик формирует тестовые транзакции с различными параметрами (сумма, время, реквизиты получателя) и фиксирует, какие комбинации проходят без алерта. Результаты бывают неприятными для заказчика.
Подробный разбор техник обхода и рекомендации по настройке правил - в материале «Обход антифрод систем: как атакующие уклоняются от фрод-мониторинга».
Threat Hunting и SOC: обнаружение атак в финансовой сети
По данным Picus Blue Report 2024, сектор BFSI значительно увеличил эффективность логирования, но alert score при этом существенно снизился. Критический разрыв: банки стали лучше собирать логи, но хуже превращать их в алерты. SOC-аналитик тонет в данных, но не видит атаку.Что искать в финансовой сети
IOC уровня сети:- DNS-запросы к доменам из фидов ФинЦЕРТ
- Аномальный трафик на порты управления банкоматной сетью
- SMB-сессии между пользовательским и SWIFT-сегментом (их не должно быть вообще)
- Запуск
procdump.exe -ma lsass.exeили вызовrundll32.exe comsvcs.dll MiniDump(дамп LSASS) - Создание scheduled task или сервиса с подозрительным именем
- Загрузка и исполнение PowerShell-скриптов из нестандартных директорий
- Нетипичные запросы к SWIFT Alliance API
- Изменение конфигурации лимитов в процессинговой системе вне регламентного окна
- Массовые запросы к API ДБО с одного IP (credential stuffing)
-encodedCommand из директории C:\Users\Public = алерт» (1-2 срабатывания в месяц, каждое - реальная угроза) - это разница между рабочим SOC и декоративным.Полный набор SIEM-правил и методика threat hunting для банка - в статье «Threat hunting в банке: IOC, SIEM-правила и поиск APT-активности».
Регуляторные требования: ГОСТ Р 57580, PCI DSS и 6 надзорных органов
Кибербезопасность банков в России регулируется многоуровневой системой требований. За несоблюдение - не просто штраф, а ограничение операций, усиленный контроль и в перспективе отзыв лицензии.Ключевые нормативные акты
| Регулятор | Документ | Что контролирует |
|---|---|---|
| Банк России | Положение 683-П | Защита информации кредитными организациями: оценка рисков, контроль доступа, реагирование на инциденты |
| Банк России | Положение 821-П | Безопасность денежных переводов, взаимодействие с ФинЦЕРТ (уведомление об инциденте - в течение 1 часа) |
| Банк России | ГОСТ Р 57580.1/57580.2 | Технические требования к защите информации + методика оценки соответствия |
| PCI SSC | PCI DSS 4.0 | Защита данных держателей карт: сегментация, шифрование, пентест, мониторинг |
| ФСТЭК | Приказ №21, 239 | Сертификация средств защиты, безопасность объектов КИИ (ФЗ-187) |
| ФСБ | Приказ №378, ГосСОПКА | Криптографическая защита (СКЗИ КС1-КА), обмен данными об инцидентах через НКЦКИ |
| Роскомнадзор | ФЗ-152 | Персональные данные клиентов: уведомление оператора (ст. 22), меры защиты по УЗ |
Пересечение требований на практике
ГОСТ Р 57580 и PCI DSS пересекаются примерно на 60-70% по контролям, но расходятся в деталях. Банк, работающий с картами международных платёжных систем, обязан выполнять оба стандарта, и часто это приводит к дублированию работ. На практике эффективнее выстроить единую матрицу контролей с маппингом на оба стандарта - иначе два отдельных аудита каждый год съедают бюджет ИБ-отдела на корню.Финансовые организации, попадающие под определение субъектов КИИ (ФЗ-187), обязаны провести категорирование объектов (ст. 7), направить результаты в ФСТЭК (ст. 8) и обеспечить обмен данными об инцидентах через ГосСОПКА (ст. 5). Сроки уведомления НКЦКИ - от 3 до 24 часов в зависимости от категории объекта.
Чеклист: минимальный набор действий для комплаенса
- Провести категорирование объектов КИИ и направить результаты в ФСТЭК
- Пройти оценку соответствия по ГОСТ Р 57580 (ежегодно)
- Обеспечить уведомление ФинЦЕРТ об инцидентах в течение 1 часа
- Провести внешний пентест (минимум ежегодно для PCI DSS, по требованию - для ЦБ)
- Внедрить СКЗИ соответствующего класса (КС1-КА) для защиты каналов передачи ПДн
- Уведомить Роскомнадзор об обработке ПДн (ФЗ-152, ст. 22)
- Обеспечить подключение к ГосСОПКА для значимых объектов КИИ
Защита банковской инфраструктуры: технический стек и архитектурные принципы
Защита банка строится послойно - от сетевого периметра до прикладного уровня. Ни одно решение «из коробки» не закрывает все вектора. Архитектура безопасности - это баланс между глубиной защиты и операционной эффективностью.Сетевой уровень
- Микросегментация: SWIFT-сегмент, процессинг, АБС, ДБО, корпоративная сеть - каждый в своём VLAN с явными правилами межсегментного взаимодействия. На пентесте проверяется через попытку VLAN-hopping и анализ маршрутизации через management-интерфейсы.
- NGFW/IPS: фильтрация трафика с инспекцией на уровне приложений. Для банковских протоколов (ISO 8583, FIX) нужны специализированные сигнатуры.
- DDoS-митигация: сочетание облачной очистки трафика и on-premise решений для защиты процессинговых эндпоинтов.
Уровень конечных точек
- EDR: для банков критична вендор-специфика. Kaspersky EDR Expert, PT EDR, MaxPatrol EDR - каждый закрывает свои сценарии. Универсальных EDR не бывает: что ловит Kaspersky в режиме kernel hook, может пропустить PT EDR, и наоборот. Выбор зависит от стека ОС и критичности хоста.
- Application Whitelisting: на банкоматах и POS-терминалах - обязательно. Запрет запуска любого ПО, кроме явно разрешённого, блокирует malware-based jackpotting. Тут философия простая: разрешено только то, что в списке. Всё остальное - нет.
Уровень приложений
- WAF: защита ДБО и API от инъекций, XSS, CSRF. WAF не спасает от логических уязвимостей (BOLA/IDOR) - для этого нужен пентест.
- Антифрод-система: поведенческий анализ транзакций, ML-модели для детекции аномалий. Эффективность зависит от качества правил и покрытия сценариев.
Уровень мониторинга
- SIEM: централизованный сбор и корреляция логов. Для банка критично покрытие: каждый критичный сервер, каждый сетевой сегмент, каждая точка входа. По данным Picus Blue Report, 3 из 10 финансовых организаций всё ещё испытывают проблемы с предотвращением атак - prevention score в секторе BFSI практически не изменился в 2024 году (Picus Blue Report 2024).
- SOC: команда аналитиков, работающая по playbook'ам для финансовых инцидентов. Без выделенного SOC банк не способен выполнить требование ФинЦЕРТ об уведомлении в течение 1 часа.
Куда движется кибербезопасность финансового сектора
Угрозы меняются быстрее, чем банки обновляют защитные системы. Три тренда определяют ближайший год:GenAI как инструмент атаки. Удвоение вредоносного использования GenAI (CrowdStrike GTR 2025) - только начало. Персонализированные фишинговые кампании, deepfake-звонки от «руководства», автоматизированная разведка через LLM - всё это уже применяется против финансового сектора. Банкам придётся перестраивать антифишинг с учётом AI-генерированного контента. Старые фильтры, заточенные на «нигерийские письма», тут бессильны.
Разрыв между логированием и алертингом. Alert score в BFSI значительно снизился, несмотря на рост логирования (Picus Blue Report 2024). Инвестиции в SIEM не окупаются без инвестиций в detection engineering - написание правил, привязанных к конкретным TTP.
Supply chain как главный вектор. Атаки через подрядчиков становятся нормой. Банк может идеально защитить свой периметр, но один скомпрометированный интегратор с VPN-доступом обнуляет всю работу.
Для практикующих специалистов это означает: пентест банка без проверки supply chain и без тестирования SOC-playbooks - неполный. Регуляторный комплаенс без реальной валидации контролей через red team - бумажная безопасность.
Следующий шаг: от теории к практике
Если вы работаете в ИБ финансовой организации или проводите пентесты банков - начните с конкретного вектора из карты выше. Каждый spoke-материал содержит команды, detection-правила и чеклисты, готовые к применению.Хотите отработать эти техники в легальной среде? На курсах Codeby Academy по пентесту и red team операциям - инфраструктуры, максимально приближённые к банковским, с АБС, процессингом и SWIFT-эмуляторами.
Большинство команд ИБ в банках занимаются комплаенсом, а не безопасностью. По документам - соответствие ГОСТ Р 57580, оценка «четвёртый уровень», красивый отчёт для ЦБ. А в реальности - Windows Server 2008 в процессинговом сегменте, один общий пароль на все сервисные учётки AD и SIEM, который никто не читает.
Разрыв между «бумажной» и реальной безопасностью в российских банках - системная проблема, которая не решается покупкой очередного продукта. Решается она людьми: пентестерами, которые приходят и за два дня добираются до SWIFT-терминала, и SOC-аналитиками, которые учатся на результатах этих пентестов.
В ближайшие два года регулятор ужесточит требования к верификации контролей - не «покажите политику», а «покажите результат red team». Банки, которые сейчас инвестируют в реальный пентест и detection engineering вместо очередного compliance-отчёта, окажутся в выигрыше. Остальные продолжат узнавать о взломах из новостей.
