С каждым годом роль DevSecOps в обеспечении безопасной разработки ПО становится всё больше и больше. Масло в огонь подливает стремительное развитие ИИ. Больше не в моде письма от «нигерийских принцев» и многомиллионных выигрышах. На смену им пришли дипфейки, имитирующие голос, внешность и поведение звёзд, директоров и других ЛПР. В этой и следующих своих статьях я расскажу, какие подходы для обеспечения безопасности мы, как DevSecOps, используем в CUSTIS.
Векторы атаки

Для начала давайте определимся с основными векторами атаки на компании, которые занимаются разработкой ПО, по состоянию на 2025 год.
Среди основных, а их может быть сколько угодно в зависимости от таланта и находчивости атакующего, выделим:
Социальная инженерия — атаки на сотрудников компаний с целью получить доступ к внутренним системам. Также сюда можно отнести действия инсайдеров и саботаж (внутрисистемные угрозы).
Misconfiguration attack — атаки, возможные при ошибках в конфигурации ПО.
Атаки на цепочки поставок ПО — злоумышленники внедряют вредоносный код в исходные коды, процессы сборки или обновления ПО.
Компрометация учётных данных и инфраструктуры DevOps — злоумышленники атакуют репозитории кода (GitHub, GitLab), CI/CD пайплайны, конфигурационные скрипты, что позволяет получить полный контроль над разработческими и производственными средами.
Программы-вымогатели (ransomware) — шифрование корпоративных данных с требованием выкупа.
DDoS-атаки — нарушение доступности сервисов разработчика, приводящее к временному отказу в работе веб-ресурсов, сервисов поддержки и автоматизированных систем разработки.
И начнем мы с самого популярного и эффективного — социальной инженерии.
Социальная инженерия. А при чём тут DevSecOps?

А при том, что неправильно исключать DevSecOps-инженера из общего процесса обеспечения ИБ, сегментируя его до настройки безопасности пайплайнов.
Многим кажется, что вопросами социальной инженерии должна заниматься только служба безопасности. Также часто эту функцию возлагают на отделы системного администрирования или выделенный отдел ИБ. И всё это будет правильно, но недостаточно! В современных условиях каждый сотрудник должен понимать, что есть внутренний периметр компании, куда стремится попасть злоумышленник. DevSecOps-инженер является одним из ключевых сотрудников, который должен доносить до коллег правила ИБ.
Давайте посмотрим, какие основные трюки используют злоумышленники для эксплуатации социальной инженерии.
Компрометирующие устройства
«Передайте, пожалуйста, фотографии Марье Ивановне в бухгалтерию», — сказала, улыбнувшись, девушка на ресепшене и протянула флешку.

Истории с вредоносными USB-устройствами сейчас на слуху, но всё ли так просто? Я думаю, что нет.
Во-первых, далеко не везде есть инструктаж по ИБ для новых сотрудников, где будет рассказано, что нельзя подключать неизвестные устройства на своём рабочем месте.
Во-вторых, не везде можно заблокировать USB-порты, что является достаточно распространённой практикой в крупных организациях.
Ну и в-третьих, нельзя исключать внутрисистемные угрозы, но об этом чуть позже.
Что можно предпринять в таких условиях:
Внедрить инструктаж по ИБ.
Постараться отключить usb-порты, там где это явно не требуется.
Сегментация сети и ограничение доступа.
Само собой наличие антивирусного ПО везде, где это возможно.
Мониторить аномальную активность сетевого трафика.
Скрининг по ИБ на этапе собеседования. Минимум вопросов, чтобы оценить, насколько человек погружён в такие темы.
На самом деле, компрометирующие устройства могут быть разными — смартфоны, внешние жесткие диски, зарядные устройства, всякие снифферы в т.ч. Wi-Fi, которые можно «случайно» забыть. Тут в дело вступает служба безопасности, которая смотрит не только на посетителей, но и следит, чтобы граждане ничего не забывали.
Корпоративная почта и мессенджеры

Попытки скомпрометировать пользователя через электронную почту стары как мир, но по-прежнему актуальны. Сотрудникам могут начать рассылать письма от «директоров», «контрагентов» и прочих очень важных людей. Любят злоумышленники и громкие слова «СРОЧНО! ВАЖНО!», чтобы посеять панику.
Вариант защиты тут — в первую очередь рассказать сотрудникам, что если письмо вызывает хоть малейшее подозрение, нужны дополнительные проверки. Нужно открыть корпоративный портал и как минимум посмотреть, настоящий адрес сотрудника в этом письме или это что-то другое.
Например, злоумышленник может мимикрировать под настоящий адрес, заменив одну
из букв или цифру или, наоборот, добавить их (vasya@gogle.com, например).
То же самое касается и мессенджеров с небольшими дополнениями.
Во-первых, можно также зайти на портал и посмотреть никнейм в карточке вашего коллеги или руководителя.
Во-вторых, обратите внимание на сам аккаунт, с которого вам пишут:
когда аккаунт был создан;
когда менялись имя или фото.

В-третьих, при обнаружении попыток, когда злоумышленники пытаются выдать себя за коллегу или контрагента, мы в компании оперативно информируем всех сотрудников через чат и электронную почту.
Также нужно быть готовым к тому, что атака может быть «от Солнца». Сейчас популярен вид атак, когда пользователя находят в какой-нибудь группе (видят его комментарий, например) и начинают ему писать с целью обсудить какую-либо тему. Сейчас крайне популярно использовать ИИ для этого. Даже если злоумышленник не получит учётных данных пользователя, общение с ним поможет провести OSINT вашей компании. А дальше на основе собранной ботом информации можно начинать таргетированную атаку. Совет тут простой — не общаться с непонятными людьми/ботами. Если хочется общения, лучше напишите проверенным коллегам или друзьям!
Кто ты???

Ещё недавно общение по ВКС без камер было нормой и все либо смотрели в чёрные квадратики, либо слушали своих коллег. Но ИИ внёс свои коррективы, потому что:
Любым именем может прикрываться злоумышленник, получивший ссылку на встречу. Для того чтобы подделать голос, сейчас нужно 6 секунд и пример вашей речи. Кстати, сейчас активно идёт сбор голосовой информации, так что не спешите отвечать на все вопросы роботов в телефонных звонках.
Злоумышленник может получить доступ к аккаунту реального пользователя и выдавать себя за него.
В этой ситуации можно посоветовать следующее:
Больше никаких чёрных квадратиков. Все сотрудники подключаются с включёнными камерами. Когда это войдёт в привычку, вам сразу будет бросаться нетипичное поведение коллег, например, отсутствие видео или постоянно выключенный микрофон.
Устанавливать срок действия конференций и защищать их паролем, не надо ходить по одной и той же ссылке десятилетиями.
Объяснить коллегам, что это именно мера безопасности, а не желание полюбоваться каким-то отдельным сотрудником или подразделением.
В случае обнаружения подозрительной активности прекратить ВКС и отправить новые ссылки участникам.
Внутрисистемные угрозы

Напоследок давайте обсудим очень сложную тему — внутрисистемные угрозы. Можно условно разделить их на две большие группы — инсайдеры и саботаж.
С деятельностью инсайдеров все более-менее понятно. Инсайдер — это сотрудник, который помогает вести противоправную деятельность злоумышленнику. Часто это сотрудник, который недавно устроился с целью получить доступ к данным компании, но бывают и исключения. Как правило, СБ отсеивает потенциальных инсайдеров на этапе скрининга.
Вот несколько рекомендаций, которые могут помочь пресечь инсайдерскую деятельность:
Инструктаж по ИБ. Да, снова он. И на нём сотрудникам объясняется, к каким последствиям приводит инсайдерская деятельность. А это целый ряд статей: 185.6 УК РФ, 183 УК РФ, 159.6 УК РФ. Отдельно стоит выделить 276.1 УК РФ, с ней инсайдер уже может получить срок 10–15 лет. Часто люди не осознают последствий.
Периодически общайтесь с сотрудниками один на один. Как правило, инсайдер нервничает и избегает прямого общения.
Отслеживание аномальной активности пользователя: резкое увеличение количества подключений к базам данных, скачивание и удаление больших объёмов информации.
Гораздо сложнее дело обстоит с саботажем. Потому что он может иметь разные причины, но всё сводится к ситуации, когда сотрудник по своей воле хочет принести вред компании. В случае с саботажем подходят все рекомендации, о которых я упомянул для инсайда. Однако есть отдельная рекомендация — выстраивать прозрачные рабочие процессы, стараться выстроить доверительные отношения с сотрудниками, практиковать открытость менеджмента к диалогу.
В следующей статье я продолжу тему роли DevSecOps в обеспечении безопасной разработки ПО и планирую рассказать про кейс misconfiguration attack в проекте Modeus. Спасибо за внимание!