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

فهرست ِ محتوای ِ کتاب

این نوشته بخشی از کتاب ِ «بازپرسی جرایم سایبری» است. برای ِ دست‌رسی به فهرست ِ محتوای ِ کتاب و خواندن ِ بخش‌های ِ دیگر می‌توانید به این لینک بروید.

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

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