Разбираемся с открытой библиотекой Agent Skills для кибербезопасности на 754 навыка, показываем, как она устроена, и проводим живой эксперимент: даём агенту Hermes два навыка и просим разобрать реальный IPS-лог и провести аудит правил файрвола – сначала на бесплатной модели Owl Alpha (из-за того что подобную модель при желании можно использовать локально), затем на платной Opus 4.8 (Cloude Security). Сравниваем, где проходит граница между «бесплатно» и «дорого, но качественно».
Откуда взялась «пещера»
В одну ночь у нас на столе оказались четыре вещи: открытый репозиторий с 754 (!) навыками по ИБ для AI-агентов, автономный агент Hermes от Nous Research, LLM-модели Owl Alpha и Opus 4.8, а также открытое API Ideco NGFW в markdown-формате и соответствующий тестовый сервер. Собрали всё вместе и проверили на что способен AI-native администратор NGFW.
Ощущение от первого захода в репозиторий было ровно как у Аладдина в пещере: вокруг сундуки с готовыми playbook’ами, на каждый второй случай из жизни безопасника. Volatility3 для дампов памяти, Zeek для разбора PCAP, Sigma-правила под Kerberoasting, разбор Cobalt Strike beacon, форензика облаков на трёх провайдерах. И ключ ко всему этому богатству – почти любая LLM, которая умеет в tool calling.
Проведем эксперимент: два конкретных навыка из сетевой безопасности, один агент, реальные данные. И в конце – где здесь грабли, на которые легко наступить.
Что такое Agent Skills и почему это не просто очередные промпты
Agent Skills – это открытый формат для расширения возможностей AI-агента специализированными знаниями и рабочими процессами. Вместо того чтобы каждый раз промтом объяснять модели, «как senior-аналитик расследует утечку через DNS-туннель», вы один раз описываете этот workflow в структурированном виде – и подкладываете агенту.
Технически навык – это директория с файлом SKILL.md. Внутри – YAML-фронтматтер для быстрого обнаружения и Markdown-тело с пошаговой инструкцией:
skills/performing-memory-forensics-with-volatility3/
├── SKILL.md ← определение навыка (YAML + Markdown)
├── references/
│ ├── standards.md ← маппинг на MITRE ATT&CK, ATLAS, D3FEND, NIST
│ └── workflows.md ← глубокая техническая процедура
├── scripts/
│ └── process.py ← рабочие вспомогательные скрипты
└── assets/
└── template.md ← шаблоны отчётов и чек-листы
Ключевая находка здесь – progressive disclosure. Сканирование фронтматтера одного навыка стоит агенту порядка 30 токенов, а полная загрузка тела – 500–2000 токенов. Это означает, что агент может за один проход просмотреть все 754 навыка, отобрать релевантные по тегам и описанию, и подгрузить в контекст только два-три нужных. Никакого раздувания контекстного окна.
Выглядит это примерно так, как описывает сам репозиторий:
Запрос: «Проанализируй дамп памяти на признаки кражи учётных данных»
Что делает агент:
1. Сканирует 754 фронтматтера (~30 токенов каждый)
→ находит 12 релевантных навыков по тегам и описанию
2. Загружает топ-3 совпадения:
• performing-memory-forensics-with-volatility3
• hunting-for-credential-dumping-lsass
• analyzing-windows-event-logs-for-credential-access
3. Выполняет workflow пошагово
→ запускает плагины Volatility3, проверяет паттерны доступа к LSASS
4. Валидирует результат и мапит на ATT&CK T1003 (Credential Dumping)
Важная оговорка. В названии репозитория стоит слово «Anthropic», но это независимый community-проект, не аффилированный с компанией Anthropic PBC. Эта библиотека навыков – работа энтузиаста, а не известного вендора. Для нас это не минус: открытость как раз и означает, что любой может проверить, форкнуть и допилить под себя. Но как и к любому OpenSource, нужно подходить осторожно и не забывать о основах информационной безопасности. Рекомендуем использовать агентов в строго контролируемой среде.
Что внутри: 754 навыка, 26 доменов, 5 фреймворков
Масштаб библиотеки – её главный аргумент. На момент анализа это 754 навыка в 26 доменах ИБ. Распределение по ключевым направлениям:
|
Домен |
Навыков |
Что покрывает |
|
Cloud Security |
60 |
Харденинг AWS/Azure/GCP, CSPM, облачная форензика |
|
Threat Hunting |
55 |
Гипотезо-ориентированные охоты, LOTL-детект, поведенческая аналитика |
|
Threat Intelligence |
50 |
STIX/TAXII, MISP, интеграция фидов, профайлинг акторов |
|
Web Application Security |
42 |
OWASP Top 10, SQLi, XSS, SSRF, десериализация |
|
Network Security |
40 |
IDS/IPS, правила файрвола, сегментация VLAN, анализ трафика |
|
Malware Analysis |
39 |
Статический/динамический анализ, реверс, песочницы |
|
Digital Forensics |
37 |
Снятие образов дисков, форензика памяти, реконструкция таймлайнов |
|
Security Operations |
36 |
SIEM-корреляция, анализ логов, триаж алертов |
|
SOC Operations |
33 |
Playbook’и, эскалации, метрики, tabletop-учения |
|
OT/ICS Security |
28 |
Modbus, DNP3, IEC 62443, защита SCADA |
Отдельная сильная сторона – каждый навык размечен сразу под пять фреймворков: MITRE ATT&CK v19.1, NIST CSF 2.0, MITRE ATLAS, MITRE D3FEND и NIST AI RMF. Один навык – пять «галочек» по комплаенсу. Для тех, кто живёт в логике соответствия требованиям, это экономит часы ручного маппинга. Выглядит не сложно скорректировать навыки под требования ФСТЭК, КИИ и специфики российского регулирования.
Вот как это выглядит на одном навыке:
|
Навык |
ATT&CK |
NIST CSF |
ATLAS |
D3FEND |
AI RMF |
|
analyzing-network-traffic-of-malware |
T1071 |
DE.CM |
AML.T0047 |
D3-NTA |
MEASURE-2.6 |
Тело навыка устроено стандартно: разделы When to Use (когда активировать), Prerequisites (что нужно), Workflow (пошаговое исполнение с конкретными командами) и Verification (как убедиться, что всё отработало). Это чек-лист – формализованный процесс принятия решений, по которому работает опытный аналитик.
Почему это вообще нужно: про дефицит кадров
Контекст, в котором всё это появилось, – хронический дефицит кадров в ИБ. К 2027 году дефицит кадров на рынке ИБ в России прогнозируется на уровне 54–65 тыс. специалистов (23–25% от потребности).
Сегодняшние модели умеют писать код и искать в вебе, но для ИБ им не хватает именно практических playbook’ов, превращающих генеративную LLM в способного аналитика. Джун знает, какой плагин Volatility3 запустить на подозрительном дампе и какие Sigma-правила ловят Kerberoasting. Базовая LLM этого не знает – пока вы не дадите ей навыки.
Это ровно та логика, которую мы в Ideco исповедуем в продукте: интеллект должен быть встроен в инструмент, а не жить отдельно в голове эксперта. Хорошо то, что интеллект сейчас подаётся агенту в виде переносимых текстовых навыков.
Эксперимент: Hermes + Owl Alpha администрируют реальный NGFW
Мы взяли два конкретных навыка из библиотеки и прогнали их на реальных данных нашего тестового шлюза. Все чувствительные данные ниже обезличены: имена пользователей убраны, внутренние адреса заменены на условные, хостнейм – тоже. Технические находки оставлены как есть – именно они представляют ценность.
Стенд
|
Компонент |
Что использовали |
|
Агент |
Hermes Agent (Nous Research) |
|
Модель |
Owl Alpha – бесплатная фронтир-модель на OpenRouter, контекст 1,05M токенов |
|
Навык 1 |
analyzing-network-traffic-for-incidents – для разбора IPS-лога |
|
Навык 2 |
implementing-network-segmentation-with-firewall-zones – для анализа правил файрвола |
|
Источник данных |
Ideco NGFW API v22 (/ips/alerts, конфигурация правил) |
|
Расход |
~12 млн токенов на тестовые прогоны (112 запросов) |
Пара слов про инструменты. Hermes Agent – это автономный агент с замкнутым циклом обучения: он создаёт навыки из опыта, улучшает их в процессе работы и строит модель пользователя между сессиями. Запускается где угодно – от локали и Docker до SSH и serverless. То, что нам и нужно: посадить его рядом со шлюзом и дать инструменты. Мы уже писали о его использовании для пентеста веб-приложений. В данных примерах используем его на MacMini.
Owl Alpha – высокопроизводительная foundation-модель под агентные нагрузки с нативной поддержкой tool use и длинного контекста. На момент эксперимента она бесплатна и числится в топе бесплатных моделей OpenRouter с расходом почти в 2 триллиона токенов. Используем ее для проверки, можно ли на для AI-Red/Blue-Team использовать локальные DeepSeek/Qwen модели.
Прогон 1: навык analyzing-network-traffic-for-incidents на IPS-логах
Навык заточен под разбор сетевого трафика и инцидентов: детект C2-биконинга, латерального движения, эксфильтрации. В оригинале он опирается на Wireshark, Zeek и NetFlow. Мы скормили агенту выгрузку IPS-алертов через API (4 353 события за сутки, 16 389 уникальных алертов в базе за месяц) и попросили отработать по шагам навыка.
Что нашёл агент – по убыванию серьёзности (данные обезличены):
CRITICAL – атаки изнутри сети. Агент сгруппировал события по источникам и подсветил несколько хостов:
|
Источник (обезличен) |
Алертов |
Что детектировано |
|
Хост в подсети пользователей A |
87 critical |
Kolibri HTTP Buffer Overflow |
|
Хост B |
48 |
DNS Inverse Query Overflow (CVE-1999-0009) |
|
Хост в WiFi-сегменте |
262 (140 пропущено) |
Imatix Xitami DoS |
|
Хост C |
30 |
User-Agent от Windows 98 |
Отдельно стоит история с попытками эксплуатации переполнения буфера в HTTP-сервере Kolibri – 87 критических попыток, 0 заблокировано, и все ночью, в 02:41–04:43. Источник – внутренний хост. Агент перечислил возможные сценарии: компрометация хоста (червь/бэкдор), легитимное сканирование уязвимостей (но ночью – подозрительно) или L2-спуфинг. И выставил приоритет P0: изолировать и проверить.
Отдельно стоит сказать, что явные false positive срабатывания сигнатуры «DNS Inverse Query Overflow (CVE-1999-0009)» агент на OWL Alpha никак не обозначал. Тогда как Cloude в подобных случаях и при перепрогоне выяснял ложность срабатывания и не добавлял их в отчет.
CRITICAL – IPS молчит 2+ часа. Последний алерт зафиксирован в 04:59:58, после чего – тишина. Агент сам предположил причины (краш Suricata, сбой event-syncer, переполнение базы логов, остановка сервиса администратором – последнее было верно для этого стенда) и поставил это первым пунктом плана: проверить работоспособность движка и настроить алертинг на саму остановку IPS. Это ценный момент: модель не просто разобрала то, что есть в логах, но и заметила отсутствие данных – а это классическая слепая зона автоматизированного анализа.
Любопытно, что срабатывание сигнатуры User-Agent от Windows 98 агент верно проинтерпретировал её двояко: либо это реально устаревшая ОС без обновлений безопасности 20+ лет (критический риск), либо спуфинг User-Agent для обхода фильтров. Оба сценария требуют расследования.
Заметим также, что человеку просмотреть 4,5 тысячи строк логов и выявить главное – заняло бы достаточное количество времени, даже с использованием фильтров.
Прогон 2: навык implementing-network-segmentation-with-firewall-zones на правилах файрвола
Второй навык – про правила файрвола и сегментацию: зоны, VLAN, ACL, микросегментация, принцип default deny. Агент по API самостоятельно получил доступ (в режиме «только для чтения») к конфигурации правил шлюза и провел аудит. Навык в оригинале ориентирован на Palo Alto / Fortinet / Cisco, но логика default-deny и анализа теневых правил универсальна – и агент применил её к нашей таблице правил. Благо Ideco NGFW имеет схожую структуру правил – zone-based firewall, профили IPS и контроля приложений в правилах.
Сводка находок (обезличено): 1 HIGH, 16 MEDIUM, 18 LOW.
HIGH – нет явного deny-all в цепочке INPUT. Последнее правило INPUT – автоматически созданное при миграции ANY→ANY ACCEPT без логирования. То есть весь трафик к самому NGFW разрешён по умолчанию: веб-интерфейс, SSH, API потенциально доступны из любой сети. Прямое нарушение принципа «запрещено всё, что явно не разрешено». Рекомендация агента: удалить auto-migration правило и добавить последним ANY→ANY DENY с логированием.
MEDIUM – дыры в аудите. Покрытие логированием оказалось неравномерным:
FORWARD: ████████████████████░░░░░░░░ 24/38 (63%)
INPUT: ██████░░░░░░░░░░░░░░░░░░░░░░░ 3/14 (21%) ← критично
DNAT: ██████████░░░░░░░░░░░░░░░░░░░ 2/5 (40%)
Секция INPUT, которая управляет доступом к самому шлюзу, логируется всего на 21%. Агент обнаружил настройку глобального логирования правил log_mode=all, но ошибочно решил, что она не переопределяет настройку на уровне отдельного правила. Очевидно навык «из коробки» требует небольшой доработки. Причем сделать это может сам Hermes – достаточно сказать ему об этом и навык был адаптирован.
MEDIUM – теневые и дублирующие правила. Два catch-all ACCEPT подряд (один с DPI, другой без), причём второй полностью перекрывается первым. Правило блокировки порта 445 продублировано (TCP и UDP в разных правилах, одно никогда не срабатывает). Такой анализ – неоценимая польза на фарволах, содержащих сотни и тысячи правил (рекорд Ideco NGFW – 100 000 правил у одного из клиентов!).
В сухом остатке: оба навыка не выдали ничего, чего не нашёл бы опытный инженер с доступом к консоли. Но они выдали это за один прогон, структурированно, с приоритизацией P0–P3 и готовым чек-листом исправлений – и сделали это на бесплатной модели, аналог которой можно запустить и локально.
Контрольный заход: те же задачи на Opus 4.8
После прогона на бесплатной Owl Alpha закономерно возник вопрос: а что изменится, если поставить вместо неё топовую платную модель? Мы повторили эксперимент на Claude Opus 4.8 – с тем же агентом, теми же навыками, но с двумя усложнениями. Во-первых, взяли свежее окно логов – 3 часа против суток у Alpha, но более нагруженный сервер: 21 500 событий безопасности. Во-вторых, добавили вторую стадию – расследование двух «подозрительных» хостов, которые модель сама же и подсветила на первой стадии. Цена вопроса вышла около 8 долларов. Данные, как и выше, обезличены.
Стадия 1: тот же навык анализа трафика, но плотнее
На окне в 3 часа (21 500 событий) Opus отработал тот же навык analyzing-network-traffic-for-incidents.
Что Opus сделал заметно лучше Alpha – это отделение сигнала от шума. Он сразу вычислил, что более половины всего объёма (около 11 700 событий, 54%) – это два «шумовых» класса: STUN Binding Response (легитимный WebRTC/VoIP-трафик) и AM INFO HTTP Cache-Control. И в рекомендациях предложил создать правила-исключения, потому что этот шум маскирует реальные инциденты. Alpha такой приоритизации «что выкинуть из поля зрения» не делал.
Дальше – две находки, которые Opus вытащил как приоритет P1 и которые в потоке из 21 500 событий легко пропустить вручную:
|
Находка (обезличено) |
Сигнатура |
Реакция IPS |
|
Исходящее соединение к возможному C&C |
Outbound connection to a possible C&C server (severity 1) |
allowed (пропущено) |
|
Загрузка PE-файла трояна |
AM TROJAN Trojan/Win32.CeeInject (severity 2) |
allowed + blocked (частично) |
И положительная часть, которую модель отметила: блокировка хорошо работает там, где настроена – DoH-обход DNS-фильтрации (около 4 000 событий заблокировано), VPN и анонимайзеры (Browsec, HolaVPN, Anonymizer), фишинг-кит W3LL (частично).
Стадия 2: расследование хостов – то, чего Alpha не делал вовсе
Вот здесь проходит главный водораздел между моделями. Alpha остановился на «вот подозрительные хосты, проверьте их». Opus сделал следующий шаг сам: взял два IoC-хоста и провёл по каждому полноценное расследование, коррелируя пять разных источников – журнал IPS, журнал межсетевого экрана и DPI, журнал DNS с категориями угроз, активные сессии. Это уже не разбор одного лога, а мультиисточниковая реконструкция поведения хоста. Дай агенту еще данных – и он самостоятельно сделает корреляцию лучше SIEM.
Хост 1 – мнимый C&C, оказался ложным срабатыванием. Сигнатура severity-1 «исходящее соединение к C&C» выглядела угрожающе. Opus разобрал внешний адрес по PTR/AS – это оказался российский телеком-хостинг, соединение единичное, без бикон-паттерна и сопутствующих индикаторов. Проверил хост как источник и как назначение в IPS: только информационный шум и ложноположительные NOP-паттерны на трафике от CDN мессенджера. Сверил с DPI – трафик легитимный (DNS, QUIC/TLS к публичным облачным сервисам). Проверил DNS-угрозы: единственная «угроза» – домен сервиса автообновления Electron-приложений, ошибочно отнесённый к DNS-туннелированию, и тот уже блокируется фильтром. Вердикт: ложноположительное срабатывание, компрометации нет. На ручную отработку такой тревоги аналитик потратил бы час; Opus закрыл её с обоснованием за один проход.
Хост 2 – реальный детект, но с нюансами. Здесь модель не стала спешить с «всё чисто». Троян Trojan.Win32.CeeInject (сжатый PE) – это не ложное срабатывание, файл доставлялся через легитимный мессенджер по HTTP (порт 80), и антивирусный движок Ideco NGFW частично заблокировал передачу. Opus аккуратно развёл смягчающие факторы (доставка через легитимный канал, часть сессии заблокирована, нет последующей C2-активности и аномального exfil) и остаточный риск (часть файла из-за режима allowed могла достичь хоста). Итоговый вердикт – средний/высокий приоритет с конкретным планом: проверить эндпоинт на сохранение/запуск файла, опросить пользователя, рассмотреть блокировку передачи PE через мессенджеры в контентном фильтре. Ровно та работа, которую делает L2-аналитик SOC.
Alpha против Opus: где проходит граница
Оба прогона полезны, но они играют в разных лигах. Сведём наблюдения – с оговоркой, что окна логов и профили различались, поэтому сравнение качественное, а не лабораторно-чистое.
|
Критерий |
Owl Alpha (бесплатно) |
Opus 4.8 (~8$) |
|
Базовый диагноз (IPS в режиме alert) |
Нашёл |
Нашёл и подтвердил с другого окна |
|
Приоритизация шума (что игнорировать) |
Слабо |
Вычислил 54% шума, предложил правила-исключения |
|
Разделение true/false positive |
Не делал |
Развёл FP и реальный детект по каждому хосту |
|
Мультиисточниковая корреляция |
Один лог (IPS) |
Четыре источника (IPS, FW/DPI, DNS, сессии) |
|
Глубина расследования хоста |
«Проверьте этот хост» |
Полный разбор с PTR/AS, вердиктом и планом |
|
Ложные тревоги |
Поднимал как критичные без проверки |
Закрывал с обоснованием |
|
Стоимость прогона |
0 ₽ |
~8$ |
Ключевое отличие не в том, что Opus «умнее» в разборе одного лога – базовый системный пробел нашли обе модели. Отличие в глубине рассуждения и способности довести расследование до вердикта. Alpha работает как быстрый сканер, который поднимает флаги. Opus работает как аналитик, который эти флаги проверяет, отсеивает ложные и доводит реальные до плана действий. Для триажа потока алертов хватит и дешёвой модели; для расследования инцидента, где цена ошибки – ложная изоляция боевого хоста или, наоборот, пропущенная компрометация, разница в качестве оправдывает плату. Выглядит так, что здорово будет работать мультиагентная система, где AI-аналитик первого уровня будет проводить общий анализ, а фронтир-модель – глубокое исследование подозрительных хостов.
Очевидный и видимый вывод про сами навыки: один и тот же SKILL.md на сильной модели раскрывается существенно полнее. Навык задаёт каркас процесса, но насколько глубоко агент пройдёт по этому каркасу – зависит от модели.
Честный разбор: где здесь грабли
Эксперимент получился показательным, но было бы нечестно подавать его как историю успеха без оговорок. Идём по острым углам.
Грабля №1: данные ушли «наружу»
Главная и неустранимая в тестовом сетапе проблема. Owl Alpha – stels-модель на OpenRouter, и провайдер прямо предупреждает: промпты и ответы логируются и могут использоваться для обучения. Мы фактически отправили конфигурацию файрвола и IPS-логи тестового шлюза стороннему провайдеру. Для КИИ и во многих других случаях это не допустимо. Однако сопоставимую по качеству модель можно развернуть локально. Эксперимент доказал ее базовую эффективность.
С Opus картина не лучше «по факту отправки»: мы точно так же передали логи и конфигурации стороннему API. Разница лишь в условиях: у платных моделей обычно есть внятная политика по данным и режимы без обучения на ваших запросах, у бесплатной модели – прямое предупреждение о логировании. Но оба варианта – это вынос чувствительных данных за периметр.
Грабля №2: человек в контуре обязателен
Все навыки выдают рекомендации, но ни один не должен исполнять их автоматически на боевом шлюзе. Агент может неверно понять кастомную конфигурацию сети, и автоматическое исправление правила файрвола – это прямой путь к самостоятельному отключению себе доступа.
Splunk в прогнозах на 2026 формулирует это как «гибридный человеко-агентный SOC»: агенты берут на себя повторяемую низкорисковую работу, а люди задают границы и проверяют решения. На русскоязычном Хабре уже выходил разбор Agentic SOC ровно в этой логике – самостоятельность агента должна быть ограничена четкими рамками.
Грабля №3: риск самих агентов как новой поверхности атаки
Когда мы даём агенту инструменты и право выполнять код, мы открываем новый вектор. OWASP Agentic Security Initiative относит неожиданное выполнение кода (RCE) агентом к угрозам наивысшего уровня: агент может быть склонён к генерации и запуску вредоносного кода в рантайме, минуя обычные процедуры авторизации изменений. Сюда же – prompt injection через те самые логи, которые агент анализирует. Если в логе есть строка, которую модель воспримет как инструкцию, поведение агента можно подменить.
Кроме того, нужно тщательно проверять навыки, которые вы используете – это тоже потенциальный способ перехвата контроля над агентом.
Правила простые: агент, работающий с инфраструктурой, должен жить в изолированной песочнице, с минимальными правами и полным логированием каждого своего шага и решения.
Что это значит для информационной безопасности
Открытая библиотека навыков снимает проблему «модель не знает, как работает настоящий ИБ-аналитик». Автономный агент даёт исполнительный контур. Дешёвый (или бесплатный) inference снимает порог входа. По отдельности всё это было и раньше – но именно сейчас три компонента сошлись настолько, что разбор боевого шлюза по навыку из открытого репозитория стал делом одного вечера и нуля рублей за модель.
Сравнение двух моделей добавляет важный нюанс к этой картине. Порог входа действительно нулевой: даже бесплатная модель находит системные пробелы. Но «потолок» расследования задаёт модель: переход от «вот флаг, проверьте» к «вот вердикт с обоснованием» – это ровно та работа, за которую платят аналитику SOC. Практический вывод – гибридная схема: дешёвая модель на первичном триаже потока алертов, сильная – на расследовании того, что прошло первичный фильтр.
Gartner относит AI SOC-агентов к категории на подъёме к пику завышенных ожиданий: измеримый прирост скорости и пропускной способности при развёртывании в пилотных проектах, но проблемы в настоящей эксплуатации и остающаяся доля ручного труда аналитиков. Наш эксперимент это подтверждает: пользы много, но и слепых зон хватает.
Для нас в Ideco этот опыт ложится в собственную траекторию. Мы исходим из того, что безопасность должна не успевать устаревать – а значит, интеллектуальный анализ конфигураций, аудит правил и приоритизация инцидентов должны жить внутри продукта, под контролем, на ваших данных и без отправки логов неизвестным провайдерам. То, что в эксперименте мы делали внешним агентом на чужой модели, в правильной архитектуре должно работать локально, рядом с трафиком, с человеком в контуре и с полным аудитом действий самого агента. Открытый API Ideco NGFW v22, через который агент и забирал данные, – это как раз тот фундамент, на котором такие сценарии собираются без боли. Мы проверили, что раскрытия API достаточно и ничего не пришлось «объяснять» агенту дополнительно.
Что попробовать прямо сейчас
-
Установить агента (Hermes или OpenClaw);
-
Склонировать репозиторий навыков и просто почитать SKILL.md интересных навыков – это бесплатный конспект практик senior-аналитика.
-
Прогнать любой навык на обезличенном тестовом стенде, а не на боевом контуре.
-
Помнить, что агент с правами на инфраструктуру – сам по себе объект защиты.
А если вам интересно, как подобный анализ может работать внутри NGFW, на ваших данных и без отправки наружу – это ровно то направление, в котором мы движемся. Расскажем в следующих материалах.
Автор: Ideco


