מיפוי אוטומטי של בקרות ISO 27001 מבוסס AI לשאלוני אבטחה

שאלוני אבטחה מהווים צוואר בקבוק במערכות ניתוח סיכון של ספקים. מ auditors מבקשים לעיתים קרובות הוכחות שהספק SaaS עומד ב-ISO 27001, אך המאמץ הידני הדרוש לאיתור הבקרת המתאימה, חילוץ המדיניות התומכת, וניסוח תשובה תמציתית יכול להימשך ימים. דור חדש של פלטפורמות מונעות AI משנה פרדיגמה זו מתהליכים תגובתיים, תלויי‑אדם לזרמי עבודה חזויים, אוטומטיים.

במאמר זה אנו מציגים מנוע ראשון מסוגו שמבצע:

1. יבוא של כל סט הבקרות של ISO 27001 ומיפוי כל בקרת למדיניות הפנימית של הארגון.
2. יצירת גרף ידע המקשר בין בקרות, מדיניות, תיעוד הוכחות, ובעלי תפקידים.
3. שימוש בצינור יצירת תשובות מבוסס שליפה‑הרחבה (RAG) לייצור תשובות לשאלונים שהן תואמות, קונטקסטואליות, ועדכניות.
4. גילוי סטיית מדיניות בזמן אמת, המפעיל יצירה מחודשת אוטומטית כאשר מדיניות מקור של בקרה משתנה.
5. מתן ממשק UI בעל קוד נמוך למבקרים לשים דגש או לאשר תגובות שנוצרו לפני ההגשה.

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

1. למה מיפוי בקרות ISO 27001 חשוב

ISO 27001 מספק מסגרת מוכרת ברמה עולמית לניהול אבטחת מידע. נספח A שלו מפרט 114 בקרות, כולל תתי‑בקרות והנחיות יישום. כאשר שאלון אבטחה של צד שלישי שואל, לדוגמה:

“תארו כיצד אתם מנהלים את מחזור חיי המפתחות הקריפטוגרפיים (בקרת A.10.1).”

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

• עבודה מיותרת – תשובות זהות נכתבות מחדש עבור כל בקשה.
• שפה לא עקבית – שינויי ניסוח עדינים עלולים להתפרש כחסרים.
• הוכחות מיושנות – מדיניות מתעדכנת, אך טיוטות השאלונים נשארות ללא שינוי.

אוטומציה של מיפוי הבקרות לקטעי תשובה שניתן להעתיק elimintates these problems at scale.

2. תכנית ארכיטקטורה מרכזית

המנוע בנוי סביב שלושה עמודים:

להלן תרשים Mermaid שממחיש את זרימת הנתונים משלב היבוא ועד מסירת התשובה.

  graph LR
    A[ISO 27001 Control Catalog] -->|Import| KG[Control‑Policy Knowledge Graph]
    B[Internal Policy Store] -->|Sync| KG
    C[Evidence Repository] -->|Link| KG
    KG -->|Query| RAG[Retrieval‑Augmented Generation Engine]
    RAG -->|Generate| Answer[Questionnaire Answer Draft]
    D[Policy Change Feed] -->|Event| Drift[Policy Drift Detector]
    Drift -->|Trigger| RAG
    Answer -->|Review UI| UI[Security Analyst Dashboard]
    UI -->|Approve/Reject| Answer

כל תוויות הצמתים מוקפות במירכאות כפולות כפי שנדרש בתחביר Mermaid.

3. בניית גרף הידע של בקרה‑מדיניות

3.1 מודל הנתונים

• צמתי בקרה – כל בקרת ISO 27001 (למשל “A.10.1”) הופכת לצומת עם מאפיינים: title, description, reference, family.
• צמתי מדיניות – מדיניות פנימית מיובאת מקבצי Markdown, Confluence, או מאגרי Git. מאפיינים כוללים version, owner, last_modified.
• צמתי הוכחה – קישורים ללוגים, צילומי מסך של קונפיגורציה, או הסמכות של צד שלישי.
• קשתות בעלות – MANAGES, EVIDENCE_FOR, DERIVES_FROM.

סכמת הגרף מאפשרת שאילתות בסגנון SPARQL כגון:

MATCH (c:Control {id:"A.10.1"})-[:DERIVES_FROM]->(p:Policy)
RETURN p.title, p.content LIMIT 1

3.2 העשרת גרף בעזרת GNN

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

4. צינור יצירת תשובות מבוסס שליפה‑הרחבה (RAG)

4.1 שלב שליפה

1. חיפוש מילות‑מפתח – BM25 על טקסט המדיניות.
2. חיפוש וקטורי – אמבדינגים (Sentence‑Transformers) להתאמה סמנטית.
3. דירוג משולב – משקל משולב של BM25 ו‑relevance_score של ה‑GNN (α = 0.6 סמנטיקה, 0.4 למילוליות).

ה‑k‑הטובים (בדרך כלל 3) מועברים ל‑LLM יחד עם פרומפט השאלון.

4.2 הנדסת פרומפט

אתם עוזר ציות. באמצעות הקטעים המדיניותיים הבאים, כתבו תשובה תמציתית (מקסימום 200 מילים) עבור בקרת ISO 27001 "{{control_id}} – {{control_title}}". שמרו על הטון של המדיניות המקורית אך התאימו אותה לשאלון אבטחה של צד שלישי. ציינו כל קטע עם תגית רגל‑הערה במרקודון.

ה‑LLM ממלא את מקומי‑ההצבה עם הקטעים שהושגו ומפיק טיוטה עם ציטוטים.

4.3 עיבוד פוסט‑פרודקשן

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

5. גילוי סטיית מדיניות בזמן אמת

מדיניות כמעט שאינה קבועה. מחבר Capture שינויי נתונים (CDC) צופה במאגר המקור עבור commits, merges או מחיקות. כאשר שינוי נוגע לצומת הקשור לבקרת ISO, מגלה ה‑drift:

1. מחשב hash של ה‑diff בין קטע המדיניות הישן לחדש.
2. מעלה אירוע סטייה לנושא Kafka policy.drift.
3. מפעיל את צינור ה‑RAG ליצירת תשובות מחדש.
4. שולח התראה לבעל המדיניות ולוח האנליסטים לביקורת.

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

6. חוויית משתמש: לוח המחוונים של האנליסט

הממשק מציג רשת של פריטי שאלון ממתינים עם סימון צבעי מצב:

• ירוק – תשובה נוצרה, ללא סטייה, מוכנה לייצוא.
• צהוב – שינוי מדיניות אחרון, יצירה מחודשת ממתינה.
• אדום – נדרשת בדיקה אנושית (למשל מדיניות לא ברורה או סימן הסתרה).

תכונות מרכזיות:

• ייצוא בלחיצה אחת ל‑PDF או CSV.
• עריכה בא‑line למקרים קיצוניים.
• היסטוריית גרסאות המציגה את גרסת המדיניות המדויקת שבה השתמשו לכל תשובה.

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

7. השפעה עסקית מדודה

הפיילוט בוצע בחברת SaaS בגודל בינוני (≈ 250 עובדים), והפחת את עומס צוות האבטחה השבועי בכ‑≈ 30 שעות וה elimintated 4 אירועי ציות משמעותיים שנגרמו מתשובות מיושנות.

8. אבטחה ושלטון

• מיקום נתונים – כל נתוני גרף הידע נשמרים ב‑VPC הפרטי של הארגון; אינפרנס LLM מתבצע על חומרה מקומית או קצה ענן פרטי ייעודי.
• בקרות גישה – הרשאות מבוססות תפקיד מגדירות מי יכול לערוך מדיניות, להפעיל יצירה מחודשת, או לצפות בתשובות שנוצרו.
• שרשרת ביקורת – לכל טיוטת תשובה נשמר hash קריפטוגרפי המקשר לגרסת המדיניות המדויקת, מה שמאפשר אימות בלתי ניתן לשינוי במהלך audits.
• הסבריות – הלוח מציג תצוגת עקביות שמפרטת את הקטעים המדיניותיים שהושגו וה‑relevance scores שתורמים לתשובה הסופית, מה שמרכך דרישות רגולטוריות לשימוש אחראי ב‑AI.

9. הרחבת המנוע מעבר ל‑ISO 27001

אף שהפרוטוטיפ מתמקד ב‑ISO 27001, האדריכלות לא תלויה ברגולטור:

• SOC 2 Trust Services Criteria – מיפוי לאותו גרף עם משפחות בקרה שונות.
• HIPAA Security Rule – הכנסת 18 התקנים וקישור למדיניות ספציפית למגזר הבריאות.
• PCI‑DSS – קישור לנוהלי טיפול בנתוני כרטיסי חיוב.

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

10. מדריך התחלה: רשימת בדיקה שלב‑אחר‑שלב

1. איסוף בקרות ISO 27001 (הורדת קובץ CSV של נספח A).
2. ייצוא מדיניות פנימית לפורמט מובנה (Markdown עם front‑matter לגרסאות).
3. פריסת גרף הידע (תמונת Docker של Neo4j עם סכמת ברירת‑מחדל).
4. התקנת שירות ה‑RAG (קונטיינר FastAPI עם קצה LLM).
5. הגדרת CDC (Git hook או משגיח קבצים) להזנת דטא דריפט דיטקטור.
6. הפעלת לוח המחוונים של האנליסט (React front‑end, אימות OAuth2).
7. הרצת פיילוט של שאלון ויטולול של תבניות הפרומפטים באופן איטרטיבי.

ע"י מעקב אחרי מסלול זה, רוב הארגונים יכולים לקבל צינור מיפוי ובניית תשובות ISO 27001 אוטומטי מלא בתוך 4‑6 שבועות.

11. כיוונים עתידיים

• למידה פדראלית – שיתוף embeddings של בקרה‑מדיניות בטוחה בין חברות שותפות כדי לשפר דירוג רלוונטיות מבלי לחשוף מדיניות קניינית.
• תיעוד מולטי‑מודלי – שילוב דיאגרמות, קבצי קונפיגורציה, ו‑log snippets באמצעות Vision‑LLMs להעשיר תשובות.
• ספרי ציות גנרטיביים – הרחבה מתשובות בודדות לנרטיב ציות שלם, כולל טבלאות הוכחות והערכת סיכונים.

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

ראה גם

• ISO 27001 – נספח A הרשמי של הבקרות
• מיפוי NIST SP 800‑53 ל‑ISO 27001
• שליפה‑הרחבה (RAG): סקר של טכניקות ויישומים