بایگانی ماهیانه: بهمن ۱۳۹۵

مطرح شدن ایران در Cryptographers’ Panel رویداد RSA2017

این روزها رویداد RSA2017 در حال برگزاری است. یکی از برنامه های ثابت این رویداد، پنل رمزنگاران یا Cryptographers’ Panel هست که هر سال برگزار می شود و معمولاً صاحبنظران رمزنگاری در آن حضور دارند.

فیلم برنامه امسال با شرکت بزرگانی چون Adi Shamir، Ronald Rivest، Whitfield Diffie در اینجا قابل مشاهده است. یکی از نکات جذاب این پنل، بحثی است که Adi Shamir درباره یک پروژه تحلیل رمز مربوط به استاد دانشگاه صنعتی شریف (احتمالاً دکتر عارف*) مطرح می کند. صرفنظر از صحت و سقم موضوع، مطرح شدن این موضوع در پنل مربوطه جالب توجه است. این بحث رو در دقیقه ۲۷ مشاهده کنید.

* مقاله دکتر عارف و بهنام بهرک (A Novel Impossible Differential Cryptanalysis of AES):

https://www.emsec.rub.de/media/crypto/veroeffentlichungen/2011/01/29/PreliminaryConferenceRecord.pdf

و دومی مقاله ای که روش حمله مقاله اول بهبود داده شده، و اسم حمله مقاله اول رو  Bahrak-Aref Attack گذاشتن:

https://eprint.iacr.org/2008/540.pdf

اشتراک گذاری

جایگاه و وظایف مدیر ارشد امنیت اطلاعات (CISO)

[این یادداشت در شماره ۷۲ ماهنامه بانکداری الکترونیک منتشر شده است. دانلود فایل]

مدیر ارشد امنیت اطلاعات (CISO) [1] بالاترین مقام اجرایی در حوزه امنیت سازمان است که مدیریت و راهبری کلیه مسائل فنی و اجرایی امنیت را برعهده دارد. آمارهای جهانی نشان از رشد تقاضا برای به خدمت گرفتن افراد در جایگاه CISO داشته و پیش بینی می­شود که این رشد در چند سال آینده نیز ادامه داشته باشد.

به طور کلی CISO یک شغل تمام وقت با اختیارات کامل در حوزه امنیت فناوری و نیز مدیریت ریسک­های امنیتی و مسائل اجرایی امنیت است. در برخی سازمان­ها، CISO مستقیماً به بالاترین مقام اجرایی یعنی مدیر عامل یا پاسخ می­دهد. در برخی دیگر از سازمان­ها این جایگاه می­تواند ذیل CTO یا CIO تعریف شود. طبعاً یک فرمول ثابت برای تعیین جایگاه CISO وجود ندارد و هر سازمانی بر اساس ماهیت کسب و کار، اندازه سازمان و چارت سازمانی فعلی خود باید در این خصوص تصمیم گیری کند.

یک پرسش اساسی این است که بر اساس استاندارد ایزو ۲۷۰۰۱ ، جایگاه و شرح وظایف CISO کدام است؟ شاید در نگاه اول عجیب به نظر برسد، اما باید اذعان کرد که ایزو ۲۷۰۰۱ هیچ الزامی برای وجود جایگاه CISO در چارت سازمانی در نظر نگرفته است. اما دلیل این موضوع چیست؟ همواره تأکید شده که این استاندارد برای تمام سازمان­ها مستقل از ماهیت، اندازه و دیگر ویژگی­های کسب و کار تدوین شده است. در نتیجه، منطقی نیست که یک  سازمان­ کوچک را مجبور به ایجاد یک جایگاه مستقل در سطح معاونت یا مدیریت ارشد به عنوان CISO کرد.

در سازمان­های کوچک، نقش CISO را باید به یکی از مدیران موجود در چارت سازمانی تخصیص داد. به عنوان مثال، برای یک سازمان ۱۰ تا ۱۰۰ نفری، راهبر شبکه یا مدیر فناوری اطلاعات می­تواند این نقش را در کنار دیگر وظایف خود ایفا کند. اما اگر سازمان شما صدها یا چندهزار پرسنل دارد، به طور طبیعی باید فردی به صورت تمام وقت و اختصاصی به مدیریت امنیت بپردازد.

وظایف عمومی CISO

از آنجا که ایزو ۲۷۰۰۱ توصیه صریحی برای ایجاد جایگاه CISO ندارد، این بر عهده خود سازمان است که چگونه و تحت چه جایگاهی به مدیریت امنیت اطلاعات بپردازد. با این حال، می­توان بر اساس الزامات مختلف ایزو ۲۷۰۰۱، وظایف CISO را در عنوان­های زیر دسته بندی کرد:

  • سازگاری و تطبیق
    • تعیین و مستندسازی ذینفعان امنیت و انتظارات آنها
    • برقراری ارتباط دائمی با ارگان­های حاکمیتی و ذینفعان خاص
    • ایجاد هماهنگی در اجرای الزامات حریم خصوصی
  • مستندسازی
    • پیشنهاد الگوی مستندات اصلی ایزو ۲۷۰۰۱
    • مسئولیت بازبینی و بروزرسانی دائمی مستندات
  • مدیریت مخاطرات
    • تدوین و آموزش روش ارزیابی ریسک
    • راهبری فرآیند ارزیابی ریسک
    • پیشنهاد کنترل­های امنیتی
    • زمانبندی پیاده سازی کنترل­های امنیتی
  • مدیریت منابع انسانی
    • طرحریزی آموزش و فرهنگ سازی امنیت
    • پیشنهاد نحوه برخورد با موارد نقض امنیت توسط پرسنل
    • انجام بررسی پیشینه افراد برای استخدام
  • ارتباط با مدیریت ارشد
    • تعامل با مدیران ارشد در خصوص آثار مثبت امنیت
    • پیشنهاد و تدوین اهداف امنیت
    • گزارش سنجش­ها و اندازه گیری­ها
    • پیشنهاد اقدامات اصلاحی و بهبودها در حوزه امنیت
    • پیشنهاد بودجه امنیت
    • هشدار به مدیران ارشد درباره مهم­ترین ریسک­ها
    • مشاوره به مدیران ارشد درباره کلیه موضوعات امنیت
  • مدیریت دارایی­ها
    • نگهداری سیاهه (لیست) دارایی­های حیاتی سازمان
    • راهبری شیوه امحاء امن دارایی­ها
  • مدیریت حوادث امنیتی
    • طراحی و اجرای ملزومات جمع آوری حوادث امنیتی
    • راهبری پاسخ به حوادث
    • جمع­آوری شواهد برای ارائه به مراجع قانونی
    • تحلیل حوادث
  • تداوم کسب و کار
    • راهبردی طرح تداوم کسب و کار
    • راهبری تست­ها و مانورها
  • موضوعات فنی
    • تایید روش محافظت از دارایی­ها
    • پیشنهاد روش­های احراز هویت، محافظت از اطلاعات، رمزنگاری و غیره
    • پیشنهاد قواعد امنیتی دورکاری
    • تدوین اصول توسعه امن سامانه­ها

ویژگی­های یک کاندیدای مناسب برای CISO

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

[۱] Chief Information Security Officer

اشتراک گذاری

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

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

اشتراک گذاری

آسیب پذیری جدید SMB ویندوز منجر به حمله DoS

یک آسیب پذیری جدید با شناسه CVE-2017-0016 در نسخه های مختلف ویندوز منتشر شده که ناشی از مدیریت نامناسب ترافیک پروتکل SMB بوده و منجر به ریبوت شدن سیستم عامل میشود. گفته شده که یک سیستم ویندوز ۱۰ که به طور کامل به روز هم شده، نسبت به این حمله آسیب پذیر است. اگر سیستم قربانی به یک سرور SMB تحت کنترل نفوذگر متصل شود، Crash کرده و ریبوت خواهد شد. این اتصال می تواند توسط خود قربانی یا به صورت خودکار با بارگذاری یک شیء، مثلاً یک تصویر، که به این سرور اشاره می کند، انجام شود. تا این لحظه اصلاحیه ای برای این آسیب پذیری منتشر نشده، با این حال برای کاهش ریسک آن باید ترافیک Outbound (خارج شونده) شبکه روی پورت های SMB را مسدود کرد. این کار البته به طور معمول در پیکربندی فایروال یا ابزارهای دیگر لبه شبکه، توصیه می شود.

اشتراک گذاری

ابزاری جدید برای بازیابی حساب کاربری

رویداد Enigma 2017، از سری کنفرانس های انجمن Usenix، در حال برگزاریست و نگاهی به برنامه و سخنران ها نشان از جذابیت این کنفرانس دارد. فیسبوک در این رویداد از یک پروتکل جدید به نام Delegated Recovery برای حساب های کاربری رونمایی کرد. هدف این پروتکل، ارائه روشی امن و ساده برای بازیابی حساب کاربری به جای روش سنتی استفاده از ایمیل یا تلفن همراه است. به بیان ساده، با داشتن یک حساب فیسبوک و یک حساب گیت هاب (Github)، می توانیم از یک حساب به عنوان ابزار بازیابی حساب دیگر استفاده کنیم. روش کار به این شکل هست که یک توکن با حساب گیت هاب می سازیم که بعداً در حساب فیسبوک ما ذخیره می شود. وقتی پسورد گیت هاب رو فراموش کردیم، با ورود به حساب فیسبوک و استفاده از این توکن، گیت هاب صاحب حساب از دست رفته رو شناسایی می کنه. البته فیسبوک توضیح داده که هویت صاحب واقعی حساب در سایت مبدأ، برای سایت مقصد پنهان باقی خواهد ماند. این ابزار به صورت متن باز ارائه شده و جزئی از برنامه باگ باونتی فیسبوک هم هست.

اشتراک گذاری

رونمایی از عامل انتشار Mirai

Brian Krebs که یکی از اولین قربانیان حملات DDoS بدافزار Mirai بوده، در یک یادداشت طولانی در وبسایت خودش، از هویت نفر اصلی مسئول Mirai و کسی که این حملات رو انجام داده، پرده برداری کرده. یادداشت پر از نکات جالب و جذاب برای افراد علاقمند هست. Brian Krebs از مجموعه شواهد نتیجه گیری کرده که مسئول این بدافزار یک دانشجوی بیست ساله دانشگاه Rutgers به نام Paras Jha بوده که اتفاقاً مدیر یک شرکت ارائه دهنده خدمات مقابله با DDoS به نام ProTraf است.


بعد از گزارش Krebs ، حالا خبر رسیده که این فرد توسط FBI هم در همین زمینه بازجویی شده.

اشتراک گذاری

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

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

اشتراک گذاری