گزارشات فنی مرکز SOC باید با توجه به موارد زیر تهیه شود:
یک: سیاست هایی که باید در نظر گرفت: برای مثال تمامی مجموعه ها از AV به روز برخوردار باشند.
دو: استاندارد های به روز: استفاده از استاندار های روز دنیا در این حوزه. برای مثال برای نصب سنسور (Agent) می بایست مطابق با استاندارد مرتبط با خود نصب شود.

سه: Procedures: استفاده گام به گام از دستورالعمل هایی که برای انجام یک Task ارائه شده اند.
چهار: Guideline: استفاده از دستورالعمل های پیشنهادی که در خوده مرکز SOC تهیه شده و یا در اشتراک دانش با سایر تیم ها بدست آمده است.
پنج: Base Line: استفاده از لیست های خاص مانند چک لیست نصب فلان ابزار.
شش: Playbook/ usecase: ارائه نقش ها و فعالیت ها جهت شناسایی تهدید.

Technical reports of the SOC should be prepared according to the following:

•Policies to consider: for example, all departments have up-to-date AV.
•Up-to-date standards: using the latest world standards in this field. For example, to install the sensor (Agent), it must be installed according to the standard related to it.
•Procedures: step-by-step use of the instructions provided to perform a task.
•Guideline: using suggested guidelines prepared in the SOC itself or obtained in knowledge sharing with other teams.
•Base Line: Using specific lists such as checklists for installing certain tools.
•Playbook/usecase: providing roles and activities for threat detection.

#SOC
#BlueTeam

t.me/ICTlive

🔰چه موقع یک شبکه Defensible است؟

•قابل مانیتورینگ باشد: داده شبکه و سیستم ها جهت مانیتورینگ، جمع آوری و مرکزیت داده شوند.
•قابل سرشماری باشد: از شبکه و دارایی های آن شناخت کافی داشته باشیم. (برخی از مهاجمین از سیستم هایی که رها شده اند و در سرشماری موجود نیستند استفاده می کنند.)
•همه چیز قابل کنترل باشد: واقف بودن به ترافیک عبوری، وضعیت ارتباطات و ... .
•قابل ادعا کردن باشد: صاحبان سرویس در آن شبکه با حوزه کاری خود آشنا بوده و تمامی رویه ها برنامه ریزی شده باشد.
•قابلیت کمینه کردن سطح حمله را داشته باشد: شناسایی افراد مسئول برای کمینه کردن حمله(برای مثال در یک حمله باج افزاری نیاز است ارتباط شبکه سرور با دیگر مناطق قطع شود. و می بایست شخصی مسئولیت این قطعی را در نظر گرفته و با هماهنگی صورت گیرد).
•قابلیت ارزیابی داشته باشد: ضعف ها شناسایی شده و تیم های تست نفوذ و ارزیابی آسیب پذیری بتوانند فعالیت کنند.
•قابلیت وصله داشته باشد: به روز نگه داشتن تجهیزات شبکه با انجام وصله، upgrade. ( البته در برخی موارد این عمل باعث اختلال در سرویس دهی می شود. به همین دلیل آشنایی با آسیب پذیری ها و وصله های مربوطه کمک مهمی در کاهش خرابی می شود).
•قابلیت اعمال سنجه(معیار) داشته باشد: بتوان پیشرفت ها و فعالیت هایی که در توسعه شبکه انجام می شود را با مراحل قبل مقایسه کرد.

When is a network defensible?

•Can be monitored: Network and systems data should be collected and centralized for monitoring.

•Can be enumerated: to have sufficient knowledge of the network and its assets. (Some attackers use abandoned systems that are not in the census.)

•Everything can be controlled: being aware of passing traffic, communication status, etc.

•Can be claimed: service owners in that network are familiar with their work area and all procedures are planned.

•Have the ability to minimize the level of the attack: identifying the responsible people to minimize the attack (for example, in a ransomware attack, the network connection with other areas needs to be cut off. And someone should take responsibility for this cut and coordinate with the take).

•Be able to assess: Weaknesses are identified and penetration testing and vulnerability assessment teams can operate.

•Patching capability: keeping the network equipment up-to-date by patching, upgrading. (Of course, in some cases, this action causes service disruptions. For this reason, familiarity with vulnerabilities and related patches is an important help in reducing failures).

•To be able to apply criteria: to be able to compare the progress and activities carried out in the development of the network with the previous stages.

#SOC
#BlueTeam

t.me/ICTlive

انواع مانیتورینگ امنیت:
• مانیتورینگ Endpoint: برنامه ها و فعالیت هایی که در Host ها صوت می پذیرد.
• مانیتورینگ Network: شناسایی ارتباطات، سرویس ها و هر فعالیتی که در ترافیک شبکه موجود است.
به طور کلی دو مفهوم CSM و NSM در مانیتورینگ وجود دارند. به طوری که Data at rest در مانیتورینگ Endpoint و Data at transit در مانیتورینگ شبکه کاربرد دارد.

یکی از علل استفاده از SIEM ها مرکزیت دادن مانیتورینگ امنیت است.یعنی CSM و NSM در یکجا بررسی شوند. باید در نظر داشت که جهت تشخیص درست باید هردو نوع مانیتورینگ صورت گیرد. برای مثال یک سیستم الوده به بدافزار با استفاده از سرویس پورت 443 که از دید ما مجاز است اقدام به فعالیت خرابکارانه می کند. پس می بایست هم مانیتورینگ شبکه و هم سیستم صورت گیرد.

Types of security monitoring:
1-Endpoint monitoring: programs and activities that take place in hosts.

2-Network monitoring: identification of connections, services and any activity in network traffic.

In general, there are two concepts of CSM and NSM in monitoring. So that Data at rest is used in endpoint monitoring and Data at transit is used in network monitoring.
One of the reasons for using SIEMs is to centralize security monitoring, that is, CSM and NSM should be checked at the same time. It should be kept in mind that both types of monitoring should be done in order to make a correct detection. For example, a system infected with malware performs malicious activity by using service port 443, which is allowed from our point of view. Therefore, both network and system monitoring should be done.

#SOC
#BlueTeam

t.me/ICTlive

در مانیتورینگ شبکه موارد زیر باید بررسی شوند:

• میزان ترافیک عبوری و پهنای باند.
• نوع سرویس ها و توپولوژی شبکه.
• دامین های موجود در شبکه.
• پاسخ به این سوال که آیا می توانیم Full packet capture داشته باشیم؟
• بررسی وضعیت سرویس های مختلف شبکه.
• شناسایی رفتار ترافیک مشکوک(Exploit ها، ترافیک C&C و ...)
• مانیتورینگ قسمت های مختلف شبکه از جمله: DMZ، Access Layers، ترافیک مربوط به اینترنت و سرور ها)

In network monitoring, the following should be checked:

• Amount of passing traffic and bandwidth.
• Type of services and network topology.
• Domains available in the network.
• The answer to the question of whether we can have full packet capture?
• Checking the status of various network services.
• Identify suspicious traffic behavior (exploits, C&C traffic, etc.).
• Monitoring of different parts of the network including: DMZ, Access Layers, Internet traffic and servers.

#SOC
#BlueTeam

t.me/ICTlive

یک نمونه مطلوب برای دریافت لاگ در شبکه.

A good example for receiving logs on the network.

#SOC
#BlueTeam
#Network_Monitoring

T.me/ICTlive

موارد مهمی که در مانیتورینگ 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