זרימת עבודה SOC מקצה לקצה, אוטומציה (SOAR), ניהול איכות וביקורת עצמית

רווחים:

• יכולת לתכנן זרימת עבודה SOC מקצה לקצה המורכבת מאיסוף, איתור, בדיקה, חקירה, התערבות, שיפור, דיווח ומשוב, ציון המיקום של בינה מלאכותית ושערים אנושיים
• יכולת להפריד אוטומציה לפי רמת הסיכון (שלבים בעלי סיכון נמוך/הפיך הם אוטומטיים, שלבים בסיכון גבוה/בלתי הפיך נשלטים על ידי אדם) ותכנון נתיב החזרה לכל פעולה אוטומטית.
• יכולת ליצור לולאת ניטור עצמי ומשוב המודד באופן קבוע שיעור חיובי/שלילי שקרי, MTTD/MTTR, דיוק פלט וסחיפה של מודל

יחידה אחרונה זו משלבת את החלקים שלמדנו בנפרד לאורך המודול - ניתוח יומן, ציד איומים, ניהול פגיעות, תגובה לאירועים, דיוג, סקירת קוד, מודיעין, דיווח - לזרימת עבודה אחת מקצה לקצה. במרכז פעולות אבטחה אמיתי (SOC), השלבים הללו אינם מנותקים; אזעקה מפעילה חקירה, שמעוררת תגובה, שמעוררת דיווח, שמפעילה תיקון. בינה מלאכותית מעורבת בכל חוליה בשרשרת הזו, אבל האדם הוא זה שמחזיק בשרשרת ומקבל החלטות בכל דלת קריטית.

בנוסף, יחידה זו מכסה שני נושאים קריטיים. הראשון הוא אוטומציה: כאשר SOAR (תזמורת אבטחה, אוטומציה ותגובה - הפלטפורמה שממכנת ומארגנת תהליכי אבטחה) ובינה מלאכותית משלבים, הן הכוח והן הסיכון גדלים; יש צורך להבחין בין מה שניתן להפוך לאוטומטי לבין מה שלעולם לא ניתן להסיר מאישור האדם. שנית, ניהול איכות וויסות עצמי: פעולת אבטחה התומכת בינה מלאכותית אינה מוגדרת וננטשת פעם אחת; זה כל הזמן מפוקח, נמדד, ניזון ומתוקן. אוטומציה מגבירה מהירות אך אינה מבטלת אחריות; תוכנית אבטחה נשארת בטוחה רק באמצעות ניטור עצמי קבוע.

End-to-end SOC workflow

בואו נראה היכן בינה מלאכותית נכנסת לתמונה ומי מאשר אותה במחזור חיים טיפוסי של אירוע:

1. איסוף וניטור: יומנים זורמים ל-SIEM; AI מפחית רעש, מסכם. (Automatic, low risk.)
2. זיהוי ואזעקה: כלל + אנומליה + זיהוי דפוסי AI. (ייצור אוטומטי; טריאז' הוא בבני אדם.)
3. טריאז': האם האזעקה אמיתית או חיובית כוזבת? AI מציע רציונל ועדיפות; analyst confirms. (Human door.)
4. חקירה: בינה מלאכותית אוספת ראיות, קובעת ציר זמן, מפרטת את שורש הסיבה; האנליסט מאשר עם ראיות גולמיות. (Human door.)
5. התערבות: בידוד, נעילה, ניקוי. AI מספק בחירה/השפעה; ההחלטה נמצאת בידיו של האנליסט המוסמך. (Critical human gate.)
6. תיקון: סגירת פגיעות, סילוק שורש. טיוטת תוכנית בינה מלאכותית; אישור בניהול שינויים. (Human + process.)
7. דיווח: בינה מלאכותית כותבת טיוטה, מתאימה לקהל; המומחה מאמת וחותם על הראיות. (דלת אנושית.)
8. לימוד שיעור ומשוב: AI מחלץ דפוסים; עדכון חוקי זיהוי צוות וחוברות משחק. (אדם + תהליך.)

הכלל של שרשרת זו: צעדים בסיכון נמוך, חוזרים והפיכים יכולים להיות אוטומטיים; צעדים בסיכון גבוה, בלתי הפיך, הדורשים שיפוט עוברים בדלת האנושית.

טבלת החלטות אוטומציה

צעד

האם זה יכול להיות אוטומטי

מצב

אישור אנושי

איסוף יומנים, נורמליזציה

כן, בדיוק

—

לא הכרחי

העשרת אזעקה (חיפוש IOC)

כן

המקור אמין

זה נבדק

חיסול חיובי כוזב (טוב ידוע)

באופן חלקי

כלל נוקשה

נבדק על ידי דגימה

דוא"ל דיוג בהסגר

באופן חלקי

דיוק גבוה

סקירה + נתיב חזרה

נעל חשבון אוטומטית

זהיר

רק קריטריונים ברורים

אימות אנושי מהיר

תבודד את השרת

בדרך כלל לא

מלבד תשתית קריטית

החלטה אנושית כפויה

תיקון (הפקה)

לא

—

בדיקות + ניהול שינויים

דיווח/הודעה רשמית

לא

—

מומחה + משפט

ניהול איכות וביקורת עצמית

פעולת אבטחה המונעת בינה מלאכותית היא מערכת חיה; הביצועים שלו משתנים עם הזמן (התקפות חדשות, סביבה משתנה, עדכוני מודל). נדרשת מדידה קבועה כדי לשמור על בטיחותו:

• שיעור חיובי כוזב ושלילי כוזב: באיזו תדירות AI מעלה אזעקות לשווא, באיזו תדירות היא מחמיצה את האיום האמיתי? שלילי שווא נצפה במיוחד מכיוון שהם גורמים נזק בשקט.
• MTTD/MTTR: ​​האם זמני הזיהוי והתגובה הממוצעים משתפרים?
• דיוק פלט AI: לפי דגימה, כמה מהסיכומים/ממצאים/ציטוטים של AI עוברים אימות?
• אבטחת אוטומציה: האם פעולות אוטומטיות עובדות כצפוי, האם יש טריגרים שווא, האם ההחזרות פועלות?
• לולאת משוב: האם אירועים אמיתיים שנמצאו הופכים לכללי זיהוי חדשים, והתרעות שהועלו הופכות לרשימות חריגים?

תנאים: MTTD (זמן ממוצע לזיהוי). לולאת המשוב היא כאשר הפעולה לומדת מהתוצאות שלה ומעדכנת את הכללים שלה. סחיפה של מודל היא כאשר ה-AI מתיישן והביצועים יורדים ככל שהסביבה משתנה. ביקורת עצמית היא סקירה קבועה וביקורתית של התהליכים של הצוות עצמו.

שלושה מיני תיקים

מקרה 1 - אוטומציה נכונה. SOC הופך את השלב של "העשר ותעדוף אוטומטי של התראות התואמות ל-IOC זדוניים ידועים ונמצאים בקטגוריית סיכון נמוך"; אבל תמיד משאיר את שלב "בידוד שרת" לאישור אנושי. התוצאה: אנליסטים משוחררים מ-400 אזעקות שגרתיות ביום, מפנים זמן לחקירות אמיתיות, משאירים החלטות קריטיות בידי האדם. החלק הימני של השרשרת הוא אוטומטי, המקום הנכון הוא אנושי.

מקרה 2 - אוטומציה פוגעת. SOC אחר מגדיר את הכלל "חשבון נעילה אוטומטית בכניסה חשודה" בצורה רחבה מאוד. יום אחד, עקב שגיאת תצורה, הכלל נועל 1,200 משתמשים לגיטימיים בבת אחת והעבודה נעצרת; יתרה מכך, נתיב ההחלמה אינו מוגדר. לקח: אוטומציה בעלת השפעה גבוהה חייבת להיות בעלת קריטריונים קפדניים, פריסה הדרגתית ונתיב חזרה לאחור. אוטומציה צריכה להיות הפיכה ומפוקחת באמצעות ויסות עצמי.

מקרה 3 - ההחלקה שנתפסה על ידי שליטה עצמית. בביקורת עצמית של שלושה חודשים, צוות מבחין שדיוק זיהוי הדיוג של הבינה המלאכותית הולך ופוחת: גל דיוג חדש מתפספס מכיוון שהוא לא מתאים לדפוסים ישנים (סחף דפוס). הצוות אוסף דוגמאות, מעדכן את כללי הזיהוי ומרענן את ההקשר שניתן ל-AI. ללא שליטה עצמית קבועה, ההתחמקות השקטה הזו הייתה יכולה להימשך חודשים ארוכים. לקח: רק בגלל שהביצועים טובים פעם אחת, הם לא תמיד נשארים טובים; מדידה ומשוב חיוניים.

הנחיה חלשה / הנחיה חזקה

הנחיה חלשה:

הפוך את ה-SOC שלנו לאוטומטי לחלוטין ותן ל-AI לטפל בהכל.

בקשה זו דורשת אוטומציה ללא אפליה של סיכון, מתעלמת מדלתות אנושיות ואינה מתייחסת לחזרה ובקרה. אם ייושמו, החלטות בסיכון גבוה יהפכו לאוטומטיות ללא פיקוח ויהפכו לאסון בטעות הראשונה.

הנחיה עוצמתית:

תפקידך: יועץ בתכנון תהליכי SOC. [רשום] את השלבים הללו במחזור החיים של אירוע לשלושה בהתבסס על רמת הסיכון: (א) אוטומטי לחלוטין (סיכון נמוך, הפיך, חוזר), (ב) AI ממליץ + אישור אנושי, (ג) החלטה אנושית תמיד (סיכון גבוה, בלתי הפיך). הצע נתיב החזרה חובה ומדד מעקב עבור כל (A) ו-(B). כמו כן, נסח רשימת ביקורת עצמית רבעונית: שיעור חיובי/שלילי שגוי, MTTD/MTTR, דגימת דיוק פלט בינה מלאכותית, סימנים לסחיפת דפוסים.

ביקוש חזק מפריד בין אוטומציה לפי רמת סיכון, מצריך החזרה וניטור, וקובע מסגרת רגולציה עצמית.

תבניות הנחיות הניתנות להעתקה

תבנית הפרדת סיכוני אוטומציה הפרד את שלבי זרימת העבודה האבטחה הללו לשלושה: (א) מתאים אוטומטי לחלוטין, (ב) ממליץ על אישור אנושי, (ג) החלטה אנושית תמיד. כתוב הצדקה, הפיכות והשפעה עסקית עבור כל שלב. המלץ על נתיב החזרה חובה לאחור עבור שלבים בעלי השפעה גבוהה. שלבים: [רשימה]

תבנית עיצוב ROLLBACK לפעולה אוטומטית [למשל. נעילת חשבון] מציעים עיצוב מאובטח: קריטריוני טריגר (צר), פריסה הדרגתית, שלב החזרת טריגר שגוי, אזהרה ונקודת אימות אנושית. עיצוב כדי למנוע אוטומציה עיוורת. פעולה: [כתוב]

תבנית ביקורת עצמית של ביקורת עצמית נסח רשימת ביקורת עצמית רבעונית עבור SOC המופעל על ידי בינה מלאכותית: שיעור חיובי/שלילי שגוי, הטיית MTTD/MTTR, דגימת דיוק פלט AI, טריגרים שגויים של אוטומציה, סימני סחיפה של דפוס, פעולת לולאת משוב, תאימות לפרטיות/אנונימיזציה. עבור כל פריט, כתוב כיצד הוא יימדד.

תבנית לולאת משוב צייר את מה שנלמד מהאירוע / אזעקה שנכשל בפועל: (1) הדפוס שיהפוך לכלל זיהוי חדש, (2) החיוב השגוי שתתווסף לרשימת החריגים, (3) שלב ה-Playbook שיעודכן, (4) ההקשר החדש שיינתן ל-AI. סיכום אירוע/אזעקה: [הדבק]

טעויות נפוצות

• אוטומציה של השלב בסיכון גבוה. שלבים בלתי הפיכים כגון בידוד שרת, תיקון ייצור, הודעה רשמית אינם מוסרים מהדלת האנושית.
• לא מתכננים דרך לשליפה. ייתכן שכל פעולה אוטומטית תפעל בצורה שגויה; אוטומציה ללא נקודת ביטול ואישור מסוכנת.
• קבע ותשכח. ביצועי AI משתנים ככל שהסביבה משתנה; ללא בקרה ומדידה עצמית קבועה, מצטברות התחמקויות שקטות.
• רק עוקב אחר החיוב השקרי. שלילי כוזב (האיום האמיתי שמתפספס) מסוכן יותר אך קשה יותר לראות; צפו בו באופן פרטי.
• הזנחת משוב. אם האירועים שזוהו אינם הופכים לכלל חדש והאזעקות שנכשלו אינן הופכות לחריגה, הפעולה לא לומדת וחוזרת על אותה טעות.

רמז: שאלת הזהב בהחלטת אוטומציה: "האם ניתן לבטל פעולה זו אם מופעלת בצורה שגויה ומהי ההשפעה העסקית?" אם התשובה היא "לבטל בקלות, השפעה נמוכה", בצע אוטומציה; אם "השפעה בלתי הפיכה או גבוהה" שמור על דלת האדם.

זהירות: אוטומציה לא מבטלת אחריות, היא רק מאיצה אותה. פעולה אוטומטית לא מתוכננת גורמת נזק הרבה יותר מהר ורחב יותר ממה שאדם יכול היה. כל אוטומציה מוקפת בקריטריונים צרים, נתיב חזרה ובדיקה קבועה; האחריות הסופית תמיד מוטלת על האדם.

לסיכום

יחידה זו שילבה את כל חלקי המודול לזרימת עבודה SOC מקצה לקצה: איסוף, איתור, בדיקה, חקירה, תגובה, תיקון, דיווח ומשוב. בינה מלאכותית מעורבת בכל חוליה, אבל האדם הוא זה שמחזיק בשרשרת ומקבל החלטות בכל דלת קריטית. אוטומציה (SOAR + AI) מגבירה כוח; הכלל ברור: צעדים בסיכון נמוך, הפיכים, החוזרים על עצמם הופכים לאוטומטיים, צעדים בסיכון גבוה ובלתי הפיכים עוברים בדלת האנושית, ולכל אוטומציה יש דרך לבטל. לבסוף, תוכנית אבטחה המופעלת על ידי בינה מלאכותית פעילה: חיוביות/שליליות שגויות, MTTD/MTTR, דיוק פלט וסחיפת דפוס נמדדים באופן קבוע; מה שנמצא הופך לחוקים ולספרי משחק בלולאת משוב. אוטומציה מאיצה אחריות, לא מסירה אותה; שליטה עצמית שומרת על הביטחון בחיים.

משימת יישום

כתוב את מחזור החיים של האירועים של הארגון שלך (או דוגמה של SOC). סווגו כל שלב כ-A/B/C עם תבנית "הפרדת סיכוני אוטומציה" והפקו עיצוב אוטומציה בטוח עם תבנית "עיצוב החזרה" לשלב אחד של "השפעה גבוהה" לפחות. לאחר מכן צור רשימת בדיקה רבעונית עם התבנית "רשימת ביקורת עצמית" וקבע כיצד תמדוד כל מדד בסביבה שלך.

רשימת בדיקה

• [ ] חילקתי כל שלב במחזור החיים של האירוע לדרגת סיכון A/B/C.
• [ ] שמרתי על צעדים בסיכון גבוה ובלתי הפיך ליד דלת האדם.
• [ ] תכננתי קריטריונים צרים וביטול נתיב עבור כל פעולה אוטומטית.
• [ ] תכננתי לעקוב אחר שיעור התוצאות השגויות ובעיקר השליליות השגויות.
• [ ] תכננתי למדוד את דיוק הפלט של MTTD/MTTR ו-AI באופן קבוע.
• [ ] הקמתי רשימת בדיקה רבעונית לניטור עצמי לסחף דפוסים.
• [ ] חיברתי את האירועים שנמצאו וזרקתי אזעקות ללולאת המשוב.

מבחן מודול

1. AI Triage של SIEM סימן אזעקה כ'עדיפות נמוכה, כנראה חיובי שגוי' ודחף אותה לתחתית הרשימה. מה על האנליסט לעשות עם האזעקה הזו?

• א) עדיין בודק באופן עצמאי את האזעקה ומאמת אותה עם ראיות גולמיות; האנליסט מקבל את החלטת הסגירה ורושם אותה ✔
• ב) בינה מלאכותית מכבה את האזעקה אוטומטית מבלי לבדוק אותה כי היא אומרת שהיא בעדיפות נמוכה.
• ג) מעביר את האזעקה למשמרת הבאה כפי שהיא.
• ד) פשוט תסתכל על הסיכום שניתן על ידי בינה מלאכותית ותעביר את הדו"ח

הסבר: תעדוף בינה מלאכותית היא המלצה, לא אבחנה; הדגל של 'עדיפות נמוכה' עשוי לכסות התקפה אמיתית (שלילי כוזב). על האנליסט עדיין לבדוק באופן עצמאי את ההתראה, לאמת אותה עם ראיות גולמיות ולקבל את ההחלטה לסגור אותה בעצמו. פלט AI שלילי אינו ערובה ל'אין איום'.

2. באיזה שילוב של סיכונים ה-AI מתייג מתקפה אמיתית כ'נורמלית' והאנליטיקאי סומך על זה ומרגיע את הניתוח שלו?

• א) חיובי כוזב ועייפות אזעקה בלבד
• ב) שלילי כוזב והטיית אוטומציה (הסתמכות יתר על AI) ✔
• ג) היעדר מקור יומן בלבד
• ד) שגיאת כלל SIEM בלבד

הסבר: זוהי שלילית כוזבת אם המודל מחטיא את האיום האמיתי; הטיית אוטומציה היא כאשר האנליסט סומך יתר על המידה בבינה מלאכותית וזנוח ביקורת עצמאית. כאשר השניים משתלבים, סיבת השליטה האנושית נעלמת וניתן לעקוף את המתקפה לחלוטין. לכן נבדקים גם אזורים שבינה מלאכותית מכנה 'נקיים'.

3. ה-AI אמר 'CVE-2024-88888, CVSS 9.8, תיקון מיד' במהלך טריאז'. מה על האנליסט לעשות קודם?

• א) רואה את ה-CVE אמין ויוזם את תוכנית התיקון באופן מיידי
• ב) רק בגלל ש-CVSS הוא 9.8, הוא שם אותו במקום הראשון מבלי להסתכל על נקודות תורפה אחרות
• ג) מאמת את מספר ה-CVE והניקוד ברשומת NVD/ספק; ✔ אם אין תיעוד, הוא לא יופיע בידיעה שהוא מזויף.
• ד) מבלי לאמת את ה-CVE, המנהל כותב אותו בדוח כ'איום קריטי'

תיאור: מודלים של שפה יכולים להתאים באופן שוטף למספר וציון CVE שאינם קיימים (הזוי). על האנליסט לאמת את ה-CVE ביומן NVD/ספק ולאשר את האותנטיות והניקוד שלו לפני שהוא מתחייב ללוח הזמנים של התיקון. CVE לא מאומת מתחבר תחילה למשאב; אחרת, הצוות יבזבז זמן במרדף אחר תיקון שלא קיים.

4. כדי לזרז חקירת תקרית, מומחה מדביק את יומן חומת האש הגולמי יחד עם כתובות IP פנימיות, שמות משתמש ושמות שרתי VPN בפועל בכלי AI זמין לציבור. מה הבעיה העיקרית כאן?

• א) AI לא יכול לקרוא את פורמט היומן, כך שהניתוח חסר תועלת
• ב) אם היומן ארוך מדי, זה מאט את המודל.
• ג) יומני חומת אש אינם מתאימים לניתוח בכל מקרה
• ד) IP אמיתי, שמות משתמשים ושרתים משותפים ללא אנונימיזציה; מדובר גם בהפרה של KVKK וגם בהדלפת מפת הרשת של הארגון ✔

תיאור: נתוני אבטחה הם גם נתונים אישיים (משתמש, IP) וגם מודיעין תאגידי שחושף את משטח ההתקפה של הארגון (טופולוגיית רשת, שמות שרתים). מתן זה לכלי חיצוני מבלי לעשות אנונימיות זה גם הפרה של KVKK וגם חושף מפת רשת שתהיה שימושית לתוקף. ראשית, הערכים בפועל מוסווים עם מצייני מיקום עקביים.

5. מה הופך את ציד האיומים למעוצב היטב?

• א) זה מתחיל בהשערה קונקרטית ניתנת לבדיקה והעקבות שנמצאו מאוששות על ידי ראיות גולמיות ✔
• ב) זה מתחיל באמירה לבינה המלאכותית 'מצא אם יש תוקף ברשת שלי'
• ג) מכריז אוטומטית על כל אירוע חריג/נדיר שנמצא כהתקפה
• ד) זה עובד רק כשמגיעה אזעקה, זה לא פרואקטיבי

הסבר: ציד איומים טוב מתחיל לא באזעקה, אלא בהשערה קונקרטית וניתנת לבדיקה שיכולה להתברר כנכונה או לא (למשל, 'האם חשבון X התחבר ליותר מ-50 כתובות IP פנימיות בשעות שאינן עסקיות'). לא ניתן לבדוק שאלה מעורפלת כמו 'האם יש משהו רע ברשת שלי' ומשאירה את הבינה המלאכותית לנחש. העקבות שנמצאו לא נחשבות לאיום עד שהיא מאומתת עם ראיות גולמיות.

6. לפגיעות יש ציון CVSS של 9.1 בשרת בדיקה מבודד ברשת הפנימית; באותה רשימה, CVSS 7.5 בשרת פתוח לאינטרנט, אך ישנה פגיעות נוספת ברשימת ה-KEV (שבפועל מנוצלת). מהו סדר עדיפויות נכון?

• א) זה עם ה- CVSS הגבוה ביותר (9.1) תמיד תוקן ראשון
• ב) הפגיעות של 7.5 ברשימת האינטרנט וה-KEV נלקחת קדימה; CVSS אינו הקריטריון היחיד, חשיפה והתעללות בפועל הם המכריעים ✔
• ג) שניהם מתוקנים באותו זמן ובאותה עדיפות, הבחנה מיותרת
• ד) אף אחד מהם לא תוקן כי ישנה פגיעות בשרת הבדיקה

הסבר: CVSS לא קובע סדרי עדיפויות לבד; הסיכון בפועל נקבע על ידי EPSS (הסתברות לניצול), KEV (ניצול בפועל) והקשר ארגוני (חשיפה, קריטיות, בקרה מפצה). פגיעות חשופה לאינטרנט ומנוצלת בפועל (KEV) מונעת פגיעות מבודדת עם סבירות נמוכה גבוהה של CVSS.

7. בתגובה לאירוע, בינה מלאכותית אומרת 'התנועה שמקורה מ-IC_HOST_7 חשודה, בודדים את השרת הזה'. IC_HOST_7 הוא שרת האימות הראשי של המוסד. מה על האנליסט לעשות?

• א) בינה מלאכותית מבודדת מיד את השרת כי הוא אומר כך
• ב) משאיר את החלטת הבידוד כולה לבינה מלאכותית
• ג) ראשית להעריך את ההשפעה העסקית ואת הסיבה לתנועה; הוא אינו מבודד תשתית קריטית מבלי למדוד את השפעתה ומקבל את ההחלטה כאנליסט ✔
• ד) מבודד את השרת ולאחר מכן מוחק את כל היומנים

תיאור: בידוד הוא החלטה קריטית שקשה להפוך אותה ועלולה להוביל להפרעה עסקית; לא ניתן להעביר לבינה מלאכותית. בידוד שרת האימות יכול לעצור את כל העובדים מלהתחבר. על האנליסט להעריך תחילה את ההשפעה העסקית ואת הגורם לתעבורה (עשוי להיות עסקה לגיטימית), לקבל את ההחלטה בעצמו; אין ליישם את ההצעה של בינה מלאכותית כצו.

8. בתקרית כופר, הצוות רוצה לבנות מחדש מכונה מושפעת כדי לנקות אותה במהירות; אבל יש ראיות פורנזיות (מזבלה של זיכרון, כלי תוקף) על המכונה שעדיין לא נאספו. מהי הגישה הנכונה?

• א) המכונה מותקנת מחדש מיד; ראיות לא רלוונטיות
• ב) מבינה מלאכותית מתבקשת 'הניקוי המהיר ביותר' וההוראה מיושמת באופן עיוור.
• ג) מכבים את המכונה וזורקים כי הראיה כבר ביומן.
• ד) תחילה מצלמים את התמונה המשפטית ומזבלת הזיכרון והראיות נשמרות, לאחר מכן מתבצע ניקוי/שחזור ✔

הסבר: מהירות ההתאוששות אינה יכולה לנצח את שימור הראיות. התקנת המכונה מחדש ללא איסוף ראיות הורסת את שרשרת המשמורת ומשתקת את ההליך השיפוטי. ראשית, מצלמים תמונה פורנזית ו-dump זיכרון, לאחר מכן מתבצע ניקוי/שחזור. צעדים משפטיים אינם מואצלים לבינה מלאכותית.

9. מהי אחת השכבות המהימנות ביותר של אימות טכני בעת ניתוח הודעת דוא"ל חשודה להתחזות וכיצד יש לאשר אותה?

• א) תוצאות SPF/DKIM/DMARC בכותרות דוא"ל; אושר מהכותרת הגולמית, לא מסיכום ה-AI ✔
• ב) צבע וגופן של המייל; הוחלט על ידי עיצוב ויזואלי
• ג) לחצו על הקישור החשוד במערכת החיה והסתכלו בעמוד שנפתח.
• ד) בינה מלאכותית שאומרת 'דיוג' בלבד היא ראיה מספקת

הסבר: תוצאות SPF/DKIM/DMARC בכותרות דוא"ל הן אינדיקטורים חזקים לשאלה האם האימייל אכן מגיע מהדומיין שאליו הוא מתיימר; אם שלושתם נכשלים והשולח מזייף את הדומיין, החשד מתחזק. עם זאת, יש לאשר זאת מהכותרת הגולמית ולא מסיכום ה-AI. בנוסף, קישורים חשודים לעולם אינם נלחצים במערכת החיה.

10. בסקירת קוד, ה-AI הציע תיקון לפגיעות XSS ואמר 'זה סוגר את הפגיעות'. מה על האנליסט/המפתח לעשות?

• א) רואה בתיקון אמין ומכניס אותו ישירות לייצור
• ב) סוקר את התיקון, מאשר שהוא בעצם סוגר את הפגיעות ואינו מציג פרצות/באגים חדשים, וכותב בדיקה; רק אז זה נכנס לאחסון ✔
• ג) מאחר שאינו בטוח, הוא משכתב את כל הקובץ לבינה המלאכותית ומשתמש בו.
• ד) מיישם את התיקון אך עובר מבלי לכתוב מבחנים

הסבר: התיקון המוצע על ידי ה-AI אינו בטוח אוטומטית; ייתכן שהוא לא יסגור את הפגיעות לחלוטין, הוא עשוי לנקות את השכבה הלא נכונה, או שהוא עלול להציג פגיעות חדשה/שגיאה תפקודית חדשה. כל תיקון נבדק, מוערך אם הוא אכן סוגר את הפגיעות והאם הוא מציג בעיות חדשות, ונכתבים מקרי מבחן חיוביים ושליליים; רק אז זה נכנס למחסן.

11. בעת ניתוח תקיפה, הבינה המלאכותית אמרה 'זו בהחלט העבודה של קבוצת APT-Dark Eagle'. מהי הגישה הנכונה מבחינת מודיעין איומים?

• א) קבל את ההתייחסות כפי שהיא ורשום אותה בדוח כ'עבריין מובהק'
• ב) הוא בונה את כל ההגנה שלו על בסיס אותה קבוצה מבלי להטיל ספק בשם הקבוצה.
• ג) משתמש בשפה 'תואמת לטכניקות' ולא בייחוס מדויק, מאמת את הקבוצה במקורות ידועים ולוקח בחשבון את האפשרות של ייצור ✔
• ד) ציטוט תמיד מיותר, הוא לא נלקח בחשבון כלל

הסבר: ייחוס קבוצתי הוא התחום הקשה והלא מדויק ביותר של המודיעין; AI יכול אפילו להמציא שם להקה שלא קיים. במקום התייחסות מדויקת, נעשה שימוש בשפה 'תואמת לטכניקות אלה' ושם הקבוצה מאושר במקורות מודיעיניים ידועים. בנוסף, ההגנה אינה מבוססת על IOCs קצרי מועד אלא על זיהוי TTP קבוע.

12. בטיוטת דו"ח תקרית, הבינה המלאכותית כתבה את המשפט "ככל הנראה התוקף היה בפנים במשך שלושה שבועות והוציא נתוני לקוחות"; ואילו אין ראיות יומן חותכות לתמיכה בטענות אלו. מה על האנליסט לעשות?

• א) משאיר את המשפט כפי שהוא כי הוא דרמטי ומרשים
• ב) עוזב את המשפט אך מוסיף 'בינה מלאכותית כתבה' בסוף
• ג) מדפיס מחדש את כל הדו"ח לבינה המלאכותית וחותם עליו מבלי לאמת אותו.
• ד) מתקן טענות המבוססות על ראיות; עושה את ההבחנה בין 'אפשרי/מוכח/בחקירה' ומחלץ את ההצהרה הסופית ללא ראיות ✔

הערה: בדוח אבטחה פורמלי, כל טענה צריכה להיות מבוססת ולעולם אין לבלבל בין 'סביר' ל'מוכח'. לתביעה ללא ראיות יש השלכות משפטיות, כספיות ומוניטין. על האנליסט לתקן את גזר הדין בהתאם לראיות (לדוגמה, לכתוב את תאריך הגישה הראשונה שזוהתה ולומר 'לא נמצאו ראיות חותכות, חקירה נמשכת' עבור דליפת הנתונים).

13. מנהל רוצה ליצור פרופיל של כל הפעילות של עובד מתוך יומני אבטחה עם בינה מלאכותית על מנת להבין האם הוא 'נאמן' או לא. מה צריך לעשות איש אבטחה?

• א) דוחה את הבקשה ומפנה אותה לערוץ המתאים (חקירה אנושית/משפטית/מוגדרת); נתוני אבטחה אינם אמצעי למעקב אישי ✔
• ב) יוצר ומעביר את הפרופיל כי המנהל מבקש זאת
• ג) זה רק מחלץ כמה יומנים ונותן פרופיל חלקי
• ד) יש ליצור את הפרופיל על ידי בינה מלאכותית כי האחריות עוברת לבינה מלאכותית

תיאור: נתוני אבטחה נאספים למטרות אבטחה; מעקב אחר/פרופיל אדם הוא שימוש לרעה, הופך למעקב אישי ומפר את KVKK. על המומחה לדחות בקשה זו ולהפנותה לערוץ המתאים (HR, משפטי, מסגרת חקירה מוגדרת ולגיטימית). רצון טוב או רצון המנהל אינם מצדיקים מגבלה זו.

14. SOC מחליט אילו שלבים של זרימת העבודה האבטחה לבצע אוטומציה. מהו העיקרון הטוב ביותר לאוטומציה?

• א) ההחלטות בסיכון הגבוה ביותר צריכות להיות אוטומטיות תחילה כך שאין מעורבות אנושית
• ב) צעדים בסיכון נמוך/הפיכים הם אוטומטיים; צעדים בסיכון גבוה/בלתי הפיך נשארים בפתח האדם ולכל אוטומציה יש דרך לבטל ✔
• ג) כל SOC צריך להיות אוטומטי לחלוטין וביקורת עצמית מיותרת
• ד) אין צורך לבטל פעולות אוטומטיות כי AI אינו עושה טעויות

הסבר: שלבים בסיכון נמוך, חוזרים והפיכים (איסוף יומן, העשרת אזעקות) ניתנים לביצוע אוטומטי; צעדים בסיכון גבוה, בלתי הפיך ודורשים שיפוט (בידוד שרת, תיקון ייצור, הודעה רשמית) עוברים בדלת האנושית. בנוסף, כל פעולה אוטומטית חייבת להיות בעלת קריטריונים צרים ודרך לביטול. אוטומציה לא מסירה אחריות, היא רק מזרזת אותה.