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

مرکز پاسخ به حوادث بهداشت و سلامت

Z-cert مرکز فوریت های رایانه ای یا پاسخ به حوادث امنیتی در حوزه بهداشت و سلامت کشور هلند است. این مرکز، خدماتی در راستای امنیت سایبری و مدیریت حوادث برنامه های کاربردی، شبکه و تجهیزات پزشکی و سلامت به بیمارستانها، کلینیک ها و دیگر سازمانهای این صنعت ارائه می کند.

در کشورهای دیگری از جمله نروژ و انگلستان هم CSIRT بهداشت و سلامت وجود دارد.

اشتراک گذاری

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

از بین ده ها مسأله ای که در طراحی مرکز عملیات امنیت در یک سازمان دارای سطح بلوغ قابل قبول باید حل شود، مسأله جایگاه 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.

اشتراک گذاری

یک نمونه فارنزیک در ویندوز

فرمان های net use و net view دو ابزاری هستند که احتمال استفاده از آنها در یک سیستم هک شده یا آلوده به بدافزار زیاد است. این دو فرمان که در خط فرمان ویندوز (cmd) قابل اجرا هستند، به ترتیب برای وصل شدن به یا قطع شدن از یک سیستم راه دور و نیز برای مشاهده سیستم های متصل به کار می روند. 

برای اطلاع از اینکه آیا این دو فرمان در سیستم اجرا شده اند یا خیر، دو موضوع را باید بررسی کرد:

۱- آیا در دایرکتوری Prefetch ویندوز، فایلی که نشان دهنده اجرای آنها باشد ایجاد شده است؟

۲- آیا در مجموعه event log های ویندوز، رخدادی مبتنی بر اجرای این فرمان ها ثبت شده است؟

برای این کار دو ابزار وجود دارد:

Microsoft Log Parser 2.2

Nirsoft WinPrefetchView v1.25

نحوه استفاده از این دو ابزار برای حل مسأله فوق در اینجا ذکر شده است.

اشتراک گذاری

OpenSOC: راه حل متن باز SOC سیسکو

سیسکو اعلام کرده که پروژه پایش و تحلیل داده های امنیتی در مقیاس بزرگ (Big Data) را با عنوان OpenSOC تحت لایسنس آپاچی توسعه خواهد داد.

این پلتفرم قرار است تا ۱٫۲ میلیون بسته در ثانیه را به صورت عمیق پردازش کند. این به معنای جمع آوری و تحلیل ۵۰ ترابایت اطلاعات در روز است. به وضوح مشخص است که سیسکو بعد از پایان دادن به فروش محصول SIEM خود با نام Cisco Mars ، برای ورود قدرتمند به بازار پایش امنیت و مرکز عملیات امنیت به دنبال ارائه پاسخ به چالش اصلی این بازار یعنی پردازش در سطح Big Data است. سیسکو از مجموعه ابزارهای Apache Hadoop برای ایجاد این چارچوب استفاده کرده است.

برای راه اندازی OpenSOC باید اجزای زیر راه اندازی شوند:

  • ۲ Network Capture Cards (Recommend Napatech NT20E2-CAP)
  • Apache Flume 1.4.0 +
  • Apache Kafka 0.8.1+
  • Apache Storm 0.9 +
  • Apache Hadoop 2.x (any distribution)
  • Apache Hive 12 + (13 recommended)
  • Apache Hbase 0.94+
  • Elastic Search 1.1 +
  • MySQL 5.6+

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

اشتراک گذاری

ارتباط سیستم مدیریت امنیت اطلاعات و مرکز عملیات امنیت

بسیاری از افراد این سوال برایشان پیش می آید که ارتباط سیستم مدیریت امنیت اطلاعات (ISMS) و مرکز عملیات امنیت (SOC) چیست؟ آیا یکی پیشنیاز دیگری است؟ آیا استقرار یکی مستلزم استقرار دیگری است؟ آیا این دو کلاً مستقل هستند و به دو حوزه متفاوت می پردازند؟

از چند منظر می شود ارتباط بین ISMS و SOC را توضیح داد.

۱- سیستم مدیریت امنیت اطلاعات بر دیدگاه “فرآیند ـ محور” نسبت به امنیت اطلاعات تأکید دارد. یکی از اهداف مهم این سیستم، استقرار فرآیندهای اصلی امنیت اطلاعات از جمله “پایش امنیت” در محدوده ISMS است. فرآیند پایش امنیت یکی از کارکردهای اولیه مرکز عملیات امنیت است. در نتیجه، با استفاده از SOC می توان برخی فرآیندهای مهم امنیت اطلاعات را که مدنظر ISMS هم هست، در سازمان مستقر کرد. البته این به آن معنی نیست که این فرآیندها الزاماً باید در قالب SOC پیاده سازی شوند.

۲- محدوده فیزیکی و منطقی استقرار سیستم مدیریت امنیت اطلاعات در یک سازمان می تواند دربرگیرنده بخش هایی مثل شبکه داخلی، سرویس های اینترنتی، مرکز داده و غیره باشد. به همین ترتیب، SOC سازمان هم می تواند جزئی از محدوده ISMS باشد. یعنی سازمان می تواند ISMS را در SOC خود پیاده سازی کرده و گواهی ISO 27001 را در این محدوده دریافت کند.

به نظرم یکی از ریشه های اینگونه پرسش ها، نگاه “پروژه ـ محور” به مقوله امنیت اطلاعات است. به طور مشخص، خیلی از سازمان ها در چند سال گذشته روی استقرار سیستم مدیریت امنیت اطلاعات تمرکز داشته اند. فارغ از اینکه این پروژه در آن سازمان ها موفق بوده یا خیر، این سوء تفاهم در بسیاری ایجاد شده که امنیت اطلاعات برابر است با ISMS . حالا که همین نگاه اشتباه در برخی افراد نسبت به SOC وجود دارد، طبعاً پرسشهایی از قبیل فوق به ذهن می رسد.   

اشتراک گذاری

یکی از چالشهای SIEM در سیستم های برونسپاری شده

در بحث راه اندازی مرکز عملیات امنیت (SOC) ، راه اندازی و عملیاتی کردن SIEM از اهمیت حیاتی برخوردار بوده و نباید به آن صرفاً به عنوان نصب یک محصول جدید در شبکه نگاه کرد.

یکی از چالش هایی که می تواند راه اندازی موثر SIEM را با مشکلات جدی مواجه کند، نبود لاگ های مناسب است. در واقع با وجود لاگ های مناسب و کافی می توان انتظار داشت که SIEM قابلیت های خود را نشان دهد.

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

اشتراک گذاری

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

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

اشتراک گذاری