Если вы полагаетесь в своем антиспаме на Dmarc и не отклоняете письма с SPF fail, рекомендуется изучить новый тип атаки DKIM replay.

https://www.kaseya.com/blog/dkim-replay-attacks-apple-paypal-invoice-abuse/

https://github.com/praetorian-inc/augustus
Открытый фреймворк для тестирования моделей на безопасность (промт инъекции, джейл брейки и т.д.) декларируется готовность к использованию в проде, а не просто для исследований (одновременное сканирование, таймауты, лимиты и т .д.).

OWASP Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling v1.0

https://genai.owasp.org/resource/owasp-vendor-evaluation-criteria-for-ai-red-teaming-providers-tooling-v1-0/

Усиливаем защиту Kaspersky Security Center!

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

📚 Читать
У нас уже опубликовано Руководство по усилению защиты KSC, из него вы узнаете о важных настройках и сможете проверить себя.

🎬 Смотреть
Недавно наши эксперты записали видео, в котором они разбирают самые частые векторы атак и комментируют практические рекомендации из Руководства.

✅ Ключевые моменты
— Установите KSC на выделенный сервер и настройте безопасные подключения.
— Включите 2FA и создайте администраторам роли под конкретные задачи.
— Установите приложение безопасности на сервер KSC.  
— Настройте детальную защиту управляемых устройств.
— Организуйте обслуживание сервера, мониторинг событий и интеграцию с SIEM.

Посмотрите видео и выполните все рекомендации из Руководства, чтобы ваш KSC оставался неуязвим для злоумышленников.

#ksc #tips

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux. Документ на 17 страниц содержит 12 групп рекомендаций:

1. Парольные политики Windows и Linux
2. Доступ и логирование событий в MySQL/MariaDB, PostgreSQL, MS SQL Server
3. Отключение SMBv1 в Windows
4. Отключение NTLMv1 в Windows
5. Удаление учётной записи "Гость" из групп "Администраторы" в Windows
6. Хранение учётных данных и ограничение доступа к конфигурационным файлам Windows и Linux (здесь занятный список отечественных PAM-ов 😉)
7. Аудит и блокирование неиспользуемых открытых портов
8. Отключение автовхода пользователя в Windows
9. Безопасная настройка SSH в Linux
10. Назначение прав доступа на файлы и директории в Windows и Linux
11. Отключение неиспользуемых служб и компонентов операционной системы в Windows и Linux
12. Отключение неиспользуемых учётных записей и ограничение записей с избыточными правами в Windows и Linux

@avleonovrus #FSTEC #Linux #Windows #Microsoft

Произвел верхнеуровневый анализ проекта методического документа ФСТЭК России .
1. Несмотря на декларирование, того что документ предназначен и для объектов по 239 (КИИ), 21 (ПДн) и 31 (АСУ ТП) приказам, документ изначально подготовлен как дополнение к приказу № 117 (ГИС).
2.Если все таки его примут как методические рекомендации для всех вышеуказанных приказов без структурных изменений это повлечет за собой значительный объем расходов на уже защищенные объекты.
3.В проекте документа появился целый новый раздел 3 про процессную часть. И этот раздел 3 частично дублирует уже выпущенные выше указанные приказы ФСТЭК и другие методические документы (моделирование угроз, работа с уязвимостями, работа с обновлениями и т.д.).
4. Нет попытки мапинга всех мер и их названий из всех приказов ФСТЭК России.
5. Отсутствие мер "нулевок", типа ИАФ.0 частично закрывается разделом 3 и корректировок других мер типа ИАФ.1.
6. Есть попытка двумя абзацами ввести логику ущерба и "недопустимых событий".
7. Есть пара досадных опечаток (CMDB система стала SMDB).

ИМХО, с учетом вступления в силу приказа № 117 (ГИС) с 01.03.26, я бы на месте автора выпустил первую редакцию документа исключительно для 117 приказа. Распространения данного приказа на КИИ, ИСПДн и АСУТП в текущей логике проекта документа означает необходимость самостоятельного анализа заказчикам какие требования приказа уже выполнены, а на какие нужно снова планировать расходы.

Рекомендую и вам произвести анализ проекта документа и свои предложения направить во ФСТЭК.

https://www.kommersant.ru/doc/8420040 когда читаешь подобные исследования нужно учитывать года в скоупе, а тут у ВШЭ нет по объективным причинам 2025 года ещё. Т к не все компании пока опубликовали годовую отчетность за 2025.
А 2025 был довольно интенсивным для ИИ.

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

5 марта Cloud Security Alliance проводит онлайн summit по безопасности финансового сектора в облаках FinCloud Security Summit 2026.
Формат онлайн.

Заканчивается правда в 00:30 по Мск 🙂

https://cloudsecurityalliance.org/events/

https://layerxsecurity.com/blog/claude-desktop-extensions-rce/
Пример уязвимости RCE показывающий необходимость запуска MCP коннекторов, и в целом ИИ приложений в изолированных средах.

Готовятся к релизу 2 полезных инструмента в Windows 11
1.Windows Baseline Security Mode - включено по умолчанию, запуск и установка только доверенного софта.

2.Windows User Transparency and Consent - перенос подхода со смартфонов, когда у пользователю будет явно подсвечиваться запрос доступа приложения к критичным объектам (камера, память ...).

https://blogs.windows.com/windowsexperience/2026/02/09/strengthening-windows-trust-and-security-through-user-transparency-and-consent/

https://www.intel.com/content/www/us/en/security/security-practices/blogs/google-collaboration-strengthen-intel-tdx.html
Мажорный релиз Intel TDX - технологии для обеспечения дополнительной конфиденциальности вычислений в облаке.

https://www.microsoft.com/en-us/security/blog/2026/02/09/prompt-attack-breaks-llm-safety/ пример показывающий фундаментальные проблемы с безопасностью использования ИИ и необходимостью полагаться на более детерминированные решения чем сам ИИ при защите ИИ.

Docker предоставил бесплатный доступ к защищённым образам контейнеров
https://www.opennet.ru/opennews/art.shtml?num=64766

Компания Docker объявила о предоставлении бесплатного доступа к коллекции защищённых образов контейнеров DHI (Docker Hardened Images), насчитывающей более тысячи минималистичных сборок на базе Alpine и Debian c готовыми преднастроенными окружениями для запуска различных приложений, инструментариев, runtime и платформ. Образы распространяются под лицензией Apache 2.0 и сопровождаются силами Docker.

Использование DHI-образов упрощает работу по поддержанию безопасности инфраструктуры, так как за исправление уязвимостей в базовом содержимом образов и оперативную подготовку обновлений отвечают сотрудники Docker, а пользователям остаётся лишь заботится о безопасности своих приложений и дополнительно установленных зависимостей. Для защиты от атак через компрометацию зависимостей (Supply Chain), используемых в предоставляемых образах, содержимое образов собирается из исходного кода с использованием контролируемых пространств имён, проведением рецензирования и "периодом охлаждения" перед доставкой новых версий.

На Опёнке "сухо" написано, оригинальный пост более обширный

Hardened Images Are Free. Now What?
https://www.docker.com/blog/hardened-images-free-now-what/

Сами образы тут можно посмотреть
https://hub.docker.com/hardened-images/catalog

На сколько ваши процессы безопасной разработки готовы к такой разработке? =)

Создатель OpenClaw идёт дальше. AgentOps и смена парадигмы разработки.

Продолжаем тему изменения рынка разработки с МАС. В комментариях к посту мы обсуждаем смену парадигмы разработки, и вот я нашёл прекрасный пример как оно изменилось. Это другой взгляд на мой тейк в предыдущем посте.

Вышел очень интересный подкаст от создателя MoltBot про его ведение разработки с МАС.
Вещает Питер Штайнбергер – автор проекта OpenClaw.

🧠 Методология и философия разработки.

Ключ к продуктивности Питера – полное погружение в «AI-native» workflow, где ИИ-агенты (в основном он использует Cursor с Claude и Codex) – его основная команда.

· Масштаб работы: В январе он один сделал более 6600 коммитов, что сравнимо с активностью целой компании.
· Сдвиг парадигмы: Традиционные этапы вроде code review и пулл-реквестов ушли в прошлое. Вместо них – обсуждение архитектуры и «prompt-реквесты», где важнее промпт, сгенерировавший код, чем сам код.

🔟 Ключевые принципы и выводы

Из беседы можно выделить 10 главных уроков о работе с ИИ:

1. Отказ от перфекционизма. Опыт управления командой научил его принимать код, который не идеален, но работает. Это критически важно при работе с агентами.

2. Замыкание цикла разработки на агентах. Агенты должны сами проверять свою работу – компилировать, линтить, запускать тесты и валидировать вывод.

3. PULL-РЕКВЕСТЫ МЕРТВЫ. ДА ЗДРАВСТВУЮТ PROMPT-РЕКВЕСТЫ! Питера теперь интересуют в первую очередь промпты, которые привели к созданию кода, а не итоговый код.

4. Code review заменяется обсуждением архитектуры: Даже с ядром команды в Discord он обсуждает только высокоуровневый дизайн системы, а не строчки кода. Т.е. вы все ещё тимлид и архитектор и тех пис. Какие тут джуны справятся?

5. Параллельная работа в «потоке». Он запускает 5-10 агентов одновременно над разными задачами, оставаясь в состоянии потока как дирижёр. Опять же ещё и AgentOps.

6. Инвестиции в планирование. Он тратит много времени на уточнение плана работы с агентом, предпочитая для этого Codex, и только когда план готов, отпускает агента на самостоятельное выполнение. Тема с планированием перед генерацией известна как хака апающая кодген. Кстати еще добавляет принцип сначала сделай план, к нему тесты на каждый этап и после ток прогай.

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

8. Локальный CI лучше удалённого. Агенты запускают тесты локально, чтобы не ждать 10+ минут ответа от внешней системы CI/CD. Снова AgentOps.

9. Большинство кода – скучно. Основная масса кода в приложениях – это преобразование данных. Энергию нужно направлять на проектирование системы.

10. Фокус на результатах, а не деталях реализации. С ИИ преуспевают те инженеры, которые одержимы выходным продуктом, а не решением алгоритмических головоломок.

🏗️ Роль инженера в эпоху ИИ

Питер — пример того, что программная инженерия не умерла, а трансформировалась. Он действует как архитектор и «благожелательный диктатор» проекта:

· Держит в голове всю высокоуровневую структуру.
· Уделяет огромное внимание архитектуре, модульности и расширяемости (успех OpenClaw во многом обусловлен этим).
· Освобождён ИИ от рутины, он может полностью сосредоточиться на системном дизайне и общем направлении.

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

Опубликовали видео с практической конференции ИБ Bsides 2025 Munich.

https://youtube.com/playlist?list=PL8N5HiRDvZ-cvW9miva4rFc55Zh091zHa&si=Uh22AaanV3lOwgLw

https://www.kommersant.ru/doc/8420894

"По оценке «Эксперт РА», в 2026 году доля расходов крупнейших банков на информбезопасность останется неизменной и займет всего 3%, тогда как у банков из топ-50 вырастет с 4% до 6%. «Рост доли расходов на ИБ у банков вне топ-10 обусловлен ограниченным эффектом масштаба, меньшими возможностями распределения затрат по другим направлениям цифрового развития, а также необходимостью выполнения единых регуляторных требований при более узкой ресурсной базе и более низком уровне автоматизации процессов»,"

Agentic AI Risk-Management Standards Profile

A new paper authored by researchers from the Center for Long-Term Cybersecurity’s Artificial Intelligence Security Initiative (AISI) focuses on “AI agents” or “agentic AI,” AI systems that can autonomously pursue goals and take actions with little to no human oversight, often through interaction with external environments and tools.

https://cltc.berkeley.edu/2026/02/11/new-cltc-report-on-managing-risks-of-agentic-ai/

Кибербез попал в список причин почему пилот по ИИ может провалиться в исследовании МШУ Сколково.

https://www.skolkovo.ru/researches/ot-pilota-k-masshtabu-kak-vstroit-ii-v-processy-i-poluchit-otdachu/