אחד האלמנטים החשובים, אך המוזנחים ביותר כיום בתהליך הפיתוח בארגונים הוא תיקצוב היבטי אבטחת המידע כחלק מתוכנית העבודה של מתכנתים בארגון.
תהליך פיתוח בריא צריך להיות מורכב כבר מראשיתו מתשומת לב רבה להיבטי אבטחת מידע. חלק לא קטן מהמתכנתים לא מודעים מספיק לחשיבות הנושא ולפעמים חוסר תשומת הלב עולה עד לדרגים הגבוהים ביותר בגוף הפיתוח ביחידת מערכות המידע ועלולה לחשוף את מערכות הארגון לפגיעויות חמורות. בחלק מהארגונים בישראל אומרים לנו שהם מקפידים מאוד על עריכת מבדקי חדירות, כך שהם "מכוסים". חשוב להבין שביצוע מבדקי חדירות (penetration tests) באופן תדיר הוא מענה מצויין, אך חלקי בלבד ברוב המקרים. מטרת בדיקות החדירות היא זיהוי נקודות כשל ספציפית במערכת או אפליקציות ספציפית. כלומר, בהחלט יתכן שקיימת פגיעות במקום אחר באותה מערכת או אפליקציה שלא נתגלתה. איך אמר לי גורם מקצועי בתעשייה: תאר לעצמך שכדי לבדוק את פגיעות גדר המערכת באותו אתר מפורסם ליד דימונה ינסו לפרוץ אותה רק דרך רצועה של 20 מטר שנבחרה באקראי. מבדיקה כזו הרי לא מומלץ להקיש על הנעשה בחלקים אחרים של הגדר. כך גם בפיתוח: על מנת לתת מענה מקיף לפגיעויות שמקורן בקוד יש להתחיל את התהליך כבר במהלך הלימודים האקדמאים. בהמשך יש לשמור על מודעות בקרב המתכנתים לנושא התיכנות המאובטח באמצעות השתלמויות מעת לעת. גם כאן התהליך לא מסתיים והוא ממשיך גם לתהליך הכתיבה עצמה: החל בייזום הפרוייקט, איפיונו ועיצובו, כך שיעמדו גם בדרישות אבטחת מידע, דרך שימוש בכלים אוטומטיים/ידניים בעת כתיבת הקוד ועד הבטחת איכות (QA) גם להיבטי אבטחת המידע (code review) לצד בדיקות אחרות. זהו, על פי רוב, השלב שבו מתבצעות בדיקות החדירות למערכת.
אחת הבעיות הקשורות בתהליך מקיף יותר של פיתוח היא תיקצוב החלק שכל מתכנת צריך להקדיש לאבטחת מידע מתוך סה"כ זמן עבודתו.
בעקבות שאלות של לקוחות ביררנו את הנושא עם מספר גורמים שקשורים לתהליך הפיתוח ממספר כיוונים וביניהם מנהלי אבטחת מידע, מנהלי תשתיות, מנהלי תפעול וכן מנהלי פיתוח ו PMO: את השאלה העלנו גם בפורום"שולחן עגול" של portfolio management officers (או בשמם המקוצר PMO) על נושא פיתוח שנערך אצלנו לאחרונה. בפורום השתתפו נציגים של 10 ארגונים גדולים במשק.
התשובה הרווחת לעניין תיקצוב אבטחת מידע בתוך כל תהליך פיתוח היא שאין "כללי אצבע". כלומר בייזום פרוייקט חדש כל אחד ממנהלי הפרוייקטים יודע להגיד כמה מהתקציב הולך לאיפיון, כמה לעיצוב וכן הלאה אבל קשה לו לנקוב במספר או טווח לגבי טיפול בהיבטי אבטחת מידע. אם בכל זאת מנסים לפלח את התשובות גם על פי מקרי קיצון, אז אבטחת מידע בפרויקטים של MF, מצד אחד, לא מתוקצבת כלל (מטבע הדברים) ואילו בפרויקטים עם ממשק web, מצד שני, אחוזוני אבטחת המידע עולים (שמענו אחוזים כמו 5%, 8% ואפילו 10% במקרה ספציפי מסויים של מערכת ליבה מאוד חשובה לארגון על פלטפורמת web). באופן כללי כל ההתייחסות לחלק של אבטחת מידע בפרוייקט היא תלויית צורך ועולה בשלב האפיון בדר"כ. מנהל אבטחת מידע בארגון גדול אומר שכל פרוייקט מתוקצב גם לנושא האב"מ, אבל קשה לנקוב באחוז מדוייק. בתיקצוב של סקרי סיכונים או בדיקות חדירות התהליך יותר פשוט: הם נוהגים להכניס את זמן העבודה על ליקויי אבטחת מידע לתוך תקצוב פרוייקטי ה PEN TEST, כלומר לחייב את לקוח הפרוייקט גם בתקורה נוספת על עלות הפרוייקט לצורך בדיקות ותיקוני ליקויים בעקבות בדיקות חדירות. ע"פ הניסיון שלו הממוצע במקרים אלה הוא בערך 5% מהתיקצוב, אך היו לו פרויקטים של 8% (פרוייקט ליבה של מערכת גדולה בארגון עם ממשק אינטרנטי). מנהל תפעול בארגון פיננסי מספר שפיתוח מאובטח מהווה בערך 1%-3% מתיקצוב הפיתוח והנושא כפוף למו"מ. בפיתוח תשתית חדשה האחוזים יעלו כמובן. בפרויקטים מסויימים הגיע החלק של אבטחת מידע גם עד 8% (שוב, במערכות ווביות עם שרתים ב DMZ וכן הלאה).
מנהל אבטחת מידע בארגון פיננסי אחר מספר על מו"מ שמסתיים בדר"כ בתיקצוב אב"מ של מ 1% מזמן עבודת מתכנתים כללים בארגון ועד 5% למתכנתי אפליקציות.
לסיכום: הסקאלה שעולה מהבדיקה היא 0%- 10%. ברוב המקרים מדובר על 3%-5% מסך תקציב הפיתוח. זה מספיק? תלוי את מי שואלים.
תהליך פיתוח בריא צריך להיות מורכב כבר מראשיתו מתשומת לב רבה להיבטי אבטחת מידע. חלק לא קטן מהמתכנתים לא מודעים מספיק לחשיבות הנושא ולפעמים חוסר תשומת הלב עולה עד לדרגים הגבוהים ביותר בגוף הפיתוח ביחידת מערכות המידע ועלולה לחשוף את מערכות הארגון לפגיעויות חמורות. בחלק מהארגונים בישראל אומרים לנו שהם מקפידים מאוד על עריכת מבדקי חדירות, כך שהם "מכוסים". חשוב להבין שביצוע מבדקי חדירות (penetration tests) באופן תדיר הוא מענה מצויין, אך חלקי בלבד ברוב המקרים. מטרת בדיקות החדירות היא זיהוי נקודות כשל ספציפית במערכת או אפליקציות ספציפית. כלומר, בהחלט יתכן שקיימת פגיעות במקום אחר באותה מערכת או אפליקציה שלא נתגלתה. איך אמר לי גורם מקצועי בתעשייה: תאר לעצמך שכדי לבדוק את פגיעות גדר המערכת באותו אתר מפורסם ליד דימונה ינסו לפרוץ אותה רק דרך רצועה של 20 מטר שנבחרה באקראי. מבדיקה כזו הרי לא מומלץ להקיש על הנעשה בחלקים אחרים של הגדר. כך גם בפיתוח: על מנת לתת מענה מקיף לפגיעויות שמקורן בקוד יש להתחיל את התהליך כבר במהלך הלימודים האקדמאים. בהמשך יש לשמור על מודעות בקרב המתכנתים לנושא התיכנות המאובטח באמצעות השתלמויות מעת לעת. גם כאן התהליך לא מסתיים והוא ממשיך גם לתהליך הכתיבה עצמה: החל בייזום הפרוייקט, איפיונו ועיצובו, כך שיעמדו גם בדרישות אבטחת מידע, דרך שימוש בכלים אוטומטיים/ידניים בעת כתיבת הקוד ועד הבטחת איכות (QA) גם להיבטי אבטחת המידע (code review) לצד בדיקות אחרות. זהו, על פי רוב, השלב שבו מתבצעות בדיקות החדירות למערכת.
אחת הבעיות הקשורות בתהליך מקיף יותר של פיתוח היא תיקצוב החלק שכל מתכנת צריך להקדיש לאבטחת מידע מתוך סה"כ זמן עבודתו.
בעקבות שאלות של לקוחות ביררנו את הנושא עם מספר גורמים שקשורים לתהליך הפיתוח ממספר כיוונים וביניהם מנהלי אבטחת מידע, מנהלי תשתיות, מנהלי תפעול וכן מנהלי פיתוח ו PMO: את השאלה העלנו גם בפורום"שולחן עגול" של portfolio management officers (או בשמם המקוצר PMO) על נושא פיתוח שנערך אצלנו לאחרונה. בפורום השתתפו נציגים של 10 ארגונים גדולים במשק.
התשובה הרווחת לעניין תיקצוב אבטחת מידע בתוך כל תהליך פיתוח היא שאין "כללי אצבע". כלומר בייזום פרוייקט חדש כל אחד ממנהלי הפרוייקטים יודע להגיד כמה מהתקציב הולך לאיפיון, כמה לעיצוב וכן הלאה אבל קשה לו לנקוב במספר או טווח לגבי טיפול בהיבטי אבטחת מידע. אם בכל זאת מנסים לפלח את התשובות גם על פי מקרי קיצון, אז אבטחת מידע בפרויקטים של MF, מצד אחד, לא מתוקצבת כלל (מטבע הדברים) ואילו בפרויקטים עם ממשק web, מצד שני, אחוזוני אבטחת המידע עולים (שמענו אחוזים כמו 5%, 8% ואפילו 10% במקרה ספציפי מסויים של מערכת ליבה מאוד חשובה לארגון על פלטפורמת web). באופן כללי כל ההתייחסות לחלק של אבטחת מידע בפרוייקט היא תלויית צורך ועולה בשלב האפיון בדר"כ. מנהל אבטחת מידע בארגון גדול אומר שכל פרוייקט מתוקצב גם לנושא האב"מ, אבל קשה לנקוב באחוז מדוייק. בתיקצוב של סקרי סיכונים או בדיקות חדירות התהליך יותר פשוט: הם נוהגים להכניס את זמן העבודה על ליקויי אבטחת מידע לתוך תקצוב פרוייקטי ה PEN TEST, כלומר לחייב את לקוח הפרוייקט גם בתקורה נוספת על עלות הפרוייקט לצורך בדיקות ותיקוני ליקויים בעקבות בדיקות חדירות. ע"פ הניסיון שלו הממוצע במקרים אלה הוא בערך 5% מהתיקצוב, אך היו לו פרויקטים של 8% (פרוייקט ליבה של מערכת גדולה בארגון עם ממשק אינטרנטי). מנהל תפעול בארגון פיננסי מספר שפיתוח מאובטח מהווה בערך 1%-3% מתיקצוב הפיתוח והנושא כפוף למו"מ. בפיתוח תשתית חדשה האחוזים יעלו כמובן. בפרויקטים מסויימים הגיע החלק של אבטחת מידע גם עד 8% (שוב, במערכות ווביות עם שרתים ב DMZ וכן הלאה).
מנהל אבטחת מידע בארגון פיננסי אחר מספר על מו"מ שמסתיים בדר"כ בתיקצוב אב"מ של מ 1% מזמן עבודת מתכנתים כללים בארגון ועד 5% למתכנתי אפליקציות.
לסיכום: הסקאלה שעולה מהבדיקה היא 0%- 10%. ברוב המקרים מדובר על 3%-5% מסך תקציב הפיתוח. זה מספיק? תלוי את מי שואלים.
עדכון לכתבה למעלה 17.12.08:
לאחר פרסום הפוסט ביקשתי תגובה מאחד הגורמים המקצועיים החשובים בתחום בישראל. הנה תגובתו כלשונה:
"בדיקות חוסן טובות, אינן בודקות פגיעות רק ב "20 מטר מוגדרים של הגדר". בדיקת חוסן, בניגוד לתהליכים אחרים אשר מקובלים לאחר סיום הפיתוח, הנה הדרך החסכונית ביותר מבחינה תקציבית, להבין היכן החולשות ה"אמיתיות" של האפליקציה או המערכת, מכיוון שהן מדמות את אותן שיטות, טכניקות וטכנולוגיות בהן משתמשים התוקפים האמיתיים ולא בדיקה תיאורטית של היכן "יכולות" להיות בעיות.
אבטחת מידע, מורכבת ככל סוג אחר של אבטחה ממעגלי אבטחה. מודעות, הינה השלב הראשון כלומר "המעגל הראשון" של אבטחת המידע. בדיקות חוסן, הנן מעגל נוסף של אבטחת מידע. ביניהן, יש כתיבת קוד מאובטח, נהלי קוד מאובטח, הקשחת השרתים עליהם נמצאת האפליקציה ויישום מוצרי מדף המאפשרים להעלות את רמת אבטחת המידע.
במאמר חסר נושא האפקט המצטבר: כאשר מתקצבים מודעות לאבטחת מידע או קורס בכתיבת קוד מאובטח תחת סעיף תקציבי של פרויקט זה או אחר, למעשה מקבלים את אותו הידע, והאיכות גם לפרויקטים נוספים. מתכנת אשר למד לכתוב קוד נכון מהיבטי אבטחת מידע, יעשה זאת בכל פרויקט אשר ישתתף בו, אלא אם כן קיבל הנחיות מפורשות לא לעשות כך. מכך, שהשקעה חד פעמית של הכשרה ומודעות, תורמת לארגונים בטווח הארוך, ולאו דווקא לפרויקט ספציפי."
אבטחת מידע, מורכבת ככל סוג אחר של אבטחה ממעגלי אבטחה. מודעות, הינה השלב הראשון כלומר "המעגל הראשון" של אבטחת המידע. בדיקות חוסן, הנן מעגל נוסף של אבטחת מידע. ביניהן, יש כתיבת קוד מאובטח, נהלי קוד מאובטח, הקשחת השרתים עליהם נמצאת האפליקציה ויישום מוצרי מדף המאפשרים להעלות את רמת אבטחת המידע.
במאמר חסר נושא האפקט המצטבר: כאשר מתקצבים מודעות לאבטחת מידע או קורס בכתיבת קוד מאובטח תחת סעיף תקציבי של פרויקט זה או אחר, למעשה מקבלים את אותו הידע, והאיכות גם לפרויקטים נוספים. מתכנת אשר למד לכתוב קוד נכון מהיבטי אבטחת מידע, יעשה זאת בכל פרויקט אשר ישתתף בו, אלא אם כן קיבל הנחיות מפורשות לא לעשות כך. מכך, שהשקעה חד פעמית של הכשרה ומודעות, תורמת לארגונים בטווח הארוך, ולאו דווקא לפרויקט ספציפי."
רשומות
