1-1-1 مؤلفه‌ی پیش‌پردازش

1-1-1 مؤلفه‌ی پیش‌پردازش

هشدارهای بهنجارشده، قالبی استاندارد دارند که توسط سایر مؤلفه‌های رویکرد قابل پردازش است، اما پیش‌پردازش بیشتری نیز ممکن است مورد نیاز باشد؛ چرا که امکان دارد برخی از حسگرها، مقادیر بعضی از ویژگی‌ها را ارائه نکنند، ویژگی‌هایی که مقادیرشان برای سایر مؤلفه‌های رویکرد مورد نیاز است [Valeur et al., 2004]. هدف مؤلفه‌ی پیش‌پردازش، تأمین مقادیر تخمینی برای چنین مؤلفه‌هایی است. شکل ‏4‑3، شبه کد مؤلفه‌ی پیش‌پردازش را نشان می‌دهد.

Preprocess(alert) {

if(alert.TS == NULL) alert.TS = alert.ReceiptTime;

if(alert.Sensor.Type == HIDS) {

if(alert.IPsrc == NULL) alert.IPsrc = alert.Sensor.IPAddress;

if(alert.IPdst == NULL) alert.IPdst = alert.Sensor.IPAddress;

}

send alert to next component;

}

شکل ‏4‑3: شبه کد مؤلفه‌ی پیش‌پردازش

در صورتی که هشدار دریافتی، حاوی مهر زمانی شناسایی حمله نباشد، مهر زمانی، برابر با زمان دریافت هشدار توسط سیستم مدیریت هشدارها در نظر گرفته می‌شود؛ در حقیقت، این مقدار، بهترین تخمین ممکن برای زمان شناسایی حمله است. لازم به ذکر است که هرچند چنین تخمینی، باعث ورود مقداری خطا در محاسبات بعدی خواهد شد، اما از طرف دیگر، به دلیل عدم تعیین مقدار توسط حسگر، این خطا اجتناب‌ناپذیر است. سپس، اگر هشدار دریافتی، از طرف یک IDS مبتنی بر میزبان (HIDS) صادر شده باشد، هشدار، برای وجود مقادیر آدرس IP مبدأ و مقصد بررسی می‌شود. در صورتی که این مقادیر خالی باشد، مقدار آن‌ها برابر آدرس IP حسگر قرار داده می‌شود. این مؤلفه نیز تمامی هشدارهای ورودی را از خود عبور می‌دهد و بنابراین تعداد هشدارها را کاهش نمی‌دهد.

1-1-2 مؤلفه‌ی همجوشی

حسگرهای مختلف، از روش‌های متفاوتی استفاده می‌کنند؛ به همین علت، ممکن است دقت متفاوتی داشته باشند. به علاوه، ممکن است که یک حسگر خاص، در زمینه‌ی شناسایی مجموعه‌ی خاصی از حملات، از یک حسگر دیگر، بهتر عمل کند. این شرایط، موجب می‌شود که در بسیاری از شبکه‌ها، به جای استفاده از یک IDS، از چند IDS استفاده شود. در این صورت، دقت شناسایی حملات در شبکه، در حالت کلی افزایش می‌یابد. با این حال، در صورتی که یک شبکه‌ی خاص، توسط چندین حسگر نظارت شود، ممکن است که یک حمله، توسط چند حسگر شناسایی شود و در نتیجه، هر حسگر، یک هشدار برای آن حمله صادر می‌کند [Valeur et al., 2004]. به این هشدارها، «هشدارهای تکراری» گفته می‌شود. در این حالت، سیستم مدیریت هشدارها، چندین هشدار تکراری دریافت می‌کند. هدف این مؤلفه، ترکیب هشدارهای تکراری است. هشدارهای تکراری به ازای هر حمله، با یکدیگر ترکیب شده و تشکیل یک «فراهشدار» را می‌دهند.

مؤلفه‌ی همجوشی، در حقیقت از دو روال تشکیل شده است که به صورت همزمان، داده‌های ورودی را پردازش می‌کنند. شکل ‏4‑4، شبه کد مؤلفه‌ی همجوشی را نشان می‌دهد. همان طوری که در شبه کد نشان داده شده است، دو روال FuseJob() و RemoveJob()، بر روی دو نخ جداگانه فراخوانی می‌شوند تا بتوانند به صورت همزمان، پردازش لازم را به انجام برسانند.

Fuse() {

start FuseJob() on ThreadFFJ;

start RemoveJob() on ThreadFRJ;

}

شکل ‏4‑4: شبه کد مؤلفه‌ی همجوشی

روال FuseJob()، روالی است که عملیات همجوشی هشدارها را انجام می‌دهد. تصمیم برای همجوشی دو هشدار مفروض، بر اساس اختلاف زمانی آن‌ها و اطلاعات موجود در آن‌ها اتخاذ می‌شود. در این مؤلفه، یک پنجره‌ی زمانی لغزان به طول  در نظر گرفته می‌شود و هشدارها و فراهشدارهای موجود در آن پنجره (هشدارهایی که اختلاف زمان آن‌ها کوچک‌تر از یا مساوی با  است)، به ترتیب مهر زمانی مرتب می‌شوند. زمانی که یک هشدار جدید از راه می‌رسد، با هشدارهای موجود در پنجره مقایسه می‌شود (با شروع از جدیدترین هشدار). در صورتی که هشدار جدید با یکی از هشدارهای موجود در پنجره تطابق داشته باشد، این دو هشدار ترکیب شده و فراهشدارِ تولیدشده، جای هشدار قدیمی‌تر را در پنجره می‌گیرد و جست‌و‌جو برای یافتن تطابق خاتمه می‌یابد. در صورتی که تطابقی یافت نشود، هشدار جدید به پنجره اضافه می‌شود. مهر زمانی فراهشدار تولیدشده از ترکیب دو هشدار تکراری، برابر مهر زمانی هشدار قدیمی‌تر در نظر گرفته می‌شود. این کار، منطقی است؛ چرا که هشدارهای تکراری، نشانگر وقوع یک حمله هستند و تأخیر در مهر زمانی هشدار دوم، به احتمال زیاد، به سبب تأخیر در حسگر بوده است [Valeur et al., 2004]. شکل ‏4‑5، شبه کد روال همجوشی در مؤلفه‌ی همجوشی را نشان می‌دهد.

FuseJob() {

q = new PriorityQueue();

while(Incoming Alert) {

alert = Incoming Alert;

match = q.SearchForMatch(alert);

if(match == NULL) q.Enqueue(alert);

else {

q.RemoveFromQueue(match);

hyperAlert = alert;

hyperAlert.TS = min(alert.TS, match.TS);

hyperAlert.Tag = alert.Tag  match.Tag;

}

}

}

شکل ‏4‑5: شبه کد روال همجوشی در مؤلفه‌ی همجوشی

روال RemoveJob()، وظیفه‌ی حذف هشدارهای قدیمی را از مؤلفه‌ی همجوشی و تحویل آن به مؤلفه‌ی وارسی آسیب‌پذیری به عهده دارد. در صورتی که اختلاف زمان حال با مهر زمانی هشدارهای قدیمی بیشتر از  شود، این هشدارها از پنجره خارج‌شده و به مؤلفه‌ی بعدی تحویل داده می‌شوند. اگر مقدار  بسیار بزرگ انتخاب شود، هشدارهایی نامربوط با یکدیگر ترکیب می‌شوند و در صورتی که مقدار  بسیار کوچک انتخاب شود، برخی از هشدارهای مربوط به هم، ترکیب نخواهند شد [Valeur et al., 2004]. شکل ‏4‑6، شبه کد روال حذف در مؤلفه‌ی همجوشی را نشان می‌دهد.

RemoveJob() {

while(true)

while(q.First.TS < Now – WF) {

alert = q.Dequeue();

send alert to next component;

}
}

شکل ‏4‑6: شبه کد روال حذف در مؤلفه‌ی همجوشی

واضح است که این مؤلفه، تنها زمانی تعداد هشدارهای ورودی را کاهش می‌دهد که حسگرهای شبکه، دارای افزونگی بوده و هشدارهای تکراری تولید نمایند.

1-1-3 مؤلفه‌ی وارسی آسیب‌پذیری

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

مؤلفه‌ی وارسی آسیب‌پذیری، با بهره‌گیری از پایگاه اطلاعات اجزای شبکه، می‌تواند مؤثر یا بی‌اثر بودن حمله‌ی گزارش‌شده توسط هر هشدار را وارسی نماید.

پایگاه اطلاعات اجزای شبکه، شامل اطلاعاتی درباره‌ی اجزای مختلف شبکه، نظیر میزبان‌ها و مسیریاب‌ها است. اطلاعات موجود در این پایگاه داده، شامل نوع سیستم‌عامل، سرویس‌های در حال اجرا، و آسیب‌پذیری‌های شناخته‌شده می‌باشد. چنین پایگاه داده‌ای را می‌توان با استفاده از ابزارهایی نظیر Nmap [Nmap]، Nessus [Nessus]، و OpenVAS [OpenVAS] ایجاد کرد.

همان طوری که شبه کد این مؤلفه در شکل ‏4‑7 نشان می‌دهد، در صورتی که حمله‌ی گزارش‌شده توسط هشدار، بی‌اثر باشد، هشدار نیز بی‌اثر بوده و با استفاده از ویژگی  علامت‌گذاری می‌شود. واضح است که صحت اطلاعات موجود در پایگاه اطلاعات اجزای شبکه، برای کارکرد صحیح این مؤلفه، حیاتی است. بنابراین، لازم است که اطلاعات موجود در این پایگاه داده، به صورت دوره‌ای، روزآمد شود.

VerifyVulnerability(alert) {

targetVulnerable = VulnerabilityDB.IsTargetVulnerableToAttack(alert.IPdst, alert.Portdst, alert.AID);

if(targetVulnerable == false) alert.Tag = alert.Tag  “INEFFETIVE”;

send alert to next component;

}

شکل ‏4‑7: شبه کد مؤلفه‌ی وارسی آسیب‌پذیری

این مؤلفه، می‌تواند به صورت بالقوه، کاهش بسیار چشمگیری در تعداد هشدارهای ورودی داشته باشد.

1-1-4 مؤلفه‌ی کاهش هشدارهای غلط

فرآیند تشخیص در سیستم‌های تشخیص نفوذ، بی‌عیب نیست و در نتیجه امکان دارد که یک ترافیک بی‌خطر، به عنوان یک حمله گزارش شود. به چنین هشدارهایی که به اشتباه صادر می‌شوند، «هشدارهای غلط» گفته می‌شود [Salah et al., 2013]. هدف این مؤلفه، کاهش تعداد هشدارهای غلط است.

در این مؤلفه، از روش‌های یادگیری با ناظر استفاده می‌شود. در ابتدا، یک روش داده‌کاوی تجمعی، به صورت برون‌خط بر هشدارهایی که درست و غلط بودن آن‌ها مشخص است، اعمال می‌شود تا مدلی برای دسته‌بندی این هشدارها به دست آید. روشی که در این پژوهش مورد استفاده قرار گرفته است، الگوریتم AdaBoost [Alpaydin, 2010] می‌باشد. سپس، همان طوری که شبه کد مؤلفه در شکل ‏4‑8 نشان می‌دهد، این مدل به صورت برخط استفاده می‌شود تا هشدارهای غلط را از هشدارهای درست، تمیز دهد. در صورتی که یک هشدار، به عنوان هشدار غلط شناسایی شود، با استفاده از ویژگی  علامت‌گذاری می‌شود. برای آموزش مدل، می‌توان از مجموعه‌های داده‌ی آماده، نظیر دارپا [DARPA, 1998] استفاده نمود. در شبه کد این مؤلفه، ، در حقیقت مدل ایجادشده توسط الگوریتم AdaBoost می‌باشد.

global Model; //AdaBoost Model

FalsePositiveReduction(alert) {

if(Model.IsFalsePositive(alert)) alert.Tag = alert.Tag  “FALSE POSITIVE”;

send alert to next component;

}

شکل ‏4‑8: شبه کد مؤلفه‌ی کاهش هشدارهای غلط

این مؤلفه نیز کاهش چشم‌گیری در تعداد هشدارهای ورودی دارد.

1-1-5 مؤلفه‌ی شناسایی هشدارهای رایج

«هشدارهای رایج»، هشدارهایی هستند که در بازه‌های زمانی مختلف، به صورت مکرر صادر می‌شوند. این‌گونه هشدارها، هم ممکن است در واکنش به رویدادهای عادی و هم ممکن است در واکنش به شناسایی برخی از حملات، نظیر حملات جلوگیری از سرویس (DoS) یا حملات شناسایی، صادر شوند [مکاریان، 1391]. هدف این مؤلفه، شناسایی هشدارهای رایج می‌باشد.

برای پیاده‌سازی مؤلفه‌ی شناسایی هشدارهای رایج، از الگوریتم پیشنهادی مکاریان برای دسته‌بندی هشدارها [مکاریان، 1391]، استفاده می‌شود. این الگوریتم، بر مبنای روش کاوش مجموعه‌داده‌های تکراری طراحی شده است. به عبارت دیگر، ابتدا الگوریتم شکل ‏3‑5 بر روی مجموعه‌ای از هشدارهای موجود اجرا می‌شود تا با استفاده از الگوریتم مکاریان، الگوهای هشدارهای تکراری استخراج شود. این الگوها، در یک متغیر سراسری  نگهداری می‌شود. سپس، همان طوری که شکل ‏4‑9 نشان می‌دهد، از این الگوها بای شناسایی هشدارهای رایج استفاده می‌شود.

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

global Patterns; //Frequent Patterns

FrequentAlertRecognition(alert) {

foreach(pattern in Patterns)

if(pattern.Matches(alert)) {

alert.Tag = alert.Tag  “FREQUENT”;

send alert to next component;

break;

}

}

شکل ‏4‑9: شبه کد مؤلفه‌ی شناسایی هشدارهای رایج

این مؤلفه نیز به صورت بالقوه قادر است تعداد هشدارهای ورودی را کاهش دهد.

1-1-6 مؤلفه‌ی تجمیع

هشدارهایی که وارد سیستم مدیریت هشدار می‌شوند، ممکن است با یکدیگر مرتبط باشند؛ به عنوان مثال، بسیاری از هشدارها، ممکن است دلایل ریشه‌ای مشترکی داشته باشند. همچنین، بسیاری از حملات، در چند مرحله انجام می‌شوند و حسگرها، برای هر مرحله، هشدار یا هشدارهای مجزایی صادر می‌کنند [مکاریان، 1391]. هدف این مؤلفه، تجمیع هشدارهای مرتبط باهم، در قالب یک فراهشدار است.

این مؤلفه، برای انجام وظیفه‌ی خود، از صورت تغییریافته‌ی الگوریتم خوشه‌بندی پیشنهادی مکاریان [مکاریان، 1391]، استفاده می‌کند. در الگوریتم پیشنهادی وی، یک مقدار ثابت NDT به عنوان حد آستانه‌ی فاصله برای دو هشدار موجود در یک خوشه در نظر گرفته می‌شود. در ابتدای ورود هر هشدار جدید، فاصله‌ی آن با مرکز خوشه‌ها (در صورت وجود حداقل یک خوشه) محاسبه می‌شود. اگر یک فاصله‌ی کمینه یافته شود که کوچک‌تر از یا مساوی با NDT نیز باشد، خوشه‌ی مربوطه به عنوان کاندیدایی برای به عضویت درآوردن هشدار جدید در نظر گرفته می‌شود؛ در این وضعیت، هشدار جدید تنها در صورتی وارد خوشه‌ی منتخب می‌شود که فاصله‌ی آن تا تمام اعضای آن خوشه، کمتر از مقدار NDT باشد. در صورتی که هیچ‌یک از شرایط فوق برقرار نشود یا خوشه‌ای در هنگام ورود هشدار وجود نداشته باشد، یک خوشه‌ی جدید ایجاد شده و هشدار مورد نظر، به عنوان مرکز آن در نظر گرفته می‌شود [مکاریان، 1391].

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

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

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

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

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

بنابراین شبه کد مؤلفه‌ی تجمیع، بایستی به صورت نشان داده‌شده در شکل ‏4‑10 باشد. در اینجا، دو روال ClusterJob() و RemoveJob() بر روی دو نخ، به صورت همزمان فراخوانی می‌شوند.

Aggregation() {

start ClusterJob() on ThreadACJ;

start RemoveJob() on ThreadARJ;

}

شکل ‏4‑10: شبه کد مؤلفه‌ی تجمیع

روال خوشه‌بندی یا ClusterJob()، در حقیقت صورت تغییریافته‌ی الگوریتم شکل ‏3‑3 می‌باشد که همان روش پیشنهادی مکاریان برای خوشه‌بندی است. در صورت تغییریافته‌ی الگوریتم مکاریان، یک ویژگی به هر خوشه اضافه می‌شود که زمان آخرین به‌روزرسانی خوشه را نگهداری می‌کند. روال حذف یا RemoveJob() نیز به صورت همزمان با ClusterJob() بر روی مجموعه‌ی خوشه‌های تولیدی این روال، عمل می‌کند. روال حذف، مجموعه‌ی خوشه‌های تولیدی روال خوشه‌بندی را پیمایش می‌کند و در صورتی که خوشه‌ای یافته شود که از زمان به‌روزرسانی آن، بیشتر از  گذشته باشد، آن خوشه را از مجموعه‌ی خوشه‌های نهایی، خارج می‌کند و به سیستم نظارت مرکزی تحویل می‌دهد. شکل ‏4‑11 شبه کد روال حذف در مؤلفه‌ی تجمیع را نشان می‌دهد.

global Clusters; //Shared with ClusterJob()

RemoveJob() {

while(true)

foreach(cluster in Clusters)

if(cluster.UpdateTime < Now – WA) {

Clusters.RemoveFromClusters(cluster);

send cluster to presentation;

}

}

شکل ‏4‑11: شبه کد روال حذف در مؤلفه‌ی تجمیع

با توجه به این که این مؤلفه، چندین هشدار مرتبط را در قالب یک فراهشدار نهایی (مرکز خوشه) در اختیار متخصص امنیت شبکه قرار می‌دهد، بنابراین در کاهش تعداد هشدارها نقشی اساسی را ایفا می‌کند.

1-2 جمع‌بندی

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

 

فصل 2                   آزمایش‌ها و ارزیابی رویکرد پیشنهادی

 

 

2-1 مقدمه

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