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

1. הדרכות פיתוח מאובטח: הכשרות והדרכות למפתחים בנושא פיתוח מאובטח הן חשובות וחיוניות. אך הדרכות נשכחות מהר מאוד. לאחר מספר שבועות הן לא אפקטיביות והמפתחים שוכחים על מה דובר בהדרכות. כמו כן קשה מאוד ללמד פיתוח מאובטח בהדרכה חד פעמית. הדרכה צריכה להיות רציפה ולאורך זמן
2. נוהל/מדריך כתוב לכתיבת קוד מאובטח: מדריך לכתיבת קוד מאובטח הינו חיוני ויכול לשמש את המפתחים בהבנת Best Practices ובפתרונות. הבעיה שרוב המדריכים והספרים בנושא, ארוכים ולא תמיד רלוונטיים לפיתוח שלכם. גם אם נכתב נוהל ממוקד עבורכם, המפתחים מתישהו שוכחים אותו וזה נהיה עוד מסמך או ספר שנשאר על המדף.
3. שימוש בכלי סריקה אוטומטים של קוד המערכת (Static Code Analysis) – כיום נמצאים הרבה מאוד כלים אשר יודעים לסרוק את קוד המערכת ולמצוא חולשות אבטחת מידע אשר נמצאים בקוד המערכת כתוצאה מטעויות של המפתחים. ישנם כלים חינמיים וישנם כלים בתשלום אבל לכולם ישנה אותה הבעיה שנקראת False Positive. False Positive הינן התראות שווא של הכלים הנ"ל. כלומר הכלי שסורק את קוד המערכת מוציא דוח הכולל בין היתר המון False Positive כלומר ממצאים או בעיות לא נכונות כלומר שאינן בעיות ואין צורך לתקנם. התוצאה היא המון עבודה לשווא שהמפתחים צריכים לתקן בקוד שבסוף מובילה לחוסר אמון בכלים ולהפסקת העבודה איתם.
4. ביצוע מבדקי חדירה (Penetration Test) – מבדק חדירה הינה סימולציה המדמה כיצד האקר יכול לפגוע במערכת ומה הנזק שהוא יכול לעשות בזמן מסוים. הדגש החשוב הוא "בזמן מסוים". ברוב המקרים מבדק חדירה הינה בדיקה של מספר ימים. לרוב החשיפות שניתן למצוא במבדק חדירה הן חשיפות פחות מורכבות. במידה וקיימות חשיפות הדורשות מספר שבועות או אולי חודשים בשביל לגלות אותן הן לא יהיו כחלק מהחשיפות אשר ימצאו במבדק חדירה.
5. יישום תהליך SSDLC שאינו מותאם לארגון – SSDLC (Secure Software Development Lifecycle) הינו הפתרון ליישום של פיתוח מאובטח בארגון. SSDLC מגדיר כיצד ניתן לשלב את כלל פעילויות "פיתוח מאובטח"  כחלק מתהליך הפיתוח. אחת הבעיות הינה, שארגונים מנסים לאמץ נוהל מוכן או כתוב מראש שאינו מתאים לארגון שלהם. התוצאה – כשלון של יישום תהליך ה- SSDLC.

תהליך SSDLC צריך להיות מותאם לארגון ע"פ קריטריונים כגון: משאבים, תקציב, רמת הידע בארגון אשר על פיהם צריך להתאים תהליך ה- SSDLC המתאים לארגון. לדוגמא ביצוע Code review/Static Code Analysis  הינה פעילות חשובה מאוד והכרחית כחלק מפתרון לפיתוח מאובטח בארגון אך לא בכל ארגון יש את הידע ואת המשאבים לבצע זאת ולכן צריך למצוא פתרון אחר שיתאים ספציפית לארגון שלכם.

תהליך ה- SSDLC משתלב כיחידה אחת עם תהליך הפיתוח שמטרותיו:

1. להקטין את כמות החשיפות במערכות המפותחות ושיפור רמת אבטחת המידע
2. לאתר חשיפות אבטחת מידע בשלבים מוקדמים יותר בתהליך הפיתוח
3. להגדיר לכל מערכת את רמת אבטחת המידע הרצויה ואת דרישות הפיתוח והבדיקות הרצויות בתהליך הפיתוח

התוצאה של שלושת המטרות הנ"ל הן:

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

נכתב ע"י: אופיר ענבר