AlexRedSec

Самые переоцененные и вызывающие наименьшее доверие концепции и заявления в ИБ👎 Тут в исследовании SCF Council участников попросили назвать самые оверхайпнутые концепции и технологии, а также маркетинговый буллшит – пожалуй, самая интересная статистика во всем документе😅 Среди самых переоцененных концепций/технологий есть два явных "лидера": использование генеративного ИИ для SecOps и "Zero Trust как готовый продукт": и если первый "лидер", по моему мнению, скорее пал жертвой больших ожиданий и невысокой эффективностью/боязнью полагаться на решения ИИ, то второй "лидер" заслужил свое место некомпетентностью ИБ-маркетинга🤷 Также в топе оверхайпа: ➡️Блокчейн для нужд ИБ и киберстрахование как замена мерам защиты. ➡️Прогнозы сроков возникновения угроз со стороны квантовых вычислений (наступление "дня Q"). ➡️Рассмотрение ISO27001 или SOC 2 в качестве гарантированного доказательства уровня ИБ. ➡️Внедрение стека решений от одного вендора. ➡️Использование оценок и рейтингов для расчета уровня зрелости ИБ. ➡️Эффективность тренингов по повышению осведомленности. Если посмотреть на топ маркетингового буллшита, то здесь всё стабильно: ➡️Маркировка продуктов "На базе/С использованием ИИ-технологий". ➡️Маркетинг "Next-Gen" или "революционных" решений. ➡️Заявления о "невзламываемости" или соответствия самым высоким стандартам надежности (сравнение с военным уровнем стандартов, military-grade). ➡️Сертификация как гарантия компетентности и заверение в том, что комплаинс равен безопасности. ➡️Повсеместное использование термина "Zero Trust". ➡️Маркетинг, основанный на страхе перед взломом и утечками, + запугивание "квантовым апокалипсом". #scf #grc #zerotrust #marketing #ai #buzzword #compliance

А в Steam сейчас ещё идёт распродажа игр, где можно примерить на себя роль хакера или программиста. Некоторые игры подойдут в качестве инструментов геймификации в процессе повышения осведомленности. Несколько лет назад я делал подборку таких игр, но сейчас появилось много новых, правда, часто жестко навайбкоденных😅 Из нового советую обратить внимание на HackHub - Ultimate Hacker Simulator, а из классики – ThreatGEN: Red vs. Blue👍 #game #gamification #awareness

В интересное время живем: с одной стороны, классические инсайдерские угрозы от сотрудников никуда не делись и только усложняются благодаря развитию технологий, а с другой – на горизонте появилась новая категория нарушителей в виде ИИ-агентов, лишенных "недостатков" человеческих инсайдеров. К чему это я? Тут вот агентство CISA разродилось обновленной редакцией руководства по противодействию инсайдерским угрозам, где в том числе описало новые риски, связанные с использованием ИИ: мало того, что злоумышленникам стало проще обманывать и манипулировать сотрудниками с помощью дипфейков и "грамотного" фишинга, так еще и сами сотрудники стали сливать чувствительные данные в дипсики и gpt-подобные чаты😭 А тут еще инсайдеры стали отравлять данные и искажать настройки моделей в ИИ-системах работодателя... В общем, терпения работодателям, а CISO/CSO – времени на чтение гайда от CISA и ресурсов для построения эффективной программы противодействия инсайдерским угрозам. Хотя, в скором времени скорее всего угрозами от сотрудников-инсайдеров мы пренебрежем, так как появилась более совершенная версия, которую мы сами и взращиваем – ИИ-агенты🫂 Почитать про инсайдерские угрозы от ИИ-агентов можно в публикации Мэтта Адамса "Actions Speak Louder Than Tokens", где он также презентовал модель угроз ИИ-инсайдеров: всего описано 27 угроз, сгруппированным в 6 категорий, соответствующих архетипам классических инсайдеров. Учитывая, что в скором времени на каждого сотрудника в среднем будет приходиться по 82 ИИ-агента, а эти агенты, в отличие от людей, работают на машинных скоростях, не делают перерывов на обед и не имеют психологического состояния, за которым можно было бы следить, программу противодействия инсайдерским угрозам уже пора натягивать и на ИИ-агентов... Кстати, в статье Мэтта Адамса есть рекомендации по мониторингу и выявлению инсайдерской деятельности ИИ-агентов, а также меры митигации. #insider #ai #cisa #guide #threat #model #framework #agent

В конце августа агентство CISA выпустило аналитический отчет об угрозах, связанных с эксплуатацией уязвимостей, за 2024-2025 (финансовые) годы. Даже без учета "национальных особенностей" много интересной статистики, а главный вывод можно сформулировать так:

Причина подавляющего количества инцидентов не сложные APT-атаки, а эксплуатация уязвимостей в доступных из сети Интернет активах. Сами уязвимости "спровоцированы" давно известными дефектами (CWE) в коде, которые систематически попадает в ежегодные топы самых опасных (инъекции, межсатовый скриптинг, недостаточная проверка ввода и т.п.).

В целом, отчёт однозначно стоит посмотреть: дублировать цифры не буду, а лишь подсвечу ключевые рекомендации, которые CISA транслирует в адрес организаций, закупающих программное обеспечение. Чтобы оценить безопасность приобретаемого ПО, организациям предлагается задавать следующие вопросы вендорам: ➡️Прост ли процесс установки патчей безопасности и включены ли по умолчанию автоматические обновления? ➡️Предоставляется ли технология единого входа (SSO) бесплатно в базовом пакете поставки? ➡️Настроена ли по умолчанию многофакторная аутентификация, в том числе устойчивая к фишингу? ➡️Отсутствует ли функционал "паролей по умолчанию" или есть ли планы по исключению этого функционала в будущих версиях? ➡️Какие классы уязвимостей производитель уже полностью "искоренил" в своем ПО, и каков его план по устранению оставшихся (есть ли дорожная карта)? ➡️Включены ли журналы безопасности в стандартную поставку продукта (без дополнительной платы)? ➡️Предоставляет ли вендор машиночитаемый SBOM (Software Bill of Materials)? ➡️Насколько точно производитель сопоставляет уязвимости в своих продуктах со справочниками CWE и CPE? #cisa #vm #vulnerability #cve #cwe #cpe

SANS опубликовал ежегодное исследование, посвященное повышению осведомленности и культуре кибербезопасности внутри организаций. Пожалуй, главное изменение по сравнению с отчетом прошлого года – это взрывной рост риска, связанного с ненадлежащим использованием ИИ-инструментов, что подтверждается вторым местом в топе человеческих рисков. Правда, в исследовании подчеркивается, что ИИ не только новый вектор атак, но и мощный инструмент для специалистов по повышению осведомленности. ИИ-инструменты используются в следующих направлениях: 1️⃣Создание обучающего контента – быстрое создание понятной инфографики и видеороликов. 2️⃣Геймификация обучения – можно навайбкодить интерактивные и игровые учебные курсы/игры. 3️⃣Упрощение политик ИБ – можно перевести внутренние документы на доступный язык или сделать краткие чеклисты и инфографику. 4️⃣Опросы и оценка знаний – разработка тестов, проведение исследований и автоматизация подсчета метрик и иной аналитики. 5️⃣Бизнес-кейсы – помогает подготовить обоснование для руководства, переводя на понятный им язык финансов. Среди ключевых выводов выделяют следующие: ➡️Работа специалиста по повышению осведомленности в области ИБ заключается не в обучении людей безопасности, а в том, чтобы обучать ИБ-команду понимаю людей. ➡️Программы поощрения сотрудников (за правильное поведение) работают гораздо лучше, чем наказания или публичное порицание за ошибки. ➡️Первые три месяца (на новом месте работы) следует потратить на изучение культуры организации и болей сотрудников, а не на запуск обучения. ➡️Безопасность нужно "продавать", объясняя сотрудникам личную выгоду и упрощая правила. ➡️Полноценное изменение культуры невозможно силами одного специалиста – необходимо заручаться поддержкой коллег из различных подразделений и уровней. ➡️Чтобы достичь высшего уровня зрелости программы повышения осведомленности рекомендуется иметь как минимум одного специалиста по "человеческому фактору" на каждые десять технических специалистов по ИБ. #sans #awareness #culture #ai

Aikido Security в очередной раз сравнили последние версии ИИ-моделей с точки зрения способности обнаружения уязвимостей в коде🥇🥈🥉 В последнем тестировании смотрели на десять моделей, которым скормили наборы данных с 32 "свежими" уязвимостями: каждой модели давали по три попытки с максимум 30 итерациями для нахождения уязвимости (без доступа в сеть Интернет). Дублировать результаты для каждой модели нет смысла: всё понятно из статьи и графиков, а после выхода новых версий моделей результаты изменятся. Поэтому подсвечу обобщённые выводы из сравнения открытых и закрытых моделей: 🔗Объединение (pooling) результатов нескольких независимых прогонов значительно расширяет общий процент выявления уязвимостей – ИИ-модели по своей природе показывают нестабильные результаты от запуска к запуску, предлагая разные пути решения задачи, что может сыграть на руку при задаче поиска уязвимостей. 🔗Стратегия многократного запуска более дешевых и эффективных (с открытыми весами) моделей оказывается экономически более выгодной и результативной, чем один запуск дорогой коммерческой (закрытой) модели. 🔗Главной проблемой открытых моделей становится высокий уровень ложноположительных сработок, что увеличивает затраты (нагрузку) на последующий этап постпроверки и фильтрации шума. Дорогие коммерческие модели, напротив, окупают свою стоимость снижением затрат на последующий триаж, благодаря более высокой точности. 🔗Для достижения высокой эффективности работы ИИ-моделей в любом случае требуется качественный управляющий слой оркестрации (harness), который управляет агентом, координирует шаги проверок, интерпретирует выводы и отсекает ложные срабатывания. Модели с открытыми весами особенно чувствительны к качеству такой программной обвязки. #ai #benchmark #cve #vulnerability #harness #llm #triage

Такое берем🔥 p.s. Почте России на заметку) p.p.s. Бонусом идет срач дискуссия о том как правильно хранить пароли. #humor #friday

Cloud Security Alliance выпустила обновленный топ угроз облачной безопасности на основе опроса экспертов. Для каждой угрозы есть описание причин возникновения, технического и бизнес-влияния, ключевых мер митигации (в т.ч. связь с мерами из фреймворков CSA), тезисы из исследований и примеры связанных инцидентов (ссылки тоже есть). Сам топ угроз версии 2026 года выглядит следующим образом: ➡️Недостаточное управление идентификацией и доступом ➡️Атаки с использованием искусственного интеллекта ➡️Небезопасные сторонние ресурсы (зависимости и компоненты) ➡️Небезопасные интерфейсы и API ➡️Неправильная конфигурация и недостаточный контроль изменений ➡️Компрометация систем искусственного интеллекта ➡️APT-атаки ➡️Отсутствие стратегии и управления облачной безопасностью ➡️Небезопасная разработка ПО ➡️Случайное раскрытие облачных данных ➡️Системные уязвимости p.s. ИИ-технологии повлияли на развитие всех перечисленных угроз, о чем отдельно говорится в описании каждой из них. #cloud #csa #threats #landscape #ti #impact #mitigation #controls

Выбираем SIEM методом Сократа 😏 Интересная визуализация методики выбора SIEM‑системы (правда, забугорной) через анализ ресурсов и потребностей организации с помощью восьми контрольных (критически важных, по мнению автора) вопросов. Для выбора решения предлагается дать ответы на следующие вопросы: 1️⃣Что является приоритетом — простое соблюдение нормативных требований или проактивное обнаружение угроз? 2️⃣Каков объем данных? Это небольшая инфраструктура или среда с более чем 100 устройствами, облачными сервисами (c EDR+IAM), объемом данных свыше 250 ГБ в день и 2+ сотрудниками SOC? 3️⃣Используются другие ИБ-решения от выбираемого вендора или внедрен мультивендорный стек? 4️⃣Соответствует ли объем алертов возможностям команды? Каково качество обнаружения (уровень ложноположительных срабатываний, точность)? 5️⃣Готова ли компания инвестировать в собственную команду по разработке правил обнаружения или планирует полностью передать это на аутсорс? 6️⃣Нужно ли пытаться оптимизировать текущую legacy-систему или лучше начать «с чистого листа» с новой SIEM? 7️⃣Критически ли важно проводить анализ в реальном времени в момент поступления данных или допустима задержка после их сохранения в хранилище? 8️⃣Требуется ли решение, изначально созданное для облака, или необходимо поддерживать сложную гибридную инфраструктуру? Как верхнеуровневый чеклист – приемлемо, может задать направление, но сама методика не учитывает многие важные моменты: как минимум, не учитываются скрытые и косвенные затраты, упор сделан на на объеме обработки данных, но ничего не говорится про сложность парсинга и нормализации и т.п. #framework #maturity #soc #siem

ИБ-инженеры из Figma поделились опытом внедрения и использования ИИ-агентов для поиска и исправления уязвимостей в программном коде – статья написана простым доступным языком, да еще и с забавными иллюстрациями (Figma же😁). В компании ИИ-агенты используются в трех процессах: генерации кода, проверка пулл-реквестов и аудит (ретроспективный) всего кода. Из всех выводов и тезисов остановлюсь только на одном, который показался очень интересным с точки зрения баланса между "ИБ-запретительством" и "ИБ с человеческим лицом". Несмотря на то, что ИБ-инженеры Figma обязали разработчиков направлять все пулл-реквесты через проверку ИИ-агентами, они сознательно не стали внедрять режим блокировки – руководство решило не платить "налог на трение", который возник бы при автоматической блокировке работы разработчиков. Вместо этого они сосредоточились на "правильных" коммуникациях: 🔗Figma отошла от мягких, «извиняющихся» формулировок в комментариях (с информацией о найденных багах в пулл-реквестах) агентов, чтобы сделать требования безопасности более весомыми. Было:

«Есть вопросы? Напишите в #security. Ложное срабатывание? Нажмите 👎. Извините за шум».

Новый вариант содержит жирный шрифт и прямой призыв:

«🎯 Мы настраиваем точность сработок на основе оценок и отзывов пользователей. Пожалуйста, обработайте этот недостаток. Нажимайте 👎 на ложные срабатывания, чтобы помочь нам поддерживать высокий уровень точности. Вопросы? #security.

🔗Чтобы разработчикам было проще воспринимать информацию и они не игнорировали длинные отчеты, был жестко ограничен формат вывода комментариев агента: 🟠Одно предложение с сутью проблемы. 🟠Пронумерованные шаги воспроизведения эксплойта. 🟠Краткая рекомендация по исправлению. 🟠Ссылки на соответствующие участки кода. Это решение помогло побороть привычку современных моделей (таких как Opus 4.5+) выдавать избыточные описания. Это позволило повысить метрику исправления уязвимостей до мержа пулл-реквестов. Однако тут стоит отметить, что: 1️⃣ИИ-агенты получили возможность комментирования (оповещения о нахождении потенциальных уязвимостей) пулл-реквеста только после достижения порога в 70% по метрике точности (доли реальных уязвимостей среди всех сработок). 2️⃣Использование ИИ-агентов не заменяет классических инструментов (SAST/DAST/SCA), а там скорее всего блокировки есть. 3️⃣Если автор пулл-реквеста помечает сработку ИИ-агента как ложноположительную, то такой кейс проверяется другим ИИ-агентом и, в случае, повторной сработки направляется дежурному ИБ-инженеру для ручной проверки и окончательного вынесения вердикта. #ai #figma #vm #vulnerability #culture #scr #ssdlc #awareness

Хех, ISACA заколлабилась с Nike и выпустила лимитированную серию кроссовок) p.s. Говорят, чтобы не потерять право ношения кроссовок надо ежегодно заносить в ISACA 45$😁 ISACA – Just Pay It! #isaca #humor #merch

🥇KPMG и TAG Infosphere недавно выпустили совместное руководство (скорее набор статей с рекомендациями) по пересмотру подходов к формированию бюджетов на кибербезопасность. Ключевые тезисы вынесены в иллюстрацию к посту, а ниже немного распишу общие (не отраслевые) рекомендации. Бюджетирование на принципах «Нулевого доверия» ➡️Ни одно средство защиты/услуга не должны автоматически пролонгироваться только потому, что они использовались в прошлом году. ➡️Бюджет должен разделяться на небольшие проверяемые сегменты, привязанные к конкретным целям снижения рисков. ➡️Каждый сегмент бюджета должен постоянно (например, ежеквартально) оцениваться с точки зрения фиксации наличия измеренного риска, который закрывается этим объемом бюджета, и изучения данных телеметрии, подтверждающих (или нет) его эффективности. 📌В публикации есть описание кейса бюджетирования в банке. Риск-ориентированный подход к формированию бюджета ➡️Каждая категория расходов должна быть привязана к задокументированному и количественно оцененному риску. ➡️Бюджеты должны быть гибкими и обновляться в зависимости от изменения ландшафта угроз, а не фиксироваться раз в год. ➡️Должна поддерживаться прозрачность между затратами и снижением риска для всех участников процесса бюджетирования. 📌Для этого необходимо сформировать перечень "топ-рисков", смаппить статьи бюджета с техническим описанием на бизнес-риски и перераспределить средства из областей с избыточными мерами контроля и митигации в проблемные зоны. Переход к "четырехмерной" модели оценки рисков ➡️Расширенная оценка вероятности – учитывает мотивацию, возможности и ресурсы злоумышленников в контексте конкретной отрасли и организации. ➡️Комплексная оценка воздействия – gереход от оценки технического ущерба к моделированию сбоев в критических бизнес-процессах. ➡️Анализ скорости – измерение скорости "материализации" угрозы и доступного времени на реагирование. ➡️Каскадность – оценка того, как инцидент может распространиться через цепочки поставок и экосистемы партнеров. 📌Помимо очевидных моментов, связанных с развитием направления Threat Intelligence и Red Teaming и использования полученных данных для динамической приоритизации рисков, есть важный совет как учитывать бизнес-контекст – интеграция с бизнес-календарем (например, корректировка оценки риска целевого фишинга в периоды подачи финансовой отчетности). p.s. Следуя современным тенденциям, также приведены рекомендации по использованию ИИ в процессе бюджетирования. #budget #ciso #risk #crq #roi #cost #effectiveness

✅ Здесь, кстати, исправил несколько ошибок и разместил веб-версию курса по адресу sa.alexredsec.ru. p.s. Еще подборку ресурсов на тему управления уязвимостями положил в репозиторий и продублировал по адресу vm.alexredsec.ru ❤️ #awareness #training #vm #bookmarks

Pillar Security выпустили обновленную версию своего фреймворка SAIL, разработанного для обеспечения безопасности ИИ-систем на всех этапах их жизненного цикла. Для практического использования фреймворка SAIL авторы поделились также скиллом для ИИ-агентов, с помощью которого можно: ➡️Провести оценку по фреймворку, например, своих ИИ-агентов, чтобы выявить присущие риски (сформировать модель угроз). ➡️Сформировать план повышения уровня безопасности вашего проекта. ➡️Проверить на соответствие комплаинс-требованиям (например, ISO 42001). ➡️Сформировать опросник для оценки безопасности сторонних ИИ-решений. p.s. Скилл совместим с Claude Code, Codex, ChatGPT, Antigravity и другими skill.md-совместимыми агентами. #ai #framework #risk #sail #lifecycle #skill

AI SOC Evaluation Framework – еще один вендор-независимый фреймворк для оценки применимости и эффективности AI SOC. На сайте проекта также есть онлайн-калькулятор. Ключевые компоненты ASEF: 🟠Shift Map (карта жизненного цикла инцидента) Позволяет оценить применимость ИИ на каждом этапе обработки данных и угроз: 🟠Evaluator Scale (шкала автономности) – каждая функция оценивается по уровню автоматизации от 0 (ручной режим) до 2 (полная автономия). Например, уровень 1A (Approve) означает, что ИИ самостоятельно сформировал план действий и ожидает только подтверждения от аналитика. 🟠Builder Mode (оценка рисков внедрения) – скоринг применимости функций под специфику конкретной команды, учитывая степень надежности реализации алгоритма (Trust), ресурсоемкость развертывания и поддержки силами внутренней команды (Complexity) и риски для бизнес-процессов в случае ошибки ИИ (Impact). 🟠Метрики эффективности (PICERL) – внедрение платформы оценивается через изменение (дельту) метрик на разных стадиях инцидента (Preparation -> Identification -> Containment -> Eradication -> Recovery -> Learning) относительно исходного состояния. Этапы выбора AI SOC платформы по методологии ASEF: 🟠Frame – самооценка слабых мест текущего SOC, фиксация базовых метрик и определение критических требований. Без фиксации базовой линии дальнейшая объективная оценка невозможна. 🟠Shortlist – фильтрация кандидатов по ключевым технологическим критериям, проверка наличия механизмов логирования и аудита, исключение заведомо незрелых решений. 🟠Evaluate – тестирование систем на собственных данных. Проводится сначала в Shadow mode (ИИ наблюдает и готовит черновики без активных действий в инфраструктуре), затем — с постепенным расширением зон контроля (тестовые хосты -> рабочие станции -> продуктивная среда). 🟠Maturity – составление итогового профиля возможностей продукта на карте Shift Map. 🟠ROI – расчет изменения метрик эффективности PICERL и оценка совокупной стоимости владения для покупателя. 🟠Decide – принятие финального решения на основе сопоставления результатов пилота с пороговыми значениями, установленными на первом этапе. Посты про другие фреймворки: ➡️SIEM and AI SOC Ratings Framework ➡️AI Response Maturity Model #framework #maturity #soc #siem #ai