הגיע הזמן להודות שכמעט בכל ארגון הקשר בין צוותי הפיתוח לצוותי הסקיוריטי הוא קורקטי במקרה הטוב, ומנותק לחלוטין במקרה הרע. מדובר, כידוע, בשני צוותי ליבה שהארגון מסתמך עליהם כדי לבנות תהליכי פיתוח ומוצר מאובטחים ולקדם יעדים עסקיים. הנתק ביניהם יכול להיות הרסני ולהשפיע לרעה על היעדים העסקיים, תוצרי הארגון, התרבות הארגונית, וכמובן - להוביל לכך שהארגון יהיה פחות מאובטח. אם נשים את הקלפים על השולחן ונבין את המקור לקצר בתקשורת, נוכל למצוא פתרונות יצירתיים ולבנות מוצרים פורצי דרך ומאובטחים כראוי.
ניגוד עניינים
הנתק בין הצוותים הוא לא תופעה חדשה ומקורו בתקופה שבה לצוותי הסקיוריטי יצא שם של מעכבי חדשנות ומסרבלי תהליכים, שמעדיפים את אבטחת החברה על פני קידום יעדיה העסקיים. כמו תמיד, על מנת להבין את הבעיה לעומקה צריך ראשית לבחון את האינטרסים והמטרות העומדים מאחורי ההתנהלות של שני הצדדים. למפתחים יש מטרה עיקרית אחת - לפתח יכולות ומוצרים ולשחרר אותם לשוק במהירות על מנת שלקוחות יוכלו להשתמש בהם. הם שואפים ואמורים לפעול במהירות, להתמקד במה שחשוב ולהתעלם מרעשי רקע. שלא במפתיע, סקיוריטי נחשב בעיניהם לחלק מרעשי הרקע האלה. המטרות של צוותי הסקיוריטי בארגונים הן אחרות לחלוטין. ככל שיש לצוותים אלה שליטה על התוצרים והתהליכים של הארגון, כך הם יוכלו לבדוק אותם ולוודא שהם מאובטחים. מטבע הדברים, מעורבות זו של צוותי סקיוריטי בתהליכי הפיתוח מאטה את התהליך שהמפתחים רוצים להאיץ. כאן נמצא הניגוד הבסיסי בין השניים.
האבולוציה של סמנכ"לי אבטחת המידע בארגונים (ה-CISO)
בעבר, צוותי סקיוריטי חשבו רק על דבר אחד - סקיוריטי. ההנחה הייתה שמטרות עסקיות הן לא בתחום האחריות שלהם ולכן הן לא רלוונטיות עבורם. הם הציבו מגבלות ומחסומים קריטיים לאבטחת התשתית והנתונים של הארגון, אבל פגעו על הדרך ביכולת לפתח במהירות וביעילות. סמנכ"לי אבטחת מידע היו צריכים לראות את תהליכי העבודה ולהיות מעורבים בהם, מקצה לקצה, על מנת לשלוט בהם, וזה גרם לשיבושים ועיכובים שיצרו את החיכוך המוכר בין הצוותים.
המהפכה הדיגיטלית יצרה שינויים אדירים בסביבה העסקית המודרנית, הפכה את סדרי העדיפויות וערערה את הנחות היסוד הישנות. בנוסף, האיומים המתפתחים הפכו את תחום הסקיוריטי מנישה מקצועית ומנוכרת למחלקה חיונית המחייבת שיתוף פעולה בין כלל הצוותים, על מנת למנוע אובדן הכנסות, פגיעה במוניטין והשלכות חמורות אחרות של תקיפות סייבר. כיום, סמנכ"לי אבטחת מידע לוקחים חלק משמעותי בקביעת האסטרטגיה של הארגון, מובילים תהליכים עסקיים ומספקים לבכירים מידע קריטי על סטטוס הסקיוריטי של החברה. הקונטקסט העסקי הוא קריטי עבור צוותי הסקיוריטי כיום, ומבטיח סנכרון בין יעדי הסקיוריטי למטרות החברה. שילוביות זו היא רחוקה מאוד מהתדמית המבודדת שהייתה לצוותי הסקיוריטי בעבר.
מהפכת הענן הולידה פתרונות סקיוריטי חדשים שחשפו כמויות אדירות וגדלות של התראות סקיוריטי, שכוללות גם כפילויות, התראות לא רלוונטיות ועוד. ומי אחראים על טיפול בהתראות אלו? נכון - המפתחים. העומס עליהם עלה, הרעש של ההתראות גבר והתסכול של המפתחים החריף את המתח בינם לבין צוותי הסקיוריטי, שכבר היה נפיץ מלכתחילה.
לגשר על הפער
נכון, על מנת להימנע מעבודה משותפת עם צוותי הפיתוח, צוותי סקיוריטי יכולים לאמץ כלי סקיוריטי שלא דורשים את מעורבות המפתחים. הם לא יצטרכו להשקיע זמן ומשאבים ביישום ואינטגרציה של כלי R&D וגם לא ירגיזו את המפתחים, שצריכים היום לעצור את עבודתם על מנת להתמודד עם ההתראות. זו אפשרות ישימה, אבל הפרדה כזו תגרום לארגונים לפספס שיתוף פעולה מעשיר ומשמעותי.
נכון להיום, כלי סקיוריטי שדורשים אינטגרציה עם מפתחים הם מיעוט לעומת כלי סקיורטי שעובדים בניתוק מהמפתחים. מדובר בפספוס גדול כיוון שלכלים אלה יש פוטנציאל להאיץ את מהירות הפיתוח ולהשתלב באופן מלא עם הכלים שהמפתחים משתמשים בהם מראשית הדרך, וכך לוודא שכלל התהליך מאובטח. בנוסף, הפער הקיים גורם לחברות בשוק להשיק מוצרים שאינם מאובטחים מיסודם. אם היבטי סקיוריטי היו משולבים ישירות בתהליכי הפיתוח ובכלים של צוותי הפיתוח, היינו יכולים לשפר את היכולת לזהות ממצאים קריטיים בשלב מוקדם יותר. מפתחים לא אוהבים את האפשרות הזו, לאור עומס הממצאים האדיר שקיים היום בלי יכולת מלאה של תעדוף והקשר. התוצאה: חברות מפתחות מוצרים פחות מאובטחים.
יש מספר פעולות שניתן לבצע על מנת להתחיל ולגשר על הפער:
1. זהות אינטרסים - ברגע שיש לשני הצדדים מטרה משותפת, הדרך להגשמתה תחייב שיתוף פעולה מלא. ההכרח לפתח מוצרים באופן יעיל אך גם מאובטח חייב לעמוד בבסיס הפעילות של הארגון, והדרך הנכונה לעשות זאת היא בעדכון הגדרת היעדים של שני הצוותים. ברגע שלצוותי הסקיוריטי יהיו יעדי מוצר/פיתוח ולהיפך, האינטרסים המשותפים יולידו שיח ותקשורת מיטבית.
2. שיח פתוח - המתח הקיים בין הצוותים ישכך ברגע שיהיה שיח פתוח ביניהם, בו כל צוות מציף את האתגרים שלו וכך יתקיים דיאלוג על סדרי עדיפויות, צרכים וקשיים.
3. הפחתת רעש - זו האחריות של החברים בצוותי הסקיוריטי. במקום להפציץ את המפתחים עם טיקטים והתראות שחלקן לא רלוונטיות, לא קריטיות או זהות להתראות אחרות, עליהם לעשות ככל שביכולתכם לתעדף את מה שחשוב, לנטר את ההתראות ולאבחן אותן לפני שהם מעבירים את האחריות למפתחים. כבדו את הזמן שלהם והם יתייחסו לצרכים שלכם בהתאם.
4. שילוב מוקדם - ככל שנקדים לשלב תהליכי סקיוריטי בשלבים מוקדמים של תהליך הפיתוח, כך נוכל לשפר את היכולת שלנו לזהות בעיות מוקדם ולטפל בהן ביעילות ומבלי להכביד על התהליכים הקיימים.
ברגע שארגונים יודו בבעיה ויסכימו שצריך לטפל במתח הזה בעדיפות גבוהה, נוכל לשנות את הגישה בתעשייה כולה וכך לטייב ולאבטח תהליכי פיתוח ביעילות גבוהה יותר. במקום ליצור מובלעות סקיוריטי נפרדות ונתק מלא בין שני צוותים חשובים כל כך, נוכל להתקדם לבניית מוצרים שמשלבים בין סקיוריטי לפיתוח.
יש כאן הזדמנות אמיתית עבור התעשייה כולה - לבנות כלי סקיוריטי שמספקים התרעות משמעותיות יותר, כאלה שלא היה ניתן לגלות בלי אינטגרציה עם הפיתוח, ולייצר כלים שמשתמשים בקונטקסט מקיף על מנת לתעדף ולהפחית את מספר ההתראות. בכך יתאפשר למפתחים לפנות זמן לעבוד על המוצר עצמו. ארגונים צריכים להשקיע גם בחינוך של צוותי הסקיוריטי והפיתוח, דרך דיאלוג, פתיחות ותקשורת. אי אפשר לוותר על תהליכי סקיוריטי שיתופיים - הם חיוניים וחשובים מדי.
הכותב הוא סמנכ"ל טכנולוגיות ב-YL Ventures
לאתר>>>
בשיתוף YL Ventures
