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

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

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

سطح انتزاع (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) از جمله منابعی هستند که در ابتدا باید به سراغ مدیریت لاگ های اونها رفت. ممکن است بعضی برنامه های کاربردی هم وجود داشته باشند که امنیت اونها از اهمیت فوق العاده برخوردار است و به نوعی هسته کسب و کار سازمان در این برنامه ها پیاده سازی شده باشه. این برنامه ها هم، در صورتی که لاگ مناسبی تولید کنند، جزو اولین گزینه ها برای مدیریت لاگ هستند. ممکنه در اضافه کردن بعضی از منابع مهمی که اشاره کردیم به سیستم مدیریت لاگ، چالش هایی وجود داشته باشه از جمله مناسب نبودن مکانیزم جمع آوری لاگ در اون منبع خاص یا مناسب نبود فرمت و سطح لاگ تولید شده، که در جای خودش به اونها اشاره خواهیم کرد.

اشتراک گذاری

بررسی لاگ مدیریت کاربران در پاورشل

با استفاده از فرمان زیر در پاورشل، لاگ نام های کاربری ایجاد شده در سیستم و کاربران اضافه شده به گروه ها مشاهده می شود:

Get-WinEvent -FilterHashtable @{LogName=”Security”;ID=4720,4732,4728}

اشتراک گذاری

مدیریت لاگ، پیش نیاز راه اندازی مرکز عملیات امنیت

اگر یک سیستم مدیریت لاگ عملیاتی و قابل استفاده ندارید، شما به هیچ عنوان کاندیدای استفاده از SIEM و راه اندازی SOC نیستید. این موضوع آنقدر بدیهی بوده و در دنیا پذیرفته شده است که اساساً SIEM را به نوعی تکامل یافته مدیریت لاگ می دانند. صرفاً سازمانی که  با معضل مدیریت لاگ به صورت عملی و در مقیاس بزرگ درگیر شده باشد این موضوع را درک می کند. کم نیستند سازمان هایی که حتی یک IP Plan مشخص و درست ندارند چه رسد به مدیریت لاگ، و الان در پی خرید SIEM هستند. 

اشتراک گذاری