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

דוגמאות לסוג זה של פתרונות כוללים חומות אש מהדור הבא (next generation firewalls), אנטי-וירוס וכלי הגנה מפני איומים מתקדמים (ATP) ו-Security Incident and Event Monitoring (SIEM), הנתמכים על ידי תהליכי מודיעין איומים.

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

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

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

התלונה השלישית היא היעדר הידע של מפתחים רבים בנוגע לאמצעי אבטחה בסיסיים ולהשפעה של חולשות אבטחה משמעותיות שכבר תועדו על ידי קהילת האבטחה. התקווה היא שכל המפתחים יודעים על מתקפות כמו SQL Injection, Cross-Site Scripting, Session Hijacking וכו'. עם זאת, די ברור שלפעמים חסרה למפתחים ההבנה העמוקה של מה התוצאות האמיתיות של ניצול מוצלח של חולשות אלה. לדוגמה, מפתח עלול לדעת שמתקפת הזרקת SQL עלולה להוביל לגניבת נתונים ממאגר מידע אך הם אינם מודעים לסכנות האחרות שאותה מתקפה יכולה להוביל אליהן כגון הרצת פקודות מרחוק על השרת עליו הנתונים הרגישים נמצאים.

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

OWASP (the Open Web Application Security Project) הוא ארגון ללא מטרות רווח בינלאומי המוקדש לאבטחת אפליקציות. הוא מספק משאבים יקרי ערך החל בכלים, דרך מסגרות וכלה במסמכים – כולם פותחו על ידי רשת של מתנדבים מוקדשים מרחבי העולם. כיום, זהו המאגר הטוב ביותר בות וכלו למצוא את כל המידע הנחוץ על מנת להעלות את רמות הידע והכישורים של כל הצוותים הטכניים וההנהלה שלכם.

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

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

ארבע פונקציות אלו יכולות להתחלק ל-12 פעולות אבטחה שונות:

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

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

הפעולות הקשורות בכל שלב מפורטים מטה:

• מינהל
  • אסטרטגיה ומטריצה
    • הערכת פרופיל סיכונים עסקיים כללית
    • בנייה ותחזוקה של תכנית ניהול
    • סיווג מידע ואפליקציות על בסיס סיכון עסקי
    • יצירת ומדידת מטרות אבטחה פר-סיווג
    • ניהול השוואת עלויות תעשייתיות תקופתית
    • איסוף מספרים להוצאות אבטחה היסטוריות
  • מדיניות ותאימות
    • זיהוי וניטור מניעי תאימות חיצוניים
    • בנייה ותחזוקה של הנחיות תאימות
    • בניית נהלים ותקנים לתאימות אבטחה
    • מיסוד נוהל ביקורת פרויקט
    • יצירת שערי תאימות לפרויקטים
    • אימוץ פתרונות לאיסוף מידע ביקורות
  • חינוך והנחייה
    • קיום הדרכת מודעות אבטחה טכנית
    • בנייה ותחזוקה של הנחיות טכניות
    • קיום הדרכות מותאמות-תפקיד בנושא אבטחת אפליקציות
    • שימוש במדריכי אבטחה לשיפור צוותי פרויקט
    • יצירת פורטל רשמי לתמיכה בנושאי אבטחת מידע
    • יצירת הסמכה/בחינה מותאמת-תפקיד
• בנייה
  • הערכת סיכונים
    • בנייה ותחזוקה של מודל סיכונים ספציפי לאפליקציה
    • פיתוח פרופיל תוקף מארכיטקטורת התוכנה
    • בנייה ותחזוקה של מודל טיפול בניצול פר-פרויקט
    • אימוץ מערכת שקילה למדידת סיכונים
    • הערכת סיכון מפורש ממרכיבי צד-שלישי
    • הרחבת מודל האיומים עם בקרות פיצוי
  • דרישות אבטחה
    • הקשת דרישות אבטחה מן הפונקציונליות העסקית
    • הערכת אבטחה והנחיית תאימות עבור הדרישות
    • בניית מטריצת בקרת גישה למשאבים ויכולות
    • פירוט דרישות אבטחה בהתבסס על סיכונים ידועים
    • הבניית דרישות אבטחה אל תוך הסכמי ספקים
    • הרחבת תכנית הביקורת כך שתכלול דרישות אבטחה
  • ארכיטקטורה מאובטחת
    • שמירת רשימה של תשתיות תוכנה מומלצות
    • שימוש מפורש בעקרונות אבטחה בעיצוב
    • זיהוי וקידום אבטחה בשירותים ותשתיות
    • זיהוי תבניות תכנון מאובטח מתוך הארכיטקטורה
    • הקמת פלטפורמות וארכיטקטורות רשמיות
    • אימות שימוש בתשתיות, תבניות ופלטפורמות
• אימות
  • סקירת עיצוב
    • זיהוי שטח התקיפה של התוכנה
    • ניתוח העיצוב כנגד דרישות אבטחה ידועות
    • בחינה לצורך הספקה מלאה של מנגנוני אבטחה
    • פריסת שירותי סקירת עיצוב לצוותי פרוייקטים
    • פיתוח דיאגרמות זרימת-נתונים עבור מקורות רגישים
    • יצירת שערי שחרור לסקירת עיצוב
  • סקירת קוד
    • יצירת צ'קליסט לסקירה מתוך דרישות אבטחה ידועות
    • ביצוע סקירה נקודתית של קוד בעל סיכון גבוה
    • שימוש בכלי ניתוח קוד אוטומטיים
    • שילוב סקירת קוד אל תוך תהליך הפיתוח
    • התאמה של ניתוח הקוד עבור שיקולים ספציפיים עבור כל אפליקציה
    • יצירת שערי שחרור לסקירת קוד
  • בדיקות אבטחה
    • הקשת מקרי בדיקה מדרישות האבטחה הידועות
    • ניהול בדיקות חדירה על שחרורי גרסאות תוכנה
    • שימוש בכלי בדיקות אבטחה אוטומטיים
    • שילוב בדיקות אבטחה אל תוך תהליך הפיתוח
    • הפעלת אוטומציה בבדיקות אבטחה ספציפיות לתוכנה
    • יצירת שערי שחרור לבדיקות אבטחה
• פריסה
  • ניהול חולשות
    • זיהוי איש קשר לנושאי אבטחה
    • יצירת צוות תגובה בלתי רשמי לנושאי אבטחה
    • יצירת תהליך תגובה עקבי לאירועים
    • אימוץ הליך מסירת מידע בנושאי אבטחה
    • ניהול אנליזת סיבת המקור למקרים
    • איסוף מידע לכל מקרה
  • הקשחת סביבה
    • קיום מפרט סביבת תפעול
    • זיהוי והתקנת עדכונים ופאטצ'ים קריטיים לאבטחה
    • יצירת תהליך ניהול פאטצ'ים שגרתי
    • ניטור סטטוס הגדרות סביבה במצב תקין (baseline)
    • זיהוי ופריסת כלי הגנת תפעול רלוונטיים
    • הרחבת תכנית הביקורת להגדרות סביבה
  • איפשור ביצועי
    • תפיסת מידע אבטחה קריטי לפריסה
    • תיעוד תהליכים להתראות אבטחה טיפוסיות
    • יצירת נהלים לניהול שינויים לפני שחרור
    • ניהול מדריכי אבטחה תפעוליים רשמיים
    • הרחבת תכנית הביקורת למידע תפעולי
    • חתימת קוד למרכיבים אפילקטיביים

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

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

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

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

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

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

זכרו תמיד לנטר בזהירות את התהליך כולו ולבסס יעדי SMART (Specific, Measurable, Achievable, Relevant, Timely) עבור כל שלב. גישה טובה לאימוץ על מנת לסייע במעבר היא מתודולוגיית Objectives and Key Results (OKR) מאחר וזו תקל על הזיהוי של מה צריך להשיג בכל שלב ולאיזו תוצאה יש לשאוף. המידע לזה כבר מסופק על ידי מתודולוגיית SAMM. קיים לינק למידע הזה בחלק הקישורים במאמר זה.

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

קישורים

OWASP – https://owasp.org

Open SAMM – https://www.owasp.org/index.php/OWASP_SAMM_Project

BSIMM – https://www.bsimm.com/

ISMM – https://www.iiconsortium.org/pdf/SMM_Description_and_Intended_Use_2018-04-09.pdf

OKR – https://en.wikipedia.org/wiki/OKR

DASMM – https://duo.com/blog/rsac-2018-building-a-software-security-maturity-program