معرفی
این اپلیکیشن برای استفاده دفاعی، تحلیل، مدیریت یا تست مجاز معرفی شده و لینک اصلی آن به پروژه یا سازنده برمی‌گردد.
نکته 1
Velociraptor برای collection و triage در مقیاس endpoint طراحی شده است.
نکته 2
Artifact و VQL امکان workflowهای forensic قابل تکرار می‌دهند.
نکته 3
سطح دسترسی server و client بسیار حساس است و باید با RBAC و audit کنترل شود.
استفاده مسئولانه
قابلیت‌های RF، RFID، اسکن، credential audit، تحلیل ترافیک و تست امنیت فقط باید روی دارایی‌های خودتان، آزمایشگاه یا Scope دارای مجوز صریح استفاده شوند.
از سؤال حادثه به جمع‌آوری هدفمند
Velociraptor برای بررسی و پاسخ‌گویی روی نقاط پایانی مفید است، اما بهترین استفاده از آن با سؤال روشن آغاز می‌شود. مثلاً می‌خواهید بدانید کدام دستگاه‌های سازمان یک فایل مشخص را در مسیر معین دارند یا یک رخداد در چه بازه‌ای دیده شده است. این سؤال با «همه چیز را از همه دستگاه‌ها جمع کن» تفاوت دارد. جمع‌آوری هدفمند، هزینه و حجم داده را کاهش می‌دهد و تحلیل‌گر می‌تواند سریع‌تر به نتیجه مرتبط برسد. دامنه دستگاه‌ها و مجوز بررسی باید از ابتدا روشن باشند.
در حادثه، هر دقیقه مهم است، ولی جمع‌آوری عجولانه می‌تواند داده نامرتبط فراوان و فشار روی دستگاه‌ها ایجاد کند. ابتدا فرضیه، داده لازم برای آزمون آن و معیار نتیجه را بنویسید. اگر یک فهرست فرایند یا رویداد محدود کافی است، انتقال کل دیسک الزاماً انتخاب مناسب نیست. در مقابل، اگر حفظ تصویر کامل برای بررسی رسمی لازم است، این نیاز را با ابزار و روش مناسب جدا برنامه‌ریزی کنید. ابزار پرس‌وجو جای همه روش‌های جرم‌یابی را به صورت خودکار نمی‌گیرد.
Artifact یک بسته قابل بازبینی از منطق جمع‌آوری
در مدل پروژه، Artifact منطق VQL و اطلاعات لازم برای اجرای یک کار مشخص را بسته‌بندی می‌کند. نام قابل فهم، پارامترها و پیش‌شرط‌ها کمک می‌کنند تحلیل‌گر کار تکراری را بدون بازنویسی همه جزئیات اجرا کند. اما وجود یک Artifact آماده به معنای مناسب بودن آن برای هر محیط نیست. پیش از استفاده گسترده، منبع، منطق، دامنه خواندن و خروجی آن را بررسی کنید. بسته‌ای که ابزار بیرونی اجرا می‌کند، ممکن است اثر بیشتری از یک پرس‌وجوی ساده داشته باشد.
برای Artifact داخلی، توضیح دهید چه پرسشی را پاسخ می‌دهد و چه چیزی را پاسخ نمی‌دهد. پارامتر مسیر یا بازه زمانی را محدود و روشن تعریف کنید. اگر روی سیستم‌عامل یا نسخه خاصی معتبر است، این محدودیت باید در پیش‌شرط یا راهنمای استفاده دیده شود. خروجی خالی ممکن است به معنای نبود نشانه باشد، اما ممکن است Artifact اصلاً برای آن دستگاه قابل اجرا نبوده باشد. این تفاوت را در گزارش نتیجه حفظ کنید تا نبود داده با نبود رخداد اشتباه نشود.
پردازش نزدیک داده و محدودیت‌های آن
اجرای بخشی از تحلیل روی نقطه پایانی می‌تواند از انتقال حجم زیاد داده جلوگیری کند. برای مثال، به جای فرستادن همه فایل‌ها، می‌توان فهرست محدودی از موارد منطبق را جمع کرد. این مزیت به طراحی پرس‌وجو وابسته است؛ یک جست‌وجوی بسیار گسترده روی دیسک همچنان می‌تواند هزینه بالایی داشته باشد. فیلترهایی که زودتر دامنه را کوچک می‌کنند و انتخاب ستون‌های لازم، برای کارایی و حریم داده اهمیت دارند.
نتیجه پردازش زنده نیز تصویری از زمان جمع‌آوری است. فرایندها می‌توانند پایان یابند، فایل‌ها تغییر کنند و دستگاه میان مراحل خاموش شود. بنابراین دو مجموعه داده با فاصله زمانی الزاماً وضعیت یکسان را نشان نمی‌دهند. زمان شروع و پایان، نام دستگاه و وضعیت اجرای کار را همراه خروجی نگه دارید. اگر یافته برای تصمیم مهم استفاده می‌شود، محدودیت مشاهده زنده و نیاز به شواهد تکمیلی را بیان کنید. دقت در این زمینه از قطعیت ظاهری یک جدول جلوگیری می‌کند.
سرور جمع‌آوری یک دارایی بسیار حساس است
سامانه‌ای که می‌تواند روی نقاط پایانی پرس‌وجو و جمع‌آوری اجرا کند، نیاز به حفاظت جدی دارد. دسترسی به رابط مدیریتی، حساب‌ها، کلیدها و مسیر شبکه باید محدود و قابل ثبت باشد. نقش تحلیل‌گر مشاهده‌گر با نقشی که می‌تواند Artifact جدید تعریف یا عملیات گسترده اجرا کند یکسان نیست. مجوزها را بر اساس مسئولیت تفکیک کنید و برای کارهای حساس مسیر بازبینی داشته باشید. راحتی عملیات نباید به حساب مشترک و بدون قابلیت انتساب تبدیل شود.
همچنین حفاظت از خود داده جمع‌آوری‌شده مهم است. خروجی ممکن است شامل نام کاربر، مسیر فایل، محتوای حساس یا اطلاعات داخلی باشد. محل ذخیره، پشتیبان و دسترسی تیم‌ها باید با این حساسیت هماهنگ شود. انتقال خروجی به ابزار تحلیل دیگر نیز همان داده را کم‌حساسیت نمی‌کند. پیش از اشتراک، مجموعه لازم را انتخاب و اطلاعات غیرضروری را حذف کنید. گزارش مدیریتی معمولاً به همه جزئیات خام نقطه پایانی نیاز ندارد.
استقرار کلاینت و شناسایی دارایی
پیش از گسترش کلاینت، روش نصب، به‌روزرسانی و حذف را روی چند دستگاه نماینده آزمایش کنید. وضعیت ارتباط با سرور و هویت دستگاه باید قابل تشخیص باشد. نام میزبان به تنهایی همیشه شناسه پایدار نیست؛ ماشین می‌تواند تغییر نام دهد یا دوباره نصب شود. رابطه میان شناسه ابزار و موجودی دارایی سازمان را نگه دارید تا نتیجه به مالک درست برسد. برچسب‌گذاری گروه‌ها نیز باید از منبع قابل اعتماد و با چرخه بازبینی انجام شود.
دستگاه آفلاین را با دستگاه بدون یافته اشتباه نگیرید. اگر بخشی از ناوگان در زمان بررسی در دسترس نبوده، پوشش نتیجه را صریح گزارش کنید. لپ‌تاپی که بعداً وصل می‌شود ممکن است کار را در زمان دیگری اجرا کند و داده متفاوتی داشته باشد. در برنامه پاسخ‌گویی، مهلت انتظار و نحوه رسیدگی به دستگاه‌های غایب را مشخص کنید. عدد تعداد نتایج بدون تعداد هدف‌های موفق، تصویر دقیقی از دامنه بررسی نمی‌دهد.
Collection محدود پیش از Hunt گسترده
یک Artifact تازه را ابتدا روی دستگاه آزمایشی و سپس روی گروه کوچکی از دستگاه‌های نماینده اجرا کنید. زمان اجرا، مصرف منابع، حجم خروجی و خطاها را ببینید. پس از این مرحله، دامنه را افزایش دهید. اجرای مستقیم روی همه ناوگان، خطای کوچک در مسیر یا پارامتر را به مسئله بزرگ تبدیل می‌کند. محدودیت زمان و منابع باید با نوع دستگاه و حساسیت کار هماهنگ باشد، به‌ویژه روی سامانه‌هایی که بار کاری حیاتی دارند.
برای Hunt، معیار انتخاب دستگاه‌ها را دقیق بررسی کنید. یک برچسب عمومی ممکن است بیش از انتظار عضو داشته باشد یا دستگاه‌های قدیمی را نیز شامل شود. پیش از اجرا، تعداد و نمونه اعضای دامنه را مرور کنید. سپس نتیجه موفق، شکست و اجرا نشده را جدا نگه دارید. پایان یافتن عملیات مدیریتی به معنای موفقیت همه کلاینت‌ها نیست. تحلیل‌گر باید بداند کدام بخش داده کامل است و کدام بخش برای تصمیم نهایی نیاز به پیگیری دارد.
نمونه آموزشی: بررسی یک فایل آزمایشی
در آزمایشگاه، فایلی با محتوای بی‌خطر و نام مشخص روی دو دستگاه ایجاد کنید و دستگاه سوم را بدون آن نگه دارید. یک جمع‌آوری محدود به مسیر همان فایل طراحی کنید و خروجی مورد انتظار را از قبل بنویسید. سپس نتیجه را با واقعیت مقایسه کنید. هدف این تمرین، شناخت پارامتر، دامنه و خروجی است؛ هیچ نیاز به جست‌وجوی گسترده فایل‌های شخصی وجود ندارد. نمونه منفی دستگاه سوم به اندازه نمونه‌های مثبت اهمیت دارد.
در مرحله بعد، فایل را روی یکی از دستگاه‌ها جابه‌جا کنید و همان جمع‌آوری را تکرار کنید. نتیجه باید نشان دهد پرس‌وجو چه دامنه‌ای را پوشش می‌دهد و کجا محدود است. اگر فقط مسیر اولیه بررسی می‌شود، نبود نتیجه در مسیر تازه نباید به عنوان نبود فایل در کل دستگاه گزارش شود. این تمرین کوچک یک اصل مهم را نشان می‌دهد: نتیجه باید با زبان دامنه آزمون بیان شود. «در مسیر بررسی‌شده یافت نشد» دقیق‌تر از «روی دستگاه وجود ندارد» است.
VQL، پارامترها و جلوگیری از خطای معنایی
یک پرس‌وجوی درست از نظر نحو می‌تواند پاسخ سؤال اشتباه را بدهد. نوع داده، تبدیل زمان، حساسیت نام فایل و رفتار مسیرها باید بررسی شود. برای توسعه Artifact، داده نمونه کوچک با پاسخ معلوم داشته باشید و تغییرها را روی آن آزمایش کنید. اگر پارامتر خالی به معنای دامنه بسیار گسترده است، این رفتار باید کنترل یا به‌وضوح مستند شود. مقدار پیش‌فرض نامناسب می‌تواند کار عادی تحلیل‌گر را ناخواسته پرهزینه کند.
خروجی را نیز برای مصرف بعدی طراحی کنید. نام ستون‌ها، واحد زمان و شناسه دستگاه باید روشن باشند. اگر چند منبع داده به هم متصل می‌شوند، کلید ارتباط و احتمال چند نتیجه برای یک کلید را بررسی کنید. یک اتصال اشتباه میان جدول‌ها ممکن است تعداد ردیف‌ها را زیاد کند و به نظر برسد رخداد بیشتری وجود دارد. شمارش نتیجه را با نمونه‌های دستی کنترل کنید و پیش از ساخت هشدار یا گزارش مدیریتی، معنای هر ردیف را تثبیت کنید.
حفظ شواهد و زنجیره تصمیم
برای کار پاسخ‌گویی، نسخه Artifact، پارامترهای اجرا، زمان و شناسه مجموعه را ثبت کنید. این اطلاعات کمک می‌کند مشخص شود نتیجه با چه منطق و روی چه دامنه‌ای تولید شده است. اگر فایل جمع می‌کنید، شناسه محتوایی و محل نگهداری آن برای پیگیری مفیدند. با این حال، صرف محاسبه هش همه الزامات یک فرایند رسمی حفظ شواهد را برآورده نمی‌کند؛ روش سازمان، مسئولیت تحویل و کنترل دسترسی نیز باید رعایت شود.
تحلیل را از مشاهده خام جدا بنویسید. مثلاً وجود یک فایل با نام خاص مشاهده است، اما نسبت دادن آن به رخداد مخرب نیازمند زمینه بیشتر است. زمان ایجاد، مسیر، امضا یا ارتباط با رویدادهای دیگر می‌تواند به تفسیر کمک کند. از نتیجه‌گیری قطعی تنها بر اساس یک نام یا هش ناشناخته پرهیز کنید. گزارش خوب نشان می‌دهد چه چیزی دیده شده، چه فرضیه‌ای مطرح است و برای تأیید یا رد آن چه شاهد دیگری لازم خواهد بود.
خروجی خالی و خطاهای قابل پیگیری
وقتی نتیجه خالی است، نخست وضعیت اجرای کار را ببینید. ممکن است پیش‌شرط برقرار نبوده، مجوز خواندن کافی نبوده، مسیر وجود نداشته یا محدودیت زمان اجرا شده باشد. این حالت‌ها را به یک نتیجه منفی واحد تبدیل نکنید. پیام خطا و شمارش دستگاه‌های بررسی‌شده باید در کنار خروجی تحلیل دیده شود. برای Artifact مهم، یک داده شاهد در محیط آزمون نگه دارید تا پس از ارتقا بتوانید صحت مسیر جمع‌آوری را دوباره تأیید کنید.
اگر کار بسیار کند است، دامنه جست‌وجو و منابع بیرونی را بررسی کنید. افزایش زمان انتظار بدون فهم علت ممکن است فقط عملیات نامناسب را طولانی‌تر کند. پرس‌وجو را روی نمونه کوچک‌تر اجرا کنید و مرحله پرهزینه را پیدا کنید. در صورت توقف کار، وضعیت نهایی و داده ناقص را مشخص کنید تا تحلیل‌گر بعدی آن را مجموعه کامل فرض نکند. مدیریت این محدودیت‌ها بخشی از کیفیت جرم‌یابی است، نه صرفاً نگهداری نرم‌افزار.
پایان حادثه و نگهداری بلندمدت
پس از پایان بررسی، مجموعه‌های موقت، حساب‌های اضطراری و Artifactهای آزمایشی را بازبینی کنید. چیزی که برای یک حادثه ساخته شده نباید بدون مالک و آزمون به ابزار دائمی ناوگان تبدیل شود. یافته‌های مفید را به Artifactهای مستند و دارای نمونه آزمون تبدیل کنید و محدودیت آنها را نگه دارید. همچنین برنامه نگهداری داده را اجرا کنید؛ انباشتن بی‌پایان خروجی نقاط پایانی هم هزینه دارد و هم دامنه اطلاعات حساس را افزایش می‌دهد.
برای آمادگی بعدی، بازیابی سرور و دسترسی به داده ضروری را در محیط جدا تمرین کنید. بررسی کنید پس از بازیابی، هویت دستگاه‌ها، مجوز کاربران و مجموعه‌های مهم قابل استفاده‌اند. معیار موفقیت تنها بالا آمدن رابط وب نیست؛ باید یک جمع‌آوری شاهد از دستگاه آزمایشی انجام شود و نتیجه درست برگردد. این تمرین، ابزار را از سامانه‌ای که فقط در روز نصب کار کرده به بخشی قابل اتکا از فرایند پاسخ‌گویی سازمان تبدیل می‌کند.
