سیستم بایستی قادر باشد گزارشات را بر حسب زمان های ماهانه، روزانه، ساعت، سالیانه ارائه نماید. و در هر گزارش 10 نفر برتر را اعلام نماید. تمامی گزارشات بایستی داینامیک و بر حسب نیاز اپراتور قابل تعیین باشد. همچنین بایستی قابلیت correlate ، رویدادها و ساختن رویداد های انها بر اساس ترکیب لاگ های سامانه های مختلف وجود داشته باشد و امکان تعریف نمودار ، چارت بر اساس اطلاعات مورد نیاز کاربر نیز وجود داشته باشد.
به عنوان مثال برای لاگ مربوط به spam کاربر بتواند گزارش زیر را در سامانه مشاهده نماید.
اپراتور سیستم بایستی بتواند حالاتی را تعریف نماید که در ان حالات، اتفاقات سیستم به صورت sms و ایمیل برای کاربران مشخص شده ارسال شود. برای ارسال sms از smsengine و برای ارسال ایمیل نیز از سرویس ایمیل النون استفاده نماید.
اگر تعداد spam های ارسالی بیشتر از 90 در صد ایمیل ها در بازه 5 ساعته شد و حجم log مربوط به ایمیل های ارسالی بیشتر از 50% هارد سیستم بود sms ارسال شود.
1- نصب ابزاها با پلاگین های موجود در اینترنت برای OSSIM برای تعدادی از سرویس ها که امکان اتصال انها وجود دارد.
2- تولید پلاگین ها برای ابزارهایی که log استاندارد تولید می کنند.
3- تولید پلاگین های تحلیل log برای سیستم هایی که خاص سرویس ایمیل النون است.
3. کمبود مراکز داده پایدار، ایمن و پاسخگو
در پروژه ایمیل از مرکز داده های مختلفی استفاده شد است از جمله این مراکز می توان به تبیان، سروش رسانه، پارس انلاین، افرانت و زیر ساخت اشاره کرد.
متاسفانه مراکز داده معمولا SLA که مناسب سرویس ایمیل باشد ارائه نمی دهند. بدیهی است SLA سرویس ما پایین تر از مراکز داده خواهد بود اگر بخواهیم از یک مرکز داده استفاده کنیم. مشکلاتی از قبیل دیده نشده از برخی رنج های IP ، قطعی سرویس مشکلات برق و سخت افزاری امری اجتناب ناپذیر در مراکز داده است. پشتیبانی و پاسخ گویی تیم مرکز داده، تاثیر مستقیم در کیفیت سرویس ایمیل دارد. در استفاده از ایمیل در بسیاری از مواقع مشکلات ناشی از ضعف پشتیبانی مراکز داده باعث از دسترس خارج شدن سرویس های ما شده است.
3.1.3 مشکلات پشتیبانی
1. توسعه سیستم های دقیق پشتیبان گیری در معماری با مقیاس بالا
نگهداری حجم بالای پشتیبان ها در مراکز داده مختلف نیازمند فعالیت های زیادی است. بسیاری از مشکلات کنترل ریسک و هزینه است به گونه ای که با هزینه معقول بتوانیم در شرایط بحرانی اطلاعات کاربران را درکمترین زمان ممکن بازیابی نماییم.
2. کمبود نیروی انسانی متخصص جهت پشتیبانی و پاسخگویی به صورت 7*24
3. کاهش incident ها از طریق root cause کردن مشکلات
4. افزایش رضایت مشتریان و کاربران با توجه به متدولوژی مدیریت خدمات اخذ شده
4.1.3 مشکلات امنیت
1. امنیت و جلوگیری از حمله شدن به ایمیل و spamer ها
سرویس های ایمیل یکی از اهداف بات ها و حمله هکر ها است. بسیاری از شبکه های بات ها سعی می کنند با دسترسی به سرویس ایمیل اقدام به ارسال ایمیل با تعداد بالا نمایند. در سیستم ایمیل النون ما مواجه با حجم عظیمی که حملات به سرور های ایمیل گیتوی هستیم. این حملات در طی زمان به روز می شوند و سعی می کنند اسیب پذیری های جدیدی را در سیستم ها برای حملات پیدا کنند؛ لذا پویش مستمر امنیت و به روز رسانی سرویس های انتی spam و انتی ویروس و سیستم امنیتی یکی از مشکلات ایمیل است. بسیاری از اوقات این سیستم ها به دلیل سخت گیری هایی که انجام می دهند ممکن است باعث ایجاد false positive شوند و باعث نارضایتی کاربران گردند.
- برخی از سرو های ایمیل توسط ویروس ها و bot ها الوده می شود و به عنوان سرور های ارسال spam استفاده می شود. این روش بسیار معمول است و متاسفانه بررسی mailq به کشف این حمله کمک نمی کند زیرا مورد غیر عادی مشاهده نمی شود. بررسی ترافیک شبکه می تواند به یافتن این حملات کمک نماید. برای مقابله با این نوع حمله موارد زیر پیشنهاد می شود:
- استفاده از انتی ویروس قوی بر روی سرور ها
- به روز رسانی امنیتی و نصب وصله های امنیتی بر روی سرور ها
- بستن پورت 25 به بیرون برای سرور هایی که نیاز به این پرت ندارد.
- رعایت اصل حداقل دسترسی در مورد شبکه و دسترسی کاربران.
- نصب مجدد و پاک کردن کامل سیستم عامل هایی که الوده شده اند.
- جدا کردن شبکه سیستم هایی که ریسک بالایی دارند.
- حمله کننده کلمه عبور و نام کاربری یکی از کاربران سیستم را در می اورد و از ان ها برای ارسال spam استفاده می کند.(در مورد سیستم gateway که برای اتصال با استفاده از imap و smtp دارد، استفاده می کند):
- استفاده از کلمات عبور قوی برای کاربران
- در مورادی که کاربر sla پر نکرده یا اینکه کلمه عبور ضعیف است نتواند وارد سیستم شود.
- نام کاربری های عمومی مانند info و admin کلمات عبور سخت داشته باشند و به کاربران واگذار نشوند.
- کلمات عبور به صورت دوره های شش ماهه این تغییر نماید.
- تعداد ایمیل های دریافتی و ارسالی کنترل شود و در صورت مشاهده رشد غیر عادی گزارش گردد.
- تعداد ایمیل های ارسالی و دریافتی برای کاربران محدود شود.
- سیستم های کاربران از جهت الودگی به ویروس و تروجان بررسی گردد.
- در صورت بروز این مشکل بلافاصله نام کاربری که حمله کننده اطلاعات ان را سرقت کرده شناسایی و کلمه عبور تغییر نماید.
- اشتباه در تنظیمات شبکه
- در موارد بسیار فراموش کردن در مورد نحوه تنظیمات ممکن است باعث شود حمله کننده بتواند حملاتی را انجام دهد؛ برای حل این مشکل بایستی بعد از تغییر و یا انجام تغییرات شبکه این موارد بازبینی گردد.
2. پشتیبانی و امن سازی imap , pop3
یکی از سرویس های که معمولا هدف حملات قرار می گیرند imap و pop3 است. در این سرویس ها سعی می گردد با به روز رسانی این سرویس ها و فعال سازی رمزنگاری، بر این مشکلات غلبه شود؛ ولی از انجایی که برای دسترسی در این سیستم ها از درگاه های مختلف استفاده می شود و کنترل انها مشکل است (زیرا انعطاف و تغییر این پرتکل ها بسیار دشوار است و معمولا کلاینت هایی که از سیستم ها استفاده می کنند)، نمی توانند محدودیت های زیادی را بپذیرند.
3. جلوگیری از مشکلات مربوط به brutreforce نام کاربری و کلمه عبور
یکی از حملاتی که به سیستم ایمیل انجام می شود حدس زدن نام کاربری و کلمه عبور با امتحان کردن تعداد زیادی از حالات ممکن است. برای جلوگیری از این حملات سیاست های مختلفی از جمله captcha و یا بستن ip در نظر گرفته شده است. همچنین سعی شده در انتخاب کلمات عبور موارد زیر رعایت شود.
قوانین زیر در نگهداری و تغییر کلمات عبور در کل سیستم ایمیل بومی رعایت می شود:
1) کلیه کلمات عبور پشتیبانی بایستی بیشتر از 12 حرف شامل حرف و کارکتر خاص باشد.
2) بایستی به هیچ وجه کلمات عبور email بر روی اینترنت منتقل نشود.
3) به صورت کلامی با صدای بلند گفته نشود.
4) برای هر کاربر یک user مجزا و با حداقل دسترسی در نظر گرفته می شود.
5) کاربر root تغییر نام داده می شود و nologin می شود و کلمه عبور تنها در اختیار admin ها است.
6) برای نرم افزارها نیز در صورت نیاز کلمه عبور تعریف می شود.
7) کلمه عبور ادمین های سرور هر ماه تغییر می کند.
8) کلمه عبور root در سه ماه یک بار تغییر می کند.
9) کلمه عبور مربوط به نرم افزارها (شامل کلمه عبور پایگاه داده) هر شش ماه یک بار تغییر می نماید.
ولی این اقدامات کافی نبوده و معمولا حمله کننده ها با استفاده از ضعف انتخاب نام کاربری برای کاربران و استفاده از imap برای brute force استفاده می کنند. استفاده از تعداد زیادی از کاربران از یک vpn مشکلاتی از قبیل false positive به وجود می اورد و سختی این سیاست ها یکی از مشکلات کنترل کلمات عبور است. به نظر می رسد استفاده از OTP و کلمات عبور دوعامله می تواند تا حد زیادی این مشکلات را بهبود ببخشد.
4. جلوگیری از حملات در سطح شبکه و سیستم عامل
در سطح شبکه و سیستم عامل سعی شده است سرویس ها به صورت مداوم بررسی شود و سیاست ها و چک لیست هایی برای به روز رسانی امنیتی و محدودیت استفاده از انها انجام شود.
سیاست محیط تست و توسعه
قوانین و سیاست های زیر در مورد ماشین های تست و محیط تست وجود دارد.
1) تا جای ممکن محیط تست بر روی سرورهای داخلی ایجاد می شود و در صورت کمبود منابع و ممکن نبود تست کارا، این امر بر روی سرور های عملیاتی انجام می شود.
2) ماشین های تست در vlan و شبکه جدا بر روی ESx و pfsense قرار می گیرند و به صورت شبکه ای تا جای ممکن دسترسی از سایر سرور ها قطع می شود.
3) پهنای باند اینترنت اختصاص داده شده برای ماشین تست به صورت shape شده محدود می شود.
4) تنها دسترسی از طریق تونل به ماشین های تست امکان پذیر است و تا جای ممکن دسترسی های شبکه ای محدود می شود.
وضعیت شبکه سرور های عملیاتی
قوانین زیر در مورد سرور عملیاتی رعایت می گردد.
1) سرور ها به تدریج در چهار شبکه مجزا قرار می گیرند (سرور های داده (ldap و mysql) سرور های وب، سرور های infra (zcp ،spam)، ایمیل gateway (postfix،gateway،()
2) سرور های وب در پشت waf قرار می گیرد. مخصوصا سرور های مربوط به wordpress
3) سرور ها به صورت هفتگی به روز رسانی می گردد (patch های امنیتی بر روی انها نصب می گردد).
4) ماژول مربوط به IDP فعال می گردد.
سیاست بررسی log ها و SOC
چک کردن دوره ای log های مربوطه و history مربوط به دستورات توسط SOC
5. جلوگیری از حملات در سطح نرم افزار و سرویس‌های اختصاصی
برای تست نرم افزار به صورت دوره ای هر یک سال یکبار سیستم ها مطابق استاندارد های بین المللی تست می شود. برای تست نرم افزارها از استاندارد owasp، SANS و infosec استفاده می شود و برای تست شبکه از استاندارد OSSTM استفاده می گردد. هدف از تست های امنیتی یافتن و گزارش اسیب پذیری ها در تعامل با توسعه دهندگان سیستم است.
تمامی اطلاعات سیستم شامل کد نرم افزار در اختیار تست کننده قرار خواهد گرفت تا بیشترین اسیب پذیری های ممکن از سیستم یافت شود.
هدف اصلی رفع اسیب پذیری های امنیتی سیستم است و صرف یافتن اسیب پذیری اگرچه با ارزش است ولی هدف اصلی رفع اسیب پذیری ها است. لذا مجری تست موظف است راه حل های رفع اسیب پذیری را با جزئیات کامل ارائه دهد. همچنین تمامی فرایند تست یایستی در قالب سناریو همراه با عکس و فیلم مستند شود.
در مواردی که نیاز به توضیحات بیشتر در مورد سیستم است بایستی با برگزاری جلسات با توسعه دهنده موارد تست توضیح داده شود. توسعه دهنده با کمک مجری تست مسئول رفع اسیب پذیری ها است.
ورودی های تست
برای تست ابتدا جلسه شناخت سیستم شامل افراد شبکه، توسعه دهنده ها و تست کننده سیستم برگزار می شود و در این جلسه تمامی مستندات سیستم به مجری تست تحویل داده می شود. هدف از این جلسه اشنایی مجری تست با معماری و نحوه عملکرد سیستم است.
در طی فرایند تست نیز تست کننده با توسعه دهنده در ارتباط است و موارد تست را با توسعه دهنده هماهنگ و توضیحات لازم در اختیار توسعه دهنده قرار می گیرد.
خروجی تست
مجری تست موظف است خروجی های تست را در قالب OWASP گزارش نماید. هم سناریو های موفق و اسیب پذیر و هم نا موفق در گزارش خواهد امد. در طی انجام پروژه خروجی هر سناریو که تست می شود شامل عکس و فیلم و خلاصه از فعالیت ها به صورت گزارش مقدماتی ایمیل می شود. در پایان پروژه گزارش مفصل از وضعیت سیستم ارائه می گردد.
فرمت گزارش مفصل
گزارش مفصل مطابق ورژن چهارم استاندارد OWASP ارائه می شود و شامل موارد زیر است.
1. خلاصه مدیریتی: شامل خلاصه موارد تست شده و وضعیت هر مورد و تاثیری که اسیب پذیری ها می تواند بر روی سیستم داشته باشد.
2. پارامتر های تست: در این بخش موارد که در تست موثر بودند بیان می شود و شامل موارد زیر است:
2.1 هدف پروژه
2.2: دامنه پروژه: محدوده پروژه که در قرارداد امده است.
2.3: زمان بندی پروژه: زمان شروع و پایان پروژه.
2.4: اهداف: سیستم هایی که هدف تست بودند.
2.5: محدودیت ها: در این بخش محدودیت های دسترسی و امکانات تست بیان می شود.
2.6: جدول اسیب پذیری ها: شامل جدولی از خلاصه اسیب پذیری که در سیستم یافت شده است.
2.7: توصیه ها برای رفع: در این بخش توصیه هایی برای رفع اسیب پذیری های سیستم بیان می شود این توصیه های به صورت خلاصه است.
2.8: لیست ابزارهایی که در طی تست از انها استفاده شده است به همراه نسخه.
3. یافته ها: در این بخش TESTLOG ها و تست های انجام شده چه موفق و ناموفق به همراه عکس و ارجاع به فیلم ها بیان می شود. کلیه TEST CASE های استاندارد OWASP بایستی توسط سناریوهای این بخش پوشش داده شود و مشخص شود سناریو برای اجرای کدام TEST CASE بوده است. در اخر هر سناریو بایستی راه حل هایی جهت رفع انها با جزئیات کامل بیان شود. هدف هر سناریو بایستی در ابتدا بیان شود و در انتها مشخص شود که تا چه حدی این هدف محقق شده است.
در ادامه برخی از این TEST CASE ها امده است.
