Безопасность - это привычка, а не инструмент

В последнее время мы провели немало времени на стороне атаки: как атаки устроены на самом деле, включая те, за которыми теперь стоит модель. Во многом через TryHackMe - самый безболезненный способ разобраться в этом на практике, а не по книгам.

Дальше рабочий список. Первая половина для всех, включая тех в вашей компании, кто никогда не прочитает политику безопасности. Вторая - для тех, кто строит. Никаких спонсоров, ничего на продажу: просто список, который мы дали бы другу.

Если вы не технический специалист, эти шесть покрывают почти всё

• Читайте адрес по буквам. Почти любая убедительная подделка выдаёт себя в адресе: подменённая буква, лишнее слово, настоящий бренд, сидящий в поддомене у кого-то другого. Нужный вам домен - тот, что стоит прямо перед первой одиночной косой чертой, и всё, что левее, ничего не обещает.
• Наведите курсор до клика. Сокращённые ссылки прячут адрес по замыслу. checkshorturl.com развернёт её за вас, не открывая страницу.
• Погуглите отправителя. Название компании плюс слово "scam" занимает десять секунд и закрывает удивительно много случаев.
• Срочность - это и есть сигнал. "Действуйте сейчас", "счёт будет заблокирован сегодня", "просрочен платёж": искусственное давление временем есть почти в каждой атаке, потому что именно размышление их и ломает.
• Включите двухфакторную аутентификацию везде. Код в приложении или аппаратный ключ, а не SMS, если есть выбор. Один этот шаг отсекает подавляющее большинство атак на пароли.
• Сомневаетесь - спросите. Вставьте сообщение в ассистента и спросите, похоже ли это на фишинг. С этим он справляется хорошо, а проверка ничего не стоит.

Что изменилось, когда у атакующих появился ИИ

Именно эта часть изменилась сильнее всего за последние два года, и об этом стоит сказать прямо.

Старый совет - искать кривую грамматику и неловкие формулировки. Этот совет мёртв. Фишинговое письмо теперь написано на свободном латышском, английском или русском, лексикой вашей отрасли, со ссылкой на реальный проект, и стоит это примерно ничего. Признак, который вас учили искать, исчез.

С голосом происходит то же самое. Короткого фрагмента с конференции или подкаста хватает, чтобы клонировать голос достаточно хорошо для телефонного звонка, и "руководитель позвонил и попросил перевести сегодня" теперь случается с обычными компаниями, а не только в кино.

Поэтому работают те привычки, которые не зависят от умения распознать подделку:

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

Если вы разрабатываете софт

• Zero trust по умолчанию. Никакого неявного доверия просто потому, что вы внутри сети. Аутентификация и авторизация на каждый запрос, и минимально необходимые права каждому сервису.
• Защита и мониторинг конечных точек. EDR или управляемый EDR, если некому смотреть оповещения: непрочитанное оповещение - это не контроль.
• Статический и динамический анализ плюс проверка зависимостей в CI. SAST, DAST и SCA на каждый пул-реквест, а не раз в квартал. Большинство реальных уязвимостей приходит через зависимость, которую кто-то добавил год назад.
• Централизованные логи, привязанные к известному фреймворку. SIEM плюс MITRE ATT&CK превращает "у нас есть логи" в "мы можем сказать, что произошло".
• Следите за самой конфигурацией облака. Контроль облачной конфигурации плюс взаимный TLS между сервисами. Гораздо больше инцидентов случается из-за неправильно настроенного хранилища или слишком широкой роли, чем из-за чего-то экзотического.
• Знайте, что внутри того, что вы поставляете. SBOM и подписанные обновления. Когда очередная широко используемая библиотека окажется скомпрометированной, единственный важный вопрос - можете ли вы за минуты понять, касается ли это вас.
• Проверяйте это на практике. Красная команда, чтобы узнать, фиолетовая - чтобы находка превратилась в исправление. Непроверенный план реагирования - это документ, а не способность.

И одна по-настоящему новая категория

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

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

Сбой здесь - это не падение. Это система, которая делает ровно то, что ей сказали, и сказал это тот, кто вообще не должен был иметь возможности ей что-либо говорить.

Что мы встраиваем, чтобы это не зависело от чьей-то памяти

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

В проектах, которые ведём мы, это как минимум означает:

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

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

И, если уж на то пошло, лучшая домашняя охрана - по-прежнему собака. Только не используйте кличку собаки как пароль.