Ассоциация ФинТех, ГК «Солар» и сообщество FinDevSecOps подвели итоги первой премии «Security UP: Безопасность начинается с кода». Награждали компании, которые не просто «ставят сканеры», а реально встроили безопасную разработку в процессы за 2024–2025 годы. Вот тут почитай инфоповод, а я пока дам кратко выжимку.

• «Фундамент безопасности: DevSecOps‑революция» — Почта России. Ну если серьозно, тут ребята ушли от своего текущего состояния, потому что большая программа трансформации разработки: единая нормативка, роль ответственных за безопасность ПО, охват DevSecOps‑подходом всего жизненного цикла сотен сервисов и миллионов строк кода
• «Страховой щит: зрелые практики безопасности в страховом бизнесе» — Росгосстрах: DevSecOps‑платформа и модель управления безопасностью релизов
• «Региональный импульс: развитие DevSecOps в регионах» — Центр ИБ Московской области: внедрение практик безопасной разработки в госорганах Подмосковья с упором на масштабируемость подхода для других регионов
• «Открытые горизонты: Open Source в безопасности ПО» — Инфосистемы Джет: open‑source фреймворки для безопасности сред контейнеризации и DevSecOps‑процессов, выложенные в открытый доступ, плюс спецприз «Знак качества АФТ» за методологию
• «Архитекторы безопасности: интеграция DevSecOps» — Faberlic: Security‑by‑Design в разработке, как проект по внедрению безопасной архитектуры и процессов на уровне компании
• «Технологический прорыв: новые горизонты безопасности ПО» — СберТех: Система непрерывного мониторинга и устранения уязвимостей в продуктах, рассчитанная на масштабирование внутри финсектора.
• «Новые герои безопасной разработки» — Т Плюс: трансформация AppSec в крупной частной энергетической компании, как автоматизация и повышение эффективности процессов безопасной разработки

Ролевая модель доступа — это когда мы управляем не правами конкретных людей, а ролями, привязанными к задачам и зонам их ответственности, где под каждую роль чётко определено: что можно, а что нельзя

Segregation-of-Duties используется в разделении конфликтующих полномочий между разными ролями, чтобы один человек не мог сам себе придумать доступ, провести операцию и её же согласовать

• Тот, кто заводит контрагента, не проводит по нему платежи
• Тот, кто выдаёт доступы, не утверждает свои же заявки
• Тот, кто меняет правила сетевой безопасности, не согласовывает их в одиночку
• Разработчик не ходит напрямую в продуктивную БД и т.д.

• Вместе с бизнесом описываем роли и ключевые процессы
• Ищем точки, где один человек может «инициировать, согласовать и выполнить» — это и есть SoD‑конфликты
• Оформляем всё в SoD‑матрицу: какие комбинации ролей и прав запрещены
• Заводим эти правила в IAM и сервисы доступа, чтобы система просто не давала собрать «токсичный» набор привилегий
• Регулярно прогоняем отчёты по SoD‑нарушениям и чистим исключения, а не копим их годами

Смысл Segregation-of-Duties в том, что бы она стала частью архитектуры. То есть нам важно уметь не просто выдавать доступы, права и разделять обязанности, а именно предотвращать конфликты, что бы равномерность покрытия правами была достигнута со всех сторон. Нам надо все-таки уметь оркестрировать и правильно разделять полномочия людей.

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

В результате взлома похищены средства российских пользователей на сумму более 1 млрд рублей. Цифровые следы и характер атаки свидетельствуют о беспрецедентном уровне ресурсов и технологий, доступных исключительно структурам недружественных государств.

В связи с атакой биржа Grinex вынуждена приостановить работу. Вся доступная информация передана в правоохранительные органы. По месту нахождения инфраструктуры подано заявление для возбуждения уголовного дела.

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

Обычно исследователи выкладывают эксплойты после неудачной попытки договориться с владельцем бизнеса, но на базе практики все чаще, когда утечки попадают напрямую в сеть и продаются группам атакующих, поэтому у них есть доступ к 0‑day уязвимостям, высокому уровню операционной безопасности и возможности длительное время оставаться незамеченными в инфраструктуре жертвы.

- Жёсткое управление ключами и кошельками: аппаратные HSM, мультиподписные схемы (multisig и желательно использование схем 3/5 подписи), разделение горячих кошельков, строгие процедуры вывода средств. Это не столько снижает вероятность взлома, сколько ограничивает возможный ущерб при компрометации отдельного узла или аккаунта, естественно подразумевая, что ноды хранения должны быть распределенными
- Важно воспринимать атаки на инфраструктуру не только как технический, но и как геополитический фактор. Если бизнес работает с чувствительными категориями клиентов, обходит санкционные ограничения или является частью критической финансовой экосистемы, то уровень потенциального противника нужно автоматически поднимать до учета всех возможных атакующих и учитывать заинтересованность не только с целью мошенничества
- Segregation of duties и ролевые модели доступа. Один человек не должен иметь возможность и инициировать крупную операцию, и согласовать её, и технически провести. Это касается как финансовых транзакций, так и управления кошельками, ключами, конфигурациями боевых систем

Cреди крупных финансовых организаций и наиболее зрелых криптоплатформ такие меры уже стали де‑факто стандартом. Но если смотреть на рынок в целом, особенно на быстро растущие сервисы, часть игроков ограничивается базовым набором средств защиты, не успевая перестроить архитектуру и процессы под новый уровень угроз. Именно в этом “разрыве зрелости” и возникают подобные инциденты. Аналогично учитываем модели зрелости на базе нехватки компетенций