Человеческий фактор в эпоху импортозамещения ИБ

Когда из-за внешних условий бизнесу приходится оперативно перестраивать ИБ-архитектуру, сами сотрудники становятся новым эшелоном защиты. Может ли человеческий фактор укрепить безопасность, а не создавать новые угрозы? Да – зачастую люди видят признаки атак эффективнее автоматических систем, и это позволяет компаниям качественно пересмотреть подход к киберзащите. О том, как этого добиться, рассказали эксперты ИБ-интегратора iTPROTECT и компании «Антифишинг».

ИБ-интегратор iTPROTECT предлагает своим клиентам более 40 типов решений и услуг по ключевым направлениям информационной безопасности: защита от внутренних угроз и от мошенничества, сбор и анализ событий безопасности, защита мобильных устройств и баз данных, контроль пользователей и др.

«Антифишинг» — российский разработчик решений, направленных на борьбу с человеческим фактором в защите информационных ресурсов. Создатель платформы «Антифишинг», которая помогает обучить сотрудников и контролировать их навыки информационной безопасности.

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

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

Максим Головлёв, технический директор iTPROTECT: «Мы видим рост спроса на решения по сетевой безопасности: NGFW, WAF, защита от DDoS. Из менее типичных запросов – пентесты. Те, кто ещё не попал под атаки, хотят понять, как их могут взломать и до чего дотянутся».

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

Почему это важно – на примерах

Кейс №1 – классический blackbox-пентест (исследователи не получают от заказчика данных об инфраструктуре, т.е. атакуют с теми же вводными, какие были бы у реальных злоумышленников).

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

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

Можно ли было избежать такого сценария? Конечно – поставить NGFW, закрыться IPS и т.д. Но остаётся проблема ИТ-администратора, который пренебрегает правилами безопасности.

Кейс №2 – моделирование фишинговой атаки.

За последние 2,5 года удалённая работа вошла в повсеместную практику, и сейчас в некоторых компаниях даже администраторы могут работать из других стран. А вот обучением и тренингами безопасности многие по-прежнему пренебрегают.

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

Результаты – 2/3 пользователей открыли письмо, больше половины прошли по фишинговым ссылкам, из них ещё половина ввела учётные данные. Самое главное – в мероприятии участвовали не простые пользователи, а ИТ- и ИБ-специалисты. Вывод: такие риски невозможно устранить, только минимизировать.

Сергей Волдохин, директор компании «Антифишинг»: «Процесс импортозамещения – это повод задуматься о том, какую задачу выполняют СЗИ, зачем они нужны компании и какие проблемы можно решать другими способами. Знания и навыки ваших сотрудников могут стать элементами цифрового иммунитета для киберустойчивости бизнеса».

Большинство продвинутых атак, построенных с применением 0-day и авторских эксплойтов, начинаются всё с тех же фишинговых рассылок и вредоносных Word-документов.

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

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

Поэтому главным вопросом для ИБ-специалистов в эпоху импортозамещения может оказаться «Как быстро сформировать у пользователей навыки безопасности?».

1. Познакомьте с технологиями безопасной авторизации

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

Это как нельзя лучше демонстрирует реальную проблему: люди не понимают, как работают системы аутентификации, как пользоваться токенами и т.д. ИБ-специалисты худо-бедно отучили пользователей записывать пароль на стикере, а корпоративные политики безопасности не позволят установить на компьютер qwerty123. Но в условиях реальной атаки для мошенников нет особой проблемы в том, чтобы вдобавок к основному паролю узнать у пользователя и второй фактор.

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

Это простое, но эффективное действие сразу снизит вероятность взлома. Как сильно – видно по результам фишинговой атаки выше по тексту.

2. Научите определять признаки атаки

Если случается взлом крупной корпорации, промышленного предприятия или государственной организации, всегда возникает вопрос: «Неужели у компании не было возможности построить эффективную систему защиты?»

Разумеется, большинство жертв инвестировали в ИБ, но рано или поздно меч побеждает щит. Организаторы направленных атак знают, что им незаметно закрепиться в инфраструктуре, обойдя системы безопасности. Поэтому таковой обход входит в бюджет атаки. И позднее, через несколько недель или месяцев ИБ-профессионалы по логам смогут восстановить действия, которые позволили злоумышленникам обмануть современную и мощную XDR-систему.

При этом пользователь рабочей станции очень часто может заметить подозрительную активность, сообщить об этом ИТ-службе – и остановить атаку на первых подступах. А потом и разработчик той самой XDR изучит ситуацию и внесёт обновления в логику своего продукта.

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

• Откроет сотрудник письмо или нет?
• Пройдёт ли по ссылке?
• Разблокирует ли документ?
• Пойдёт ли с счётом в бухгалтерию?
• И т.д.

Многие компании воздерживаются от таких мероприятий, чтобы не подвергать сотрудников дополнительному стрессу, когда и настоящих атак хватает. Таким организациям стоит присмотреться к виртуальным тренажёрам с актуальными примерами атак, которые адаптируются под отрасль, компанию, сценарии. Такие ресурсы позволяют сделать ИБ-тренировку рутинной процедурой для сотрудников. Если еженедельно по несколько раз человек будет проходить по сценарию атаки,у него сформируется профессиональная «насмотренность» и он запомнит, как выглядит подозрительное письмо.

Такие тренажёры могут стать частью корпоративного обучающего курса – люди отнесутся к ним как к части своего профессионального роста. В результате они научатся выявлять атаку лучше антивируса. А кнопка «Сообщить об атаке» в почтовом клиенте или браузере позволит ИБ-службе оперативно получить всю информациб об инциденте, включая индикаторы компрометации.

3. Прививайте разработчикам навыки безопасного кодинга

Сейчас самые разные компании, от банков до ретейла, развивают собственные программные продукты. ИБ-службам приходится думать о том, насколько безопасно в таких системах организован обмен данными, как не пропустить уязвимости в коде. С ростом популярности open source появляются новые вопросы – какие библиотеки работают в нашем сервисе, не отправляют ли они наши данные на сторонний сервер и т.д.

Проблема более чем актуальна – на недавней кибербитве Standoff-2022 компоненты с открытым кодом не раз и не два становились уязвимой точкой ИТ-инфраструктуры. Средства автоматического анализа (SAST/DAST) не позволяют обнаружить все логические уязвимости, а профессиональные взломщики знают, за что можно зацепиться в коде.

При этом вряд ли какой-то разработчик не захочет писать безопасный код. Трудность в том, чтобы создать понятные и конкретные требования по безопасности, применимые к продукту, над которым трудится отдел разработки. Задача – научить писать безопасный код, вовлечь разработчиков в тему безопасности.

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

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