שתף באמצעות

המלצות לניתוח איומים

  • מאמר

חל על המלצה זו של Well Architected Framework Reliability של Power Platform:

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

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

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

הגדרות

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

אסטרטגיות מרכזיות בתכנון

מידול איומים הוא תהליך חיוני שארגון צריך לשלב ב-SDLC שלו. מידול איומים אינו רק משימה של מפתחים. זוהי אחריות משותפת בין:

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

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

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

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

הבנת היקף התרגיל

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

אספו מידע על כל רכיב

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

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

העריכו את האיומים הפוטנציאליים

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

סווגו האיומים על-ידי שימוש במתודולוגיה של התעשייה

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

לצמצם את האיומים

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

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

הנה דוגמה:

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

- בין משתמשים לאפליקציה?

- בין רכיבי אפליקציה לשירותים?		 מנעו גישה בלתי מורשית לרכיבי האפליקציה ולנתונים.
האם אתם מגבילים את הגישה רק לחשבונות שצריכים לכתוב או לשנות נתונים באפליקציה? מנעו שיבוש או שינוי לא מורשים בנתונים.
האם פעילות האפליקציה מתועדת ומוזנת למערכת לניהול מידע ואירועי אבטחה (SIEM) דרך Azure Monitor או פתרון דומה? זהו וחקרו התקפות במהירות.
האם נתונים קריטיים מוגנים באמצעות הצפנה שצוות האבטחה אישר? מנעו העתקה בלתי מורשית של נתונים במצב מנוחה.
האם תעבורת רשת נכנסת ויוצאת מבודדת לתחומים שאושרו על-ידי צוותי האבטחה? מנעו העתקה בלתי מורשית של נתונים.
האם האפליקציה מוגנת מפני גישה ממקומות חיצוניים/ציבוריים כגון בתי קפה באמצעות חומות אש IP בסביבה? מנעו גישה ממקומות ציבוריים לא מורשים.
האם האפליקציה מאחסנת אישורי כניסה או מפתחות לגישה ליישומים, מסדי נתונים או שירותים אחרים? זהה אם התקפה יכולה להשתמש באפליקציה שלכם כדי לתקוף מערכות אחרות.
האם בקרות האפליקציה מאפשרות לכם לעמוד בדרישות הרגולטוריות? הגנו על הנתונים הפרטיים של המשתמשים והימנע מקנסות תאימות.

עקבו אחר תוצאות מידול האיומים

אנו ממליצים בחום להשתמש בכלי למידול איומים. כלים יכולים להפוך את תהליך זיהוי האיומים לאוטומטי ולהפיק דוח מקיף של כל האיומים שזוהו. הקפידו להעביר את התוצאות לכל הצוותים המתעניינים.

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

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

סקרו באופן קבוע דרישות עומס עבודה החיוניות לעסק

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

סיוע של Power Platform

Power Platform בנוי על תרבות ומתודולוגיה של עיצוב מאובטח. הן התרבות והן המתודולוגיה מקבלים חיזוק מתמיד מ‬‏‫נוהלי מחזור החיים של פיתוח האבטחה ‏(SDL) ומידול האיומים של המובילים בענף של Microsoft.

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

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

ה- SDL של מיקרוסופט מקביל ל- OWASP Software Assurance Maturity Model ‏(SAMM). שניהם בנויים על הנחת היסוד שעיצוב מאובטח הוא חלק בלתי נפרד מאבטחת אפליקציות לאינטרנט.

למידע נוסף, ראו 10 הסיכונים המובילים של OWASP: פעולות צמצום ב- Power Platform.

דוגמה

דוגמה זו מתבססת על סביבת טכנולוגיית המידע (IT) המפורטת ב‏‫המלצות לקביעת הגדרות בסיס לאבטחה‬. גישה זו מספקת הבנה רחבה של נוף האיומים על פני תרחישי IT שונים.

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

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

בקרות אבטחה. כחלק מניתוח איומים, זהו את שירותי האבטחה של Microsoft, ‏Azure ו- Power Platform שישמשו כדי להגן על הפתרון שלכם ובדקו כמה הפתרונות הללו יעילים.

איסוף רישומי יומן. יומנים ממשאבים ורכיבים אחרים של Power Platform הכלולים בעומס העבודה שלכם, כגון משאבי Azure ורכיבים מקומיים, עשויים להישלח אל Application Insights או Microsoft Purview כדי שתוכלו להבין את ההתנהגות של הפתרון שפיתחתם ולנסות ללכוד נקודות תורפה ראשוניות.

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

למידע נוסף

רשימת תיוג של אבטחה

עיין במכלול ההמלצות המלא.

רשימת התיוג של אבטחה