https://www.aquasec.com/blog/cloud-security-trends-predictions-and-strategies-for-resilience/
Интересные прогнозы.

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

(1) Использование потенциально скомпрометированных каналов связи.

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

Это касается и мессенджера Telegram, клиент которого может быть установлен на рабочей машине в скомпрометированном домене. Даже если вы твёрдо уверены, что вашу телегу не читают, это ещё не значит, что злоумышленники не читают телеги всех 30+ человек из чата по инциденту.

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

(2) Поспешное удаление вредоносного ПО.

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

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

(3) Слишком быстрое восстановление бизнес-процессов.

Конечно, всем хочется поскорее вернуться в строй. Однако необходимо собрать артефакты: файлы, журналы и другие данные для расследования. Не знаете, что это? Снимите побитовую копию (FTK Imager, dd). Не сделали? Скорее всего придётся показывать эффективность в восстановлении бизнеса ещё раз, как минимум.

Поспешная переустановка поломанных систем – типичная ситуация, при которой уничтожаются артефакты, что мешает восстановлению картины инцидента.

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

(4) Непредсказуемое выполнение рекомендаций специалистов по реагированию.

Например, просьба выключить всю коммуникацию между внутренними корпоративными сетями и внешними сетями может подразумевать множество действий (отключить пользователей, отключить онлайн-сервисы организации, отключить удаленный доступ админов, подрядчиков и т.д.). Клиенты могут понять задачу по-разному – и выполнить только часть этих действий.

Плохо сформулирована рекомендация? Потребуйте переформулировать. Нет компетенций выполнить рекомендации? Попросите инструкцию. Нет времени? Попросите помощи. Не откладывайте в долгий ящик – он не такой уж долгий.

(5) Проведение пентеста для купирования инцидента попыткой обнаружить "путь" злоумышленника.

Пентест может внести много дополнительного шума (детекты СЗИ; файлы/персистенс и т.д.) и затереть полезные артефакты. Поэтому лучше сделайте расследование инцидента вместо анализа защищенности во время инцидента.

https://cyberscoop.com/cisa-mobile-security-best-practices-salt-typhoon/

"The guidance includes using only communication apps that have end-to-end encryption; enabling Fast Identity Online (FIDO) phishing-resistant authentication; using a password manager; setting a Telco PIN; and not using personal virtual private networks (VPNs). The guidance also makes platform-specific security recommendations for iPhones and Android devices. "

https://vulncheck.com/blog/cwe-top-25-2024 сравни топ от митре и топ от CISA.

Видео с румынской конференции DefCamp. Темы от нейросетей до IOT.

https://m.youtube.com/playlist?list=PLnwq8gv9MEKiaXSWNRmCrW9Q-lUd_kAgr

NIST рассматривает возможность стандартизации увеличения размеров блока одного из вариантов AES (Rijndael) до 256 бит. Больший размер блока может повысить производительность для сценариев с большим объемом шифруемой информации, особенно для сценариев хранения.

https://csrc.nist.gov/pubs/sp/800/197/iprd

Поздравляю с наступающим новым годом, дорогие читатели! Этот год выдался интенсивным у автора канала, в новом году постараюсь вас чаще радовать новыми полезными практиками!

Спасибо, что читаете нас!

https://csrc.nist.gov/pubs/sp/800/189/r1/ipd
"This document provides technical guidance and recommendations to improve the security and resilience of Internet routing based on BGP. Technologies recommended in this document for securing Internet routing include Resource Public Key Infrastructure (RPKI), Route Origin Authorization (ROA), ROA-based route origin validation (ROA-ROV), and prefix filtering. Additionally, the technologies recommended for mitigating DDoS attacks focus on the prevention of IP address spoofing using source address validation (SAV) with access control lists (ACLs) and unicast Reverse Path Forwarding (uRPF). Other technologies are also recommended as part of the overall security mechanisms, such as remotely triggered black hole (RTBH) filtering and flow specification (Flowspec)."

Интересная инициатива США - выкладывать в доступ свои разработки ФОИВ США

https://fedscoop.com/agencies-must-share-custom-source-code-under-new-share-it-act