דעה | עד כמה הארגון שלכם בשל לתהליכי אבטחת מידע אפליקטיבי?

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

דעה | עד כמה הארגון שלכם בשל לתהליכי אבטחת מידע אפליקטיבי?

שלומי צרפתי. צילום: שי בראל

לאחרונה פרסמה חברת המחקר פורסטר (Forrester Research) שאלון אבחון שמשמש למדידת המוכנות והבשלות של ארגונים בכל הנוגע לתהליכי אבטחת מידע אפליקטיבי (Application Security), בדגש על הנקודות שבהם על ארגונים להשתפר. 

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

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

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

כאן מגיעה שאלת השאלות: איך הארגון יכול להעריך באיזו רמת בשלות הוא נמצא? 

חברת פורסטר מציעה צ׳ק ליסט של שישה שלבים בשם Forrester Secure What You Sell Model. ששת השלבים הם: Discover, Define, Align, Build, Launch, Grow. במתודה זו, כל שלב מציג מספר דגשים שיסייעו לכל ארגון להבין מהי רמת הבשלות שלו בתחום אבטחת המידע האפליקטיבי ומה נדרש מהארגון כדי לטפס לרמה הבאה וליצור לעצמו תמונת מצב עדכנית. 

Discover
בשלביו הראשונים, פרויקט לא אמור להיות יותר מניצוץ קטן במחשבה של צוות פיתוח המוצר. יחד עם זאת, זו בדיוק נקודת הזמן הנכונה לבצע הערכות מודיעיניות בנוגע לאיומים (threat intelligence assessments), הערכות סיכונים (risk assessments) ואף לבחון תסריטי של ניצול לרעה של המידע (abuse scenarios).

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

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

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

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

כמו כן, מרגע שהמוצר עושה שימוש בקוד פתוח או בתוכנה צד שלישי (והרוב המוחלט עושים כך), חשוב מאד לקבוע מדיניות ביחס לסיכונים שעלולים להיגרם על ידי צד שלישי. מהלך זה חייב לכלול רשימת תכולה, מרכיבים הכלולים במושג החדש:   SBOM - Software Bill of Materials, וכן רשימת כל התלויות (contingencies) והנתונים שמגיעים משרשרת האספקה.  

Build
זהו השלב שנוגע בעיקרו לאנשי ה-DevSecOps שביננו, האחראים למירב הפעולות שיש לבצע בשלב זה. הם אלו שיהיו אמונים על הטמעת כלי בדיקות אוטומטיים כגון: Static Application Security Testing (SAST), Dynamic Application Security (DAST), Software Composition Analysis (SCA), שיש לשלב בתהליכי ה-CI/CD.

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

Launch
זהו השלב שבו המוצר בשל וזמין לציבור המשתמשים. בשלב זה מירב האחריות נופלת כבר על צוותי אבטחת המידע שמגינים עליו באמצעות כלים כגון: Web application firewall, Bot management, Runtime application self-protection.

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

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

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

לאחר שהבנו את שלבי התהליך, מה עכשיו?

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

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

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

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

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

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

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

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


מאת: שלומי צרפתי, מנהל מכירות אזורי, סינופסיס (Synopsys Inc)

אולי יעניין אותך גם