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

تحلیل رفتار کاربر: مورد “اوبر”

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

  • ایجاد یک فنس جغرافیایی در اطراف مکان های مربوط به مشتریان فوق،
  • مانیتور کردن کاربرانی که به طور مداوم، اپ اوبر را باز و بسته می کنند،
  • بررسی اطلاعات کارت اعتباری کاربر و شناسایی مواردی که به نهادهای مالی پلیس مربوط هستند،
  • شناسایی تلفن های متعدد متعلق به یک شخص،
  • بررسی پروفایل مشتری در شبکه های اجتماعی

بعضی از موارد بالا در حیطه تحلیل رفتار کاربر (User Behavior Analytics) قرار می گیرند، که شاخه مهمی در مانیتورینگ امنیت به حساب می آید.

اشتراک گذاری

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

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

سطح انتزاع (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 از این موضوع اطلاع ندارد.

اشتراک گذاری

بدافزار اندرویدی برای حمله به شبکه بی سیم

یک بدافزار جدید با نام Trojan.AndroidOS.Switcher از طریق آلوده کردن سیستم عامل اندروید، تلاش می کنه شبکه Wi-Fi سرویس دهنده به دستگاه آلوده رو هک کنه. این کار از طریق نفوذ به روتر بی سیم یا Wi-Fi با استفاده از حمله Brute force انجام می شه. بنابراین اگر پسورد پیش فرض روتر بی سیم عوض نشده باشه یا پسورد اون ضعیف باشه، بدافزار با لاگین کردن به روتر، تنظیمات DNS دستگاه رو عوض می کنه. این در واقع یک حمله سرقت DNS یا DNS Hijacking هست. در نتیجه، درخواست های DNS ارسالی از کلاینت های متصل به شبکه Wi-Fi ، به سرورهای مدنظر نفوذگر ارسال خواهد شد.
بر اساس اعلام کسپرسکی، این بدافزار به دوشکل ظاهر می شه، یکی به عنوان کلاینت موبایل موتور جستجوی چینی بایدو (Baidu) و دیگری به شکل یک برنامه موبایل پرطرفدار چینی که برای اشتراک گذاری اطلاعات مربوط به شبکه های Wi-Fi عمومی استفاده می شه. وقتی بدافزار به طور خودکار به روتر یا نقطه دسترسی بی سیم لاگین کرد و تنظیمات DNS رو عوض کرد، به تدریج تمام درخواست های DNS از اون شبکه بی سیم به سمت سرورهای مدنظر نفوذگر خواهد رفت. از اینجا به بعد انواع حملات از فیشینگ گرفته تا آلوده سازی شبکه با بدافزارهای دیگر قابل اجرا هست.
اگر ترافیک DNS به مقصد آدرس های IP زیر در شبکه مشاهده کردید، حتماً دستگاهی آلوده به این بدافزار در شبکه وجود داره:

۱۰۱٫۲۰۰٫۱۴۷٫۱۵۳
۱۱۲٫۳۳٫۱۳٫۱۱
۱۲۰٫۷۶٫۲۴۹٫۵۹
مانیتور کردن درخواست های خروجی DNS بسیار مهم هست و مثال بالا یکی از دلایل این اهمیت هست. این کار رو می شه با استفاده از سنسور IDS (تشخیص نفوذ) در داخل شبکه یا روی Gateway انجام داد. همچنین تعویض پسورد پیش فرض تجهیزات شبکه وایرلس و استفاده از پسوردی که به راحتی قابل Brute force نباشه از دیگر تمهیدات مقابله با این بدافزار هست.

اشتراک گذاری

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

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

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

اشتراک گذاری

ابزاری برای مشاهده فایل های باز شده از شبکه

با ابزار Networkopenedfiles می توانید فایل هایی که در حال حاضر از طریق شبکه روی کامپیوتر شما باز شده را مشاهده کنید.

 

اشتراک گذاری

عادل کریمی و هانی پات!

عادل کریمی اسلایدهای ارائه خودش در جلسه ماهانه Ruxmon در سیدنی رو درباره هانی پات ها برای دانلود قرار داده. این اسلایدها به صورت مفید و مختصر داستان هانی پات و روندهای جدید اون رو ذکر می کنه.

آشنایی من با عادل به وبلاگ امنیت وب (websecurity.ir) یعنی حدود ۱۰ سال پیش بر میگرده و بعد از اون در پروژه های متعددی با هم همکاری داشتیم. عادل علاوه بر اینکه یک متخصص حرفه ای امنیت هست، یک عکاس فوق العاده هم هست و میتونید از دیدن عکسهاش در پس زمینه فایل ارائه لذت ببرید.

اشتراک گذاری

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

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

اشتراک گذاری

بررسی شهرت آدرس ها با استفاده از سرویس های رایگان

یکی از ابزارهای مورد نیاز برای مقابله با تهدیدهای امروزی برای یک شبکه بزرگ، مدیریت دسترسی آدرس های IP خارجی بر اساس شهرت (Reputation) آنها است. این یکی از جنبه های هوش امنیتی (Security Intelligence) است که کمک می کند آدرس های IP بدخواه که از نفوذگر بودن آنها مطمئن هستیم را در لبه شبکه شناسایی و مسدود کرده و در نتیجه لایه های داخلی شبکه را از درگیری با این آدرس ها معاف کنیم. برای این منظور، سرویس های رایگان متعددی در اینترنت وجود دارد. به عنوان مثال:

www.ipvoid.com و http://anti-hacker-alliance.com

این دو سرویس، رابطی بین شما و تعدادی از لیست های سیاه عمومی هستند که با جستجوی یک IP در آنها و اطمینان از اینکه بدخواه است، می توانید آن را در لیست سیاه شبکه خود قرار دهید.

اشتراک گذاری

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

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/

اشتراک گذاری