EDR vs Джун: кто реально слабое звено в компании?

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

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

Метод доступный и мощный. Но для серьёзных целей в наше время уже немного не то. Современные системы защиты, да и просто внимательность людей, его отлавливают.

Что куда актуальнее - это атаки, которые не такие грубые. Когда в прицеле не сотня сотрудников, а одна конкретная личность. Или несколько. Те, кто могут стать удобным мостиком к чему-то действительно важному.

Слабое звено в любой компании - это HR, рекрутеры, сотрудники, которые ведут публичные профили в LinkedIn и других сетях. Именно они на виду у всех. HR - это лицо компании. Их работа привлекать, общаться, быть на связи. У них обычно всё открыто: контакты, информация, жизнь, работа. У них есть задача помогать, отвечать, обслуживать запросы. Если свяжешься, то с высокой вероятностью получишь ответ. Глубоких навыков в ИБ у них чаще всего нет, да и мысль, что их профиль - это дверь в компанию, им в голову обычно не приходит. Они думают, что безопасность - это дело технарей из ИБ-отдела.

Но не стоит думать, что всё сводится к тому, чтобы написать HR и попросить доступ, открыть файл или ссылку. Сейчас они работают по другой схеме. HR - это прежде всего источник информации. Из их профилей, постов, списка контактов и вакансий собирают пазл: как зовут ключевых разработчиков, над какими проектами они работают, какой у них стек технологий, кто с кем общается.

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

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

Поэтому стоит запускать даже код дилетантов в песочнице - это помогает в большинстве случаев, и быть осторожнее в доверии к HR.