ساعت ۲:۴۰ بامداد است. هیچ Login ناموفق غیرعادی دیده نمیشود، فایروال هم هشدار مهمی نداده و مصرف CPU سرورها طبیعی است؛ اما فایل تنظیمات یک سرویس حیاتی تغییر کرده، یک Script اجرایی در مسیر حساس اضافه شده و Permission یک پوشه مالی دستکاری شده است. اگر تیم امنیت فقط «لاگ رخدادها» را ببیند، ممکن است این تغییرها تا زمان بروز اختلال یا نشت داده پنهان بمانند. اینجا دقیقاً جایی است که File Integrity Monitoring در EventLog Analyzer ارزش عملی پیدا میکند: مشاهده تغییر فایل و پوشه، ثبت اینکه چه چیزی عوض شده و تبدیل تغییر مشکوک به سیگنال قابل بررسی برای SOC.
FIM قرار نیست جای EDR، آنتیویروس، Change Management یا SIEM را بگیرد. نقش آن محدودتر اما بسیار مهم است: تغییرات غیرمنتظره روی فایلها و پوشههای حساس را قابل مشاهده و قابل پیگیری کند. در معماری درست، این سیگنال کنار Event Log، Syslog، تغییرات دسترسی و سایر رویدادهای امنیتی تحلیل میشود تا تیم امنیت بتواند میان «تغییر مجاز» و «تغییر مشکوک» تفاوت بگذارد.
File Integrity Monitoring یا FIM چیست؟
File Integrity Monitoring فرآیندی برای پایش تغییرات روی فایلها و پوشههای منتخب است. در مستندات رسمی ManageEngine، FIM در EventLog Analyzer و Log360 برای مشاهده ایجاد، حذف و تغییر فایلها و پوشهها در سیستمهای Windows و Linux معرفی شده است. داشبورد FIM همچنین میتواند تغییرات Rename و Permission را نمایش دهد.
اصل مهم این است که FIM باید روی مسیرهای واقعاً حساس اجرا شود، نه روی کل دیسک. خود ManageEngine نیز توصیه میکند فقط فایلها و پوشههای ضروری برای FIM انتخاب شوند؛ چون پایش گسترده میتواند حجم زیادی لاگ تولید کند و بر فضای ذخیرهسازی اثر بگذارد.
چرا فقط Event Log برای کشف تغییر فایل کافی نیست؟
Event Log میتواند بخش بزرگی از رفتار سیستم را ثبت کند، اما همیشه پاسخ روشن به این سؤال نمیدهد که «کدام فایل حیاتی تغییر کرده و آیا این تغییر انتظار میرفت؟». در بسیاری از رخدادها، حمله یا خطای عملیاتی با یک تغییر کوچک شروع میشود: جایگزینی فایل پیکربندی، افزودن DLL، تغییر Permission، حذف Script کنترلی یا دستکاری فایل وبسایت.
FIM این لایه دید را اضافه میکند. وقتی این داده در کنار رویدادهای Authentication، Privilege Change، Process Execution و Network Activity دیده شود، تحلیل Incident بسیار دقیقتر میشود. برای شناخت لایه جمعآوری Event و تفاوت معماری Agentless و Agent-based نیز میتوانید راهنمای Agentless یا Agent-based در EventLog Analyzer را بخوانید.
چه فایلهایی باید در FIM مانیتور شوند؟
اشتباه رایج این است که سازمان از روز اول چند میلیون فایل را وارد Scope کند. نتیجه معمولاً هزاران Alert کمارزش و خستگی تحلیلگر است. Scope بهتر باید از Business Criticality و Threat Model شروع شود.
| گروه | نمونه مسیر/فایل | ریسک اصلی | اولویت FIM |
|---|---|---|---|
| فایلهای تنظیمات سرویس | Configهای Web Server، Application Server، Database | تغییر رفتار سرویس، باز کردن دسترسی یا ایجاد Backdoor | بسیار بالا |
| فایلهای اجرایی حساس | Script، DLL، Binary و Service File | اجرای کد غیرمجاز | بسیار بالا |
| فایلهای وب | Web root، فایلهای PHP/ASP.NET/JS حساس | Web Shell، Defacement یا Injection | بالا |
| پوشههای مالی/حقوقی | Shareهای محدود و اسناد حساس | حذف، تغییر یا دستکاری Permission | بالا |
| فایلهای امنیتی | Policy، Rule، Script کنترل امنیتی | غیرفعالسازی کنترل | بسیار بالا |
| Log و Evidence | فایلهای لاگ و Audit حساس | پاککردن ردپا | بالا |
| Temp و Cache عمومی | دایرکتوریهای پرنوسان | نویز بسیار زیاد | معمولاً پایین |
FIM در EventLog Analyzer چه تغییراتی را نشان میدهد؟
طبق راهنمای رسمی ManageEngine، File Integrity Monitoring برای مشاهده تغییر روی فایلها و پوشهها طراحی شده است. داشبورد FIM اطلاعات ایجاد، حذف، تغییر و Rename را نمایش میدهد و تغییر Permission فایل یا پوشه نیز قابل مشاهده است. برای تیم SOC، ارزش این داده زمانی بیشتر میشود که مشخص باشد تغییر در چه زمانی و روی کدام Asset رخ داده و سپس با سایر Eventها Correlate شود.
۱. ایجاد فایل
ایجاد یک فایل جدید در مسیرهایی مانند Web root، Startup، Script directory یا پوشه تنظیمات میتواند نشانه Deploy مجاز، عملیات ادمین یا رفتار مهاجم باشد. خود «ایجاد فایل» Incident نیست؛ Context تعیین میکند که مهم است یا نه.
۲. حذف فایل
حذف فایل Backup، Log، Policy یا Script کنترلی میتواند هم ناشی از Maintenance باشد و هم بخشی از Defense Evasion. به همین دلیل حذف فایلهای حساس باید با Change Window و هویت کاربر بررسی شود.
۳. تغییر محتوا
تغییر یک Config ممکن است Port سرویس را عوض کند، Authentication را تضعیف کند، Logging را خاموش کند یا مسیر ارتباطی جدیدی بسازد. این دسته از تغییرها برای FIM ارزش بالایی دارند.
۴. Rename و Permission Change
Rename در ظاهر ساده است اما گاهی برای پنهانسازی Artefact یا دور زدن کنترلهای مبتنی بر نام استفاده میشود. تغییر Permission نیز میتواند دسترسی یک User یا Group را افزایش دهد؛ بنابراین در پوشههای حساس باید بهعنوان یک Signal امنیتی دیده شود.
سناریوی واقعی طراحی: مانیتورینگ یک Web Server حیاتی
فرض کنید یک سامانه داخلی سازمان روی Windows Server اجرا میشود و تیم امنیت میخواهد هرگونه تغییر غیرمنتظره روی Web root و فایلهای تنظیمات را تشخیص دهد. اگر تمام درایو C وارد Scope شود، Alertها خیلی سریع غیرقابل مدیریت میشوند. طراحی بهتر میتواند اینگونه باشد:
- Web root و پوشه Configuration بهعنوان Scope اصلی تعریف شود.
- مسیرهای Temp، Cache، Session و Uploadهای پرنوسان از Scope حذف یا جداگانه طبقهبندی شوند.
- Change Windowهای رسمی تیم DevOps مشخص شوند.
- تغییر خارج از Change Window با اولویت بالاتر Alert شود.
- برای فایلهای اجرایی، Config و Permissionها Severity متفاوت در نظر گرفته شود.
- رویداد FIM با Login ادمین، تغییر Group Membership، Process Creation و Network Event همان Host بررسی شود.
این رویکرد باعث میشود FIM از یک «ماشین تولید Alert» به یک کنترل امنیتی قابل استفاده تبدیل شود.
Agent در File Integrity Monitoring چه نقشی دارد؟
در معماری EventLog Analyzer، روش جمعآوری Log همیشه یکسان نیست. طبق مستند رسمی ManageEngine، برای مانیتورینگ فایل روی Windows File Server استفاده از Agent لازم است. همین موضوع در طراحی Deployment مهم است؛ چون تیم باید قبل از Rollout، Firewall Rule، دسترسی شبکه، منابع Host و روش مدیریت Agent را مشخص کند.
برای Windows Server معمولی، Workstation و File Server نیز ملاحظات لایسنس متفاوت است. مستند FIM ManageEngine توضیح میدهد که در Windows، اگر یک File Server برای FIM پیکربندی شود، هم Windows Server و هم File Server License لازم است؛ برای Windows Server معمولی فقط Windows Server License و برای Workstation نیز Workstation License لازم است. بنابراین پیش از فعالسازی گسترده FIM، Scope فنی باید با Scope لایسنس تطبیق داده شود.
چگونه Alertهای FIM را طوری طراحی کنیم که SOC خسته نشود؟
FIM بدون Tuning معمولاً شکست میخورد. مسئله اصلی تکنولوژی نیست؛ مسئله Signal-to-Noise Ratio است.
Severity را بر اساس Asset و Path تعیین کنید
تغییر یک فایل در لپتاپ آزمایشگاهی نباید همان اولویتی را داشته باشد که تغییر فایل Authentication روی Domain Controller یا سامانه پرداخت دارد. Criticality دارایی و حساسیت مسیر باید در Severity اثر بگذارد.
Change Window را وارد منطق تحلیل کنید
اگر هر شب ساعت ۱ بامداد Deployment رسمی انجام میشود، تغییر فایل در همان بازه لزوماً مشکوک نیست. اما همان تغییر در ساعت ۳:۳۰ بامداد و بدون Change Ticket باید توجه بیشتری بگیرد.
Baseline واقعی بسازید
قبل از سختگیر کردن Alertها، چند روز یا چند هفته رفتار عادی را مشاهده کنید. مسیرهایی که دائماً تغییر میکنند اما ارزش امنیتی ندارند باید Exclude یا با Severity پایینتر مدیریت شوند.
تغییر را با هویت و Process مرتبط کنید
بهجای اینکه فقط بپرسید «چه فایلی تغییر کرد؟»، بپرسید «چه کسی، از کجا، با چه سطح دسترسی و در چه Contextی باعث تغییر شد؟». این همان نقطهای است که Log Management و SIEM در کنار FIM ارزش بیشتری ایجاد میکنند.
FIM و NIST؛ چرا Integrity یک کنترل مستقل است؟
NIST در کنترل SI-7 از SP 800-53 Rev. 5.1 بر استفاده از ابزارهای Integrity Verification برای تشخیص تغییرات غیرمجاز در Software، Firmware و Information تأکید میکند و میگوید هنگام کشف تغییر غیرمجاز باید اقدام تعریفشده انجام شود. این نگاه مهم است؛ چون FIM فقط «ثبت تغییر» نیست. یک برنامه بالغ باید چرخه Detect، Verify، Investigate و Respond داشته باشد.
به زبان اجرایی، اگر EventLog Analyzer تغییر فایل حیاتی را نشان دهد اما هیچ Runbook، Owner یا Escalation وجود نداشته باشد، کنترل نیمهکاره است. تیم باید از قبل مشخص کند چه تغییرهایی Informational هستند، چه تغییرهایی نیازمند Ticket و چه تغییرهایی نیازمند Incident Response فوریاند.
FIM و PCI DSS؛ کجا اهمیت پیدا میکند؟
در الزامات PCI DSS 4.x، Change Detection و File Integrity Monitoring برای حفاظت از فایلهای حیاتی و همچنین محافظت از Logها اهمیت دارد. برای مثال PCI SSC در منابع آموزشی خود به Requirement 11.5.2 اشاره میکند که استفاده از Change-detection mechanism مانند FIM را برای هشدار درباره تغییر، افزودن یا حذف غیرمجاز فایلهای حیاتی، فایلهای Configuration یا Content مطرح میکند.
این موضوع به این معنی نیست که صرف نصب EventLog Analyzer مساوی «Compliance» است. Compliance به Scope، Configuration، فرآیند، Review، Retention، Evidence و کنترلهای مکمل وابسته است. ابزار فقط بخشی از معماری انطباق است.
FIM چه تفاوتی با EDR دارد؟
| قابلیت | FIM | EDR |
|---|---|---|
| تمرکز اصلی | تغییر فایل/پوشه و Integrity | رفتار Endpoint و Threat Detection/Response |
| کشف تغییر Config | بسیار مناسب | بسته به محصول |
| Process Tree و رفتار Runtime | محدود | قوی |
| Isolation Endpoint | هدف اصلی نیست | معمولاً دارد |
| Evidence برای Audit | بسیار کاربردی | متفاوت بر اساس محصول |
| جایگزین یکدیگر؟ | خیر؛ مکمل یکدیگرند | |
FIM چه تفاوتی با Change Management دارد؟
Change Management پاسخ میدهد «چه تغییری مجاز بود؟»، در حالی که FIM نشان میدهد «چه تغییری واقعاً رخ داد؟». وقتی این دو کنار هم قرار بگیرند، تیم میتواند تغییر مشاهدهشده را با Change Record مقایسه کند. تغییر بدون Change، تغییر خارج از Window یا تغییری که با Scope مجوز مطابقت ندارد، ارزش بررسی بالاتری دارد.
در سازمانهایی که ServiceDesk Plus دارند، این نقطه برای Integration عملی اهمیت دارد: Change Ticket منبع Authorization است و EventLog Analyzer منبع Detection. هدف این نیست که هر File Change تبدیل به Ticket شود؛ هدف این است که تغییرهای پرریسک و بدون مجوز وارد Workflow مناسب شوند.
چطور FIM را مرحلهای Rollout کنیم؟
راهاندازی سازمانی بهتر است چهار فاز داشته باشد:
فاز ۱: Pilot روی ۵ تا ۱۰ دارایی حیاتی
ابتدا سرورهایی را انتخاب کنید که Criticality بالا و مالک مشخص دارند؛ مثلاً Domain Controller، Web Server حیاتی، File Server مالی و Application Server.
فاز ۲: Tuning مسیرها
مسیرهای پرنوسان را شناسایی کنید. اگر یک Folder در هر ساعت هزاران تغییر عادی دارد، یا باید Exclude شود یا Policy جداگانه بگیرد.
فاز ۳: Alert و Escalation
Severity، Recipient، Schedule و Threshold را تنظیم کنید. هر Alert باید Owner داشته باشد؛ Alert بدون Owner فقط Noise تولید میکند.
فاز ۴: گسترش بر اساس Risk
پس از پایدار شدن Pilot، Scope را بر اساس Business Service، Regulatory Requirement و Asset Criticality گسترش دهید؛ نه صرفاً بر اساس تعداد Server.
یک ماتریس ساده برای اولویتبندی FIM
| سؤال | اگر پاسخ «بله» است |
|---|---|
| آیا تغییر این فایل میتواند Authentication را تضعیف کند؟ | اولویت بالا |
| آیا فایل بخشی از سرویس درآمدزا یا حیاتی است؟ | اولویت بالا |
| آیا تغییر میتواند Evidence یا Log را از بین ببرد؟ | اولویت بالا |
| آیا مسیر دائماً و بهشکل طبیعی تغییر میکند؟ | نیازمند Tuning یا Exclusion |
| آیا Owner و Change Process مشخص دارد؟ | مناسب برای Correlation با Change |
| آیا الزام Audit/Compliance دارد؟ | Scope و Retention باید مستند شود |
لایسنس و ظرفیت؛ قبل از روشنکردن FIM چه چیزهایی را بسنجیم؟
EventLog Analyzer براساس تعداد Log Source، Endpoint و Cloud Account لایسنس میشود و مدلهای Perpetual و Annual Subscription دارد. برای FIM نیز نوع Host مهم است. پیش از خرید یا توسعه Scope، فهرست دقیق Server، Workstation و File Serverهایی که واقعاً باید مانیتور شوند تهیه کنید.
اگر قصد ارزیابی یا خرید دارید، صفحه نرمافزار EventLog Analyzer در مدانت مسیر اصلی محصول است. برای محیطهایی که Correlation گستردهتر، UEBA و معماری SIEM جامعتر نیاز دارند، بررسی Log360 نیز منطقی است.
نکته نسخه: EventLog Analyzer در اوت ۲۰۲۶
طبق ReadMe رسمی ManageEngine، نسخه EventLog Analyzer 13.0.7 Build 13071 در ۲۵ اوت ۲۰۲۶ منتشر شده است. در این Build، PostgreSQL داخلی به 14.23 و Apache Tomcat به 9.0.120 ارتقا یافتهاند تا آسیبپذیریهای امنیتی مرتبط برطرف شوند. این نکته برای تیمهایی که FIM را بهعنوان کنترل امنیتی جدی استفاده میکنند مهم است: خود پلتفرم مانیتورینگ نیز باید در چرخه Patch و Upgrade نگه داشته شود.
اشتباههای رایج در پیادهسازی File Integrity Monitoring
- مانیتور کردن همهچیز: حجم Event را بالا میبرد و Signal را دفن میکند.
- نداشتن Owner: Alert میآید اما هیچ تیمی مسئول بررسی نیست.
- بیتوجهی به Change Window: تغییرهای مجاز با Incident اشتباه گرفته میشوند.
- یک Severity برای همه Assetها: اولویتگذاری SOC را خراب میکند.
- نداشتن Baseline: تیم نمیداند رفتار عادی چیست.
- نگاه Compliance-only: FIM فقط برای Audit نیست؛ یک Signal دفاعی واقعی است.
- نادیده گرفتن لایسنس و Storage: Scope گسترده بدون Sizing میتواند هزینه و حجم داده را بالا ببرد.
چکلیست اجرایی برای شروع
- داراییهای حیاتی را با Owner مشخص فهرست کنید.
- فقط مسیرهای حساس را وارد Scope اولیه کنید.
- برای Windows File Server نیاز Agent را در طراحی لحاظ کنید.
- مسیرهای Temp، Cache و Upload پرتغییر را جداگانه بررسی کنید.
- Severity را بر اساس Asset Criticality و Path Sensitivity بسازید.
- Change Window و Maintenance Window را ثبت کنید.
- Alertهای FIM را با Login، Privilege Change و Process Event Correlate کنید.
- Runbook واکنش به تغییر غیرمجاز داشته باشید.
- Storage و Retention را قبل از Rollout گسترده محاسبه کنید.
- پس از Pilot، Scope را Risk-based گسترش دهید.
منابع
- ManageEngine — File Integrity Monitoring
- ManageEngine — Agent Administration
- ManageEngine — EventLog Analyzer ReadMe
- ManageEngine — Licensing Details
- NIST SP 800-53 Rev. 5.1 — SI-7
- PCI Security Standards Council — FIM and Change Detection
سخن پایانی
File Integrity Monitoring زمانی ارزش دارد که روی فایل درست، در Asset درست و با Context درست اجرا شود. روشن کردن FIM روی همه مسیرها ساده است؛ ساختن کنترلی که تغییر مهم را از هزاران تغییر عادی جدا کند، بخش حرفهای کار است. EventLog Analyzer این امکان را میدهد که تغییر فایل و پوشه در کنار Logهای امنیتی دیده شود، اما کیفیت خروجی به Scope، Agent Architecture، Tuning، Alert Design و فرآیند واکنش سازمان وابسته است.
اگر میخواهید برای سازمان خود Scope مناسب FIM، معماری EventLog Analyzer، ظرفیت لایسنس، Retention و Alerting را طراحی کنید، مدانت میتواند در استعلام و خرید لایسنس، طراحی معماری، استقرار، Upgrade، آموزش و پشتیبانی EventLog Analyzer و Log360 همراه شما باشد. برای ارزیابی فنی و تجاری از تماس با مدانت استفاده کنید.
