بایگانی برچسب: s

ابزار تشخیص نفوذ به شبکه مبتنی بر ویندوز

ابزار معرفی شده توسط مایکروسافت به نام (Advanced Threat Analytics (ATA قابلیت های متنوعی برای شناسایی فعالیت های مشکوک در شبکه ای مبتنی بر ویندوز ارائه می کنه. فرض بر اینه که کاربری در داخل شبکه با استفاده از قابلیت های Domain ویندوز، یا با استفاده از ابزارهای جانبی، سعی در جمع آوری اطلاعات ،شناسایی کاربران و سیستم های جذاب، و نفوذ به اون سیستم ها می کنه. این کاربر یا یک نفوذگر بیرونی بوده که در مرحله اول از نفوذ، جای پایی در داخل شبکه به دست آورده، یا کاربری در داخل شبکه با انگیزه نفوذ و سوء استفاده است. این راهنما، راه اندازی یک آزمایشگاه برای بررسی قابلیت های ATA رو به صورت قدم به قدم معرفی کرده. با توجه به اینکه ATA برای تشخیص نفوذ، به طور عمده از روش های مبتنی بر امضاء استفاده میکنه، و فرض کرده که در تمام انواع حملات، نفوذگر حتماً با Domain Controller تعامل خواهد کرد، راه هایی برای دور زدنش وجود داره. این ارائه در کنفرانس Brucon این راه ها رو بررسی کرده.

اشتراک گذاری

مدیریت لاگ و مرکز عملیات امنیت (۴)

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

سطح انتزاع (Abstraction) لاگ برنامه کاربردی در مفید بودن اون جهت مانیتورینگ امنیت نقش کلیدی ایفا می کنه. به عنوان مثال، در یک برنامه کاربردی وب، اینکه شما برای تحلیل یک حادثه به لاگ درخواست های HTTP دسترسی داشته باشید و داشبوردها و گزارش های متنوع رو از این لاگ در اختیار داشته باشید، در جای خودش مفید و لازم هست. اما در سطح انتزاع بالاتر، خیلی مهمه که لاگ مربوط به منطق کسب و کار اون برنامه رو در اختیار داشته باشید. اینکه کاربری در ساعت غیر اداری به برنامه لاگین کرده، یک سند ایجاد کرده، یک فاکتور رو برگشت زده، دسترسی کاربر دیگری رو به یک ماژول ایجاد کرده و غیره. هر یک از این رخدادها (که ممکن هست شامل چندین درخواست HTTP باشند) میتونن از لحاظ امنیتی اهمیت داشته باشن، به خصوص اگر در کنار هم و با داشتن اطلاعات دیگه ای مثل نوع و نقش کاربر، زمان، آدرس IP مبدأ و … مانیتور بشن. بسیاری از حمله ها و حتی تقلب ها رو میشه با پایش این رخدادهای حساس کشف کرد. اینکه کدام رخدادهای برنامه کاربردی از نظر امنیتی حساس هستند، کاملاً وابسته به کسب و کار هست.

بنابراین: اگر قرار هست که برای خرید یا توسعه یک نرم افزار به سازمانی کمک کنید، حتماً به امکانات ثبت و ارسال لاگ در سطوح مختلف (از زیرساخت برنامه مثل وب سرور و DBMS گرفته تا کسب و کار برنامه) توجه کنید. بدونید که یک برنامه با حداقل استانداردهای توسعه باید به شما امکان بده که لاگ در سطوح مختلف رو فعال و غیرفعال کنید و اون رو به فرمت ها و پروتکل های مختلف ذخیره، آرشیو و ارسال کنید.

یک راهنمای خوب در همین زمینه:

OWASP Logging Cheat Sheet

اشتراک گذاری

مدیریت لاگ و مرکز عملیات امنیت (۳)

همانطور که در دو یادداشت قبلی گفته شد، انتخاب درست منابع لاگ نقش بسیار مهمی در مفید بودن خروجی های تحلیلی سیستم مدیریت لاگ دارد. علاوه بر این، در هر یک منابع لاگ هم، باید آن بخش از لاگ ها که ارزشمندتر بوده و مستقلاً یا در کنار لاگ های دیگر، اطلاعات مفیدتری در بر دارند را جمع آوری کرد. مفید بودن لاگ ها بسته به اینکه کسب و کار مربوطه چیست و چه خط مشی هایی نیاز به پایش دارند، مشخص می شود. با این حال، الگوهایی وجود دارد که در قریب به اتفاق کسب و کارها، به پایش آنها نیاز داریم، در نتیجه باید لاگ های مناسبی که بتوان از تحلیل آنها به این الگوها دست یافت را جمع آوری کنیم. یکی از منابع جامع در این زمینه، سند SANS با عنوان Six Categories of Critical Log Information است. این شش رده را می شود به عنوان یک دسته بندی عمومی حداقلی برای تمام سازمان ها، فارغ از ماهیت کسب و کار، دانست. در هر لایه ای اعم از شبکه و برنامه های کاربردی، نیاز داریم که این نوع لاگ ها را جمع آوری کنیم تا از خروجی تحلیل آنها به حمله ها یا سوء استفاده های احتمالی برسیم.

شش رده گزارشی که باید لاگ مربوط به آنها در دسترس باشد عبارتند از:

  1. Authentication and Authorization Reports
  2. Systems and Data Change Reports
  3. Network Activity Reports
  4. Resource Access Reports
  5. Malware Activity Reports
  6. Failure and Critical Error Reports

هر کدام از این شش رده، در سطح تجهیزات شبکه و برنامه های کاربردی اهمیت خاص خود را دارند. به عنوان مثال، گزارش تغییرات در سیستم ها و داده ها (مورد ۲) برای کنترل عملکرد راهبران سیستم عامل ها، سرورها و تجهیزات شبکه کاربرد دارد. در یک شبکه بزرگ با صدها یا هزاران تجهیز، انجام این کنترل برای عیب یابی و ریشه یابی رخدادهای غیرمنتظره الزامی است. یا مثلاً تعداد لاگین های ناموفق به سیستم ها و تجهیزات، می تواند بیانگر حملات Brute Force علیه آنها باشد. فرض کنید با یک نمودار، تعداد لاگین های ناموفق در ۲۴ ساعت گذشته روی یک تجهیز یا سرور نمایش داده شود. اگر این تعداد به چند صد یا چند هزار برسد، به خصوص در صورت ثابت بودن IP مبدأ، با احتمال بالایی حمله Brute Force اتفاق افتاده است. از این طریق حتی ممکن است به یک یا چند IP مبدأ برسیم که خود این IP ها هم Compromise شده اند و صاحب IP از این موضوع اطلاع ندارد.

اشتراک گذاری

مدیریت لاگ و مرکز عملیات امنیت (۲)

در ادامه یادداشت قبلی در مورد انتخاب درست منابع لاگ مورد استفاده در مدیریت لاگ های امنیتی، باید به محدودیت های پردازشی و به خصوص ذخیره سازی اشاره کنیم. محدود بودن فضای نگهداری لاگ موضوعیست که تقریباً بدون استثنا در همه کاربردها و سازمان هایی با هر سایز، یک مسأله و چالش جدی هست. وقتی شما چندین فایروال، تعدادی نقطه دسترسی بی سیم، چند صد روتر و سوئیچ و ده ها برنامه کاربردی مهم دارید که هر کدام ارزش و اهمیت خاص خود رو در اعمال خط مشی های امنیتی سازمان دارند، طبعاً به حجم قابل توجهی فضای ذخیره سازی لاگ نیاز خواهید داشت. به خصوص که معمولاً نیاز دارید که لاگ برخی منابع، مدت قابل توجهی مثلاً یک یا چند ماه در دسترس باشند. به همین خاطر، امکان پیاده سازی به صورت توزیع شده و ایجاد کلاسترهایی از سیستم های مدیریت لاگ معمولاً در اغلب راه حل ها در نظر گرفته شده، که البته پیچیدگی های خاص خود رو هم داره. تعداد و حجم لاگ تولید شده در اکثر منابع لاگ اونقدر بالا هست که در صورت عدم بهینه سازی تنظیمات و عدم دقت به مورد کاربرد (Use case) مربوطه، به راحتی بخش عمده ای از توان پردازش و ذخیره سازی سیستم مدیریت لاگ رو درگیر کنه.
باید سطح لاگ گیری در هر منبع لاگ رو به طور دقیق تنظیم کرد تا لاگ اضافی ارسال نشه. همچنین بعضی تجهیزات مثل فایروال، امکان تولید لاگ به اضای هر قاعده (Rule) رو دارند، که باید در انتخاب قواهد ارزشمند برای تولید لاگ دقت کرد. در بعضی موارد، می شود یک مقدار آستانه برای لاگ های تکراری تعیین کرد، به طوری که مثلاً برای هر n رخداد تکراری، یک لاگ تولید بشه (این امکان در IDS ها خیلی مفید هست).

اشتراک گذاری

مدیریت لاگ و مرکز عملیات امنیت (۱)

مدیریت لاگ پیش نیاز و پایه مانیتورینگ امنیت و یکی از بدیهی ترین قدم هایی هست که باید در یک سازمان برای ورود به حیطه مانیتورینگ امنیت برداشته شود. همانطور که قبلاً اشاره کردم، اگر مدیریت لاگ سازمان به بلوغ کافی نرسیده باشه، صحبت از مرکز عملیات امنیت (SOC)، به معنای استفاده از SIEM، بیهوده خواهد بود. البته برخی علاقه دارند که همین پیش نیاز رو هم بخشی از مرکز عملیات امنیت در نظر بگیرند. دلیل این امر معمولاً این هست که مرکز عملیات امنیت مثل بسیاری از اصطلاحات دیگر در حیطه امنیت، به عنوان یک نانجی و راه حل همه مشکلات معرفی شده و مدیران اجرایی دراینگونه سازمان ها به شدت روی این اسم تأکید دارند. طبعاً برای بدنه فنی سازمان ها هم، موضوع SOC و خرید SIEM به اندازه کافی جذاب هست. فروشندگان هم که طبعاً ترجیح می دهند یک راه حل چند صد میلیون تومانی (در بهترین حالت) یا یک راه حل در مرتبه میلیارد تومانی رو بفروشند، تا اینکه شاهد تقلیل این معامله جذاب، به یک پروژه ارزان قیمت مدیریت لاگ باشند.
قبلاً در مورد اینکه یک سازمان به طور معمول چه مراحلی رو در موضوع مدیریت لاگ طی می کنه و به اصطلاح به تکامل می رسه، نوشته بودم . نکات متنوعی در موضوع مدیریت لاگ به طور عام، و مدیریت لاگ از دیدگاه امنیت، وجود داره که در اینجا و یادداشت های بعدی به چند موردش اشاره می کنم.
انتخاب درست منابع لاگ
در یک سازمان بزرگ، شما حداقل با چند صد تجهیز شبکه، ده ها یا صدها سرور با سیستم عامل های مختلف و ده ها برنامه کاربردی عمومی و داخلی مواجه هستید. هر کدام از این سیستم ها، از نظر ماهیت کاربران، اهمیت سیستم در کسب و کار، نقش سیستم در اجرای خط مشی های امنیتی سازمان و غیره با هم تفاوت دارند. طبعاً نمی شود و نباید در قدم های اول راه اندازی مدیریت لاگ، بسیاری از سیستم ها رو به عنوان منبع لاگ، وارد بازی کرد. پس برای اینکه بیشترین بهره و مفید ترین خروجی از مدیریت لاگ به دست بیاد باید منابع لاگ مناسب رو به ترتیب به این سیستم اضافه کرد. تجهیزات امنیتی از جمله فایروال، UTM ، سیستم AAA (مثل Cisco ACS یا Cisco ISE) و سنسورهای تشخیص نفوذ (IDS) از جمله منابعی هستند که در ابتدا باید به سراغ مدیریت لاگ های اونها رفت. ممکن است بعضی برنامه های کاربردی هم وجود داشته باشند که امنیت اونها از اهمیت فوق العاده برخوردار است و به نوعی هسته کسب و کار سازمان در این برنامه ها پیاده سازی شده باشه. این برنامه ها هم، در صورتی که لاگ مناسبی تولید کنند، جزو اولین گزینه ها برای مدیریت لاگ هستند. ممکنه در اضافه کردن بعضی از منابع مهمی که اشاره کردیم به سیستم مدیریت لاگ، چالش هایی وجود داشته باشه از جمله مناسب نبودن مکانیزم جمع آوری لاگ در اون منبع خاص یا مناسب نبود فرمت و سطح لاگ تولید شده، که در جای خودش به اونها اشاره خواهیم کرد.

اشتراک گذاری

مروری بر کنفرانس RSA 2016

کنفرانس سالانه RSA که در بیست و پنج سال گذشته به طور مداوم توسط شرکت RSA (متعلق به EMC) برگزار شده را می توان معتبرترین و مورد قبول ترین کنفرانس مربوط به مارکت امنیت دانست. کنفرانس امسال هم با عنوان RSAC 2016 و با شعار “اتصال برای حفاظت: Connect to Protect” از ۲۹ فوریه تا ۴ مارس برگزار شد و مطابق معمول از بزرگ ترین شرکت ها تا استارتاپ ها در نمایشگاه آن شرکت کردند. در کنار نمایشگاه، انبوهی از ارائه های تخصصی، مسابقات، سخنرانی های کلیدی و غیره توسط افراد و شرکت های صاحب نظر برگزار شد.

مجموعه اسلایدهای ۳۰۲ ارائه برگزار شده در اینجا در دسترس هست. 

همچنین ویدئوی نوزده سخنرانی کلیدی کنفرانس هم در اینجا در دسترس است. یکی از سخنرانی های کلیدی مورد علاقه من، نگاهی به آینده: مرکز عملیات امنیت سال ۲۰۲۰

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

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

اشتراک گذاری

برای علاقه مندان به مطالب جدید

اگر به موضوعات دست اول و جدید و شخصیت های جهانی مورد احترام در دنیای امنیت اطلاعات علاقه دارید، کنفرانس Usenix Enigma برای شما است! کافی است به برنامه کنفرانس، شامل سخنران ها و محتوای هر سخنرانی (که به رایگان در دسترس است) نگاهی داشته باشیم: پروفسور ویگنا (استاد دانشگاه سانتا باربارا و یکی از نظریه پردازان اصلی سیستم های تشخیص نفوذ و مرکز عملیات امنیت)، پریسا تبریز (از تیم امنیت گوگل)، ران ریوست (R الگوریتم RSA، دانشمند رمزنگاری از دانشگاه MIT)، راب جویس (مدیر برنامه TAO آژانس امنیت ملی آمریکا) و …

اشتراک گذاری

ارتباط بین مرکز عملیات امنیت و مرکز پاسخ به حوادث: فاصله بین شناسایی و پاسخ

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

اما صرفنظر از جنبه شکلی این ارتباط، باید بر اهمیت جنبه ماهوی و فرآیندی این دو مرکز تأکید شود. بخش بسیار مهمی از فرآیند امنیت اطلاعات عبارت است از شناسایی (Detection) و پاسخ (Response) که هر دو نهاد SOC و CERT بیشترین نقش را در این دو بخش بر عهده دارند. طبعاً یکی از پاسخ هایی که انتظار می رود در طراحی SOC وجود داشته باشد، میزان سهم و مسئولیت هر یک از دو نهاد در شناسایی و پاسخ است.

در همین زمینه به نکته کلیدی زیر از این یادداشت توجه کنید:

If your SOC and CIRT (at the higher end of the organizational security maturity) work really well – but not together – the chance that the attacker will WIN and you will LOSE is still very high, despite all the technology investments.

اشتراک گذاری

چند داشبورد و نقشه از رخدادهای امنیتی

http://www.sicherheitstacho.eu

http://map.ipviking.com

https://isc.sans.edu/dashboard.html

https://www.fireeye.com/cyber-map/threat-map.html

http://cybermap.kaspersky.com

https://www.trustworthyinternet.org/ssl-pulse/

http://atlas.arbor.net/

اشتراک گذاری

سرویس جدید پاسخ به حوادث سیسکو

سرویس Advanced Malware Protection سیسکو (AMP) که بعد از خرید SourceFire توسط سیسکو به خدمات امنیتی این شرکت اضافه شده حالا طبق اعلام این شرکت با سرویس Threat Grid ترکیب شده تا خدمات مختلف Threat Intelligence را در مجموعه خدمات پاسخ به حوادث سیسکو ارائه کند.

اشتراک گذاری