اعتبارسنجی دیتکشنها با ایجنتهای کدنویسی
هوش مصنوعیخلاصهٔ کاملتر
این پست که بخشی از یک تلاش بزرگتر تو مرکز دفاع سایبری بانک DNBه، تعریف میکنه که تیم چطور ایجنتهای کدنویسی مثل Claude Code و Codex رو برای اعتبارسنجی سرتاسری قواعد تشخیص بازآرایی کرده. یک پلاگین اختصاصی به ایجنت یاد میده شبیهسازی حمله بنویسه، از طریق SSH به هاست آزمایشگاهی بفرسته، منفجرش کنه و بعد از Splunk بپرسه که آیا تلهمتری رسیده و دیتکشن فعال شده یا نه. اگه جایی شکست بخوره، ایجنت بازنویسی میکنه و دوباره میره سراغش تا تکنیک بشینه یا گزینههاش تموم شه.
نویسنده اول توضیح میده که اعتبارسنجی دیتکشن طیفه: تستهای رگرسیون رویدادهای برچسبخورده رو فقط به خود قاعده میدن و تزریق لاگ مصنوعی مسیر ورود و پارس رو هم درگیر میکنه، ولی اجرای تکنیک واقعی روی اندپوینت واقعی کل مسیر رو زیر تست میبره: پیکربندی اندپوینت، رفتار سنسور، ورود داده، SIEM و سامانهای که هشدار رو برمیداره. پیشنیازش هم آزمایشگاهیه با ایمیج طلایی و مسیر ارسال لاگ کاملاً مشابه پروداکشن.
برای توصیف حملهها TTPForge (از Meta) انتخاب شده، چون اسکیمای YAMLش پشتیبانی درجهیک از بلوکهای قابل استفادهٔ مجدد، اجرای راه دور، تست، checks، cleanup و آرگومان داره. سه ویژگی مهمن: cleanup کار هر مرحله رو برعکس میکنه تا اجرای مکرر آشغال جا نذاره؛ checks بررسی میکنه که کار واقعاً انجام شده نه اینکه فقط دستور با کد صفر تموم شده؛ و args اجازه میده یک TTP بدون کپی شدن، چند هاست و مسیر و نوع مختلف رو پوشش بده.
خود پلاگین از نگاه نویسنده چیز پیچیدهای نیست: پوشهای از اسکیلها (ورکفلوهای مارکداونی که ایجنت دنبال میکنه)، هوکها (اسکریپتهای شل که روی رویدادهای چرخهٔ عمر شلیک میشن) و مواد مرجع. تفاوت مهم اینه که هوکها گاردریل واقعیان؛ چون بیرون از حلقهٔ استدلال مدل اجرا میشن، ایجنت نمیتونه ازشون رد شه — مثلاً هوکی که روی هر نوشتن فایل، YAML رو با ttpforge validate اعتبارسنجی میکنه و خطا جلوی ادامهٔ کار رو میگیره.
نیمهٔ دوم ماجرا سمت Splunkه. تیم یک پلاگین دوم دور REST API ساخته، ولی به گفتهٔ نویسنده بخش ارزشمندش پایگاه دانشیه که پشتشه: یک فایل مارکداون برای هر sourcetype که نام فیلدها، قالب مقادیر، شکافهای شناختهشده و قالبهای کوئری رو مستند میکنه. دلیلش هم اینه که Splunk وقتی فیلد ناموجود یا بازهٔ زمانی خالی یا نام هاست با قالب اشتباه بگیره، بدون خطا نتیجهٔ خالی برمیگردونه — و ایجنت بدون این دانش نمیتونه کوئری بد رو از خرابی واقعی پایپلاین تشخیص بده.
یک اجرای کامل تو مقاله این شکلیه: به ایجنت یک دیتکشن ماندگاری از نوع Netsh helper DLL (تکنیک T1546.007 در MITRE) داده میشه که نوشتن روی یک کلید رجیستری خاص رو رصد میکنه. ایجنت قاعده رو میخونه، YAML رو مینویسه، به آزمایشگاه میفرسته، اجرا میکنه و Splunk رو میکاوه. بار اول Defender مقدار رجیستری رو قبل از بررسی پاک کرده بود؛ ایجنت بررسی رو به خود عمل نوشتن تغییر داد و تطابق تمیز گرفت. سود اصلی این حلقه، بیرون افتادن خطاهای ریز و مکانیکیِ خط لولهٔ تشخیص بود که از بازبینی کد رد شده بودن.
نکات کلیدی:
- ایجنتهای کدنویسی برای نوشتن، اجرا و راستیآزمایی شبیهسازی حمله به کار گرفته شدن
- TTPForge با cleanup و checks و args انتخاب شده تا اجرای مکرر و خودکار ممکن شه
- هوکها بیرون از حلقهٔ استدلال مدل اجرا میشن و ایجنت نمیتونه ازشون رد شه
- پایگاه دانش هر sourcetype جلوی اشتباه گرفتن «کوئری بد» با «خرابی پایپلاین» رو میگیره
- بیشتر TTPها مناسب بودن؛ سود اصلی، پیدا شدن خطاهای مکانیکی پنهان تو خط لوله بود
- کاتالوگ نهایی زمانبندیشده اجرا میشه و سلامت پایپلاینها رو روی داشبورد نشون میده
