بازپرسی جرایم سایبری – بخش ۱۳

پیوست ب

بازپرسی تهدید خودی با استفاده از مدیریت امنیت بنگاه

ره‌یافت‌های این پیوست:

• ESM چیست؟
• دیوار چین چیست؟
• منابع داده
• پل زدن روی دیوار چین: آشکارسازی از طریق همگرایی

• نتیجه‌گیری

ESM چیست؟

مدیریت امنیت بنگاه (ESM) اصطلاحی عام است که در خصوصِ نرم‌افزار نظارت و آنالیز رخداد امنیتی به‌کار رفته است. سرنام‌های بسیاری در این سال‌ها برای توصیف این ره‌یافت‌ها به‌کار رفته‌اند، مانند:

• SIM مدیریت اطلاعات امنیتی
• SEM مدیریت رخداد امنیتی
• SIEM مدیریت اطلاعات و رخداد امنیتی
• و بسیاری چیزهای دیگر

صرف‌نظر از سرنام، تمرکز ره‌یافت ESM بر این است که به تحلیل‌گر این امکان را بدهد تا صرف‌نظر از محصول، فروشنده و نسخه، به‌طور بی‌درنگ بر زیرساختِ یک سازمان نظارت نماید. شیوه‌ی مبتنی بر انکارِ فروشنده، به ساده‌سازیِ وظایف مرتبط با آنالیز، گزارش، پاسخگویی و دیگر وجوهِ نظارت بر رخداد کمک می‌کند. ESMها به‌طور سنتی در خصوصِ امنیت IT، تهدیدات خودی و تطابق به‌کار رفته‌اند اما در چند دهه‌ی اخیر تا جایی گسترش یافته‌اند که بسیار فراتر از این عرصه‌ها رفته‌اند تا مجموعه‌ی گسترده‌تری از ره‌یافت‌ها را دربرگیرند. البته، تمام این کارها با رخدادهای جمع‌آوریِ اول شروع می‌شود. این رخدادها می‌توانند از هر کدام از منابع زیر ناشی شوند:

• محصولات امنیتی سنتی

• دیوار آتش‌ها
• سیستم‌های آشکارسازی و جلوگیری از نفوذ
• VPNها
• ضدّویروس
• سیستم‌های مدیریت هویت
• افزاره‌های شبکه

• مسیریاب‌ها
• سوئیچ‌ها
• نقطه‌دسترسی‌های بی‌سیم (WAP)
• اطلاعاتِ شاه‌قاب، سرور و ایستگاه کاری

• سیستم‌عامل‌ها
• برنامه‌های کاربردی
• ره‌یافت‌های امنیتی فیزیکی

• نشان‌خوان‌ها
• دوربین‌های ویدئویی
• تهویه‌ی مطبوع (HVAC)
• دیگر موارد گوناگون

• پویش‌گرهای آسیب‌پذیری
• مدیران خط‌مشی
• مدیران دارایی
• ره‌یافت‌های ارثی و اختصاصی
• افزاره‌های همراه
• سیستم‌های تلفن
• RFID
• سیستم‌های نقطه‌ی فروش (POS)
• GPS
• زمان‌صفحه‌ها
• و الخ.

در اصل، اگر یکی از دارایی‌ها رخدادی ایجاد کند و بتوان آن رخداد را با استفاده از ESM ضبط کرد، می‌توان از آن استفاده کرد. همین که ESM رخدادها را جمع‌آوری کرد، از شیوه‌های بی‌درنگ و خودکاری مانند همبستگی، آشکارسازیِ ناهنجاری، کشف الگو، و تجسّم استفاده خواهد کرد تا قطعیات کاذب را کاهش دهد، رخدادهای حیاتی را اولویت‌بندی کند، و به یک تحلیل‌گر در خصوصِ مشکل بالقوه‌ای هشدار دهد. هم‌چنین، ESM چارچوبی را در اختیار تحلیل‌گران امنیتی قرار می‌دهد تا درک انسانی خود را از طریق نمودارهای تعاملی، ابزارهای دیداری، و شیوه‌های بازپرسی، در خصوصِ موضوعات موردنظر به‌کار برند. این ترکیب قدرتمند از آنالیز خودکار و انسانی، شناساییِ خطرات را کارآمدتر و مؤثرتر می‌سازد.

ESMها می‌توانند برخی از خصیصه‌های مدیریت رویداد و آنالیز قانونی را نیز ارائه دهند. از منظر بازپرسی قانونی، ESMها از شیوه‌های کشف پیشرفته، گزارش و آنالیز داده‌هایی پشتیبانی می‌کنند که با پایگاه داده‌ی ESM ذخیره می‌شوند. در خصوص پاسخگویی، ESMها معمولاً مدیریتِ موردِ یک‌پارچه دارند و با سیستم‌های صدور بلیتِ شخص ثالث مانند Remedy یک‌پارچه هستند. علاوه بر این، آن‌ها آماده‌باش‌ها و تشدیدهایی دارند که می‌توانند به‌گونه‌ای پیکربندی شوند که به موازات فرآیندهای سازمانی‌ای مانند روندهای مدیریت تغییر کار کنند. قابلیت دیگر برای پاسخگویی این است که بتوان واقعاً با یا بدونِ دخالت انسان، اصلاحاتی در افزاره‌ها ایجاد کرد تا حمله‌ای را متوقف ساخت. برخی از نمونه‌های این پاسخگویی‌ها شامل این موارد هستند:

• غیرفعال‌سازیِ حساب‌های کاربری
• فیلترِ IPها در دیوار آتش‌ها، سوئیچ‌های لایه‌ی ۳ و مسیریاب‌ها
• قطع جلسات در VPNها، نقطه‌دسترسی‌های بی‌سیم، سیستم‌های جلوگیری از نفوذ و دیگر افزاره‌های شبکه
• قرنطینه‌سازیِ افزاره‌ها در VLANهای مجزا و کنترل‌شده
• متوقف ساختنِ دسترسی در لایه‌ی ۲ با به‌کارگیریِ فیلترهای آدرس مَک یا غیرفعال‌سازی درگاه فیزیکیِ روی یک سوئیچ

از منظر عملیات تجاری نیز، ESM می‌تواند به تعاملِ خطر و تطابق کمک نماید. مدیران ارشد و مدیران اجرایی همانندِ هم، برای آگاهی از وضعیت امنیت سازمان خود، معمولاً متکی به خروجی هستند. با مجهز شدن به این اطلاعات، می‌توان تصمیمات فرهیخته‌تری در باره‌ی پذیرش خطر، چاره‌سازیِ خطر و مدیریت خطر گرفت. تطابق نیز بخش مهمی از قابلیت‌های ESM است که این توانایی را دارد که گزارش‌های شفافی را تهیه کند، در آنالیز کمک نماید، و در پیگیریِ دارایی‌های یاری رساند که این دارایی‌ها در ارتباط با نظارت بر IT و اَشکال تطابقِ مقرراتی‌ای مانند ساربانز-اوکسلی، PCI، GLBA و HIPAA هستند.

ESM در کانونِ همگرایی امنیت فیزیکی و منطقی

امنیت منطقی، هر سال بیش از پیش با امنیت فیزیکی یک‌پارچه می‌شود. ره‌یافت‌های دیجیتال و پروتکل‌های مبتنی بر IP در حالِ تبدیل شدن به استاندارد برای امنیت فیزیکی هستند و ارزان‌تر نیز هستند. برای مثال، هزینه‌ی لازم برای قرار دادنِ دوربین‌های مراقبتیِ دیجیتال، و ذخیره‌سازیِ داده‌های فشرده‌ی آن‌ها تا حدّ زیادی کاهش یافته است. و در عین حال که این فن‌آوری‌ها یک‌پارچه‌تر می‌شوند، می‌توانند توازن‌هایی مانند مقایسه‌ی مراقبت ویدئویی و اطلاعات نشان‌خوان‌ها با VPNها و دیگر اَشکالِ دسترسی منطقی را فراهم سازند. از منظر عملیاتی، نیم‌نگاهی به هر روال و ترتیبی، تبدیل به الزامی برای جلوگیری، آشکارسازی و مدیریت رویداد خواهد شد. داشتنِ مکانی مرکزی برای بازپرسی، آنالیز، همبستگی و اولویت‌بندی- در تمام مراحل کاملاً منطقی است. تمام این چیزها برای کنترل بهترِ تطابق و اجرای خط‌مشی و در نهایت، روشی سریع‌تر و مؤثرتر برای کاهش خطر، و در عین حال افزایش بازده کاری است. ESM با ارائه‌ی چندین خصیصه‌ی حیاتی، به تسهیل این امر کمک می‌نماید.

با به‌هم‌پیوستنِ رخدادهای فیزیکی و منطقی در مکانی مرکزی، هر سازمانی می‌تواند چشم‌اندازی کل‌نگرانه از وضعیت امنیتی خود به‌دست آورد. داشتن تمام اطلاعات در انباری مرکزی، امکان بازپرسی و آنالیز فراگیرتری را می‌دهد. می‌توان اطلاعات را همبسته و اولویت‌بندی کرد و نتایج قابل‌پیگردی را برای استفاده‌ی تحلیل‌گران ارائه داد.

از آنجا که اغلبِ ESMها سیستم مدیریت موردِ یک‌پارچه و اتصال دوسویه‌ای با سیستم‌های صدور بلیت شخص ثالث دارند، گروه‌های امنیت فیزیکی و منطقی می‌توانند با استفاده از خصیصه‌هایی مانند آماده‌باش، تشدید و مدیریتِ مورد، به‌شکلِ مؤثرتری با یکدیگر همکاری نمایند. این امر به کاهش آشفتگی در خصوصِ مسئولیت‌های شغلی طیّ رویداد کمک می‌کند.

از آنجا که کنترل‌های دسترسی، درون ESMها تعبیه شده‌اند، انواع خصیصه‌ها و انواع رخدادهایی که گروه امنیت فیزیکی و منطقی‌ای می‌تواند به آن‌ها دسترسی داشته باشد، به‌شدت کنترل خواهند شد. این امر نکته‌ی مهمی برای گزارش است چرا که ممکن است لازم باشد که برای هر سرگروه امنیتی، گزارش روزانه‌ای تولید شود. بسیاری از موضوعاتی که مرتبط با آن‌ها است، کاملاً متفاوت خواهند بود، در حالی که برخی از آن‌ها نیز مشترک هستند. کار منطقی این است که اطلاعات را دقیقاً به همان اندازه‌ای محدود سازند که گروه‌های امنیتی مربوطه به آن مقدار نیاز دارند.

مثال جالبی از همگرایی گروه‌های ناهم‌خوان، مرکز هم‌جوشی است. مراکز هم‌جوشی، همکاری‌هایی بین دولت‌های محلی، ایالتی و فدرال برای کار بر روی گستره‌ی وسیعی از موضوعات از جمله حملات تروریستی هستند. به‌وضوح هر گروه اطلاعاتی دارد که در ارتباط با آن است اما نیازی ندارد که آن‌ها را با دیگران به اشتراک بگذارد. البته، هر گروه به اطلاعاتی نیز دسترسی دارد که ممکن است دیگران نداشته باشند، اما ممکن است مفید از آب درآید. آن‌ها فقط مصرف‌کنندگان اطلاعات نیستند، بلکه جمع‌آور نیز هستند. این اطلاعات می‌توانند داده‌های امنیت فیزیکی، امنیت منطقی و هوش انسانی باشند. به این ترتیب، دقیقاً مانند همکاریِ گروه‌های امنیت فیزیکی و منطقی، مراکز هم‌جوشی به امیدِ افزایش بازده و کاهش خطر، روزبه‌روز رایج‌تر می‌شوند. چندین شهر و ایالت وجود دارند که شروع به ساخت مراکز هم‌جوشی کرده‌اند تا با دوایر ملی کار کنند. برای مثال، LA، آریزونا، کولورادو، ایلینویز، ماساچوست، ویرجینیا، نیوجرسی و نیویورک همگی همین حالا مراکز هم‌جوشی‌ای دارند که در حال بازپرسیِ آن‌ها هستند. برای مثال، نیویورک دایره‌ی اطلاعات خارجیِ مخصوص به خود را دارد که تمرکز آن بر جمع‌آوری اطلاعات از دفاتر خود در حدود بیست‌وشش کشور است.

واضح است که میان دوایر محلی، ایالتی و فدرال هم‌پوشانی‌هایی وجود دارد، اما حجم زیادی از اطلاعات نیز وجود دارد که نیازی نیست میان دوایر به اشتراک گذاشته شود. همین موضوع در خصوصِ گروه‌های امنیت فیزیکی و منطقی صادق است. در حالی که ممکن است آن‌ها نیازمندِ این باشند که مدیریت مورد، گزارش، آماده‌باش، تشدید، و چارچوب‌های بازپرسی را به اشتراک بگذارند، نیازی به اشتراک تمام قسمت‌ها به‌طور انحصاری ندارند. توجه داشته باشید که بسیاری از ره‌یافت‌های ESM هم میز فرمان اجرایی و هم خدمات‌گیرنده‌ی وبِ کوچکی دارند. در عمل، اغلبِ گروه‌های امنیت منطقی به‌طور مرتب از میز فرمان اجرایی استفاده خواهند کرد، در حالی که گروه امنیت فیزیکی، خدمات‌گیرنده‌ی کوچک را برای وظایف عمومی‌تری مانند مدیریت موردها، مشاهده‌ی گزارش‌ها، و مشاهده‌ی رخدادها به‌کار می‌برند.

به‌دلیل وضوحِ همگرایی امنیت فیزیکی و منطقی از طریق ESM، همگرایی این گروه‌ها دیگر موضوعی مبهم نیست. امنیت چیزی فراتر از دیوار آتش‌ها است؛ فراتر از نشان‌خوان‌ها است. سازمان‌های امروزی، با درک این مطلب، تقاضای نمایی واقعاً کل‌نگر از وضعیت امنیت خود دارند و ESM می‌تواند چنین چیزی را فراهم سازد. ESM، با بهره‌گیری از مجموعه‌ای از ابزارها برای جمع‌آوری، آنالیز، همکاری و پاسخگوییِ رویداد، همگرایی را تبدیل به واقعیت ساخته است. پیش از آن‌که سراغِ ساختار ESM برویم، اجازه دهید به چند مثال کوتاه از جاهایی اشاره کنیم که ESM در آن‌ها، برای دستیابی به راه‌بردهای واقعاً همگرای منحصربه‌فرد و مؤثر، با ره‌یافت‌های امنیت فیزیکی یک‌پارچه شده است.

وزارت دفاع با استفاده از کاک (کارت‌های دسترسی مشترک) شروع به پیاده‌سازیِ سیستمی کرده است که کنترل دسترسی و شناساییِ فیزیکی و منطقی، وابسته به کارت سوختگی‌ای می‌شود. این کاک‌ها همان خصیصه‌های کارت دسترسی فیزیکیِ سنتی را به‌طور کامل به‌همراهِ عکس و اطلاعات تشریحی در باره‌ی حامل مربوطه را ارائه می‌کنند. البته، این توانایی را نیز دارند که صاحب کارت را روی شبکه‌ای منطقی ثبت کنند. برای مثال، فردی پس از پویش کاک خود در کاک‌خوانِ نزدیک درِ ورودی ساختمان، می‌تواند آن کارت را در کاک‌خوانی که متصل به ایستگاه کاری او است، بکشد تا خود را در شبکه اصالت‌سنجی کند. علاوه بر این، آن‌ها می‌توانند از کاک برای رمزبندی اطلاعات، دسترسی به وب‌گاه‌های ایمن و دیگر سازوکارهای به‌کاررفته برای دسترسی منطقی ایمن استفاده کنند. کاک‌ها آرام‌آرام در حالِ جای‌گزینی با مدارک شناساییِ نظامی هستند و سرانجام به‌وسیله‌ی اغلبِ کارمندان و پیمان‌کارانِ وزارت دفاع حمل خواهند شد. بحث‌هایی در خصوصِ استاندارد ساختنِ کاک برای اصالت‌سنجی برای برنامه‌ی مسافرِ ثبت‌شده‌ی TSA و برنامه‌ی کارگرِ مهمان مطرح هستند. کاک، از منظر همگرایی، گامی بزرگ رو به جلو است چرا که هم‌اکنون هویت فیزیکی و منطقیِ کاربر با کلید مشترکی مرتبط هستند، به جای داشتن هویتی مانندِ ۱۰۰۱۰۰۱۱ برای دسترسی فیزیکی و هویتی منطقی مانند bsmith، هر دو bsmith خواهند بود. این امر، موضوعات حولِ مقرّرسازیِ دسترسیِ کارمندان جدید یا لغو دسترسی را نیز بسیار آسان‌تر می‌سازد. از آنجا که تمام دسترسی‌ها مرتبط با یک کاک هستند، اگر شما کاک مربوطه را مقرّر یا لغو سازید، می‌توانید سریع‌تر و مؤثرتر دسترسی فرد را به‌کلّی مقرّر یا لغو سازید. دیگر نیازی به کار از طریق چندین گروه برای مدیریت تمام اَشکالِ دسترسی نیست. کاک کارِ ESM را به این دلیل آنقدر مؤثرتر می‌سازد که ESM دیگر نباید bsmith را به ۱۰۰۱۰۰۱۱، و بسیاری از هویت‌های بالقوه‌ی دیگر نگاشت کند. هم‌اکنون bsmith کلید مشترکی است که ESM می‌تواند با تمام هویت‌های آن کاربر ارتباط برقرار سازد.

برخی از سازمان‌ها حتی خدمات نظارتی امنیتی‌ای را که به‌طور سنتی برون‌سازمانی هستند، به درون سازمان آورده‌اند تا زمان پاسخگویی خود به رویدادها را بهتر سازند، و در نتیجه خطر را کاهش دهند و حتی در هزینه‌ها صرفه‌جویی نمایند. برای مثال، هشدار آتش‌ها، هشدار سارق‌ها، دسترسی تسهیلات و نظارت ویدئویی می‌توانند با استفاده از سازمان امنیت فیزیکی درون‌سازمانی‌ای نظارت شوند. هم‌اکنون، با درون‌سازمانی کردن این خدمات، این گزینه را در اختیار دارند که این خدمات را آسان‌تر با قابلیت‌های نظارت خطر کلّی خود در ESM یک‌پارچه سازند.

بسیاری از بانک‌ها به این نتیجه می‌رسند که الزام گروه‌های امنیت فیزیکی و منطقی خود به همکاری با یکدیگر- به‌ویژه طیّ بازپرسی‌های کلاه‌برداری- می‌تواند ارزشمند باشد. از آنجا که هر گروهی صلاحیت‌های کلیدی مخصوص به خود را دارد، آن‌ها می‌توانند، برای مثال، با استفاده از الزام گروه‌های امنیتی به همکاری با بازرسان داخلی و خارجی، در طول بازپرسی‌ها هم‌افزایی داشته باشند. اداره‌ی امنیت شرکتیِ بانک، به موازات همکاری با دوایر اجرای قانون، از منظری مالی روی مورد مربوطه کار خواهد کرد، و حال آن‌که ادارات امنیت منطقی، جزئیات ITای را فراهم می‌کنند که برای پشتیبانی از مورد مربوطه موردنیاز هستند. ESM به‌عنوان هسته‌ی چنین سیستمی، امکان ارتباطات و مستندسازیِ یک‌پارچه‌ی بازپرسی را فراهم می‌سازد، و دنباله‌ی رهگیریِ کاملی از هر چیزی که انجام شده است، ارائه می‌نماید. هیچ نیازی به مستندسازیِ رخدادها پس از وقوع نیست، چرا که به‌طور بی‌درنگ اتفاق می‌افتد. نیازی نیست که کسی خارج از زمانِ بازپرسی زمانی را صرف کند تا هر چیزی را که انجام می‌دهند، ثبت کند. شوربختانه، این مرحله مرحله‌ای مهم است که اغلب از آن چشم‌پوشی می‌شود. با وجودِ سیستم مدیریت موردِ اشتراکی، و دنباله‌ی رهگیریِ کاملِ قسمت‌های شبکه‌مرکزیِ بازپرسی، چه فیزیکی و چه منطقی، شغل بازپرسان کارآتر و سرراست‌تر می‌گردد.

استراتژی‌های صف‌آراییِ ESM

این بخش به بررسیِ چندین راه‌برد صف‌آراییِ ESM خواهد پرداخت. هر جزء از ساختار ESM موردِ بحث قرار خواهد گرفت. ESMها می‌توانند به‌صورتِ پیکربندی‌های استاندارد، با دسترسی بالا، و پراکنده (به‌لحاظ جغرافیایی) آرایش یابند. علاوه بر این، اجزاء اضافی‌ای در ساختار ESM وجود دارند که می‌توانند به‌عنوان ره‌یافتی خوداتّکا یا در پیوند با راه‌برد ESMِ بزرگ‌تری به‎‌کار روند که به پاسخگویی شبکه و پیکربندی شبکه بسط می‌یابد. برای شروع، نگاهی خواهیم داشت به یک مثال از صف‌آراییِ ESM که با شکل ب.۱ آغاز می‌شود.

شکل ب.۱ صف‌آرایی ESMِ پایه

اجزای شکل ب.۱ از پایین تا بالا مورد بررسی قرار خواهند گرفت.

همان‌طور که پیش از این اشاره شد، صرف‌نظر از فایل‌های ثبت وقایعی که- از افزاره‌های فیزیکی، افزاره‌های شبکه، سرورها و الخ- تولید می‌شوند، ESMها برای دریافت و پردازش آن‌ها طراحی می‌شوند. بین افزاره‌های نقطه‌ای و مدیر ESM، راه‌هایی برای انتقال فایل‌های ثبت وقایع وجود دارند.

در گوشه‌ی سمت چپِ نمودار، اسبابِ جمع‌آوریِ ثبت وقایع قرار دارند. این نوع از اسباب می‌توانند به‌عنوان ره‌یافت‌هایی خوداتّکا، یا به‌عنوان قسمتی از ره‌یافت ESMِ وسیع‌تری به‌کار روند. به‌عنوان ره‌یافتی خوداتّکا، برای جمع‌آوری فایل‌های ثبت وقایع در حجم بسیار بالا- ده‌ها هزار فایل ثبت وقایع در هر ثانیه و تأمین ذخیره‌سازیِ بلندمدت- طراحی می‌شوند. این ذخیره‌سازی در برخی از موارد، به دلیل وجود قابلیت‌های فشرده‌سازی، می‌تواند به اندازه‌ی سال‌ها داده باشد. شکل ب.۲ نمای سطح بالایی از اسباب جمع‌آوری ثبت وقایع را نشان می‌دهد.

شکل ب.۲ اسباب جمع‌آوری ثبت وقایع – نمای وضعیت سیستم

منبع: ArcSight Logger v1.0

شکل ب.۲ جلسه‌ی وبیِ تعاملی‌ای با اسباب جمع‌آوری ثبت وقایع است. از آنجا که این افزاره‌ها برای جمع‌آوری و ذخیره‌سازیِ حجم عظیمی از اطلاعات طراحی می‌شوند، داشتنِ داشبوردی برای ارزیابی وضعیت آن می‌تواند مفید باشد. برای مثال، از چپ به راست، مصرف CPU، مصرف حجم حافظه و تعداد رخدادهایی که در هر ثانیه دریافت و منتقل‌شده (برای مثال به مدیر ESM) نشان داده شده است. با استفاده از این نوع داشبورد، سریع و آسان می‌توان فهمید که درون این اسباب چه اتفاقی در حالِ وقوع است. شکل بعدی، ب.۳، نمای دیگری از درون اسباب جمع‌آوری ثبت وقایع نشان می‌دهد که تمرکز آن بر آنالیز است.

شکل ب.۳ اسباب جمع‌آوری ثبت وقایع – نمای آنالیز

منبع: ArcSight Logger v1.0

در شکل ب.۳ برشی از شبکه‌ی آنالیز این اسباب ارائه شده است. این شبکه رخدادهایی را نشان می‌دهد که بر اساس ملاک‌های معینی مانند زمان، پروتکل‌ها، IPهای مبدأ، IPهای مقصد و دیگر متغیرهای کلیدی درون اسباب مربوطه جریان دارند. این تصویر ویژه، دسترسیِ تلنت را برای حسابِ اَدمین نشان می‌دهد که شکست‌ها و موفقیت‌هایی داشته است. چنین ملاک‌های جست‌وجویی می‌توانند به‌هنگام انجامِ بررسی ارزشمند باشند؛ بررسی‌ای که طیّ آن، داده‌های قبلیِ ذخیره‌شده در اسباب مربوطه بازجست‌وجو می‌شوند تا استفاده از پروتکل‌های تأییدنشده‌ای مانند تلنت یافت شوند؛ پروتکل‌هایی که طیّ آن‌ها اطلاعات حساس و گذرواژه‌ها به‌صورت متن بی‌رمز انتقال داده می‌شوند.

اسباب جمع‌آوری ثبت وقایع، ره‌یافت مناسبی برای سازمان‌هایی فراهم می‌کند که می‌خواهند با آسودگی اسبابی را صف‌آرایی کنند که به موازات جمع‌آوری ثبت وقایعِ سریع و ذخیره‌سازی بلندمدتِ ارزان، امکان آنالیز سریع را مهیا سازد. اگر این اسباب به‌عنوان قسمتی از راه‌برد ESMِ بزرگ‌تری به‌کار رود، در آن صورت می‌تواند تمام یا زیرمجموعه‌ای از داده‌ها را به مدیر ESM ارسال کند تا آنالیز پیشرفته‌تری روی آن‌ها انجام شود. در این سناریوها، احتمال دارد چندین اسباب جمع‌آوری ثبت وقایع داشت که در مکان‌های کلیدیِ درون سازمان، صف‌آرایی شده‌اند. برای مثال، آن‌ها می‌توانند بر حسب واحد تجاری یا جغرافیایی تقسیم شوند. بسیاری از سازمان‌ها در واقع انبارهای مدیریتی دارند. در این صورت، این امر می‌تواند مطلوب باشد که تمام فایل‌های ثبت وقایع را در سطوح عملیاتی به‌طور مجزا نگاه داشت، اما ممکن است گروه امنیت سراسری نیاز به نمای کل‌نگرانه‌تری داشته باشد. شکل ب.۴ چنین موردی را به تصویر می‌کشد و نشان می‌دهد که چگونه سازمانی می‌تواند اسباب‌های جمع‌آوری ثبت وقایع را صف‌آرایی کند، به‌گونه‌ای که مرز‌های تجاری و جغرافیایی را لحاظ نماید و در عین حال، دیدِ سراسری و کلّی را نیز حفظ کند.

شکل ب.۴ معماری توزیع‌شده‌ی اسباب جمع‌آوری ثبت وقایع

به شکل ب.۱ برگردیم، قابلیت بعدیِ جمع‌آوری ثبت وقایع، از راه‌بردهای مدیریت ثبت وقایعِ موجودِ سازمان بهره می‌برد که معمولاً همان سرورهای ثبت وقایع سیستم هستند. سرورهای ثبت وقایع سیستم می‌توانند پیام‌های ثبت وقایع سیستم را از افزاره‌های متعددی جمع‌آوری نمایند. نرم‌افزاری روی این سرور وجود دارد که معمولاً اتصال‌دهنده‌های رخداد نامیده می‌شود. این اتصال‌دهنده‌ها در اَشکال مختلفی- ثبت وقایع سیستم، SNMP، قالب‌های اختصاصی مانند OPSEC متعلق به چک‌پوینتس یا RDEP متعلق به سیسکو و بسیاری انواع دیگر- عرضه می‌شوند. در کل، اگر سازمانی از قبل مکا‌ن‌های مرکزی‌ای دارد که ثبت وقایع در آن مکان‌ها جمع‌آوری می‌شوند، به‌راحتی می‌توان روی هر کدام از نقاط گردآوری، اتصال‌دهنده‌ای نصب کرد. این اتصال‌دهنده‌ها به نوبه‌ی خود پیش‌پردازش‌هایی را روی این ثبت وقایع انجام می‌دهند و آن‌ها را به مدیر ESM می‌فرستند.

با این‌که این روزها تا حدی غیرعادی است که سازمان بزرگی هیچ نوع راه‌برد گردآوری ثبت وقایعی نداشته باشد که ESM بتواند از آن استفاده کند، این موضوع دستِ‌کم در برخی از زیرمجموعه‌های کوچکِ شبکه اتفاق می‌افتد. در این موارد، می‌توان به‌آسانی ثبت وقایع را به‌طور مستقیم از افزاره‌های نقطه‌ای به مدیر ESM فرستاد. این نوع طراحی امکانِ استفاده از قابلیت‌های پیش‌پردازشی مانند رمزبندی، فشرده‌سازی، فیلترسازی، گردآوری و دیگر خصیصه‌هایی را که بعدها مطرح خواهند شد، نمی‌دهد، اما دستِ‌کم ثبت وقایع را به ESM متقل خواهد کرد تا بتوان آن‌ها را آنالیز کرد.

راه‌برد رایج‌تر برای سازمانی که راه‌برد گردآوری ثبت وقایعی ندارد، این است که از سرورهای موجود برای صف‌آرایی تعداد فراوانی از اتصال‌دهنده‌های رخداد بر روی آن‌ها استفاده کنند. این امر تا اندازه‌ای شبیه به اسباب جمع‌آوری ثبت وقایع، البته تنها از منظرِ قابلیت دریافت، پیش‌پردازش، و بازفرستادن رخدادها به مدیر ESM است. این سیستم‌ها با وجودِ چندین نسخه از اتصال‌دهنده‌های رخدادی که نصب شده‌اند، امکان ضبط رخداد در سطح بالا، ذخیره‌سازی بلندمدت یا آنالیز سریع را به‌اندازه‌ی یک اسباب فراهم نمی‌سازند.

آخرین راه‌برد برای انتقال ثبت وقایع از افزاره‌های نقطه‌ای به مدیر ESM، صف‌آراییِ اتصال‌دهنده‌های رخداد در هر کدام از نقاط گردآوری طبیعی مانند مدیران افزاره است. معمولاً مدیران دیوار آتش، مدیران IDS، پایگاه‌داده‌های کنترل دسترسی و الخ موجود هستند. سازمان‌های بسیاری با این هدف که بتوانند تمام فایل‌های ثبت وقایعِ حیاتی را جمع‌آوری نمایند و در عین حال تعداد افزاره‌هایی نقطه‌ای را که باید اصلاح شوند، کاهش دهند، از چند راه‌برد بهره می‌برند. با استفاده از اتصال‌دهنده‌ها در نقاط گردآوری مانند سرور ثبت وقایع سیستم یا مدیر افزاره، که از اسباب جمع‌آوری رخداد استفاده می‌کنند، یا سروری که با چند اتصال‌دهنده‌ی نصب‌شده ساخته شده است، یک سازمان می‌تواند به‌آسانی راه‌برد مدیریت ثبت وقایعی را صف‌آرایی نماید که ESM را تنها با چندین نقطه‌ی جمع‎‌آوری تغذیه می‌نماید، با این حال ثبت وقایعِ هزاران سیستم موردِ آنالیز قرار می‌گیرند. این روش کم‌تماس، یکی از دلایلی است که بسیاری از سازمان‌ها به این نتیجه می‌رسند که راه‌برد ESMِ کل‌نگرانه در واقع کاملاً عملی است و نیازی نیست به دستکاریِ سیستم‌هایی نقطه‌ای که فایل‌های ثبت وقایع را تولید می‌کنند. اگر نیاز به ایجاد تغییر در هر کدام از سیستم‌های اشاره‌شده بود، کسی از ESM در محیطی وسیع استفاده نمی‌کرد؛ این ره‌یافت‌ها چنین چیزی را ممکن می‌سازند.

مرحله‌ی بعدیِ این نمودار در ارتباط با مدیر ESM و پایگاه‌داده است. در اصل، مدیر ESM مغزِ این معماری است، مکانی مرکزی برای هر چیزی از همبستگی و آنالیز گرفته تا مدیریت بحران و آماده‌باش است. هم‌چنین از پایگاه‌داده‌ی ESMای بهره می‌برد که معمولاً پایگاه‌داده‌ای در سطح تجاری مانند اوراکل برای آنالیز قانونی است. به عبارتی، تمام رخدادهایی که واردِ ESM می‌شوند به‌طور بی‌درنگ در حافظه پردازش می‌شوند، اما اگر آنالیز‌های گذشته و گزارشِ رخدادهای قبلی مدّنظر باشند، به جای دریافت رخدادها از نقاط جمع‌آوری مختلف، ESM این رخدادها را از پایگاه‌داده بازیابی خواهد کرد. انجامِ آنالیز قانونی و بی‌درنگ در مدیر ESM معمولاً یک‌پارچه است و ابزارهای یکسانی برای هر کدام از آن‌ها موجود است.

ESMها معمولاً امکانِ چندین نوع تعامل، از جمله واسط وب و کنسول را فراهم می‌سازند. این کنسول، نرم‌افزاری است که روی لپ‌تاپ یا ایستگاه کاری‌ای بارگذاری می‌شود. کنسول‌ها معمولاً از نظر دارا بودن خصیصه‌ها غنای بیش‌تری دارند و انجامِ وظایف اجرایی‌ای مانند ایجاد محتوای اصیلی همچون قواعد، گزارش‌ها، داشبوردها، و تعریف حق دسترسی کاربر را فراهم می‌سازند. کنسول‌ها به‌طور مستقیم به مدیر ESM متصل می‌شوند. واسط وب، نسخه‌ی رقیق‌شده‌ای از کنسول است که در واقع برای اتصال به مدیر ESM نیاز به مرورگر وب دارد، یا در برخی از موارد، به‌عنوان وب‌سروری خوداتّکا است که به‌نوبه‌ی خود با مدیر ESM ارتباط برقرار می‌کند. این ره‌یافت‌ها، صرف‌نظر از این‌که کنسول یا واسط وب باشند، معمولاً رمزبندیِ ۱۲۸ بیتی با تبادل کلید ۱۰۲۴ بیتی را با بهره‌گیری از HTTPS ارائه می‌کنند. همین سطح از رمزبندی نیز بین اسباب جمع‌آوری ثبت وقایع و اتصال‌دهنده‌ی رخداد به مدیر ESM به‌کار می‌رود.

صرف‌نظر از واسط وبی یا واسط کنسولی، هر دو ره‌یافت می‌توانند کنترل‌های دسترسیِ دانه‌دانه‌ای را برای کاربران فراهم سازند. در اغلبِ موارد، این کنترل‌های دسترسی می‌توانند مقید به نام‌های کاربری و گذرواژه‌های استاندارد، LDAP، PKI، RADIUS، اصالت‌سنجیِ دو عاملی و سیستم‌های کنترل دسترسیِ مشابه باشند. در اغلبِ اوقات هر سازمانی با چند گروه روبه‌رو خواهد بود که درخواست دسترسی به اجزای ESM دارند، و هر گروه یک یا تعداد زیادی کاربر خواهد داشت. در این قالب، افزودن امتیازات ویژه به روال‌های مختلف یا برداشتنِ آن امتیازات، کار ساده‌ای است. امتیازات زیر را مدّنظر قرار دهید که مبتنی بر گروه‌ها هستند:

• اعضای گروه عملیات شبکه می‌توانند هم از واسط وبی و هم کنسولی برای دسترسی به رخدادهایی استفاده کنند که مختص به مسیریاب‌ها، سوئیچ‌ها و دیگر لوازم شبکه هستند. آن‌ها ممکن است نیاز به استفاده از سیستم مدیریت مورد، گزارش و خصیصه‌های تجسّمیِ ESM داشته باشند. اما، آن‌ها نیازی به دسترسی به دیگر خصیصه‌ها و نیز نیازی به دسترسی به رخدادهایی ندارند که به‌طور مستقیم ارتباطی با گروه آن‌ها ندارند.
• ممکن است اعضای گروه امنیت IT نیازمندِ این باشند که به هر جایی در سراسرِ تمام گروه‌ها سَرَک بکشند، و ممکن است به این نیاز داشته باشند که پیشرفته‌ترین قابلیت‌های آنالیز ESM در اختیار آن‌ها قرار گیرند. اما، شاید اعضایی در این گروه باشند که بیش‌تر در ارتباط با موضوعات تطابق هستند. در این صورت، آن‌ها تنها اجازه‌ی ورود به حریمِ رخدادهایی را دارند که در ارتباط با آن دارایی‌هایی هستند که وابسته به تطابق تنظیمی اند، تطابقی که در پایگاه‌داده‌ی داراییِ ESM تعریف شده است.
• گروه‌های امنیت فیزیکی و همین‌طور مدیریت، احتمالاً تنها نیاز به دسترسی از طریق واسط وب داشته باشند. ممکن است هر دو نیاز داشته باشند که داشبوردهای گرافیکی و سیستم مدیریت مورد را ببینند. هم‌چنین، ممکن است نیاز به دسترسی به گزارش و شاید حتی گزارش‌های روزانه‌ی حوزه‌های مربوطه‌ی خود داشته باشند. برای مثال، ممکن است گروه امنیت فیزیکی نیازمندِ مشاهده‌ی گزارشی باشد که ورود به حوزه‌ی ویژه و حساسی از این تأسیسات را مستند می‌سازد. مدیران ممکن است نیاز به مشاهده‌ی گزارش‌های سطح بالایی داشته باشند در این خصوص که موارد مربوطه تا چه اندازه به‌طور کارآمد انجام می‌شوند و وضعیت کلیِ خطر در مقایسه با هفته‌ها و فصل‌های گذشته چگونه است.

در عین حال که قابلیت‌های ESM در طول این سال‌ها به بلوغ رسیده‌اند، قابلیت‌های هسته‌ای آن‌ها نیز رشد کرده‌اند. پیش از این، به اسباب جمع‌آوری ثبت وقایع اشاره کردیم که فن‌آوریِ خوداتّکا یا یک‌پارچه‌ای برای جمع‌آوری، ذخیره‌سازی، و آنالیز سریعِ جریان عظیمی از رخدادها در اختیار ما قرار می‌دهد. حوزه‌های دیگری که در این راستا مطرح اند، پاسخگویی شبکه و پیکربندی شبکه هستند. سازمان‌ها همین‌طور که رشد می‌کردند، متوجهِ نه تنها نیاز به آشکارسازی، بلکه همچنان که شکل ب.۱ نشان می‌دهد، نیاز به پاسخگویی با استفاده از مدیر پاسخگویی شبکه (NRM) و پیش‌گیری از طریق روش عمل‌گرایانه‌ای در خصوص پیکربندی افزاره‌ی شبکه با استفاده از مدیر پیکربندی شبکه (NCM) شدند. این سیستم‌ها به‌خوبی با قابلیت‌های سنتیِ ESM و همین‌طور با ره‌یافت‌های امنیت فیزیکی، یک‌پارچه می‌شوند. البته، در ادامه‌ی این پیوست، با استفاده از مقایسه‌ی همگرایی امنیت فیزیکی و منطقی، همگراییِ مرکز عملیات شبکه‌ای و مرکز عملیات امنیتی را از طریق ارتباطات و رنگ‌آمیزی ارتقایافته بررسی خواهیم کرد.

امنیت همواره تبدیل به جزئی از مسیر بحرانیِ یک سازمان شده است. یک زمانی هنوز می‌شد عملیات را بدون وجود هرگونه امنیتی سرِپا نگاه داشت، اما آن روزها تقریباً دیگر گذشته‌اند. فروشندگان امنیت، با توجه به این امر، معماری‌هایی با قابلیت دسترسی بالا برای این ره‌یافت‌ها توسعه داده‌اند؛ فروشندگانِ ESM نیز همین‌طور هستند. شکل ب.۵ طراحی‌ای با قابلیت دسترسی بالا را برای مدیر ESM و پایگاه‌داده‌ی ESM نشان می‌دهد.

شکل ب.۵ معماریِ ESMِ با قابلیت دسترسی بالا

اغلبِ ESMها می‌توانند از بسیاری گزینه‌های با قابلیت دسترسی بالا مانند لِگاتو، وِریتاس و اوراکل راک استفاده کنند. در شکل ب.۵ رخدادها به‌وسیله‌ی مدیر ESMِ اولیه برای انجام پردازش بی‌درنگ دریافت می‌شوند. آن مدیر رخدادها را برای ذخیره‌سازی و آنالیز قانونی به پایگاه‌داده‌ی اولیه می‌فرستد. در صورتی که مدیر اولیه دچار اختلال در کار و قطعی گردد، یا برای نگه‌داری و پشتیبانی از خط خارج گردد، مدیر ESMِ ثانویه جمع‌آوریِ رخدادها را آغاز می‌کند و همچنان می‌تواند از پایگاه‌داده‌ی ESMِ اولیه استفاده کند. به‌محضِ این‌که مدیر ESM اولیه روی خط برگردد، رخدادها به‌جای ارسال به ثانویه به او فرستاده می‌شوند.

در صورتی که همین سناریو در خصوصِ پایگاه‌داده‌ی اولیه اتفاق افتد، همین فرآیند اجرا خواهد شد. به‌محضِ این‌که پایگاه‌داده‌ی اولیه روی خط برگردد، ارتباطاتِ میان پایگاه‌داده‌های ESM اولیه و ثانویه باز‌هم‌گام خواهند شد.

این معماری می‌تواند بروز هر نوع قطعیِ هم‌زمان در هر کدام از مدیران ESM و هر کدام از پایگاه‌داده‌های ESM را نیز برطرف سازد. به‌عبارتی، اگر مدیر ESM اولیه در حالِ کار باشد، اما پایگاه‌داده‌ی ESM اولیه از کار افتاده باشد، این معماریِ ESM بین مدیر ESM اولیه و پایگاه‌داده‌ی ESM ثانویه به کارِ خود ادامه خواهد داد. هم‌چنین، اگر مدیر ESM ثانویه در حالِ کار و ارتباط با پایگاه‌داده‌ی ESM اولیه باشد، در صورتی که قطعیِ دیگری هم به‌وجود آید، می‌تواند ارتباط خود را عوض کند و با پایگاه‌داده‌ی ESM ثانویه ارتباط برقرار کند.

مدیران و پایگاه‌داده‌ها همیشه در حین کار، تا زمانی که یکی از آن افزاره‌ها از کار بیفتند، هم‌گام هستند. به‌محض این‌که اتصال بازبرقرار می‌شود، فرآیندِ بازهم‌گام‌سازی را شروع خواهند کرد. این طراحی، معماریِ ESMِ بسیار مستحکمی را فراهم می‌سازد.

علاوه بر طراحی‌های با قابلیت دسترسی بالا، اغلب به نوعی سلسله‌مراتب نیز نیاز است. ESM از این لحاظ مانند علم رایانه ۱۰۱ است. اگر بخواهید چیزی را بسط‌پذیر کنید، سلسله‌مراتب می‌سازید- درست مانندِ DNS. با این نوع معماری، زوج‌های مدیر و پایگاه‌داده‌ی ESM می‌توانند به‌طور نامحدودی گسترده و ژرف باشند. البته در عمل، این درخت سلسله‌مراتبی به‌ندرت بیش از چند لایه ژرفا دارد، هرچند می‌تواند بسته به نظرِ سازمان در خصوصِ عملیات مقطعی، نسبتاً گسترده باشد. شکل ب.۶ معماریِ ESMِ سلسله‌مراتبی‌ای را موردِ کاوش قرار می‌دهد.

شکل ب.۶ معماری ESMِ سلسله‌مراتبی

شکل ب.۶ نشان می‌دهد که چگونه سازمانی می‌تواند بخش‌های مختلفی داشته باشد. هر بخش می‌تواند صف‌آراییِ ESMِ خاصِ خود را داشته باشد. این بخش‌ها فقط نسبت به چیزی مسئولیت دارند که در بخش خودِ آن‌ها اتفاق می‌افتد. در سطح منطقه‌ای، صف‌آرایی‌ای مشابهِ صف‌آراییِ بخشی وجود دارد. البته، تفاوت کلیدیِ آن این است که مدیر ESM منطقه‌ای، رخدادها را نه از اتصال‌دهنده‌های رخداد یا اسباب جمع‌آوری ثبت وقایع، بلکه از مدیر بخشی دریافت می‌کند. از منظرِ مدیر ESM منطقه‌ای، مدیران بخشی در واقع تغذیه‌کننده‌ی دیگری برای رخداد هستند. بسته به خط‌مشی‌های سازمانی، تمام یا زیرمجموعه‌ای از داده‌های بخشی برای انجام آنالیز به مدیران منطقه‌ای فرستاده خواهند شد. اگر زیرمجموعه‌ای از داده‌ها مدّنظر باشند، ممکن است گروه‌های منطقه‌ای فقط رخدادهایی را بفرستند که برای مثال، شدت بالایی داشته باشند یا بر دارایی‌های حیاتی تأثیرگذار باشند. در نهایت، همین فرآیند می‌تواند در خصوصِ مدیر ESMِ مرکزیِ سازمان به‌کار برده شود. علاوه بر این، تحلیل‌گران در مرکز می‌توانند به تمام مدیران ESMِ منطقه‌ای و بخشی دسترسی داشته باشند، البته تا زمانی که امتیاز دسترسی برای انجام چنین کاری را داشته باشند. این امر به آن‌ها امکان می‌دهد تا در صورتی که رخدادهایی وجود دارند که به مدیر ESMِ آن‌ها فرستاده نشده‌اند، بازپرسی‌های دقیق‌تری را انجام دهند.

این‌ها ضرورتاً اجزای اصلیِ معماری ESM هستند. البته، همچنان که پیش‌تر در این پیوست بیان شد، روابط معینی نیز در ارتباط با پاسخگویی شبکه و پیکربندی شبکه وجود دارند که به‌طور مناسب درونِ این معماری گنجانده می‌شوند. در بخش بعدی، مفهوم دیوار چین را بررسی خواهیم کرد و به‌تفصیل نشان می‌دهیم که چگونه کلاه‌برداریِ حساب‌شده‌ای از نوع بازرگانیِ خودی بین بانک‌دار سرمایه‌گذاری و کارگزار بورسی که برای بنگاه مالیِ بزرگی در وال استریت کار می‌کند، می‌تواند با استفاده از ترکیب داده‌های رخدادِ فیزیکی و منطقی از طریق مدیریت امنیت بنگاه (ESM) ناکام بماند.

دیوار چین چیست؟

در دنیای امنیت، اصطلاحی معروف به دیوار چین وجود دارد. دیوار چین برای جلوگیری از ارتباطِ کاربران خاصی با دانش جزءبندی‌شده طراحی شده است. در این پیوست بررسی خواهیم که این امر به چه معنا است و این‌که سازمان‌ها چگونه آن را پیاده می‌سازند تا از در دسترس قرار گرفتنِ اطلاعات حفاظت نمایند، چرا که این دسترسی می‌تواند منجر به ارتکاب به کلاه‌برداری از سوی یکی از خودی‌ها گردد. ره‌یافتی که در این پیوست ارائه می‌کنیم، شاملِ گروه امنیتیِ مجهز به ابزارهای آنالیزیِ پیشرفته و درکِ مزایایی است که از آنالیز داده‌ها فراتر از سیستم آشکارسازی نفوذ و دیوار آتش متعارف ناشی می‌شود. هم‌چنین نشان خواهیم داد که فرآیند آنالیز و سازوکار آشکارسازیِ احتمالی چگونه از منابعی داده‌ای استفاده می‌کند که این منابع داده‌ای، بیش از تمرکزِ صرف روی ترافیک شبکه، روی فعالیت کاربران تمرکز می‌کنند. این منابع شاملِ سوابق جزئیات تماس تلفنیِ (CDRها) صوت از طریق IP (VoIP)، و نیز فایل‌های ثبت وقایعِ تراکنش ایمیلی می‌شوند که می‌توانند در باره‌ی ارتباطات میان افرادِ درون یک سازمان ما را مطلع سازند.

این افزاره‌ها به‌عنوان منابع غیرسنتی شناخته می‌شوند، و ایده‌ی جمع‌آوری داده‌ها از این سیستم‌ها در افق دیدِ اغلبِ گروه‌های امنیتی قرار نگرفته است. آن‌ها حاویِ برخی از عملیات بسیار پیشرفته‌ای (و نادری) هستند که تمام فعالیت کاربر از جمله سوابق تماس تلفنی، اسناد پرینت‌شده، و دسترسی ساختمانی و اتاقی، نظارت و ردیابی می‌شود. از آنجا که این‌ها منابع داده‌ایِ غیرسنتی هستند، چالش‌های جدیدی در ارتباط با جمع‌آوری داده‌ها از این افزاره‌ها مطرح هستند. ما آن چالش‌ها، و ره‌یافت‌های آن‌ها را، در این پیوست مدّنظر قرار خواهیم داد.

واضح است که به این معنا دیوار چین دیوار عظیمِ ۶۷۰۰ کیلومتری‌ای نیست که به‌وسیله‌ی سلسله‌ی مینگ در دهه‌ی ۱۳۰۰ برای جلوگیری از یورش مغول‌ها ساخته شد. این اصطلاح پس از سقوط بازار سهام ایالات متحده در سال ۱۹۲۹ باز بر سرِ زبان‌ها افتاد. این عبارت از قوانین وضع‌شده توسط کنگره ناشی می‌شود، قوانینی که خط‌مشی‌هایی را تعیین کردند که لازم بود به‌کار گرفته شوند تا تفکیک منطقی‌ای بین گروه‌های مختلف اقتصادی و بانک‌دارهای سرمایه‌گذاری ایجاد شود. یکی از محرّک‌های اصلیِ این حکم، این بود که در خصوصِ سقوط بازار سهام تا حدّ زیادی قیمت‌های حبابیِ سهام را مقصر می‌دانستند که به دلیل بازرگانیِ خودی و دستکاری قیمت‌ها ایجاد شده بودند. قانونی که کنگره در سال ۱۹۹۳ وضع کرد، با نام قانون گلاس-استیگال، در ابتدا بانک‌های اقتصادی را از انجامِ هرگونه چیزی که در ارتباط با کارمزدِ کارگزاری باشد، منع کرد. پس از آن، سخت‌گیری این قانون کمتر شد، و هم‌اکنون سازمان‌های مالی بزرگ، در بانک‌داری سرمایه‌گذاری، بازرگانیِ سهام، و بسیاری از فعالیت‌های مالی دیگر مشارکت دارند.

دیوار چین به‌عنوان مدل بریوِر-نَش نیز شناخته می‌شود، که برای پیشگری از ایجاد موقعیت‌های تضاد منافع، و پیش‌گیری از نشت اطلاعات طراحی شده است. این مدل داده‌ها را به‌صورت دسته‌بندی‌های تضاد منافع طبقه‌بندی می‌کند. همین که داده‌ها دسته‌بندی می‌شوند، کاربران، و نیز فرآیندهایی که از سوی کاربر اجرا می‌شوند، در قالبِ آن‌چه با عنوانِ فاعل شناخته می‌شود، تفکیک می‌شوند. سپس، قواعدی به‌کار گرفته می‌شوند تا مشخص شود که کدام فاعل‌ها می‌توانند به کدام مفعول‌ها دسترسی داشته باشند یا آن‌ها را بخوانند و بنویسند. قطعه‌ی زیر از «خط‌مشی امنیتیِ دیوار چین» است که توسط دکتر دیوید اف.سی. بریوِر و دکتر مایکل جِی. نَش از گاما سِکیور سیستِمز لیمیتید (سوری، انگلستان) نوشته شده است:

اجازه‌ی دسترسی فقط در صورتی داده می‌شود که مفعول درخواست‌شده:

الف) در همان پایگاه‌داده‌ی شرکتی باشد که مفعولی که قبلاً توسط فاعل در دسترس قرار گرفته، بوده است، مثلاً درونِ دیوار، یا

ب) متعلق به دسته‌ی تضاد منافعِ کاملاً متفاوتی باشد.

دسترسیِ نویسش فقط در صورتی مجاز است که:

الف) دسترسی، طبق قاعده‌ی امنیتیِ ساده، مجاز باشد، و

ب) امکانِ خوانشِ مفعولی که در پایگاه‌داده‌‌ی شرکتیِ متفاوتی از مفعولی است که دسترسیِ نویسش برای آن درخواست شده است و حاویِ اطلاعات پاک‌سازی‌نشده‌ای است، نباشد.

قواعد بیان‌شده نشان می‌دهند که چگونه مدل بریور-نش اجازه‌ی خوانش و نویسشِ داده‌ها را تعریف می‌کنند. قاعده‌ی خوانش تلاش دارد تا این اطمینان حاصل شود که کاربر فقط داده‌هایی را که قبلاً خوانده است، داده‌های دیگری که به‌طور مشابه دسته‌بندی شده‌اند، یا داده‌هایی را بخواند که کاملاً نامرتبط با داده‌هایی هستند که قبلاً خوانده است. قاعده‌ی نویسش تلاش دارد تا این اطمینان حاصل شود که کاربرانی که می‌خواهند داده‌هایی را بنویسند باید از قبل به آن داده‌ها دسترسی داشته باشند، و آن داده‌ها روی رایانه‌های خودِ آن‌ها باشند. این امر به قاعده‌ی امنیتی ساده مشهور است. هم‌چنین، کاربر نمی‌تواند هیچ مفعولی را در حوزه‌ی تضاد منافعِ متفاوتی بخواند، و آن داده‌ها باید پاک‌سازی‌نشده باشند، به این معنا که تغییر و ابهامی در آن‌ها صورت نگرفته باشد. مطالعه‌ی «خط‌مشی امنیتیِ دیوار چین» می‌تواند بسیار جالب‌توجه باشد؛ شما می‌توانید آن را در آدرس www.gammassl.co.uk/topics/chwall.pdf مطالعه نمایید.

برخی از این امر به‌عنوان تفکیک وظایف یاد می‌کنند. بسیاری از سازمان‌ها دارای اداراتِ حساب‌های بدهکاری و حساب‌های بستانکاری هستند که برنامه‌ی مشترکی، مانند SAP، را به اشتراک می‌گذرند تا حساب‌های جدید را وارد و حساب‌ها را پرداخت نمایند. کارمندانی که امکانِ ورودِ حساب جدیدی را دارند هرگز نباید اجازه‌ی پرداخت حساب را داشته باشند. تضاد منافع در این‌جا چیز مشخصی است: ممکن است کارمندی حسابِ ساختگی‌ای بیافزاید که در واقع صرفاً شرکتی برای ظاهرسازی است، و به‌آرامی، در طول زمان، از این حساب برای اختلاس مالی از کارفرمای خود استفاده کند.

در طول ۴۰ سال گذشته، هیئت ذخیره‌ی فدرال، که مسئول تنظیم مقررات بانک‌ها است، این اجازه را به بانک‌ها داده است که شرکت‌های تابعه‌ای ایجاد کنند که بتوانند در ادغام‌ها و اکتساب‌ها و فروش و پذیره‌نویسیِ اوراق بهادار شرکت کنند. این همان جایی است که مشکل، خود را نشان می‌دهد. حالا شما شرکت بزرگی با هزاران کارمند دارید که ممکن است همدیگر را بشناسند یا نشناسند و می‌توانند از اطلاعاتی که دیگر افراد در سازمان در اختیار دارند، بهره‌مند شوند.

بیایید مثال ساده‌ای را درنظر گیریم. جو، که در اداره‌ی ادغام‌ها و اکتساب‌ها کار می‌کند، می‌داند شرکتی که او با آن کار می‌کرده است به‌زودی به شرکت بسیار بزرگ‌تری فروخته خواهد شد، و او می‌داند که این فروش منجر به کسب سود خواهد شد. لَری برای همان سازمانی کار می‌کند که جو، منتها او در بخش بانک‌داری سرمایه‌گذاری کار می‌کند. اگر جو سرِ بازیِ گلف در تعطیلات آخر هفته به‌طور اتفاقی گفت‌وگوی «معصومانه‌ای» با لری داشته باشد، و لری از این راز باخبر شود که شرکت معینی به‌زودی فروخته خواهد شد، لری می‌تواند به تمام مشتریان خود توصیه کند که در این شرکت سرمایه‌گذاری کنند، که بی‌شک سود زیادی را نصیبِ مشتریان او خواهد کرد، و به نوبه‌ی خود جیب‌های او نیز از ناحیه‌ی کارمزد پر از پول خواهد شد. این یکی از تعاریف بازرگانی خودی است. شکل ب.۷ این سناریو را به نمایش می‌گذارد.

شکل ب.۷ جریان نشت داده‌ای

شکل ب.۷ راهی را نشان می‌دهد که داده‌های سرمایه‌گذاری بین اداره‌ی ادغام‌ها و اکتساب‌ها و اداره‌ی بانک‌داری سرمایه‌گذاری نشت می‌کند. جعبه‌های وسطی، نشان‌دهنده‌ی اداره‌ها هستند و روپوش‌های روی اداره‌ها نشان‌دهنده‌ی داده‌هایی هستند که هر اداره‌ای در باره‌ی آن‌ها اطلاع دارد و دیگری اطلاع ندارد. اطلاعات از طرف اداره‌ی ادغام‌ها و اکتساب‌ها، توسط مأمور اداره، به بانک‌دار سرمایه‌گذاری نشت می‌کنند. در این‌جا تضاد منافع ایجاد می‌شود چرا که بانک‌دار سرمایه‌گذاری، می‌داند پای شرکتی در میان است که به‌زودی فروخته خواهد شد، که بسته به قیمت، می‌تواند قیمت سهامِ آن شرکت را بالا یا پایین کند. اگر بانک‌دار سرمایه‌گذاری، این اطلاعات را به مشتریان خود درز دهد، مورد کلاسیکی از بازرگانیِ خودی اتفاق افتاده است.

از زمان رهاسازیِ نسبیِ قانون گلاس-استیگال، هیچ قانونی بیان نمی‌کند که سازمانی نمی‌تواند هم اداره‌ی ادغام‌ها و اکتساب‌ها و هم اداره‌ی بانک‌دار سرمایه‌گذاری را داشته باشد، و هیچ قانونی بیان نمی‌کند که اگر سازمانی هر دو اداره را داشته باشد، این اداره‌ها باید به‌لحاظ فیزیکی از هم جدا باشند. منتها، شرکت‌ها تمایل دارند که طبق تفکیک منطقی‌ای کار کنند که در واقع بر مبنای احترام و اعتماد متقابل است، و همه‌ی ما می‌دانیم که این سیستم چقدر خوب کار می‌کند. اگرچه مثال‌های موجود در این پیوست روی مؤسسات مالی تمرکز دارند، این اصول در خصوصِ دیگر انواع سازمان‌ها نیز صدق می‌کنند. برای مثال، جامعه‌ی اطلاعات امنیتی، دارای سطحی از پاک‌سازی، مشهور به جزءبندی‎شدگی است.  ایده‌ی پشتِ سرِ پاک‌سازی جزءبندی‌شده این است که هیچ شخصی تمام جزئیات مأموریت را نداند. در موردِ اطلاعات امنیتی خارجی، یک گروه هویتِ عوامل را می‌شناسد، گروه دیگری اهداف را می‌شناسد، و گروه سومی می‌داند که چه اطلاعاتی باید جمع‌آوری گردد. این امر به این معنا است که اگر یک شخص موجبِ نشت اطلاعات گردد، نمی‌تواند کلّ مأموریت را در معرض خطر قرار دهد.

در این خصوص چه کاری از ما برمی‌آید؟ از هم مجزا نگاه داشتنِ افرادی که می‌خواهند ارتباط داشته باشند، کار بی‌نهایت دشواری است. ما می‌توانیم با استفاده از سیستم‌های دسترسی فیزیکی، اقدامات احتیاطی‌ای را در پیش گیریم، یا در خصوص شماره تلفن‌هایی که افراد می‌توانند از خط تلفنِ دفتر خود بگیرند، محدودیت‌هایی قرار دهیم. البته، تقریباً هر فردی تلفن‌همراه دارد، و در اغلبِ سازمان‌ها، شما نمی‌توانید جلوی افراد را بگیرید که درون اداره، و به‌ویژه خارج از آن، با هم ناهاری صرف نکنند. و قطعاً شما نمی‌توانید آن‌چه را که افراد در تعطیلات آخر هفته‌ی خود انجام می‌دهند، کنترل کنید. نمونه‌های بی‌شماری دیده‌ایم که در آن‌ها کارمندان CIA تحت نظارت قرار می‌گیرند و توسط گروه‌های مراقبتی پاییده می‌شوند تا این اطمینان حاصل شود که با دیگران ارتباط برقرار نمی‌کنند. معمولاً چنین امری وقتی اتفاق می‌افتد که دلیلی وجود دارد مبنی بر این‌که این کارمندان در حالِ ارتکاب به خیانت هستند. همچنان که پیش از این بیان شد، دیوار چینِ «جدید» مبتنی بر احترام و اعتماد متقابل است، بنابراین اِعمال محدودیت در واقع فقط منجر به این می‌شود که کاربران گریزان‌تر شوند. اگر شما محدودیت‌های اِعمالی بر کاربران را کاهش دهید و به‌طور انفعالی بر رفتار آن‌ها نظارت نمایید، آن‌ها معمولاً مرتکب اشتباه خواهند شد و فعالیت‌های خود را آشکار خواهند ساخت، به‌ویژه اگر ندانند که شما آن‌ها را تحت نظارت دارید. ما می‌توانیم با توجه به الگوهای فعالیت و ارتباطات، و با استفاده از ابزارهای همبستگیِ پیشرفته، توده‌های انبوهی از داده‌های ثبت وقایع را قابلِ‌فهم سازیم و استنباط‌های مستقیمی را بیرون بکشیم. در بخش بعدی، نگاهی خواهیم داشت به برخی از چالش‌هایی که در ارتباط با جمع‌آوری داده‌ها از افزاره‌های جدیدی مانند ثبت وقایع ایمیل و تماس‌های تلفنی مطرح هستند.

منابع داده

در این بخش، به بحث در خصوص فن‌آوری‌هایی خواهیم پرداخت که در این پیوست با آن‌ها سروکار خواهیم داشت. ما این‌ها را منابع داده‌ی جدید می‌نامیم چرا که تفاوت زیادی با رخداد امنیتی سنتی دارند. برای آشکارسازی فعالیت کلاه‌بردارانه و ناهنجاری‌ها در رفتار کاربران، باید چیزی بیش از داده‌های سیستم آشکارسازی نفوذ را آنالیز نمایید. ما که ندیده‌ایم بتوان امضایی در سیستم آشکارسازی نفوذ ایجاد کرد تا هنگامی که دو نفر از کارمندان «موردِ اعتماد»، در حالِ ارتکاب بازرگانیِ خودی هستند، به شما اطلاع دهد. چنین سیستمی به‌دنبالِ الگویی حمله‌ای می‌گردد که از حریم شبکه می‌گذرد و سیستم‌های رایانه‌ای را موردِ هدف قرار می‌دهد. در این مورد، ما در اصل با حمله‌ای منطقه‌ای سروکار نداریم، هرچند حمله‌ای در حالِ وقوع است. کاربران در این‌جا به سیستم‌ها و داده‌هایی که در حالِ دسترسی هستند، دسترسیِ قانونی دارند، اما مشکل از آنجا ناشی می‌شود که آن‌ها اطلاعات را با کاربران دیگری به اشتراک می‌گذارند که اجازه‌ی ورود به آن حریم را ندارند.

این مثال، مثال کلاسیکی از تهدیدی خودی است. کشفِ تهدیدهای داخلی بسیار دشوار است و می‌تواند هزینه‌هایی برابر با میلیون‌ها دلار را به شرکت‌ها تحمیل کند. تهدیدهای خودی با کاربرانی سروکار دارند که داخلِ سازمان قرار دارند و به سیستم‌ها و داده‌ها دسترسی دارند. چگونه خواهید توانست کسی را گیر بندازید که در ظاهر هیچ کار اشتباهی انجام نمی‌دهد؟ کتابِ تهدید خودی، نوشته‌ی دکتر اِریک کول، مثال‌های بسیاری از موارد واقعیِ تهدید خودی را مطرح می‌کند. کتاب دیگری که آن را توصیه می‌کنیم، دشمن به‌وسیله‌ی آب‌سردکن، نوشته‌ی براین کونتوس، است که به‌دقت بیان  می‌کند که چگونه مشکل تهدید خودی را از منظر ESM موردِ توجه قرار داد. تجربه نشان می‌دهد که برای آشکارسازیِ تهدیدی داخلی، باید سیستم هشدارِ اولیه‌ای به‌کار گرفته شود. پیش از اغلبِ خطرات داخلی، فعالیت‌های شناسایی‌کننده‌ای صورت می‌گیرند و در صورت استفاده از سیستم هشدار اولیه می‌توان همان ابتدا آن‌ها را آشکارسازی کرد. یکی از پیشران‌های اصلیِ سیستم هشدار اولیه منابع داده هستند که به کاربران واقعی، و نه فقط آدرس‌های پروتکل اینترنت (IP) اشاره می‌کنند. در دو بخش بعدی، نگاهی به برخی از این فن‌آوری‌ها خواهیم داشت.

ایمیل

همه با ایمیل آشنا هستند. این فن‌آوری مدت‌ها است که حضور دارد، و تقریباً هر شرکتی به‌نوعی از آن استفاده می‌کند تا کسب‌وکار و ارتباطات روزانه‌ی خود را هم در داخل و هم خارج از شرکت انجام دهد. سازمان‌ها خدمات ایمیل را به کارمندان خود ارائه می‌دهند، و کارمندان معمولاً از طریق خدمات‌گیرنده‌ای مانند مایکروسافت اوت‌لوک به میل‌سرورِ شرکتی متصل می‌شوند. خطراتی در ارتباط با ایمیل شرکتی، و خطرات بزرگ‌تری در ارتباط با وب‌میل وجود دارند. در محیط‌های ایمیل شرکتی، کاربری که قصد انتقال پنهانیِ داده‌ها به بیرون از شرکت را دارد می‌تواند فایلی را به پیامِ صدوریِ خود پیوست کند و آن فایل را به هر تعداد از افراد، از جمله رقبا، همکاران پیشین، یا حتی ملل خارجی بفرستد. خوش‌بختانه، می‌توانیم چنین فعالیت‌هایی را از طریق میل‌سرورِ شرکتی ردیابی کرد.

معمولاً زمانی که کارمندی موردِ بازپرسی قرار می‌گیرد، تمام ایمیل‌های گذشته‌ی او بازپرسی خواهند شد تا هرگونه خطاکاری مشخص شود یا موردی علیهِ او ساخت. مشکل زمانی بروز پیدا می‌کند که کاربران اقدام به دسترسی به وب‌میل‌سرورهایی مانند یاهو و هات‌میل می‌کنند. این سایت‌ها این امکان را به کاربران می‌دهند تا از درون سازمان اتصال پیدا کنند، و همان فایل را پیوست و به همان افراد ایمیل کنند- اما بدون باقی ماندنِ هیچ نوع سابقه‌ای از آن‌چه انجام داده‌اند. در حال حاضر، زمانی که بازپرسی‌ای در جریان است، تحلیل‌گر یا گروه قانونی نمی‌توانند به میل‌سرور رجوع کنند و سوابق فعالیت‌های آن فرد را بیرون بکشند. رشته‌ی نوظهوری با نامِ جلوگیری از نشت اطلاعاتی (ILP) تلاش دارد تا این نوع از تهدیدات را موردِتوجه قرار دهد. محصولات ILP، مشابه سیستم‌های آشکارسازی نفود، محتواها را به‌هنگامِ عبور از شبکه تحت نظارت می‌گیرند؛ منتها، تاکنون، با مشکلاتی در ارتباط با قطعیات کاذب دست‌به‌گریبان بودند، مشابهِ آن چیزی که سال‌ها پیش، فروشندگان سیستم آشکارسازیِ نفوذ با آن روبه‌رو بودند.

بازپرسان و گروه‌های قانونی سال‌ها از تراکنش‌های ایمیلی به‌عنوان مدرکِ خطاکاری استفاده کرده‌اند، در این صورت، چرا چنین چیزی به‌عنوان منبع داده‌ی «جدید»ی درنظر گرفته می‌شود؟ ایمیل از آنجا منبع داده‌ی جدیدی درنظر گرفته می‌شود که بیرون از قلمروِ چیزهایی قرار می‌گیرد که سازمان‌های امنیتیِ معمول آن‌ها را نظارت می‌کنند. تراکنش‌های ایمیلی معمولاً به‌صورت بی‌درنگ آنالیز نشده‌اند؛ آن‌ها به‌عنوان قسمتی از بازپرسی‌های قانونی به‌کار گرفته شده‌اند. زمانی که کارمندی مظنون به خطاکاری می‌شود، هر ایمیلی که فرستاده است، موردِ بررسی قرار می‌گیرد. در حال حاضر، تلاش ما بر این است که نتایجی را استخراج کنیم و شاخص‌های هشدار اولیه‌ای از نشت داده را، نه پس از وقوع، بلکه پیش از وقوع آن آشکار سازیم. اطلاعاتی که شما می‌توانید از بازرسیِ پیام‌های ایمیلی به‌دست آورید، ممکن است شما را شگفت‌زده کند.

مزایای یک‌پارچه‌سازی

چند مورد کاربرد برای این امر به ذهن می‌رسد. یکی اطلاعاتِ فرستنده و گیرنده است، که به شما این امکان را می‌دهد تا نمودارهای «بالاترین صحبت‌کنندگان» را بسازید که به شما اجازه می‌دهند تا مشخص سازید که چه‌کسی با چه‌کسی صحبت می‌کند، چه حوزه‌هایی اطلاعات را از شرکت شما می‌گیرند، و چه حوزه‌هایی اطلاعات را به کارمندان شما می‌فرستند. پیام‌های ایمیلی برای بازپرسی‌های منابع انسانی از کارمندان نیز مفید هستند. کسی از نیروی انسانی یا هیئت قانونی معمولاً تمام ایمیل‌هایی را که کارمند خاصی فرستاده است، به‌عنوان قسمتی از کارِ جمع‌آوریِ مدرک برای نوعی خطاکاری، درخواست می‌کند. در ادامه، پیام یا عنوانی وجود دارد، که این امکان را می‌دهد تا بتوان درکی نسبی از آن چیزی به‌دست آورد که در واقع مخابره شده است. و زمانی که فایلی به ایمیلی پیوست می‌شود، نام فایل می‌تواند در خط عنوان ظاهر شود، که امکان نظارت بر پیوست‌هایی را که فرستاده شده‌اند، مهیا می‌سازد. دیگر مواردِ کاربرد این امر، در خصوصِ اندازه‌ی پیام‌های ایمیلیِ فرستاده‌شده، و زمان‌هایی هستند که کاربر آن پیام‌ها را فرستاده است. اگر کاربری همیشه پیام‌های ایمیلیِ پُرحجمی را در وسط روز فرستاده باشد، می‌تواند موجب ایجاد سوءظن گردد؛ ای امر می‌تواند نشان‌دهنده‌ی نوعی نشت اطلاعات یا فعالیت دیگری مرتبط با سازمان باشد.

دیگر مثال فوق‌العاده در این زمینه رمزبندی است. اگرچه پیام رمزبندی‌شده را نمی‌توان بر اساس بسامد و گیرنده خواند، می‌توانید پی به آن‌چه اتفاق افتاده ببرید.

از آن رو که به منابع انسانی اشاره کردیم، اشاره به موضوعات قانونیِ مرتبط با نظارت بر تراکنش‌های ایمیلیِ کارمندان نیز خالی از لطف نیست. در اغلبِ سازمان‌ها زمانی که استخدام شروع می‌شود، کارمند جدید و کارفرما خط‌مشی‌ای را امضا می‌کنند که معمولاً مشخص می‌سازد که تمام ارتباطاتِ انجام‌شده با استفاده از تجهیزات شرکت، تحت نظارت قرار می‌گیرند. این خط‌مشی‌ها معمولاً در عمل، همیشه آنقدرها که باید مشخص نیستند، البته، و در بسیاری از مواردِ حریم شخصی، چنین خط‌مشی‌هایی در دادگاه زیر سؤال رفته‌اند.

برای اجتناب از سردرگمی، این خط‌مشی باید به‌وضوح بیان کند که ایمیل‌ها می‌توانند نظارت شوند و خواهند شد. در مواردی که خط‌مشی‌ها به‌وضوح بیان می‌کنند که شرکت‌ها بر ایمیل‌ها نظارت می‌کنند، دادگاه‌ها به‌نفعِ شرکت‌ها رأی داده‌اند. یکی از چنین مواردی بورک علیه نیسان است. نیسان بورک را که متهم به دریافت و ارسالِ ایمیل‌های وقیحِ جنسی بود، اخراج کرد. بورک نیسان را به دلیل نقض حریم شخصی به دادگاه کشاند، و دادگاه به‌نفعِ نیسان رأی داد چرا که خط‌مشیِ آن به‌وضوح بیان می‌کرد که ایمیل‌ها تحت نظارت قرار داشتند. ما شاهدِ مواردی در خصوصِ تبعیض نیز بوده‌ایم که در آن‌ها کارمندی ادعا می‌کند که او «انتخاب شده است» چون ایمیل‌های‌اش تحت نظارت قرار می‌گیرند، در حالی که ایمیل‌های کارمندان دیگر تحت نظارت قرار نمی‌گیرند. در این موارد، مهم است که بتوان اثبات کرد که با همه به یک شکل رفتار می‌شود، و این‌که در مواردِ خطاکاریِ مظنون، فرآیند بازپرسی یکسان است.

چالش‌های یک‌پارچه‌سازی

از آنجا که مدت‌ها است که از ایمیل‌ها استفاده می‌شود و پیام‌های ایمیلی حاویِ اطلاعات مفید بسیاری زیادی هستند، چرا جمع‌آوری و آنالیز ایمیل، خیلی گسترده نشده است؟ در خصوص جمع‌آوریِ این نوع اطلاعات، چالش‌هایی وجود دارند. اجازه دهید نگاهی به یکی از رایج‌ترین سیستم‌های پیام‌رسانیِ ایمیلی در جهان، مایکروسافت اِکسچِینج سرور، بیندازیم.

ثبت وقایعِ پراکنده

اولین چالشی که پیشِ روی جمع‌آوری داده‌ها از اِکسچِینج قرار دارد این است که سازمان‌ها معمولاً بیش از یک اِکسچِینج سرور دارند. برای مثال، ممکن است بانک بزرگی بیش از ۶۰۰ هزار کارمند داشته باشد، و برای سازگاری با آن همه حساب و حجم بزرگی از تراکنش‌های ایمیلی‌ای که روزانه اتفاق می‌افتند، ممکن است این شرکت از چندین اِکسچِینج سرور در هر مکان استفاده کند. مایکروسافت هیچ سازوکارِ متمرکزی برای ثبت وقایع ارائه نمی‌کند، در نتیجه جمع‌آوری و پیکربندی باید در تمامِ این سرور-بنیان‌ها انجام شود. شکل ب.۸ بخش پیکربندیِ کنسولِ اِکسچِینج سرور اَدمین را به تصویر می‌کشد. دو گزینه در دسترس هستند: فعال‌سازیِ ردیابی پیام و فعال‌سازیِ ثبت وقایعِ عنوان.

برای این‌که اِکسچِینج ثبت وقایعِ ردیابی را بنویسد، باید گزینه‌ی ردیابی پیام را فعال سازید. برای اطمینان از جمع‌آوریِ صددرصدیِ داده‌ها، ردیابی خط عنوان نیز باید فعال شود.

چیزی که چالش جمع‌آوریِ اِکسچِینج را بیش‌تر می‌کند، این است که هر سروری در فهرست خاصی می‌نویسد. همچنان که بیان شد، مایکروسافت ثبت وقایع متمرکزی ارائه نمی‌کند، از این رو هر نوع جمع‌آوری‌ای باید از هر کدام از سرورها صورت گیرد، یا فایل‌های ثبت وقایع باید در فهرستی اشتراکی نوشته شوند. به‌هنگام استفاده از فهرست‌های اشتراکی، ممکن است مشکلاتی بروز پیدا کنند مانند موضوعات امنیتی، دسترسی، و مصرف پهنای باند که از حجم بالای پیام‌هایی ناشی می‌شود که ثبت می‌شوند.

علاوه بر این، نیاز به سازوکاری برای جمع‌آوری است که امکانِ چرخشِ ثبت وقایع را درک و از آن پیروی کند، امکانی که به‌عنوان قسمتی از ردیابیِ پیام اِکسچِینج پیکربندی می‌شود. اگر فرآیند خودکاری، ثبت وقایعی را که نوشته می‌شوند، جمع‌آوری می‌نماید، باید بتواند به‌عنوان قسمتی از چرخش ثبت وقایع، اقدام به تغییر نام فایل و نوشتن فایل جدیدی به آن نماید.

شکل ب.۸ کنسول اِکسچِینج سرور اَدمین

حجم رخداد

ردیابی پیام اِکسچِینج، به ازای هر ایمیل فرستاده‌شده بیش از هشت پیام تولید می‌کند. از آنجا که این ثبت وقایع می‌تواند به‌عنوان امکانی برای اشکال‌زدایی استفاده شود، پیامی در هر گام از فرآیندِ تحویلِ ایمیل ثبت می‌شود. جدول ب.۱ نمونه‌ای است از برخی از رخدادهایی که تولید می‌شوند. برای دسترسی به اطلاعات بیش‌تر در خصوصِ رخدادهایی که اِکسچِینج می‌تواند تولید کند، از وب‌گاه مایکروسافت تِک‌نت، http://support.microsoft.com/kb/821905، بازدید نمایید.

جدول ب.۱ رخدادهای تولیدشده به‌هنگامِ تحویل ایمیل

شماره‌ی رخداد	نام رخداد	توضیح رخداد
۱۰۱۹	واگذاری پیام به AQ از SMTP	پیام جدیدی به صف‌بندیِ پیشرفته (AQ) واگذار می‌شود.
۱۰۲۰	اقدام به انتقال به‌خارجِ SMTP	پروتکل انتقال میل ساده (SMTP) خود را آماده‌ی ارسالِ پیامی از طریق سیم می‌کند.
۱۰۲۱	SMTP بد-میل	پیام به پوشه‌ی بدمیل انتقال داده شد.
۱۰۲۲	ایجاد اشکال در SMTP AQ	خطای وخیمی در صف‌بندی پیشرفته رخ داد.
۱۰۲۳	تحویل محلیِ SMTP	درایور ذخیره‌سازی (SD) باموفقیت پیامی را تحویل داد.
۱۰۲۴	واگذاری پیام به دسته‌بند از SMTP	صف‌بندی پیشرفته پیامی را به دسته‌بند واگذار کرد.
۱۰۲۵	اقدام به واگذاری پیام از SMTP	پیام جدیدی به صف‌بندی پیشرفته واگذار شد.
۱۰۲۶	اشکالِ SMTP AQ در پیام	صف‌بندی پیشرفته نمی‌تواند پیام را پردازش کند.
۱۰۲۷	واگذاری پیام به SD از SMTP	عاملِ انتقال میل (MTA) پیامی را به درایور ذخیره‌سازی واگذار کرد.
۱۰۲۸	تحویل محلیِ SMTP SD	درایور ذخیره‌سازی پیامی را باموفقیت تحویل داد (ثبت‌شده به‌وسیله‌ی درایور ذخیره‌سازی).
۱۰۲۹	تحویل دروازه‌ی SMTP SD	درایور ذخیره‌سازی پیام را به MTA انتقال داد.
۱۰۳۰	SMTP NDRِ همه	تمام گیرنده‌ها یک NDR فرستادند.
۱۰۳۱	انتقالِ به‌خارجِ نهاییِ SMTP	پیام خارج‌شونده باموفقیت انتقال داده شد.

حجم بالای رخدادهای تولیدشده به ازای هر ایمیل، تنها عاملی نیست که بر تعداد رخدادهای تولیدشده‌ی اِکسچِینج تأثیرگذار است. همچون اغلبِ سازمان‌ها، اگر شما نیز دارای چندین اِکسچِینج سرور باشید، هر سروری که پیام از درون آن رد شود، تعداد رخدادهای یکسانی را تولید خواهد کرد. برای کاهش مقداری از حجم رخداد، سازوکار جمع‌آوریِ شما باید بتواند برخی از اغتشاش‌ها را فیلتر کند. به‌هنگامِ آنالیز رخدادهای اِکسچِینج، معمولاً بهینه این است که تمام رخدادها به‌جز شماره‌ی رخداد ۱۰۲۸ را فیلتر کرد، این شماره رخدادی است که وقتی پیام ایمیلی‌ای تحویل داده شده، تولید شده است. فیلتر کردن تا حدّ این شماره رخداد، اغتشاش را دستِ‌کم تا یک‌هشتم کاهش می‌دهد. این موضوع فقط در خصوص اِکسچِینج صادق نیست. در جهانِ Sendmail، به ازای هر ایمیلی که فرستاده یا دریافت می‌شود، دستِ‌کم دو رخداد در هر سرور نوشته می‌شود. این تعداد به زیادیِ هشت پیام به ازای هر ایمیل نیست، اما باز هنوز می‌تواند فیلتر شود.

قالب فایل ثبت وقایع

زمانی که جمع‌آوری به‌خوبی در حال انجام باشد، پیام مربوطه باید آنالیز گردد و مقادیر مربوطه باید در حوزه‌های نرمال‌شده‌ی خود نگاشته شوند. فایل زیر رخدادهایی را در قالبی خام نشان می‌دهد که زمانی نوشته شده‌اند که یک ایمیل از طریق اِکسچِینج فرستاده می‌شود:

هر پیامی که در فایل ثبت وقایعِ بالا آمده است، حاویِ اطلاعاتی است که باید به‌صورت الگویی نرمال‌شده نگاشته شوند. رویّه‌ی معمول این است که به مستندسازیِ فروشنده رجوع شود تا توضیحی برای حوزه‌های رخدادِ غیربدیهی به‌دست آورد. جدول ب.۲ مثال‌هایی از توضیحات خلاصه برای این حوزه‌ها ارائه می‌کند که مطابق با چیزی است که مایکروسافت تهیه کرده است.

جدول ب.۲ حوزه‌های رخداد و توضیحات

حوزه	توضیح
date-time	تاریخ و زمانِ رخداد ردیابی پیام. مقدارِ آن دارای قالبی به‌صورت yyyy-mm-ddhh:mm:ss.fffZ است، که yyyy = سال، mm = ماه، dd = روز، hh = ساعت، mm = دقیقه، ss = ثانیه، fff = کسری از ثانیه، و Z نشانگرِ زولو (Zulu) است، که روش دیگری برای نمایش UTC است.
server-ip	آدرسِ پروتکل کنترل انتقال/پروتکل اینترنت (TCP/IP)ِ اِکسچِینج سرورِ مبدأ یا مقصد
server-hostname	نام اِکسچِینج سروری که مدخلِ ثبت وقایعِ ردیابی پیام را ایجاد کرده است. این نام معمولاً نام اِکسچِینج سروری است که فایل‌های ثبت وقایعِ ردیابی پیام را نگاه می‌دارد.
recipient-address	آدرس‌های ایمیلِ گیرندگان پیام. چند آدرس ایمیل به‌وسیله‌ی نقطه‌ویرگول از هم جدا می‌شوند.
total-bytes	اندازه‌ی پیامی که شاملِ پیوست‌هایی است، برحسب بایت.
recipient-count	تعداد گیرندگانِ موجود در پیام.
message-subject	عنوان پیام، همان چیزی که در حوزه‌ی سرعنوان پاراگراف دوم Subject: است.
sender-address	آدرس ایمیلِ مشخص‌شده در حوزه‌ی سرعنوان پاراگراف دوم Sender:، یا در صورت عدم حضورِ Sender:، حوزه‌ی سرعنوان پاراگراف دوم From:.

از فایل‌های ثبت وقایع تا ESM

زمانی که داده‌ها باموفقیت جمع‌آوری، نرمال، و به سکوی ESM منتقل شدند، می‌توان اقدام به آنالیز و همبستگی کرد. شکل ب.۹ از منظرِ کنسول ArcSight رخدادهای ردیابی پیامِ اِکسچِینج را در زمانی نشان می‌دهد که آن رخدادها پردازش شده و به تحلیل‌گری امنیتی ارائه شده‌اند.

رخدادهای ایمیلی منبع فوق‌العاده‌ای از اطلاعات هستند. آن‌ها نه تنها به‌عنوان روشی برای ردیابی این‌که چه‌کسی با چه‌کسی صحبت می‌کند و چه اطلاعاتی از سازمان خارج می‌شود، مفید هستند، بلکه به آنالیز دیداری نیز توجه دارند. با ایجاد نمودارهای رخدادی که نشان‌دهنده‌ی ترافیک فرستنده-گیرنده هستند، به‌همراهِ عنوان پیام ایمیلی به‌عنوان نقطه‌ی اتصال، به‌آسانی می‌توان دید که فلان کاربر با چه‌کسی ارتباط برقرار می‌کند و چند نفر این ارتباطات را دریافت کرده‌اند.

شکل ب.۹ رخدادهای ردیابی پیام اِکسچِینج پس از پردازش، آنچنان که در کنسول ArcSight نشان داده است

منبع: ArcSight ESM v4.0

اما، از آنجا که ترافیک ایمیلیِ اغلبِ سازمان‌ها معمولاً میلیون‌ها ایمیل در هر روز است، اقدام به بازبینیِ دستیِ پیام‌ها و مرورِ آن‌ها به‌وسیله‌ی نمایی از نوع کانالی، آنچنان که در شکل ب.۹ نشان داده شده است، چندان کارآمد نیست. خیلی راحت‌تر است که این رخدادها را در قالب نمایش دیداری مشاهده کرد. شکل ب.۱۰ نمودار رخدادی از ترافیک ایمیلیِ یک کاربر را نشان می‌دهد. جعبه‌ی سیاه در وسط تصویر، همان فرستنده است، حلقه‌های اتصال‌دهنده‌ی خاکستری، عنوان‌های ایمیل هستند، و جعبه‌های سفید گیرندگان هستند. کاربر ایمیلی با عنوانِ «new project» به پنج کاربر دیگر؛ ایمیلی به مدیرش؛ و ایمیلی به دوستی در یاهو.کام می‌فرستد. یکی از جالب‌ترین موارد استفاده‌ی آن، زیر نظر گرفتن تمام ترافیکی که عازمِ حساب‌های وب‌میل است و بررسی وسعت نشت‌های اطلاعاتی احتمالی است.

شکل ب.۱۰ نمودار رخدادِ ایمیلِ یک کاربر

منبع: ArcSight ESM v4.0

شکل ب.۱۱ نمایی جزئی از رخداد ایمیل

منبع: ArcSight ESM v4.0

شکل ب.۱۱ نمای جزئی‌تری از رخداد ایمیلی را نشان می‌دهد. حوزه‌هایی که معمولاً بیش از همه به‌کار می‌روند حوزه‌ی پیام است که عنوان ایمیل نگاشته می‌شود؛ و حوزه‌ی بایت‌های درون/بیرون که در آن می‌توانیم حجم پیام را مشاهده نماییم. همچنان که پیش از این اشاره شد، حجم ایمیل در انجام آنالیز بسیار به کار می‌آید. اگر شما همواره حجم پیام‌ها را در یک موتور تحلیل آماری قرار دهید، می‌توانید حجم متوسط ایمیل را به ازای هر کاربر و نیز مقدار کلّی آن را مشخص سازید. این امر به شما این امکان را می‌دهد که انحرافات بزرگ را تحت نظارت و بازپرسی قرار دهید. در این شکل، فرستنده و گیرنده به حوزه‌های نام کاربریِ مهاجم و هدف نگاشته می‌شوند، و این‌ها برای انجام هرگونه آنالیز مبتنی بر کاربر الزامی هستند. در نهایت، تعداد گیرنده‌ها به شما این امکان را می‌دهد تا ایمیل‌هایی را که به مخاطبان وسیعی فرستاده شده‌اند، ردیابی کنید.

مجالی برای به‌بود

احتمالاً مایکروسافت چنین قصدی نداشته است که گروه‌های امنیتی، فایل‌های ثبت وقایعِ ردیابی پیامِ اِکسچِینج را جمع‌آوری و آنالیز کنند، از این رو راحت‌ترسازیِ انجام جمع‌آوری و تحلیل، قسمتی از ضوابط این محصول نبوده است چرا که این فایل‌های ثبت وقایع با هدفِ اشکال‌زدایی ایجاد شده‌اند. با درنظر گرفتن این موضوع، مایکروسافت می‌تواند در چندین زمینه به‌بودهایی را ایجاد کند. یکی از این به‌بودها می‌تواند افزودنِ سازوکاری یک‌پارچه برای ثبت وقایع باشد. با در اختیار داشتنِ جمع‌آوری‌کننده‌ی متمرکزی برای ثبت وقایع، دیگر نیازی به اتصال به هر کدام از اِکسچِینج سرورها برای جمع‌آوری پیام‌ها، و کپی گرفتن از رخدادها به‌هنگامِ عبور پیام از هر کدام از سرورها نخواهد بود. در این صورت، نیاز چندانی نیز به بازگشاییِ اشتراک‌های شبکه‌ای یا نصب اتصال‌دهنده روی هر کدام از اِکسچِینج سرورها نخواهد بود. هم‌چنین، در اختیار داشتن سطوح مختلفی از ثبت وقایع می‌تواند مفید باشد. اگر تمام چیزی که شما باید انجام دهید همان ردیابیِ ایمیل‌های فرستاده و دریافت‌شده باشد، خوب است که ثبت وقایع را برای تمام اجزای دیگر خاموش سازید. اما، مهم‌ترین به‌بود، تواناییِ ثبتِ نام پیوست‌ها است. خوب می‌شد اگر می‌توانستیم پیوست واقعی‌ای را که همراه با ایمیل فرستاده شده است، ببینیم. این همان امکانی است که فایل‌های ثبت وقایع فاقدِ آن هستند. اگر این کارکرد وجود داشت، می‌شد دید که چه نوع اسنادی از سازمان خارج و به گروه‌های دیگر فرستاده شده‌اند. افزونه‌ی جزئیِ دیگری که می‌توان برای مایکروسافت درنظر گرفت این است که بتوانیم امضایی در سیستم آشکارسازی نفوذِ خود بنویسیم که نام پیوست را تحلیل نماید.

علاوه بر اِکسچِینج، Sendmail نیز نام پیوست‌ها را ثبت نمی‌کند. ما نتوانستیم از هیچ یک از این فروشندگان اظهارنظری بیابیم دال بر این‌که آن‌ها این قابلیت را در نسخه‌های بعدیِ محصولات خود خواهند گنجاند، یا حتی انجام چنین کاری را درنظر گرفته باشند. همه باید با فروشنده‌ی میل‌سرورِ خود تماس بگیرند و این پیام را به گوش آن‌ها برسانند که این اطلاعات بسیار مهم هستند و حتماً باید در نسخه‌های آینده آورده شوند. همچنان که پیش از این اشاره شد، سیستم‌های ILP‌ی وجود دارند که بر ایمیل‌ها به‌هنگام عبور از شبکه نظارت می‌کنند. چنین محصولاتی می‌توانند نام پیوست‌های ایمیل‌های فرستاده‌شده را ارائه دهند، منتها آن‌ها نیز مشکلات خاص خود را دارند. هم‌چنین، تغییر نام پیوست کار آسانی است، که در نتیجه جایی که محتوای واقعیِ پیوست موردِ آنالیز قرار می‌گیرد باید بازرسی و بازبینیِ دقیقی انجام داد. در سازمان‌های بزرگ با مقادیر عظیمی از ترافیکی که باید بازرسی شود، سروکار داریم که می‌تواند هزینه‌ی سنگینی به‌لحاظ افزاره‌ای تحمیل نماید.

ایمیل، فن‌آوریِ فوق‌العاده‌ای برای ارتباطات است. این فن‌آوری به کاربرانِ درون سازمان‌ها امکان می‌دهد تا بهره‌ورانه ورای مناطق زمانی ارتباط برقرار کنند، و به دوستان این امکان را می‌دهد که با هم در تماس باشند. فقط لحظه‌ای تصور کنید هر بار که ایمیلی را می‌فرستید مجبور بودید که واقعاً تلفن را بردارید تا آن پیام تحویل داده شود. اما، هیچ کاری لازم نیست انجام دهید. با وجودِ تمام این تسهیلات، ما هزینه‌ای را پرداخت می‌کنیم؛ خطر امنیتی‌ای که در این خصوص وجود دارد، بنابراین، باید اقداماتی احتیاطی‌ای، مانند نظارت، را موردِ توجه قرار دهیم.

صورت از طریق IP

حالا نوبت به جمع‌آوریِ فایل‌های ثبت وقایعِ VoIP می‌رسد. VoIP راهی برای ارسال صوت از طریق شبکه‌ی استاندارد IP است. کدگذارها و کدگشاهای صوت برای تبدیل صوت به بسته‌های IP به‌کار می‌روند، بسته‌هایی که می‌توانند از طریق شبکه فرستاده شوند. پروتکل آغازه‌ی جلسه (SIP) بر مسیریابی و مدیریت تراکنش‌های VoIP نظارت می‌کند. سیستم‌های تلفنیِ VoIP هر روز بیش از پیش رایج می‌شوند. آن‌ها در اغلبِ سازمان‌های بزرگ حضور دارند و حتی کم‌کم به هتل‌ها و بازارهای مصرف‌کننده رسیده‌اند. سیستم‌های VoIP چیزی به نام ثبت جزئیات تماس (CDR) را تولید می‌کنند که در واقع مدخلِ ثبت وقایعی است که بیان می‌کند تماسی گرفته یا دریافت شده است. ردیابی تماس‌های تلفنی، یکی از عناوین داغِ چند وقت اخیر بوده است، هم‌چنین جمع‌آوریِ CDRها از شرکت‌های تلفن بزرگ تعرض به حریم شخصی درنظر گرفته شده است، اما در بخش‌های خصوصی و عمومی، معمولاً موافقت‌نامه‌ای امضا می‌شود که بیان می‌کند تمام فعالیت‌های مرتبط با IP می‌توانند نظارت شوند و خواهند شد تا مواردِ سوءاستفاده کشف گردند. به‌سختی می‌توان گفت که آیا CDRها باید به‌عنوان امنیت منطقی درنظر گرفته شوند یا امنیت فیزیکی، اما به‌نظر می‌رسد که می‌شود هر دوی آن‌ها را درنظر گرفت یا هیچ‌کدام را درنظر نگرفت. ما سوابق تلفنی را به‌عنوان ترکیبی از آن دو درنظر می‌گیریم.

اجازه دهید برای درک ثبت وقایعِ VoIP، با مثال ساده‌ای از نحوه‌ی وقوع تماسی تلفنی آغاز کنیم. شکل ب.۱۲ فن‌آوری معمولِ VoIP را به تصویر می‌کشد. تماس از صادرکننده شروع می‌شود و به سوی دروازه‌ی پیش‌فرضِ تلفن مسیردهی می‌شود، که این دروازه در جهانِ VoIP با نام سرور سیگنال‌دهی شناخته می‌شود. سرور سیگنال‌دهی مسئولِ نصب و جداسازیِ تماس‌ها  است. سپس، سرور سیگنال‌دهی آن تماس را به سوی سرور تماس مسیردهی می‌کند که این سرور، نرم‌افزاری را اجرا می‌کند که توابع کنترل تماس مانند حسابداری و مدیریت، تبدیل پروتکل، و تنفیذ را اجرا می‌کند. سپس، این سرور تماس، تماس مربوطه را به سوی سوئیچ VoIP روانه می‌کند که یا تماس را به بیرون می‌فرستد یا مسیرِ آن را به سوی تلفن داخلیِ دیگری برمی‌گرداند.

در VoIP، با صدای صوتِ شما به‌عنوان داده رفتار می‌شود. صدا تبدیل به بسته‌هایی می‌شود و درست مانند بسته‌های IPی معمولی در شبکه به گردش درمی‌آید. در این‌جا نیز مسیریاب‌ها و سوئیچ‌هایی وجود دارند، منتها تفاوت در این‌جا است که یک مشکل ساده‌ی تأخیری، دانلود شما را کند نمی‌کند؛ این مشکل خدمات VoIPِ شما را غیرقابل‌استفاده می‌کند، شرایطی که مشهور به عصبیّت است. احتمالاً پیش از این نیز چنین چیزی را تجربه کرده‌اید، که انگار فردی که در حال صحبت با او هستید در سیاره‌ی دیگری قرار دارد. شبکه‌ی VoIP از اجزای دیگری مانند دروازه‌های رسانه‌ای که تبدیل پروتکل را مدیریت می‌کنند یا اجزایی تشکیل شده است که متن را به صوت تبدیل می‌کنند. برای دستیابی به اطلاعات بیش‌تر در خصوص کارکردهای داخلیِ VoIP از آدرس www.protocols.com/pbook/VoIPFamily.htm بازدید نمایید که مطالب مقدماتیِ فوق‌العاده‌ای در خصوص اجزا و پروتکل‌های مربوطه در آنجا خواهید یافت.

شکل ب.۱۲ فن‌آوری ساده‌ی VoIP

مزایای یک‌پارچه‌سازی

همچون ردیابی هر نوع ارتباطاتی، نظارت بر فایل‌های ثبت وقایعِ VoIP نیز اطلاعات جلسه‌ایِ مقدماتی‌ای مشابه با نظارت بر ترافیک ایمیلی ارائه می‌کند. این اطلاعات که معمولاً در قالب CDR ارائه می‌شوند، آغازگر تماس، گیرنده، و مدت زمان تماس هستند. اگر CDRها را با رخدادهای ایمیلی مقایسه کنیم، می‌توانیم مدت زمان را معادل با اندازه‌ی پیام یا مقدار اطلاعاتی درنظر گیریم که طی ارتباط مربوطه مبادله شده است. کاربردهای ابتداییِ آن، نظارت بر بالاترین صحبت‌کنندگان یا نظارت بر این خواهد بود که چه‌کسی با چه‌کسی صحبت می‌کند و چه اوقاتی از روز این تماس‌ها صورت می‌گیرند. یکی از کاربردهای جالبِ فایل‌های ثبت وقایع VoIP، نظارت بر استفاده در ساعت‌های تعصیل است، منظور افرادی هستند که در تعطیلات آخر هفته یا نصفه‌شب به دفتر می‌آیند تا تماس‌های شخصیِ راه دور بگیرند.

کاربردهای پیشرفته‌ترِ آن، ساخت نمودارهایی رابطه‌ای است که تمام افرادی را که از گروه‌های متفاوت با هم ارتباط برقرار می‌کنند، نشان می‌دهند. برای مثال، در جامعه‌ی اطلاعات امنیتی، افرادی با دانش جزءبندی‌شده وجود دارند که نباید این اطلاعات را با دیگر افرادی به اشتراک بگذارند که دانش جزءبندی‌شده‌ی متفاوتی دارند. به‌نظر می‌رسد که نظارت بر تماس‌های تلفنیِ بین افراد، برای برخی از بخش‌های طبقه‌بندی‌ترشده‌ی صنعت بسیار جذاب است. در خصوص کاربردِ موردبحث ما در این پیوست، فایل‌های ثبت وقایعِ VoIP نقش کلیدی‌ای در سازوکار آشکارسازیِ پیشنهادی بازی می‌کنند. نظارت بر تماس‌های تلفنیِ بین کاربرانی که نباید به‌طور مداوم با هم ارتباط برقرار کنند، ناهنجاری‌هایی مانند حجم بالای تماس‌های بین کاربران و مدت زمانِ تماس راه دور را آشکار نخواهد کرد. این نوع رفتار، اگرچه ممکن است عادی باشد و از روی بدخواهی نباشد، می‌تواند نشانی بر این باشد که کاربری باید موردِ بازپرسیِ بیش‌تری قرار گیرد.

چالش‌های یک‌پارچه‌سازی

سیستم‌های VoIP از آغاز با درنظر داشتنِ ثبت وقایعِ CDR طراحی شده‌اند. اگر نه همه، اغلبِ سرورهای تماس این قابلیت را دارند که تماس‌های گرفته و دریافت‌شده را ثبت کنند. این ثبت وقایع با درنظر گرفتنِ تحلیل‌گر امنیتی طراحی نشده است؛ هدف اصلیِ آن، صدور صورت‌حساب است. اگر هیچ ثبت وقایعی وجود نداشت، خدمات‌دهندگان نمی‌توانستند برای تماس‌هایی که قرار داده یا دریافت می‌شوند، هزینه‌ای مطالبه کنند.

سرورهای تماس CDRها را در فایل‌های متنیِ محلی می‌نویسند، اما این، مکان ایده‌آلی برای جمع‌آوری آن‌ها نیست. سرورهای تماس معمولاً بسته‌ی نرم‌افزاریِ مدیریتی‌ای دارند که به‌طور مستقیم به درگاهِ پروتکل کنترل انتقال (TCP) روی هر کدام از سوئیچ‌ها متصل می‌شود، جایی که این فایل‌های ثبت وقایع همواره در حالِ جریان هستند (مشابهِ ثبت وقایع سیستمی). پس از این‌که جمع‌آوری می‌شوند، در پایگاه‌داده‌ای قرار داده می‌شوند که در آنجا می‌توان آن‌ها را برای صدور صورت‌حساب و اطلاعات کاربردی موردِ آنالیز قرار داد. این موضوع برای یک‌پارچه‌سازی با ESM بسیار عالی است، چرا که انباشته‌سازانِ ثبت وقایع، دوستان ما هستند. از آنجا که فایل‌های ثبت وقایع از قبل انباشته و جمع‌آوری شده‌اند، تمام آن چیزی که مورد نیاز است یک اتصال‌دهنده برای اتصال به یک سیستم است تا تمام تماس‌های ثبت‌شده از تمام سوئیچ‌هایی که به‌وسیله‌ی برنامه‌ی مدیر تلفن مدیریت می‌شوند، کسب شوند.

گام بعدی برای یک‌پارچه‌سازی با محصولاتِ VoIP پیکربندی است، که به هیچ وجه کار دشواری نیست. فعال‌سازیِ CDRها برای تماس‌های خارجی‌به‌داخلی و تماس‌های داخلی‌به‌خارجی معمولاً در اغلبِ سیستم‌ها پیش‌فرض است. در سیستمِ نورتِل که در جدول ب.۳ به تصویر کشیده شده است، می‌توانید به‌آسانی پیکربندیِ شاه‌سیم‌ها را نشان دهید و ببینید که ثبت وقایعِ CDR فعال است.

جدول ب.۳ پیکربندیِ شاه‌سیم در سیستم نورتِل

فعال بودنِ ثبت وقایعِ CDR	پیکربندی پیش‌فرض

با این فرض، این موضوع خیلی چالش‌برانگیز نیست. قسمت چالش‌برانگیز، پیکربندیِ ثبت وقایع تماس داخلی‌به‌داخلی است. اغلبِ سیستم‌های تلفنی به‌طور پیش‌فرض این تماس‌ها را ثبت نمی‌کنند، چرا که ارتباطی به صدور صورت‌حساب ندارند. برای ثبت این داده‌ها، باید جزئیات تماس داخلی (ICD) فعال گردد. در سیستم‌های نورتِل، این تنظیمات به‌طور پیش‌فرض روی ICDD (غیرفعال بودن جزئیات تماس داخلی) تنظیم هستند. جدول ب.۴ نشان می‌دهد که در صورت فعال بودنِ ICD، پیکربندی مربوطه در سیستم نورتِل چگونه باید باشد.

جدول ب.۴ پیکربندی در سیستم نورتِل، زمانی که ICD فعال است

فعال بودنِ ICDA	پیکربندی پیش‌فرض

قالب فایل ثبت وقایع

قالب ثبت وقایع در سیستم‌های VoIP معمولاً بسیار ساده است و حاویِ حوزه‌های زیادی نیست که مرتبط به ESM باشند. حوزه‌هایی که به کارِ آنالیز می‌آیند، حوزه‌های آغازگر تماس، گیرنده، و مدت زمان تماس هستند. نمونه فایل زیر از یک سسیستم نورتِل است:

خط اول تماسی داخلی‌به‌خارجی را نشان می‌دهد که در ساعت ۱۷:۳۴ از داخلیِ ۲۶۰۰ به شماره‌ی ۱۲۱۲-۵۵۵-۴۱۵، به مدت ۳ دقیقه و ۱۸ ثانیه تماس گرفته شده است. خط دوم تماسی را نشان می‌دهد که از شماره‌ای خارجی با داخلیِ ۲۶۰۰ به مدت ۶ ثانیه گرفته شده است. خط سوم تماسی داخلی‌به‌داخلی را از داخلیِ ۲۶۰۰ به داخلیِ ۲۶۶۹ به مدت ۱ دقیقه و ۲ ثانیه نشان می‌دهد.

حوزه‌های مرتبط در فایل ثبت وقایعِ بالا، مبدأ تماس، مقصد، مدت، و شاه‌سیمی هستند که آن تماس از طریق آن عبور کرده است. شاه‌سیمی که تماس از طریق آن انجام شده است در آنالیز واقعی اهمیتی ندارد، اما برای آگاهی از واردشونده یا خارج‌شونده بودن تماس، مکانِ آن شاه‌سیم در خطِ فایل ثبت وقایع اهمیت دارد. در مثال قبلی، شاه‌سیم مقداری است که با T شروع می‌شود و پررنگ‌تر است. اگر شاه‌سیم پیش از شماره‌ی داخلی ظاهر شود، مثل خط دوم، تماسی واردشونده است؛ اگر شاه‌سیم پس از شماره‌ی داخلی ظاهر شود، تماسی خارج‌شونده است؛ و اگر شاه‌سیمی مشخص نشده باشد، آن تماس بین دو شماره‌ی داخلی برقرار شده است. هم‌چنین باید توجه داشت که این فایل‌های ثبت وقایع برای سرور تماسی هستند که تنها به یک پیش‌شماره خدمات می‌دهد. اگر شما سروری داشته باشید که به چندین پیش‌شماره خدمات دهد، شماره‌های داخلی به جای چهار رقم پنج رقم خواهند داشت.

از فایل‌های ثبت وقایع تا ESM

پس از تجزیه‌ی فایل‌های ثبت وقایع و ارسال رخدادها به سکوی ESM، آن‌ها آماده‌ی آنالیز و مقایسه با دیگر خوراک‌های رخداد هستند. به‌عنوان قسمتی از پردازشِ ثبت وقایعِ VoIP، نیاز به پردازشی است که مقادیر مربوطه را در حوزه‌های مناسب نگاشت کند. این امر به‌ویژه زمانی می‌تواند چالش‌برانگیز باشد که جایگذاریِ این مقادیر، معنای رخداد را تغییر دهد، همچنان که این موضوع در مورد موقعیتِ مقدارِ شاه‌سیم صادق است. علاوه بر این، از آنجا که این مورد منبعِ رخدادِ جدیدی است، شِمای آن همیشه حاویِ حوزه‌ای نیست که بتواند با مقداری مانند یک شماره تلفن سروکار داشته باشد. این امر نیازمندِ این است که حوزه‌ی جدیدی به سیستم بیافزاییم، یا از حوزه‌ای استفاده کنیم که بتوان آن را برای اختصاص به انواع مختلف مقادیر، به‌صورت ذخیره نگاه داشت.

در این مورد، بهترین کار این است که از حوزه‌ای که برای آدرس IP یا نام کاربری‌ای به‌کار گرفته شده است، سوءاستفاده نکنیم؛ بلکه، باید از حوزه‌ای استفاده کنیم که برای اختصاص به مقادیر دلخواه برای افزاره‌هایی مانندِ این به‌صورت ذخیره نگاه داشته شده است. شکل ب.۱۳ نشان می‌دهد که رخدادها به‌موازاتِ ورود به کنسول ArcSight ESM v4، به چشمِ تحلیل‌گر چگونه به‌نظر می‌رسند. به جهتِ هر کدام از رخدادها توجه کنید. تماس‌های داخلی‌به‌داخلی هیچ جهتی ندارند چرا که آن‌ها درون یک سیستم باقی می‌مانند. این امر بعدها در فرآیند آنالیز ما اهمیت خواهد داشت.

شکل ب.۱۳ چندین تماس گرفته‌شده و حوزه‌هایی را نشان می‌دهد که روی شِمای ESM نگاشته می‌شوند. در رخدادی که پُررنگ‌شده است، تماسی واردشونده از شماره‌ی ۱۲۱۲-۵۵۵-۵۱۰ به داخلیِ ۲۶۰۰ گرفته شده است. مدت زمان تماس ۱۹۸۰ ثانیه یا ۳۳ دقیقه بوده است. شکل ب.۱۴ نمایی دقیق از این تماس تلفنی را نشان می‌دهد.

شکل ب.۱۳ ArcSight ESM v4

منبع: ArcSight ESM v4.0

شکل ب.۱۴ نمایی دقیق از تماس نشان‌داده‌شده در شکل ب.۱۳

منبع: ArcSight ESM v4.0

حوزه‌های نمایش‌داده‌شده این‌ها هستند: نام رخداد؛ اولویت رخداد، که در این مورد ۲ است چرا که رخدادی عادی مشابه با پذیرش دیوار آتش است؛ جهت تماس؛ فروشنده‌ی محصولی که رخداد را تولید کرده است؛ آغازگر؛ گیرنده؛ مدت زمان؛ و شاه‌سیمی که تماس از طریق آن ایجاد شده است. بزرگ‌ترین چالش در این‌جا مدت زمان است. این حوزه از اهمیت زیادی در انجام آنالیز برخوردار است، و به شما این امکان را می‌دهد تا بالاترین صحبت‌کنندگان، بالاترین زوج‌های صحبت‌کننده، و گران‌قیمت‌ترین تماس‌های تلفنی را محاسبه نمایید. اگر فایل‌های ثبت وقایعِ خام را به یاد داشته باشید، مدت زمان در قالبی زمانی بود که به‌موجبِ آن، این تماس در این نمای جزئی باید مقداری برابر با ۲۲:۳۰، یا ۲۲ دقیقه و ۳۰ ثانیه داشته باشد. انجام هر نوع محاسبه‌ای روی این مقدار خام کاری بسیار دشوار است، از این رو این عدد باید به ثانیه تبدیل شود تا امکان اجرای توابعی روی آن مهیا گردد. در این مثال، ۲۲:۳۰ با تبدیل به سیستم عددیِ ده‌دهی برابر با ۲۲.۵ دقیقه می‌شود و سپس در ۶۰ ضرب می‌شود تا تعداد کلیِ ثانیه‌هایی که آن تماس به طول انجامیده است، به‌دست آید.

شکل ب.۱۵ آنالیزی تصویری از این تماس‌های تلفنی است. آغازگر تماس با جعبه‌های سیاه کوچک نشان دادده می‌شود؛ جهت تماس با حلقه‌های خاکستری نشان داده می‌شود؛ و مقصد یا گیرنده‌ی تماس با جعبه‌های سفید نشان داده می‌شود. این شکل چندین تراکنش را نشان می‌دهد. در سمت چپ، می‌توانید مشاهده کنید که سه تماس واردشونده با داخلیِ ۲۶۰۰ برقرار می‌گردند. نمودارِ سمت راست تمام تماس‌هایی را نشان می‌دهد که از داخلیِ ۲۶۰۰ گرفته شده‌اند: سه تماس خارج‌شونده و یک تماس داخلی‌به‌داخلی.

شکل ب.۱۵ آنالیز تصویریِ تماس‌های تلفنیِ بالا

منبع: ArcSight ESM v4.0

تصویرسازیِ داده‌های رخداد همیشه موجبِ سرعت گرفتن فرآیند آنالیز می‌شود. گفته می‌شود که یک تصویر ارزشی برابر با هزار خط ثبت وقایع دارد، و مشاهده‌ی تصویری از تماس‌های تلفنیِ گرفته‌شده و دریافت‌شده این گفته را تایید می‌کند. تعداد تماس‌های تلفنیِ گرفته‌شده و دریافت‌شده به‌وسیله‌ی سازمان‌های بزرگ در هر روز می‌تواند بالغ بر چند میلیون (یا دستِ‌کم صدها هزار) گردد. تلاش برای درکِ آن تماس‌ها در فایلی متنی در قالبی که پیش از این نشان داده شد، می‌تواند همچون کابوسی وحشتناک باشد. با استفاده از نمایش تصویریِ همان پیام‌ها، می‌توانیم به‌سرعت تماس‌های واردشونده و خارج‌شونده را از هم جدا کنیم، و نیز آغازگر تماس و گیرنده را مشخص نماییم.

اگرچه مثال‌های موجود در این پیوست شاملِ توضیح دقیقی از CDRهای VoIP و نحوه‌ی جمع‌آوریِ آن‌ها هستند، اگر نه در همه، در اغلبِ سیستم‌های تلفنیِ مبادله‌ی انشعاب خصوصی (PBX) سازوکارهای مشابهی برای ثبت وقایع وجود دارند. سیستم‌های پیشرفته‌تری مانند VoIP که قابل‌اطمینان‌تر و مقرون‌به‌صرفه‌تر هستند، کم‌کم در حال از دور خارج کردنِ سیستم‌های تلفنیِ PBX هستند. رخدادهایی که سیستم PBX می‌نویسد، با نام رخدادهای وضعیت تماس (CSEها) شناخته می‌شوند و دوباره پس از اتمامِ تماس تلفنی نوشته می‌شوند. رخدادهای وضعیت PBX حاویِ مقدار زیادی از همان اطلاعاتی هستند که سیستم VoIP در قالب CDR می‌نویسد- معمولاً آغازگر، گیرنده، و مدت زمان تماس.

امنیت منطقی معمولاً با رخدادهای تولیدشده از افزاره‌هایی سروکار دارد که این افزاره‌ها درون شبکه‌ی IPِ یک سازمان قرار گرفته‌اند. در گذشته، سیستم تلفنی کاملاً مجزا از شبکه‌ی IP بود، از این رو اگر هنوز چنین چیزی درنظر گرفته می‌شد، بیش‌تر در قلمروِ نظارت فیزیکی یا ارتباطاتی قرار می‌گرفت. هم‌اکنون با معرفیِ تلفن‌هایی که IP در آن‌ها فعال است، بیش‌تر در منطقه‌ای خاکستری قرار می‌گیرد که جمع‌آوریِ CDRها در این منطقه می‌تواند هم فیزیکی و هم منطقی درنظر گرفته شود. حالا که در حال گذر به بخش بعدی هستیم، به‌خاطر داشتنِ اطلاعاتی که می‌توانیم از طریق جمع‌آوری CDRها به‌دست آوریم، از اهمین زیادی برخوردار است. این رخدادها به‌خودیِ‌خود رخدادهای امنیتی نیستند، و نشان‌ددهنده‌ی هیچ خطاکاری‌ای نیستند، بلکه آمارهایی که آن‌ها ارائه می‌دهند، نقطه‌داده‌ی دیگری در اختیار تحلیل‌گران قرار می‌دهند تا در آشکارسازیِ اقدام به بازرگانیِ خودی از آن استفاده کنند.

پل زدن روی دیوار چین: آشکارسازی از طریق همگرایی

حالا که می‌دانیم دیوار چین چیست و از برخی مزایا و چالش‌های جمع‌آوری از منابع داده‌ی جدید برای آنالیز آگاهی داریم، سراغ سناریوی ساده‌ای خواهیم رفت که در آن دو کارمند برای بانک سرمایه‌گذاریِ بزرگی کار می‌کنند و خواهیم دید که چگونه نقشه‌ی آن‌ها برای بازرگانیِ دانشِ خودی کشف و آشکار می‌گردد. در آشکارسازیِ مشروط از چندین شیوه‌ی همبستگی، مانند همبستگی مبتنی بر نقش و آشکارسازیِ ناهنجاریِ آماری، استفاده خواهیم کرد. مثالی که ما در این پیوست استفاده می‌کنیم، در ارتباط با دو کاربر در یک بانک سرمایه‌گذاری است، اما مبنای نظری و سازوکار آشکارسازیِ آن می‌تواند در خصوص هر نوع سازمانی که باید سیلوهای اطلاعاتیِ آن مجزا از هم باشند، به‌کار رود. در حال حاضر، دوایر دولتی از این اصول و منابع داده استفاده می‌کنند تا بر ارتباطات کارمندان داخلی خود نظارت کنند. در چنین مثالی، دیگر این اطلاعات سرمایه‌گذاری نیست که جزءبندی می‌شود؛ مسئله خیلی جدی‌تر از این حرف‌ها است- داده‌ها در این‌جا می‌توانند مکان مأموران، هویت مأموران، یا مأموریت‌های پیشِ رو باشند، که در این‌جاها نمی‌توان هیچ قیمت مادی‌ای روی خطر سازش و تبانی گذاشت. در حال حاضر، این فن‌آوری در سراسر بازارهای عمودی به‌کار گرفته می‌شود، چرا که این اصول زیربنایی، رویّه‌های امنیتی خوبی هستند و از تبانیِ اطلاعات میان ادارات جلوگیری می‌کنند، اداراتی که ترکیبِ دانش‌های جزءبندی‌شده می‌تواند منجر به تبانی گردد.

توطئه

دِیوید و ماکسوِل برای مؤسسه‌ی مالی بزرگی، Finance123، کار می‌کنند. آن‌ها در ادارات متفاوتی کار می‌کنند: دیوید در اداره‌ی ادغام‌ها و اکتساب‌ها و ماکسول در اداره‌ی کارگزاری و بانک‌داری سرمایه‌گذاری کار می‌کند. از آنجا که ارتباط بین این دو اداره نشان‌دهنده‌ی نوعی تضادّ منافع است و مقررات تطابقی را نقض می‌کند، خط‌مشی‌های اکیدی به‌کار گرفته می‌شوند که ارتباط بین این ادارات را ممنوع می‌سازند. این خط‌مشی‌ها حتی تا جایی پیش می‌روند که ورودِ این کارمندان از یک ورودیِ یکسان به درون ساختمان را ممنوع می‌سازند. این خط‌مشی‌ها به‌طور شفاهی بیان می‌شوند، اما هیچ محدودیتی در این خصوص وجود ندارد که شما با چه کسی می‌توانید تماس بگیرید، به و از چه آدرسهای ایمیلی می‌توانید ارسال و دریافت داشته باشید، یا با چه کسی می‌توانید برای ناهار ملاقات داشته باشید. شوربختانه، برای Finance123، فن‌آوری و خط‌مشی‌ها همگام با یکدیگر نیستند. با این فن‌آوری نمی‌توان تمام خط‌مشی‌ها را پیاده ساخت؛ گاهی محدودیت‌های پرسنلی و تدارکاتی وجود دارند، و به قول معروف «جایی که خواستی باشد، راهی هست.» این موضوع به‌ویژه زمانی صادق است که انسان سعی می‌کند تا «سیستم» را دور بزند. بهترین چیزی که شما می‌توانید در این موقعیت به آن امیدوار باشید، سازوکار آشکارسازیِ اولیه‌ای است که از طریق علائم هشداردهنده، آشکارسازیِ ناهنجاری، و آنالیز بتواند پیش از وقوع مشکل، به کشف و متوقف ساختن آن کمک نماید.

ماکسول و دیوید، دسیسه‌چینان ما، می‌دانند که اطلاعاتی که آن‌ها در اختیار دارند، برای دیگری ارزشمند است. کافی است دیوید در خصوص اکتسابِ پیشِ‌رو اشاره‌ای به ماکسول کند تا ماکسول به تمام مشتریان خود توصیه نماید که در آن شرکتی که در آینده خریداری خواهد شد، سرمایه‌گذاری کنند. این موضوع هم برای ماکسول و هم برای دیوید خوب است؛ کارمزد آن‌ها افزایش می‌یابد و آن‌ها به چشمِ دیگران مانند فوقِ‌ستاره‌های مالی به‌نظر می‌آیند. این فعالیت دقیقاً همان چیزی است که دیوار چین برای جلوگیری از آن طراحی شده است. این سناریو نشان می‌دهد که چگونه رفتار ارتباطاتیِ دیوید و ماکسول موردتوجهِ تحلیل‌گران امنیتی قرار می‌گیرد، و از آن‌چه نقض مجموعه‌خط‌مشی‌های Finance123 و اقدام به بازرگانیِ خودی درنظر گرفته می‌شود، جلوگیری می‌نماید.

آشکارسازی

Finance123 از سیستم ESMِ پیشرفته‌ای استفاده می‌کند تا بر تهدیدهای خارجی نظارت کند و سوءاستفاده‌ی داخلی را آشکار سازد. این شرکت با جمع‌آوری رخدادها از این منابع داده‌ی غیرسنتی، می‌تواند بر ارتباطات داخلی نظارت کند و هم‌چنین رفتار ناهنجار کارمندان را آشکار سازد. این سیستم در واقع نمونه‌ای از صف‌آراییِ ESM است که از چندین جزء تشکیل شده است. شکل ب.۱۶ (از چپ به راست) افزاره‌های تولیدکننده‌ی داده‌ها، اتصال‌دهنده‌های ArcSight که داده‌ها را جمع‌آوری می‌کنند و به سیستم ESM می‌فرستند، مدیر ArcSight، و کنسول‌های تحلیل‌گر را نشان می‌دهد.

شکل ب.۱۶ اجزای سیستم ESM

ساخت دیوار چین

اولین گام مهم در آشکارسازی برای سکوی ESM است که باید از کاربران موجود در هر اداره آگاهی داشته باشد. می‌توان این موضوع را همبستگیِ مبتنی بر نقش نامید. بدون آگاهی از این‌که در هر اداره کدام یک از کاربران قرار دارند، آنالیز بی‌نهایت دشوار می‌شود و در آن صورت لازم است که تحلیل‌گر، کاربران مختلف و ادارات آن‌ها را به خاطر بسپرد. علاوه بر این، امکان ندارد که سکوی ESM بتواند ارتباطات ناهنجار میان گروه‌ها را بدون آگاهی از این‌که چه گروه‌هایی وجود دارند، آشکار سازد. از آنجا که بر ارتباطات میان‌اداره‌ای بین دو اداره نظارت می‌شود، برپایی این سیستم ساده است. تمام چیزی که سکوی ESM برای آگاهی از سازمان کاربر نیاز دارد، فهرستی از مشخصه‌های کاربر در هر اداره است. مشخصه‌ی کاربر هر مقداری، مانند نام کاربریِ ورود به حوزه، شماره‌ی داخلی، یا آدرس ایمیل، است که هویت کاربر معینی را مشخص می‌سازد.

در صورتی که مشخصه‌های کاربر معینی را بدانیم، می‌توانیم رخدادها را به آن کاربر همبسته سازیم و رخدادها را به او نسبت دهیم. با استفاده از فن‌آوریِ فهرست فعال در ESM، می‌توانیم این مشخصه‌ها را به‌آسانی ردیابی کنیم و رخدادها را با این فهرست‌ها همبسته سازیم، به‌ویژه می‌توان وجودِ رخداد ویژه‌ای را در یکی از این فهرست‌ها بررسی کرد. مثالی که می‌توان زد رخدادی است که به ESM فرستاده می‌شود که نام کاربریِ مبدأ، maxwellj@finance123.com، در فهرست فعال بررسی می‌شود تا تایید شود که آیا maxwellj@finance123.com از اعضای اداره‌ی کارگزاری هست یا نه. شکل ب.۱۷ دو فهرست فعالِ مبتنی بر نقش را نشان می‌دهد.

شکل ب.۱۷ فهرست‌های فعال مبتنی بر نقش

منبع: ArcSight ESM v4.0

در این دو فهرست فعال، دیوار چینِ مجازی‌ای برپا کرده‌ایم که سوابق مشخصه‌های کاربرِ هر اداره را نگاه می‌داریم. توجه داشته باشید که در فهرست فعال کارگزاری، چندین مدخل برای ماکسول وجود دارد. ما می‌توانیم آدرس ایمیل او، شماره تلفن داخلیِ او، و نام کاربریِ ورود به حساب حوزه‌ی ویندوزِ او را ببینیم. در فهرست ادغام‌ها و اکتساب‌ها در سمت راست، مشخصه‌های مشابهی برای دیوید وجود دارند.

پل زدن روی دیوار چین

همچنان که دیوید و ماکسول به اشتراک‌گذاریِ اطلاعات با یکدیگر ادامه می‌دهند، بدون توجه به این موضوع که می‌توانند تحت نظارت باشند، با استفاده از کانال‌های استاندارد ارتباط برقرار می‌کنند. اما، آن‌ها تحت نظارت هستند. تمام ارتباطات آن‌ها ردیابی می‌شوند، و از آنجا که تا اندازه‌ی قابل‌توجهی متناظر با هم بوده‌اند، رفتار آن‌ها اخطارهایی را در سیستم ESM ایجاد کرده است چرا که الگوهای آن‌ها ناهنجار هستند. سیستمی که برای آشکارسازیِ این ناهنجاری‌ها به‌کار گرفته شده است، سلسله‌ای از نظارت‌های داده‌ایِ میانگین متحرک است. نظارت‌های داده‌ای در مسیرِ گردشِ رخدادِ بی‌درنگ قرار می‌گیرند و آمار رخدادهایی را جمع‌آوری می‌کنند که واردِ سکوی ESM می‌شوند. نظارت‌های داده‌ایِ به‌کاررفته در این سناریو، برای جمع‌آوری اطلاعات از ارتباطات طراحی شده‌اند، ارتباطاتی که بین ادارت برقرار می‌گردند. ESM تمام اَشکالِ ارتباطاتی را بین کاربران موجود در دو فهرست فعال توصیف‌شده ردیابی می‌کند. اگر فرستنده‌ی ایمیل در فهرست فعال کارگزاری باشد و گیرنده در فهرست فعال ادغام‌ها و اکتساب‌ها، یا برعکس، این ارتباط ردیابی خواهد شد. هم‌چنین در خصوص تماس‌های تلفنی، اگر تماس‌زننده در یک فهرست باشد و داخلیِ مقصد در فهرست دیگری، این تماس ردیابی خواهد شد.

بنابراین، چرا در خصوص تمام ارتباطات بین ادارات اخطار داده نشود؟ ممکن است دلایل تجاریِ قابل‌قبولی برای برخی از اَشکالِ ارتباطات وجود داشته باشد، اما اگر شما تمام ایمیل‌هایی را که بین ادارات فرستاده می‌شوند یا تمام تماس‌های تلفنی گرفته‌شده را زیر نظر بگیرید، نیاز به گروهی چندصد نفره از تحلیل‌گران خواهید داشت. این امر دلیلی است بر این‌که به‌دنبالِ ناهنجاری‌ها می‌گردیم؛ هم‌چنین کاربرانی که هرگز قبلاً با هم ارتباطی نداشته‌اند یا کاربرانی که الگوهای رفتاری‌ای از خود نشان می‌دهند که بیرون از دایره‌ی ارتباطات به‌هنجار قرار می‌گیرند.

چهار نظارت داده‌ایِ مختلف در این سناریو به‌کار گرفته می‌شوند. اولی ردیابیِ تعداد ایمیل‌هایی است که بین کاربرانِ دو اداره فرستاده شده‌اند. شکل ب.۱۸ چندین گروه از زوج‌های فرستنده/گیرنده را نشان می‌دهد که از ادارات مختلف با هم ارتباط برقرار می‌کنند. تعداد ایمیل‌های فرستاده‌شده از ماکسول به دیوید و از دیوید به ماکسول بسیار بالاتر از تعدادی است که از سوی اغلبِ کاربران در آن سازمان فرستاده شده‌اند. آن‌ها تنها کاربرانی نیستند که بین آن ادارات با هم ارتباط برقرار می‌کنند، اما آن‌ها تنها دو نفری هستند که به‌نظر می‌رسد به‌گونه‌ای به ایمیل یکدیگر پاسخ می‌دهند که هر دو هم به‌عنوان فرستنده و هم گیرنده ظاهر می‌شوند. دو گرهِ دیگر در نظارت داده‌ای، فقط به اداره‌ی دیگر ایمیل فرستاده‌اند.

نظارت داده‌ای در این شکل تعداد ایمیل‌هایی را نشان می‌دهد که بین زوج فرستنده و گیرنده‌ی فرضی از ادارات متفاوت در طول زمان ردّوبدل شده‌اند. هر بازه‌ی زمانی ۲۴ ساعت است. محور افقی نشان‌دهنده‌ی زمان است- در این مورد، روزها- و محور عمودی تعداد ایمیل‌ها را نشان می‌دهد. بخش بزرگ‌شده نشان می‌دهد که ماکسول در ۱۱ روز گذشته، به‌طور متوسط در هر روز هشت ایمیل به دیوید فرستاده است. این مقدار ارتباط ردّوبدل‌شده، برای دو کاربر که در واقع هیچ ارتباط تجاری‌ای با هم ندارند، بسیار قابل‌توجه است. خط موجود در وسط نمودار، متوسط متحرک را نشان می‌دهد.

شکل ب.۱۸ گروه‌هایی از زوج‌های فرستنده/گیرنده که در حال ارتباط بین ادارات هستند

منبع: ArcSight ESM v4.0

فردی با توجه به نمودار می‌تواند این‌گونه نتیجه بگیرد که ایمیل‌های اولیه‌ای که از ماکسول به دیوید فرستاده شده‌اند کمتر از هشت ایمیل در روز بوده است چرا که متوسط در حالِ افزایش است، و تعداد ایمیل‌های فرستاده‌شده از ماکسول به دیوید در دو روزِ گذشته کاهش یافته است؛ بنابراین، مقدار متوسط به‌تدریج شروع به کاهش می‌کند. گرهِ موجود در سمت راست بالا، تعداد ایمیل‌هایی را نشان می‌دهد که دیوید به ماکسول فرستاده است و باز متوسط در حالِ افزایش است. این امر احتمالاً بیش‌تر به این دلیل است که وقتی ایمیل‌های ماکسول به دیوید افزایش می‌یابند، دیوید نیز بیش‌تر به ماکسول پاسخ می‌دهد، یا برعکس. قسمت پایین-چپ بالاترین زوج فرستنده گیرنده‌ی بعدی در سازمان را نشان می‌دهد. در این مورد، این user2 است که به userW ایمیل می‌فرستد.

ما در نظارت بر ترافیک ایمیلی بین ادارت، نه تنها در واقع می‌خواهیم به‌دنبالِ ناهنجاری‌ها در تعداد ایمیل‌های فرستاده‌شده بگردیم، بلکه می‌خواهیم حجم ایمیل‌های فرستاده‌شده را نیز ببینیم. اگر دو کاربر تلاش کنند که ارتباطات خود را پنهان سازند یا فقط از طریق ایمیل ارتباط برقرار نکنند، اما یکی از طرفین پیوست بزرگی به دیگری بفرستد که حاویِ جزئیاتی در خصوص تمام ادغام‌ها و اکتساب‌های پیشِ‌رو باشد، آن ارتباطات باید شناسایی شوند، ولو این‌که تعداد پیام فقط ۱ عدد باشد، به این معنا که ممکن است با استفاده از نظارت داده‌ایِ قبلی در رادارِ تحلیل‌گر ظاهر نشود. شکل ب.۱۹ نظارتی داده‌ای را نشان می‌دهد که به‌دنبالِ ناهنجاری‌ها در حجم پیام‌های بین کاربرانِ ادارات متفاوت می‌گردد. با توجه به این نمودار، واضح است که ماکسول و دیوید بسیار بیش‌تر از دیگر کاربرانِ این دو اداره اطلاعاتی را با هم ردّوبدل کرده‌اند. این آمار را با اجرای تابع جمع در حوزه‌ی بایت‌های بیرونیِ رخدادهای ایمیلی‌ای که اِکسچِینج سرور تولید می‌کند، می‌توانیم به‌دست آوریم.

همچنان که اشاره شد، این نظارت داده‌ای تابع جمع را روی حجمِ تمام پیام‌های ایمیلی‌ای اجرا می‌کند که بین کاربران ادارات مختلف فرستاده شده‌اند. باز تأکید می‌کنیم که این کار در بازه‌ی زمانی معینی صورت می‌گیرد، که در این مورد ۲۴ ساعت است. محور عمودی نشان‌دهنده‌ی بایت‌ها و محور افقی نشان‌دهنده‌ی روزها است. در این اعلام خطر، می‌توانید مشاهده کنید که ماکسول هر روز حدود ۱۲ میلیون بایت پیام به دیوید فرستاده است. این مقدار حدود ۱.۱۵ مگابایت می‌شود. پیام‌های ایمیلی معمولاً بسیار کوچک هستند. ایمیل بزرگی که حاویِ چندین پاراگراف متنی باشد، معمولاً حدود ۰.۵ مگابایت است. اما این پیام چیزی بیش از ردّوبدل کردن ایمیل‌های ساده‌ای از نوع «هی! چی شد؟» است، و در واقع نشان‌دهنده‌ی این است که احتمالاً پیوست‌هایی فرستاده می‌شوند یا آن داده‌ها در متن ایمیل نوشته می‌شوند.

شکل ب.۱۹ نظارت داده‌ای برای جست‌وجوی ناهنجاری‌ها در حجم پیام‌ها

منبع: ArcSight ESM v4.0

دیوید و ماکسول در تمام نظارت‌های داده‌ایِ ناهنجاریِ ایمیلی ظاهر شده‌اند، و نظارت‌های داده‌ای مشابهی نیز استفاده از سیستم VoIP را ردیابی می‌کنند. با استفاده از رخدادهای VoIP می‌توانیم تقریباً همان اطلاعات مرتبط با ایمیل را ردیابی کنیم، اگر مدت زمان تماس را همچون بایت‌های فرستاده‌شده در پیام ایمیلی درنظر گیریم. شکل ب.۲۰ مجموع مدت زمانِ تماس‌هایی را نشان می‌دهد که بین کاربران ادارات مختلف برقرار شده‌اند- برای مثال، دیوید با داخلیِ ۲۱۵۶ و ماکسول با داخلیِ ۲۶۰۹. توجه داشته باشید که این مدت زمان تبدیل به ثانیه شده است، بنابراین اعداد موجود در این نمودار نشان‌دهنده‌ی ثانیه هستند.

شکل ب.۲۰ مجموع مدت زمان تماس‌های بین دیوید و ماکسول

منبع: ArcSight ESM v4.0

نظارت داده‌ایِ موجود در این شکل، مجموع یا کلّ زمان صرف‌شده پای تلفن را ردیابی می‌کند که بین دو داخلی از دو اداره‌ی متفاوت برقرار شده است. محور افقی باز نشان‌دهنده‌ی بازه‌های زمانی است، که ۱۲ ساعته هستند، و محور عمودی نشان‌دهنده‌ی کلّ زمان صرف‌شده پای تلفن در روز و با واحد ثانیه است. این نمودار اشاره می‌کند که داخلیِ ۲۱۵۶ (دیوید) حدود ۲۳ دقیقه در روز پای تلفن با داخلیِ ۲۶۰۹ (ماکسول) صرف کرده است. با توجه به نشانِ متوسط که در وسط نمودار آمده است، می‌توانیم ببینیم که متوسط زمان صحبت بین این دو نفر به‌طور پیوسته در حالِ افزایش است.

شکل ب.۲۱ نظارت‌های داده‌ایِ به‌کاررفته در این سناریو را نشان می‌دهد، که روی داشبوردی به نمایش گذاشته شده‌اند. اگرچه ما تنها یک نوع نظارت داده‌ای را در این پیوست پوشش دادیم، راه‌های مختلفی برای ارائه‌ی نظارت‌های داده‌ای وجود دارند، از جمله نمودارهای رخداد، بالاترین مقادیر، و نگاشت رخداد جغرافیایی و موارد دیگری که از نام بردن آن‌ها در این‌جا صرف‌نظر می‌کنیم. ما از برخی از این انواع نظارت‌های داده‌ای برای آنالیز در دیگر مثال‌های موردیِ این کتاب استفاده خواهیم کرد.

شکل ب.۲۱ نظارت‌های داده‌ایِ نمایش‌داده‌شده در یک داشبورد

منبع: ArcSight ESM v4.0

نظارت‌های داده‌ای صرفاً نمایش تصویریِ دلپذیری از ترافیک رخداد ایجاد نمی‌کنند؛ آن‌ها هدف بسیار والاتری را نیز دنبال می‌کنند. آن‌ها در واقع همبستگیِ آماری انجام می‌دهند. اگر یک تحلیل‌گر این نمایش‌های تصویری را در تمام طول روز زیر نظر نمی‌گرفت، ممکن بود ارتباطات بین ماکسول و دیوید از نظرها دور بماند. اما، از آنجا که نظارت‌های داده‌ای در حال حاضر آنالیز بی‌درنگ انجام می‌دهند، رخدادهای همبستگی تولید می‌کنند که می‌توانند کنش‌هایی در ارتباط با آن‌ها انجام دهند. رخدادهای همبستگی مبتنی بر شرایط خاصی هستند که به‌عنوان قسمتی از نظارت داده‌ای پیکربندی می‌شوند، مثلاً میزان اختلاف درصدی که شما می‌خواهید در آن لحظه اخطاری راه‌اندازی شود یا کنشی اتفاق افتد. در این مورد،‌ زمانی که ما خیزکی در ارتباطات بین ادارات ببینیم که بیش از ۱۰ درصد باشد، اخطار صادر می‌کنیم. این امر به این معنا است که تحلیل‌گرِ Finance123 چند تذکر دریافت می‎‌کند با این مضمون که خیزکی در ترافیک بین این دو کاربر وجود داشته است. شکل ب.۲۲ رخدادهای همبستگی‌ای را نشان می‌دهد که به‌وسیله‌ی این نظارت‌های داده‌ای در کنسول تحلیل‌گر تولید شده‌اند.

شکل ب.۲۲ رخدادهای همبستگیِ تولیدشده به‌وسیله‌ی این نظارت‌های داده‌ای در کنسول ArcSight ESM

منبع: ArcSight ESM v4.0

حالا که تحلیل‌گر این تذکرات را دریافت کرده است، وقتِ آن است که بازپرسی‌هایی انجام دهد. اولین گامی که تحلیل‌گر باید بردارد این است که جزئیات این تذکرات را بررسی کند و مشخص سازد که چه‌کسی در این امر دخالت دارد و چه رخدادهای دیگری ممکن است از سوی آن کاربران به‌وقوع پیوندند. بهترین راه برای انجام این کار این است که گزارش بازپرسانه‌ای بگیرند که در آن از نام کاربریِ مربوطه به‌عنوان شرطِ فیلتر استفاده کنند. این تحلیل‌گر چندین گزارش می‌گیرد تا تماس‌های برقرارشده بین ماکسول و دیوید، مدت زمان این تماس‌ها، و ترافیک ایمیلی بین این دو کاربر را ببیند. این گزارش‌ها را می‌توان به‌عنوان مدرک به مدیران، مجاری قانونی، یا منابع انسانی ارائه داد، مدرکی که نشان می‌دهد این کاربران رفتار مشکوکی از خود نشان داده‌اند. گزارش موجود در شکل ب.۲۳ مثالی است از یک گزارش بازپرسی کاربر که مبتنی بر ترافیک ایمیلیِ بین ماکسول و دیوید است.

شکل ب.۲۳ گزارش بازپرسی کاربر مبتنی بر ترافیک ایمیلی بین ماکسول و دیوید

منبع: ArcSight ESM v4.0

تحلیل‌گر، فقط با خواندنِ صرفاً حوزه‌ی پیام ایمیل، کاملاً مشکوک می‌شود و تصمیم می‌گیرد که باید بازپرسی صورت گیرد. گزارش مربوطه به مدیران داده می‌شود، و بازپرسی‌های بیش‌تر در محتویات ایمیل‌ها، حساب‌های متفاوتی که دیوید با آن‌ها سروکار داشته است، سرمایه‌گذاری‌هایی که ماکسول توصیه کرده است، مشخص می‌سازند که سوءتفاهم‌ها و موارد تصادفیِ بسیاری ایجاد شده‌اند و آن‌ها در حالِ انجام فعالیت‌های کلاه‌بردارانه‌ای نبودند.

نتیجه‌گیری

نوع کلاه‌برداری‌ای که ما در این پیوست مطرح کردیم، نه تنها منجر به از دست دادن شغل می‌شود، بلکه تبعات قانونی نیز در پی خواهد داشت. کارمندان و شرکتِ نام‌برده در این‌جا فرضی هستند، اما این نوع مورد هر روز اتفاق می‌افتد و آشکارسازیِ آن بسیار مشکل است. اگر تمام اطلاعاتی را که حول‌وحوش سازمان شما در جریان هستند درنظر گیرید، تصور کنید که باید آن‌چه را خارج می‌شود ردیابی نمایید، آن‌چه وارد می‌شود را فعلاً کنار بگذارید. این‌ها انواع فرآیندهایی هستند که ما می‌توانیم از طریق ESM و همگراییِ منابع داده‌ی جدید، به‌سامان و خودکار نماییم. اگرچه این منابع داده واقعاً با چالش‌هایی روبه‌رو هستند، مانند جمع‌آوری پیام‌های ایمیلی و برخی از تحلیل‌های CDRهای VoIP، این‌ها چیزهایی هستند که با گذشت زمان به‌بود خواهند یافت، همچنان که در طول زمان، شرکت‌ها این حرف را به گوش فروشندگان خود خواهند رساند که آن‌ها نیاز به فایل‌های ثبت وقایعِ قابل‌مدیریت و تواناییِ جمع‌آوری آن فایل‌ها به‌روشی بی‌دردسر دارند. همین که آن‌ها جمع‌آوری شوند، امکانات بی‌شماری برای آنالیز در اختیار خواهند بود.