Review LRSA Course

سنشرح بشكل مبسط عن الـ Course المخصص لشهادة الـ LRSA أو الـ LogRhythm Security Analyst المقدمة من شركة LogRhythm محتوى الدورة يتركز على أساسيات الـ LogRhythm ويحتوي على 6 Modules سنذكر أهم ماتم طرحه في الـ Course كنظرة مبدائية لما يحتويه عليه.

Module 1 - Web Console Overview

  • في البداية نتحدث عن إحدى الأدوات وهي مايُسمى بالـ Security Operations Maturity Model (SOMM) وهي تُعتبر وسيلة لقياس أداء ونضج قدرات الـ Security Operation لمواجهة التهديدات السيبرانية.

  • لقياس هذه المرونة تعتمد على شيئين وهما : 

    متوسط الوقت اللازم لإكتشاف التهديد ( Mean Time to Detect (MTTD) ) متوسط الوقت المستغرق حتى نتّعرف على وجود تهديد ما.

    متوسط وقت الاستجابة ( Mean Time to Respond (MTTR) ) متوسط الوقت المستغرق للإستجابة وحل مشكلة الحدث الذي تم الكشف عنه.

  • يتكون كل من MTTD وMTTR من الفئات الفرعية التالية:

    • الـ ( Time to Qualify TTQ ) وهذا يعني الوقت بين تاريخ الدليل أو الـ Evidence  الذي يؤدي إلى إنشاء الـ Evidence وتاريخ إنشاءها.

    • الـ ( Time to Investigate TTI) وهذا يعني عندما يتم تحديد الـ Case على أنها ليست Incident ويتم إغلاقها بأنها "Case Completed" بحيث يعتبر المقياس بأن الـ Case إكتمل التحقيق الخاص بها وهذا يعني بأن الوقت بين إنشاء الـ case وتاريخ إغلاقها بإعتبارها انها Non-Incident.

    • الـ ( Time to Triage TTT) هنا يأتي مقياس قدرة الفريق على فحص الإنذار بشكل عاجل.

    • الـ ( Time to Detect TTD) تاريخ الـ Evidence التي تدفع لإنشاء الـ Case ومتى تم إنشاء هذه الـ Case ايضاً

    • الـ ( Time to Respond TTR) الوقت بين تاريخ إنشاء الـ Case وتاريخ معالجة الحادث ، ينطبق فقط على الحالات التي تم تصعيدها كحوادث.

  • تشير إدارة دورة حياة التهديدات ( Threat Lifecycle Management TLM ) إلى سير العمل الموصى به لتقليل MTTD وMTTR الخاصين بـ SOC.

    يتم تنظيم سير عمل TLM حول الستة المختلفة التالية وهي تعتبر مراحل الكشف والإستجابة (Detection and Response Steps ) :

    1. الـ Collect نجمع معطيات الـ Case.

    2. الـ Discover نكتشف عن الـ Case متى كانت وأين حدثت.

    3. الـ Qualify بعد ذلك إن كانت Incident نبدأ بالخطوة التالية.

    4. الـ Investigate نبدأ نتعمق في التحقيق عن الـ Incident التي حدثت.

    5. الـ Neutralize تأتي بمعنى الإصلاح وهي بنفس معنى الـ Mitigation.

    6. الـ Recover لما بعد الـ Incident التي وقعت.. 

  • الـ LogRhythm يوفّر وحدتي تحكم إداريتين، لكل منهما مهام SIEM الخاصة بها متاحة للمسؤول والمحلل ايضاً.

    وحدة تحكم العميل أو مايُسمى بالـ Client Console :

    وحدة تحكم خاصة بالـ Client وهي واجهة مستخدم للمسؤولين لتكوين LogRhythm وكيفية عرض النظام الأساسي، وتنفيذ أنشطة إدارة الـ Logs ، وإدارة التقارير، والـ Alerts ، ومراقبة صحة وصول البيانات في الـ LogRhythm ، أيضاً توفر وحدة التحكم هذه واجهة للمحللين لإجراء عمليات البحث، وتحليل البيانات،إعداد التقارير وإنشاء الإنذارات الشخصية .

    وحدة تحكم الويب الـ Web Console :

    توفر وحدة تحكم الويب LogRhythm للمحللين معلومات في واجهة ويب سهلة الاستخدام ، حيث تعد وحدة تحكم الويب مكونًا مستقلاً يمكن تثبيته على جهاز مخصص.

Module 2 - Logs, Alarms, and Data Analysis

تتكون منصة LogRhythm من المكونات الرئيسية التالية:

• وكلاء مراقبة النظام أو الـ System Monitor Agents : يجمع بيانات الـ Logs حول سلوك المستخدمين، والملفات، والتطبيقات، و

النظام في الوقت الحقيقي لدعم التحليلات والاستجابة للحوادث.

• Open Collector وLogRhythm Authored Beats : تم إنشاء Open Collector لحل مشكلة كيفية استيعاب سجلات الـ JSON ، والتي يصعب تحليلها باستخدام التعبير العادي.

• معالج البيانات (DP) الـ Data Processor : يقوم بمعالجة الـ Logs ووظائف إعادة توجيهها والبيانات المحفوظة.

• مفهرس البيانات (DX) الـ Data Indexer : يوفر فهرسة وبحثًا قابلاً للتطوير بدرجة عالية.

• محرك الذكاء الاصطناعي الـ AI Engine : محرك تحليلات متقدم قائم على القواعد ومتكيف يقوم بتقييم بيانات الـ Logs في الوقت الفعلي

للكشف عن الهجمات ومشكلات العمليات المعقدة والتغيرات في سلوك الأنظمة.

• مدير النظام الأساسي (PM) الـ Platform Manager : يوفر التنبيهات والإشعارات وإدارة الحالة وأتمتة سير العمل والإدارة المركزية لمنصة LogRhythm.

• وحدة تحكم الويب الـ Web Console : واجهة ويب توفر سهولة الوصول إلى الأدوات التحليلية والإنذارات والبيانات ولوحات معلومات قابلة للتخصيص.

• وحدة تحكم العميل الـ Client Console : تُستخدم لإدارة وتخصيص طرق عرض مختلفة لها لتحليل والرصد وإدارة التحقيقات.

  • حتى نُحدّد نوع النشاط في تصنيف رسالة السجل الـ Log Message، يكون الحدث المشترك أو مايُسمى بالـ Common Event المخصصة لكل رسالة Log محددة.

    هنا ليس المقصود من الأحداث المشتركة أن تكون محددة للغاية؛ ومع ذلك، فهي تهدف إلى تحسين مهمة التصنيف أو الـ Classification Assignment إلى مجموعة أكثر تحديدًا من الأنشطة.


  • ضمن تصنيف التدقيق “Audit” : نجاح المصادقة ( Authentication Success )، يتم تضمين الأحداث الـ Events الشائعة التالية :

• الـ User Logoff أو تسجيل خروج المستخدم.

• الـ User Logon أو تسجيل دخول المستخدم.

• الـ Computer Logoff أو تسجيل الخروج من الكمبيوتر.

• الـ Computer Logon أو تسجيل الدخول للكمبيوتر.

• الـ Service Logoff أو تسجيل الخروج من الخدمة.

• الـ Service Logon تسجيل الدخول إلى الخدمة.


الأحداث المشتركة المذكورة أعلاه أو الـ Common Events listed تندرج تحت تصنيف أوسع ( تصنيف أو الـ Classification ) حيث يتم وصف المصادقة أو الـ Authenticating بإن كل حدث مشترك يعطي إشارة أكثر تحديدًا ، فما حدث في رسالة السجل أو الـ Log Message في حالة إذا كان جهاز كمبيوتر يعمل بنظام الـ Windows يتصل بالشبكة لأول مرة في

في اليوم، سيتم إجراء تسجيل دخول للكمبيوتر (Computer Logon ) بإستخدام وحدة تحكم المجال الـ Domain Controller. ثم عندما يصل المستخدم إلى الكمبيوتر، سيتم إنشاء رسالة تسجيل دخول المستخدم ( User Logon)  للإشارة إلى نشاط المصادقة الناجح لهذا المستخدم.

  • هناك ثلاثة أنواع من الـ Metadata في LogRhythm ويتم تحليل اثنين من هذه الأنواع مباشرة من ملف رسالة السجل الأولية أو الـ raw log message ،

  • التي تتضمن التالي :

    • الـ Contextual Metadata ( حقول بيانات التعريف السياقية ) التي يتم تحليلها مباشرة من الـ Log Messages ، عادة ما تكون مستندة إلى النص طبيعة ووصفية فيما يتعلق بالرسالة.

    تتضمن الأمثلة : تسجيل الدخول (Origin Login)، والموضوع، والمجال، والـ Object .

    • الـ Quantitative Metadata ( حقول البيانات الوصفية الكمية ) التي يتم تحليلها مباشرة من رسائل السجل الـ Log Messages ويمكن إستخدامها لمقارنات رقمية.

    تتضمن الأمثلة : وحدات البايت الواردة/الخارجة، ومعدلها، وحجمها.


  • بالإضافة إلى تحليل الـ Metadata مباشرةً من رسالة السجل أو الـ Log Messages الذي يستمد LogRhythm بعض الـ Metadata من

    السجلات أو الـ Logs.

  • تستخدم الـ Derived metadata ( حقول البيانات التعريفية المشتقة ) المعلومات التي تم تحليلها من رسائل السجل الـ Log Messages وتربطها بـ LogRhythm وهي معلومات الـ Configuration Information لتوفير سياق إضافي حول رسالة السجل الـ Log Messages.

تتضمن الأمثلة : الـ Origin Entity، والـ Impacted Known Host ، والـ Direction.

  • هنا تم ذكر مايوجد في الـ Dashboards الخاصة بالـ Web Console

  • جميع الـ Evidence of threats والـ risks الموجودة في البيانات يتم إنشاؤها وجمعها.

  •  لمراجعة هذه البيانات نستخدم آداتين داخل وحدة التحكم وهي كالتالي :

    • الـ Dashboards 

    • الـ Analyzer Grid

  • الـ Analyzer grid تسمح بتحليل ومراجعة المعلومات الخاصة بالأحداث أو الـ Events المعروضة. 

    كل صف في الـ Analyzer Grid تُمثّل حدثًا أو رسالة سجل (Event, log message ).

    وكل عمود في  Analyzer Grid البيانات الوصفية أو الـ metadata التي تم تحليلها من رسالة السجل مُجمعة

  • حسب فئات المعلومات وهي كالتالي :

    • الـ Metadata Fields : هذه هي البيانات التي تم تحليلها من رسالة السجل الأولية أو الـ raw log message مثل الـ Account, Sender, Object, IP Address ، ويمكن أيضاً إستخلاص المعلومات من الـ raw logs  لإنتاج بيانات التعريف أو مايُسمى بالـ yield metadata مثل الـ Origin Host، و الـ Direction والـ Classification وايضاً الـ Common Event.

    • الـ Log Messages : هذه هي بيانات السجل الـ log data التي تم إنشاؤها بواسطة مصدر السجل الـ Log Source والتي تم جمعها بواسطة SysMon الخاص بـ LogRhythm.

    • الـ Metadata Groups : تسمح هذه المجموعات بعرض البيانات التعريفية حسب الفئة ( metadata by category ).

    فمن خلال كل مجموعة من المجموعات يمكن رؤية المعلومات المقدمة بطرق مختلفة بناءً على الفئة.

    • الـ Pinning : يسمح لك برؤية أعمدة محددة من البيانات..

كل صف في الـ Analyzer Grid يُمثل حدثًا واحدًا أو سلسلة من الأحداث المجمعة ، والإجراءات التي تحتوي عليها هي ثلاث :

الـ Event & Actions : تعرض هذه البيانات التعريفية الـ metadata التي تم تحليلها أو المستمدة من رسالة السجل الـ log message.

الـ Log Message : تعرض هذه رسالة السجل الأصلية أو الـ original log message قبل تحليل الـ metadata.

الـ Inferred Identity : هذه تعرض المستخدم المسؤول عن نشاط الحسابات حتى عندما يكون معلومات الحساب أو تسجيل الدخول غير موجودة في رسالة السجل الـ log message.

  • الـ Analyzer Grid يحتوي على ميزة تُسمى بالـ Contextualize ، والتي قد تساعد من عمليات بحث Whois والـ traceroutes والـ  ping.

  • هذه الميزة الـ Contextualize  تدعم الخيارات التالية :

    • الـ Host (Origin or Impacted)

    • الـ Hostname (Origin or Impacted)

    • الـ IP Address (Origin or Impacted)

    • الـ Known Host (Origin or Impacted)

    • الـ User (Origin)

    • الـ TCP/UDP Port (Origin or Impacted)

  • الـ Contextualization تتيح أيضاً البحث عن ثلاثة حول الـ IP Address :

    • الـ Whois : يتم الحصول على المعلومات الخاصة بالـ IP Address من موقع arin.net، باستخدام خدمة البحث عن النطاق أو الـ domain lookup service هذه.

    • الـ Trace : يتم تنفيذ أمر تتبع المسار، لتوفير معلومات حول مسار الشبكة من موقعك الحالي إلى موقع الـ host.

    • الـ Ping : يتم تنفيذ أمر الـ ping والذي يوفر المعلومات حول الاتصال بالـ host.

  • يمكن للمستخدمين عرض تصميم الـ AI Engine Rule's  من خلال إنذار أو الـ alarm أو حدث (event) يتم تشغيله بواسطة الـ AIE rule.

  • هناك طريقتان لعرض معلومات الـ AI Engine Rule الأساسية في لوحة المفتش أو الـ Inspector panel عبر الـ Event على صفحة لوحات المعلومات في  الـ Analyzer Grid ، كما هو موضح أعلاه وأدناه، أو من خلال التنقيب بين التنبيهات الـ Alarm Drilldown.

  • المحلل يحتاج إلى رؤية تفاصيل الـ AIE rule حتى يفهم سبب ظهور الـ log message. 

  • التنقل أو مايُسمى بالـ Drilldown يمكن تنفيذه على حدث أو إنذار لإسترداد السجلات المسؤولة لإنشاء ها الحدث أو مشغل الإنذار ويعرضها كنتائج. 

  • تعد خدمة الـ Threat Intelligence Service (TIS) بمثابة خدمة لـ الـ Windows مستقلة الذي يعمل جنبًا إلى جنب مع SIEM ويسمح بتغذية بيانات تهديدات الجهات الخارجية،  تقوم الـ TIS بجمع وتحليل البيانات التي تم جمعها بواسطة موفري بيانات التهديد.

  • الـ Alarm هي في وحدة تحكم الويب أو الـ Web Console وهي المكان الذي تتم فيه إدارة الإنذارات الخاصة بالجهة.

  • يقوم المسؤولو بإنشاء قواعد إنذار لمراقبة أحداث محددة ذات الأهمية ، وتمت معالجتها بواسطة محرك الذكاء الاصطناعي الخاص بـ LogRhythm من أجل الارتباط والتعرف على الأنماط لتحديد المشتبه بهم سلوكياً.

  • يساعد AI Engine في تحديد الإنذارات وتشغيلها من أي سجل أو مجموعة سجلات تتم معالجتها بواسطة LogRhythm (وليس الأحداث فقط).

  • يحتوي LogRhythm أيضًا على قواعد إنذار تم تكوينها مسبقًا، والتي يمكن تمكينها لمراقبة الأمان والمشكلات وصحة النظام والعناصر المتعلقة بالامتثال مثل PCI أو الناتج المحلي الإجمالي (GDPR) أو NIST.

  • مراقبة قواعد الإنذار لظروف معينة، مثل الهجمات على الشبكة، ومشكلات الامتثال، وأخطاء النظام. يتم إطلاق الإنذارات في الوقت الفعلي عند استيفاء تلك الشروط المحددة.

  • جميع الإنذارات يجب التحقيق فيها بحثًا عن مشكلات أمنية أو امتثال أو تشغيلية محتملة.

  • عند تشغيل قاعدة الإنذار، يتم عرض بطاقة الإنذار في صفحة الإنذارات. إذا تم تكوينها.

  • يمكن إرسال الإشعارات إلى مستخدمين ومجموعات وتطبيقات محددة عبر البريد الإلكتروني أو اعتراضات SNMP أو الملفات النصية.

  • تتيح لك طريقة عرض الشبكة في صفحة الإنذارات مراجعة معلومات الإنذار بسرعة في تنسيق قائمة.

  • هنا نستعرض ميزات للـ Alarm management وهي كالتالي : 

    • الـ Sort By : وهي تكون تغيير الترتيب التصاعدي أو التنازلي للإنذارات المعروضة حسب الـ date triggered ، والـ risk value ، والـ Name والـ Status والـ Group و تاريخ آخر تحديث أو الـ date of the last update.

    • الـ Filter : عامل التصفية وهي تغيير الإنذارات المعروضة حسب التاريخ، والحالة، والـ Entity ،والـ rule name، والـ risk value ، وقائمة الإشعارات أو الـ notification list ، والـ Group ، والـ ID number.

    • الـ Trend chart : تمثل الخطوط هذه نشاط حجم التنبيهات الجديدة أو المفتوحة أو المغلقة حسب التاريخ أو الوقت.

    • الـ Status : يعرض حالة التنبيه: جديد، مفتوح، مغلق.

    • الـ Drilldown : مثل أن تنقر على الزر للبحث عن السجل أو السجلات وهي الـ Logs التي أدت إلى تشغيل الـ Alarm Rule.

    • الـ Add to Current Case : مثل أن تضيف معلومات الإنذار إلى الحالة أو إلى الـ case.

    • الـ SmartResponse : يمكن تنفيذ البرامج النصية للإصلاح التلقائي أو مايُسمى بالـ auto-remediation scripts ، إذا تم تكوينها لـ Alarm Rule في الـ Client Console ، من الـ Alarm Card أو الـ Inspector panel.

    • الـ Inspector panel : تُسمى بالـ لوحة المفتش توفر تفاصيل حول الإنذار وسبب إطلاق الإنذار. من هنا نستطيع تنفيذ العديد من الإجراءات، مثل إضافة تعليقات لإبقاء الآخرين على علم بنشاط الإنذار.

Module 3 - Case Management and Gathering Evidence

  • تسمح الـ Cases للمستخدمين بتتبع وإدارة التحقيقات وإجراءات المعالجة أو ماتُسمى بالـ Manage Investigations والـ Mitigation Actions.

  • الـ Case Management تُسرّع سيّر عمل المحلل طوال دورة حياة الكشف عن التهديدات والإستجابة لها.

  • تبدأ إدارة الـ Case بإجراء تحقيق لفهم المخاطر التي يمثلها التهديد وتحديد ما إذا كان الحادث موجوداً. وبعبارة أخرى إذا حدث شيء سيئ أو هو في طور الحدوث. تنتهي إدارة الحالة أو الـ Case Management بإجراءات المعالجة أو الـ Mitigation والإسترداد الناجحة رداً على التهديد ، يمكن للمستخدمين إضافة الأدلة وتحليلها داخل القضية والتعاون مع الآخرين للمساعدة في التحقيق ، فبالتالي يتم تعيين الأولوية للحالات والحالة وتاريخ الإستحقاق والمالك لتسهيل الإدارة والمعالجة من المشاكل.

  • تعرض صفحة الـ Case العناصر التالية :

    • الـ Case Trends

    • الـ Case Lists

    • الـ Case History widgets

  • الـ Cases Dashboard تكون فيه عناصر مرتبطة بالـ Widgets 

  • توفّر الـ Case Trend Priority والـ Case Trend Status مساعدة المديرين على ضمان معالجة الحالات وتحديد أولوياتها بشكل فعال.

  • الـ Case Lists تعرض العناصر الخاصة بالـ Case Cards وهي : 

    • الـ Priority

    • الـ Status

    • الـ Age

    • الـ Owner

    • الـ Dates

  • تعرض الاداءة الـ Case History سجلاً للإجراءات التي تم تنفيذها بترتيب تنازلي، مع ظهور النشاط الأحدث في الأعلى ، يتم تتبع جميع الأنشطة في التاريخ، بما في ذلك أي تعديلات وتغييرات في الـ Evidence والإضافات أو الإزالة للـ Evidence.

  • الـ Case Metrics Trend يعرض الـ MTTD والـ MTTR.

  • مثل الـ Widgets في الـ Web Console من الممكن أن نُخصص الـ Case Widget Customization في جزء المفتش أو الـ Inspector Pane

    • تتضمن خيارات التخصيص الـ Customization ما يلي :

      • الـ Case widget name changes

      • الـ Priority visibility

      • الـ Status visibility

      • الـ Tag application

      • الـ Case ownership

      • الـ Due dates

      • الـ Evidence types

      • الـ Sorting options

  • تُستخدم الـ Case statuses للإشارة إلى ما إذا كانت الحالة Incident أم لا ولتلخيص تقدم سير عمل الـ Case.

  • لا يمكن تغيير الـ Case statuse إلا من خلال الـ case owners. الحالة الإفتراضية للـ New Cases  هي "Created." وهي حالة الإنشاء، ويمكن تصعيد الحالات إلى حالة "Incident" أو نقلها إلى حالة "Completed" باعتبارها non-Incidents.

  • تم تقديم الـ Case Metrics الحاصة بالـ Case لعرض متوسط الوقت اللازم للكشف (MTTD) أو مايُصسمى بالـ mean-time-to-detect (MTTD) ، ومتوسط وقت الاستجابة (MTTR) أو مايُسمى بالـ mean-time-to-respond (MTTR) ، يتم عرضها للتمييز بين حالات الحوادث وغير الحوادث ، وعندما يتم تحديد الحالة على أنها ليست حادثة ويتم إغلاقها وسنشاهد ""Case Completed" يتم الإشارة على انها  Time to Investigate (TTI) وهو الوقت بين إنشاء الـ case وتاريخ إغلاقها باعتبارها non-incident.

  • الـ Case tags تم إضافتها إلى الحالات الفردية لمساعدة المستخدمين على تصنيف الحالات وتنظيمها وتحليلها. 

  • توفّر الـ Web Console عدة أدوات للبحث :

    • الـ The Search window

    • الـ The Lucene Filter

    • الـ The Searches page

  • تساعد هذه الأدوات في تمكين تأهيلك  للتهديد والتحقيق أو مايُسمى بالـ qualification of a threat من خلال تحديد موقع المزيد من البيانات.

  • فترة مهلة الإستعلام أو الـ Query Timeout Period هي مقدار الوقت المسموح بتشغيل البحث قبل إنتهاء المهلة.

  • يمكن لكل مستخدم تكوين فترة مهلة الإستعلام الخاصة به داخل وحدة تحكم الويب - وهذا التكوين هو خاص بالمستخدم ،  فإذا تم تغيير إعداد مهلة الإستعلام في وحدة تحكم الويب إلى تحديث هذا الإعداد تلقائيًا

  • في تفضيلات المستخدم الخاصة بك داخل وحدة تحكم العميل أو الـ Client Console.

  • يتم تطبيق إعداد الميزة هذا على جميع عمليات البحث الجديدة،بما في ذلك عمليات البحث المحورية أو الـ AIE Drilldowns.

  • للوصول السريع إلى عمليات البحث الروتينية، فيمكنك حفظ أي عمليات بحث تقوم بإنشاءها في خانة البحث.

  • تتوفر جميع عمليات البحث المحفوظة في صفحة عمليات البحث، حيث يمكنك أيضًا الوصول إلى بحث السجل الخاصة بك وعمليات البحث التي شاركها المستخدمون الآخرون معك ايضاً.

  • تتيح صفحة التقارير للمستخدمين بتحليل البيانات المعروضة ، وتسمح وحدة تحكم الويب بتحليل البيانات الواردة في التقرير والتحقيق فيها بطريقة تفاعلية.

Module 4 - The Analyst’s Tasks

  • مثال على المراحل التي تمر فيه الـ Use Case كيف تكون وكيف تصدر كـ Alert.

Module 5 - Customizing the Web Console

  • الـ Lucene هي مكتبة مفتوحة المصدر لإسترجاع النصوص تم إصدارها من الـ Apache Software License.

  • توفر لك إستعلامات أو ماتُسمى بالـ queries وهي بناء الجملة بحيث تكون قادرة على تصفية البيانات المعروضة بناءً على معايير محددة.

  • لإنشاء الـ Lucene query نستخدم الصيغة الأساسية التالية :

    metadata field name, colon, open quotation mark, search term,

    and end quotation mark

    "Metadata:"search_term

  • مثال :

لتشغيل الـ query على كافة الـ activity التي تندرج ضمن تصنيف البرامج الضارة أو الـ Malware Classification ، يمكنك إستخدام :

اسم التصنيف: "البرامج الضارة" وهو الـ 

”classificationName: “malware

  • مثال آخر :

لتشغيل الـ query لمستخدم متأثر أو الـ n impacted user اسمه مثلاً jon.smith-miller، يمكنك إستخدام :

”account:“jon.smith\-miller

  • الـ Lucene Helper يتذّكر تفاصيل بناء الجملة والـ metadata عند الـ  Lucene search queries. 

  • الـ Case Playbooks توفّر للمستخدمين طريقة لتخزين وإدارة الإجراءات المرتبطة بأحداث معينة، مثل الأحداث وجود برامج الضارة.

  • قد يحتاج المحللون إلى تنفيذ مجموعة محددة مسبقًا من الخطوات لحل المشكلة.

  • تسمح الـ Playbooks بتحديد هذه الخطوات ومن ثم يمكن إضافتها إلى الحالة للتأكد من إنها كذلك كجزء من خطوات العلاج أو الفرز لتلك الحالة أو الحادثة أوالـ incident المحددة.

Module 6 - Taking Action as an Analyst

  • كان هذا القسم يتحدث عن طبيعة عمل الـ Analyst.

الـ Course بالمجمل كان ممتع ولطيف وكان تدريب مباشر لكن عن بعد ، بمعنى التدريب المكثف كان عبارة عن تمارين وشروحات عن كيفية عمل المحلل عند إستخدامه منصة الـ LogRhythm.