موارد مهمی که در مانیتورینگ Endpoint می توان مشاهده کرد:

•چه سرویس پورت هایی باز است؟
•چه آسیب پذیری ها و Exploit هایی وجود دارد؟
•چه برنامه غیرمجازی نصب شده است؟
•کدام فایل های حساس سیستم تغییر کرده اند؟
•چه برنامه و اسکریپت های آلوده ای اجرا شده اند؟
•چه ارتباطاتی با این سیستم برقرار شده است؟

به طور کلی بررسی رجیستری، پروسه های در حال اجرا، سرویس ها و ارتباطات با سیستم قربانی و ارزیابی آسیب پذیری از مهمترین اقدامات در مانیتورینگ سیستم می باشند.

Important things that can be seen in Endpoint monitoring:

•What service ports are open?
•What vulnerabilities and exploits are there?
•What unauthorized program is installed?
•Which sensitive system files have changed?
•What infected programs and scripts were executed?
•What connections have been established with this system?

In general, checking the registry, running processes, services and communication with the victim's system, and vulnerability assessment are among the most important measures in system monitoring.

#SOC
#BlueTeam

T.me/ICTlive

عموما چه لاگ هایی باید وارد ابزار SIEM شوند:

• Log سیستمی: log های مربوط به احراز هویت ها، AV، HIDS، Sysmon، DLP، آسیب پذیری ها، log برنامه ها، OS و EDR.
• Log شبکه: waf، router، switch، NIDPS، firewall، service log ها(مانندDHCP, DNS HTTP(S), SMTP, SMB, FTP, SSH, Kerberos)

نکته: traffic capture ها و netflow قبل از وارد شدن به ابزار SIEM می بایست تبدیل به log مطلوب شوند.

Generally, what logs should be entered into the SIEM tool:

• System log: logs related to authentication, AV, HIDS, Sysmon, DLP, vulnerabilities, program log, OS and EDR.
• Network log: waf, router, switch, NIDPS, firewall, service logs (such as DHCP, DNS HTTP(S), SMTP, SMB, FTP, SSH, Kerberos)

Note: traffic captures and netflow must be converted to the desired log before entering the SIEM tool.

#SOC
#BlueTeam

t.me/ICTlive

رویداد(Event): هر عملی که در شبکه و سیستم اتفاق می افتد.
هشدار(Alert): هر Event ای که غیرمجاز و بدون احراز هویت باشد.
رخداد امنیتی(Incident): هرگونه نقض سیاست و یا نقض استاندارد امنیتی .(incident ها غالبا روی محرمانگی تاثیر می گذارند).

در مورد Alert و بررسی انواع آن در یک مرکز SOC، در پست بعدی توضیح خواهیم داد.

•Event: Any action that happens in the network and system.
•Alert: Any event that is unauthorized and without authentication.
•Incident: any policy or security standard violation. (incidents often affect confidentiality).
We will explain about Alert and checking its types in a SOC in the next post.

#SOC
#BlueTeam

t.me/ICTlive

جمع آوری Event ها:
باید در نظر داشت که ابزار های SIEM روی حجم داده و EPS دارای لایسنس هستند و به همین دلیل جست و جو روی دیتای اضافی سربار زیادی ایجاد می کند. احتکار داده و یا جمع آوری کل داده به صورت بی هدف تکنیک درستی برای تشخیص درست نیست.
دریافت log از تمامی Event اهمیت چندانی نخواهند داشت.
ولی دریافت log از alert می تواند شامل log هایی باشد که از سامانه های امنیتی نظیر IDS،Firewall، AV و ... باشد. که این log ها نشانه ای از هشدار است.
به همین دلیل استفاده از یک سامانه جهت تریاژ کردن Alert ها می تواند کمک بسیار زیادی در کاهش (false positive)FP کند. به عبارت دیگر log های سامانه های امنیتی را قبل از اینکه به سرویس Ticketing برای بررسی بفرستیم، ابتدا وارد یک سامانه تریاژ هشدار کنیم تا میزان بار کاری کم شود.
نمونه ای از این سامانه ها را میتوان به Sguil اشاره کرد.

Collect events:
It should be kept in mind that SIEM tools are licensed on data volume and EPS, and therefore searching for additional data creates a lot of overhead.
Hoarding data or collecting all data aimlessly is not the right technique for correct detection. Receiving logs from all events will not be very important. But receiving logs from alert can include logs from security systems such as IDS, Firewall, AV, etc. These logs are a sign of warning.
For this reason, using a system to triage alerts can greatly help in reducing FP(false positive). In other words, before sending the logs of the security systems to the ticketing service for review, we should first enter a triage system to reduce the workload. Sguil is an example of these systems.


#SOC
#BlueTeam

t.me/ICTlive

علت دیگر استفاده از سرویس های تریاژ Alert می تواند عدم وجود نیروی کافی جهت بررسی همه alert ها در siem باشد. می دانیم که یکی از مهمترین مشکلات Alert log میزان حجم بالای آن ها می باشد. که در صورت عدم استفاده از سامانه های تریاژ alert، با FP بسیار بالا روبرو خواهیم شد و عملا مرکز SOC در رسیدگی به آن ناتوان خواهد ماند.(مگر در صورتی که وقت و تعداد نیروی کافی داشته باشد).

Another reason for using alert triage services can be the lack of enough people to check all alerts in siem.
We know that one of the most important problems of Alert log is their high volume. If we do not use alert triage systems, we will face a very high FP and the SOC will be unable to deal with it (unless it has enough time and number of people).

#SOC
#BlueTeam

T.me/ICTlive

در ادامه مبحث alert log ها، با دو نوع Alert log برخورد می کنیم:

مبتنی بر امضا: بر پایه black list ها هستند. مانند پروتکل های آلوده، URL، آدرس IP، file hash و ... .
معمولا alert هایی که از waf، IDS، AV، Firewall دریافت می شود از نوع مبتنی بر امضا هستند.

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

معمولا alert هایی که از ILP(Information Loss Prevention)، (در برخی موارد مشاهده می شود که دسترسی خاصی ایجاد و یا فایل exe دانلود شده است)IDS و UBA(User Behavior Analysis) دریافت می شود از نوع مبتنی بر رفتار هستند.

In the continuation of the topic of alert logs, we deal with two types of alert logs:

•Signature-based: based on black lists. Such as infected protocols, URL, IP address, file hash, etc.
Usually, the alerts received from waf, IDS, AV, Firewall are signature-based.

•Based on behavior: they appear in a behavioral way. For example, a user login in from another place after a long time. Or a heavy upload occurs in the network. Or a user who has not logged in for a long time suddenly login.
Usually, the alerts received from ILP (Information Loss Prevention), (in some cases it is seen that a special access has been created or an exe file has been downloaded), IDS and UBA (User Behavior Analysis) are based on behavior.

#SOC
#BlueTeam

T.me/ICTlive

حال مفهوم correlation مطرح می شود. راهی که بتوان از چندین Alert به یک همبستگی برای شناسایی تهدید رسید.

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

معمولا وقتی یک policy نقض می شود، آنومالی بوجود می آید و موقعی که یک چک لیست نقض شود یک هشدار مبتنی بر امضا داریم.

Now the concept of correlation comes up. A way to reach a correlation from several Alerts to detection the threat.

Every anomaly is not just pollution, but every pollution is definitely an anomaly. For example, high uploading in the network is abnormal, but maybe a legitimate user is allowed to upload. So there is no pollution, but the opposite is true and pollution brings anomaly.

Usually, when a policy is violated, an anomaly occurs, and when a checklist is violated, we have a signature-based alerting.

#SOC
#BlueTeam

T.me/ICTlive

چند مفهوم مهم:
مفهوم False positive: به این معنی که ترافیک سالم به عنوان ترافیک مخرب شناسایی شده است.

مفهوم False negative: به این معنی که ترافیک مخرب تشخیص داده نشده است.

مفهوم True positive: به این معنی که ترافیک مخرب شناسایی شده است.

مفهوم True negative: به این معنی که ترافیک عبوری سالم است.

Some important concepts:
False positive: It means that normal traffic is detected as malicious traffic.

False negative: It means that malicious traffic has not been detected.

True positive: It means that malicious traffic has been detected.

True negative: It means that the passing traffic is normal.


#SOC
#BlueTeam

T.me/ICTlive

یک تحلیلگر می بایست تصدیق Alert ها و عمل مناسب در قبال آن ها را انجام دهد.
زمانی که یک Alert ایجاد می شود، چه فعالیت هایی صورت می گیرد: (هنوز incident رخ نداده است)
•رسیدگی به نوع هشدار که event است یا alert و قابلیت تبدیل شدن به incident.
•بررسی نوع rule: آیا شناسه مخرب دارد؟ و یا آیا ناهنجاری خاصی در این هشدار وجود دارد؟
•بررسی محتوای فعالیت انجام شده
•غنی کردن رخداد با اطلاعات اضافی و مناسب
•انجام همبستگی با log های دیگر
•تصمیم گیری که آیا با یک incident مواجه هستیم یا خیر؟
•در صورت مثبت بودن سوال فوق: رخداد ایجاد و وارد سامانه جهت رسیدگی به incident می شود.



An analyst should verify the accuracy of alerts and take appropriate action against them.

What activities take place when an Alert is created: (an incident has not yet occurred):

•Checking the type of alert that is event or alert and the ability to become an incident.
•Checking the type of rule: does it have a malicious identifier? Or is there any abnormality in this warning?
•Check the content of the activity.
•Enrich the event with additional and appropriate information.
•Correlation with other logs.
•Deciding whether we are facing an incident or not?
•If the above question is positive: an incident is created and entered into the incident responding system.

#SOC
#BlueTeam

T.me/ICTlive

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

•سیستم IMS(Incident management system): سامانه ای برای مدیریت تیکت های ایجاد شده.
•سیستم TIP(Threat intelligence platform): استفاده از سامانه هایی برای اشتراک دانش و هوش تهدید
•سیستم SIEM: سامانه ای برای مدیریت، جمع آوری، index، جست و جو، همبستگی log و هشدار ها.
•سیستم Soar: سامانه ای جهت خودکار سازی فرایند ها.(با استفاده از Playbook ها)
•سیستم KB(knowledge base): سامانه ای جهت ذخیره اطلاعات، اشتراک دانش، ذخیره usecase ها و ... .

در ادامه هر کدام را به طور مشروح به همراه ابزار مورد استفاده ارائه خواهیم داد.

The required systems of a security operation center are as follows:

IMS (Incident management system): a system for managing the created tickets.
TIP (Threat intelligence platform): using systems to share knowledge and threat intelligence
SIEM: A system for managing, collecting, indexing, searching, log correlation and alerts.
Soar: a system to automate processes (using Playbooks)
KB (knowledge base): a system for storing information, sharing knowledge, storing use cases, etc.

In the following, we will present each one in detail along with the tools used.

#SOC
#BlueTeam

T.me/ICTlive

سامانه (Incident management system)IMS: این سامانه ها Alert ها را از SIEM گرفته و تا اتمام کار به بررسی خود روی رخداد ادامه می دهند.
از بهترین سامانه های IMS می توان به The Hive و RTIR اشاره کرد.

چند نکته در مورد IMS:
•این سامانه ها در جهت تسریع امور و خودکار سازی فرایند ها ایجاد شده و بسیار ارزشمند هستند.
•حتما قبل از استفاده از این سامانه ها به صورت مدت زمان مشخص به تست آن بپردازید.
•نسخه های پولی لزوما بهترین نیستند.
•از اصلی ترین ابزارهایی هست که کاربر مستقر در SOC با آن کار می کند. پس از کارکردن با آن لذت ببرید!

IMS :

This system receives alerts from SIEM and continues to investigate the incident until the work is completed. One of the best IMS systems are The Hive and RTIR.

A few notes about IMS:
•These systems were created to speed things up and automate processes and are very valuable.
•Be sure to test these systems for a certain period of time before using them.
•Paid versions are not necessarily the best.
•It is one of the main tools that a SOC user works with.

T.me/ICTlive

یک IMS خوب باید ویژگی های زیر را داشته باشد:

• قابلیت بارگذاری فایل
• قابلیت API
• داشتن Wiki، Tagging، workflow.
• سهولت در استفاده از Text.
• ویژگی های خاص تیکت مانند: Open، close، edit، action، resolve، In progress.
• قابلیت search پیشرفته و دقیق.
• ظاهر کاربر پسند
• قابلیت گزارش گیری متنوع

A good IMS should have the following features:

• Ability to upload files
• API capability
• Having Wiki, Tagging, workflow.
• Ease of using Text.
• Special ticket features such as: Open, close, edit, action, resolve, In progress.
• Advanced and accurate search capability.
• User-friendly appearance
• Various reporting capabilities

#SOC
#BlueTeam

T.me/ICTlive

هر Playbook: مجموعه ای از Action ها برای پاسخگویی به رخداد.

•غالبا در IMS و یا SOAR طراحی و استفاده می شوند.
•شامل بخش های 1-شروع، 2-بررسی و 3-بستن رخداد می باشد.
•هر Playbook برای هر تهدیدی(فعالیت بدافزار، فیشینگ و ...) متفاوت است.

یک نمونه playbook در تصویر ارائه شده است.

Playbook: A set of actions to respond to the incident.

-They are often designed and used in IMS or SOAR.
-Includes sections 1-starting, 2-checking and 3-closing the event.
-Each playbook is different for each threat (malware activity, phishing, etc.).

A sample playbook is presented in the photo.

#SOC
#BlueTeam

T.me/ICTlive

سامانه TheHive:
• رخداد ها به افراد مرتبط ارجاع می شود.
• هر case از چند گام به عنوان Template می تواند استفاده کند.(Playbook)
• هر Case از چند task تشکیل شده است.
• هر task دارای work log مربوط به خود است.(فعالیت هایی که برای انجام هر task انجام می شود.)
• هر case دارای مشاهدات می باشد. (این مشاهدات می تواند توسط cortex تحلیل شود)
• وظایف (task) می توانند در گروه های مختلف (task group) دسته بندی شوند.

جمع بندی:
رویداد ها (Event) در SIEM جمع شده و اگر به Alert تبدیل شوند وارد Thehive می شوند. و سپس برای هر incident یک case مرتبط با آن به همراه task های مورد نیاز(با توجه به playbook ها) ساخته شده و بررسی و تحلیل روی آن صورت می گیرد.
TheHive system:
• Incidents are referred to relevant people.
• Each case can use several steps as a template. (Playbook).
• Each case consists of several tasks.
• Each task has its own work log. (The activities that are done to complete each task.)
• Each case has observations. (These observations can be analyzed by the cortex)
• Tasks can be categorized in different groups (task group).

Conclusion: Events are collected in SIEM and if they are converted into Alerts, they are entered into Thehive. And then for each incident, a case related to it is created along with the required tasks (according to the playbooks) and analysis is done on it.

#SOC
#BlueTeam

T.me/ICTlive