You are on page 1of 21

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax.

972-97442444‬‬

‫סיכום מפגש שולחן‪-‬עגול‬

‫"פיתוח ממרס אבטחה‬


‫ממאדים"‬ ‫‪1‬‬

‫(אבטחת מידע בפיתוח מערכות ב‪)IT -‬‬

‫עורכים‪ :‬פיני כהן ושחר גייגר מאור‬

‫‪1‬‬
‫אפשר גם אבטחה ממרס ופיתוח ממאדים‪...‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫תוכן עניינים‬
‫תמצית מנהלים ‪2....................................................................................................‬‬
‫תהליך פיתוח "אידאלי" מהיבט אבטחת מידע ‪3.........................................................‬‬
‫סוגיות בעייתיות ‪3................................................................................................‬‬
‫‪ – Security.Net‬אבטחה ברשת ‪5..............................................................................‬‬
‫שיפור תהליכי עבודה ‪9.............................................................................................‬‬
‫הפיתוח הוא של השותפים\מוצרים‪ ,‬אבטחת המידע –של הארגון‪10..................................‬‬
‫נאמן אבטחת מידע ‪12.............................................................................................‬‬
‫תקציב אבטחת המידע בפיתוח ‪14..............................................................................‬‬
‫דוגמאות לטכנולוגיות בשימוש ‪15...............................................................................‬‬
‫אבטחת מידע באקדמיה ‪16.......................................................................................‬‬
‫טיפים והמלצות לשיפור יחסי אבטחת המידע‪/‬פיתוח ‪17..................................................‬‬
‫נספח מיוחד –התייחסות ספקים לנאמר במפגש ‪18.......................................................‬‬
‫התייחסות חברת אמן‪18.......................................................................................‬‬
‫התייחסות חברת ‪18....................................................................................... F5‬‬
‫התייחסות חברת ‪19..................................................................................... IBM‬‬
‫התייחסות חברת ‪19.................................................................................. Matrix‬‬
‫התייחסות חברת ‪20................................................................................... Ness‬‬
‫התייחסות חברת ‪21............................................................................... Tescom‬‬

‫תמצית מנהלים‬
‫פיתוח מערכות הוא אחת מנקודות הקשר המעניינות ביותר בין עולם הפיתוח לעולם אבטחת‬
‫המידע‪.‬‬
‫בעוד שאנשי הפיתוח ניצבים מול אתרים טכנולוגים מורכבים‪ ,‬לו"ז קשוח ועומס עבודה טבעי‪,‬‬
‫הם נדרשים לעמוד לא פעם גם באתגרים הנוגעים להיבטי אבטחת המידע של המערכת‪.‬‬
‫אנשי אבטחת המידע‪ ,‬לעומתם‪ ,‬מוצאים עצמם‪ ,‬לא פעם‪ ,‬ממודרים מפרוייקטים בשל "החשש‬
‫מהצקות" שלהם למנהלי הפיתוח ועיכוב העליה לאוויר‪ .‬אחריות מנהלי אבטחת היא לשמור‬
‫על סטנדרטים גם בנושאי פיתוח ואתגר זה לא פשוט בכלל‪.‬‬
‫המוטיבציות של שני הגורמים המקצועיים שונות לגמרי במקרים רבים והבדלים אלה עלולים‬
‫להביא לחיכוכים‪ ,‬וסיכונים מיותרים‪ .‬מטרת המפגש הנ"ל היא לתאר את נקודות החיכוך‬
‫העיקריות בין גופי הפיתוח לאבטחת המידע ולנסות למצוא נקודות לשיתוף פעולה‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫דוגמה בולטת לפערים בין שני הגופים הוא המונח ‪ .SDLC‬מונח זה נפוץ בשימוש על ידי שני‬
‫הגופים אולם הפירוש הוא שונה בתכלית!‬
‫‪ SDLC‬אליבא‪-‬דה אנשי הפיתוח משמעו ‪ .Software Development Lifecycle2‬אולם לפי‬
‫אנשי האבטחה משמעו ‪ .Secured Development Lifecycle3‬כלומר‪ ,‬אין שפה משותפת‬
‫בין הצדדים‪.‬‬
‫במפגש השתתפו נציגים מגופי פיתוח וניהול פרוייקטים לצד אנשי אבטחת מידע במספר‬
‫ארגונים גדולים ובינוניים בישראל‪ .‬רוב המשתתפים מגיעים מהסקטור הממשלתי והפיננסי‪,‬‬
‫אך היו בו נציגים ממגזרים נוספים‪.‬‬
‫מצ"ב סיכום עקרי הדברים שעלו במהלך המפגש‪ .‬במפגש עלו נושאים מהותיים שתומצתו‬
‫בסיכום כפי שעלו‪ .‬אין בסיכום זה המלצה גורפת ללקוחות אלא מתן פרספרטיבה והצגה של‬
‫ההתלבטויות שעלו במפגש‪ ,‬כלומר "מהשטח"‪.‬‬

‫תהליך פיתוח "אידאלי" מהיבט אבטחת מידע‬


‫לרוב המשתתפים ברור הצורך בשילוב אבטחת המידע בתהליך הפיתוח כאשר שילוב זה‬
‫אמור לכלול במצב אידאלי‪:‬‬
‫‪ .1‬ערוב של אבטחת מידע בכל שלבי הפרוייקט ‪ -‬החל בשלב הייזום (לפעמים עוצרים‬
‫כבר בשלב הזה פרוייקט בגלל אי יישימות או סיכון אבטחתי)‪ ,‬המשך בשלב הניתוח‪,‬‬
‫הקידוד ועד השלבים השונים של הבדיקות‪.‬‬
‫‪ .2‬כלי בדיקות אוטומטיות במהלך הקידוד‪ .‬אידאלית הקוד נבדק כל הזמן\כל יום‪.‬‬
‫‪ .3‬ביצוע סקר קוד ייעודי מעמיק בשלב הבדיקות בנושא של אבטחת מידע‪.‬‬
‫‪ .4‬בדיקות ‪– "white-black-gray" ( 4PT‬ראו ביאור בהמשך) על קוד בשל שעבר ‪QA‬‬
‫אחד לפחות‪ .‬ישנם ארגונים אשר מבצעים ‪ PT‬גם בייצור (כלומר ‪ PT‬שני)‪.‬‬
‫‪ .5‬נהלים של אבטחת מידע לפיתוח – "עשה ואל תעשה" בכל טכנולוגיה‪.‬‬
‫‪ .6‬הכשרות בסיסיות של כל המפתחים והכשרות מתקדמות יותר למפתחים שהנם‬
‫"נאמני אבטחת מידע"‪.‬‬

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

‫‪2‬‬
‫‪ http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle‬וגם‬
‫‪http://en.wikipedia.org/wiki/Software_development_process‬‬
‫‪3‬‬
‫‪https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/sdlc/326-BSI.html‬‬
‫‪4‬‬
‫‪Penetration test‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫נציג מארגון פיננסי העלה את הקושי הזה כקושי מרכזי בליווי פרוייקטים מצד‬
‫אבטחת המידע‪ .‬בארגון זה יש קושי בהגדרה של מה זה בדיוק "פרוייקט"‪ .‬במקרים‬
‫שלא מוגדר "פרוייקט" –אין אבטחת מידע מתחילת התהליך ומבחינתם של אנשי‬
‫הפיתוח המיזם "סובל" פחות מבירוקרטיות‪ .‬דוגמא לכך היא שינוי מסויים שהתבקש‬
‫במערכת מסויימת בארגון‪ .‬כחלק מהשינוי ניתנו הרשאות גישה לנתונים רגישים‪.‬‬
‫בגלל שהשינוי לא הוגדר "פרוייקט" הוא חמק מעיניהם של אנשי אבטחת המידע והם‬
‫גילו את השינוי רק בדיעבד‪.‬‬
‫האם המפתחים רשאים לראות נתונים כאלה ואחרים תוך כדי תהליך הפיתוח? האם‬ ‫‪‬‬
‫בכלל ניתן לבצע פיתוח בלי לראות את הנתונים כלל? מובן שמפתחים (ובודקים) ירצו‬
‫לעבוד על נתונים קרובים ככל הניתן לנתוני האמת‪.‬‬
‫אחד הפתרונות המוצעים על ידי אנשי אבטחת המידע ומוזכרים ברגולציות כגון ‪PCI5‬‬
‫הם פתרונות לערבול נתונים‪ .‬ערבול נתונים מלא הוא משימה כמעט בלתי אפשרית‪,‬‬
‫לדעתם של חלק מהנוכחים‪ ,‬בגלל אוסף המערכות והקשרים המורכבים בין הנתונים‪.‬‬
‫פערים טכנולוגיים‪ :‬לטענת אנשי הפיתוח‪ ,‬אנשי אבטחת המידע חוסמים לעתים‬ ‫‪‬‬
‫שימוש בטכנולוגיות מסויימות בגלל חשש מוגזם או בגלל חוסר ידע מספק‪ .‬לדוגמא‪:‬‬
‫לקוח תאר מצב שבו אסרו עליו להשתמש ב‪ AJAX -‬או ‪ . jQuery‬אנשי אבטחת‬
‫המידע מנסים לעתים לנתב את הפיתוח לטכנולוגיות מוכרות להם כדי שיוכלו להכיר‬
‫טוב יותר את תהליכי הפיתוח ולנטר אותם‪ .‬פרוייקטים בעייתים במיוחד הם פרוייקטי‬
‫‪ .Main-Frame‬תחום ה ‪ MF‬מתאפיין ברמת מומחיות גבוהה מאוד וידע אשר לא‬
‫תמיד קיים ברשותם של אנשי אבטחת המידע‪ .‬פיקוח על פרוייקטים אלה מאוד קשה‬
‫באופן טבעי אם כי נחשב ברמת סיכון נמוכה יחסית‪.‬‬
‫קוד שמתקבל מגורמי צד שלישי‪ .‬אחד הארגונים תאר מצב שבו התקבלה בארגון‬ ‫‪‬‬
‫אפליקציה שפותחה על ידי בית תוכנה קטן מאוד (אפליקציה בתחום רשתות‬
‫חברתיות – תחום המטופל על ידי אגף השיווק) שהמרחק בינו לבין פיתוח במתכונת‬
‫‪ SDLC‬גדול מאוד‪ .‬בגלל אופי הארגון והאיומים‪ ,‬נדרש בית תוכנה זה לעמוד‬
‫בדרישות הפיתוח של ‪ .SDLC‬דרישה זו האריכה את זמן העליה לאוויר של קמפיינים‬
‫מסויימים פי ‪ 6‬מהמתוכנן (!!)‪ .‬במובנים עסקיים מדובר על מחיר גבוה שהארגון‬
‫שילם כדי לשמור על סטנדרטים גבוהים של אבטחת מידע‪ .‬אולם בארגונים אחרים‬
‫עלתה תמונה הפוכה‪ .‬במקרה אחר סופר כי בעבר נמצאו מערכות עם לקויים‬
‫וחולשות אבטחתיות ונדרשו תיקונים‪ ,‬אולם בשום מקרה לא ירדה מהאוויר מערכת‬

‫‪5‬‬
‫‪/https://www.pcisecuritystandards.org‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫בשל ליקויי אבטחה שנמצאו בה‪ .‬ישנם מקרי ביניים שבהם מעלים מערכת עם בעיות‬
‫מבחינת אבטחת מידע אך מעדכנים את גוף ניהול הסיכונים בארגון‪.‬‬
‫ההבדלים בין סביבת הבדיקות והפיתוח לבין סביבת הייצור‪ .‬נושא ה"סביבות" הוא‬ ‫‪‬‬
‫‪6‬‬
‫נושא בעייתי במספר רב של מובנים ‪ .‬הקושי העיקרי בהקשר של אבטחת מידע הוא‬
‫העובדה ששרתי הייצור מוקשחים יותר משרתי הפיתוח\בדיקות‪ .‬נקודה זו מביאה‬
‫לכך שפונקציונליות שעובדת בפיתוח\בדיקות עלולה לא לעבוד בסביבת הייצור‪.‬‬
‫לטענת מספר משתתפים בדיון‪ ,‬סביבת הבדיקות אמורה להיות שונה מסביבת הייצור‬
‫‪File‬‬ ‫כדי לאפשר ‪ Debug‬טוב יותר (לדוגמא‪ :‬לקוח אינו מאפשר יכולת של‬
‫‪ Export\Import‬של ‪ SPS-MOSS‬בייצור אך כן מאפשר זאת בפיתוח ובבדיקות)‪.‬‬

‫‪ – Security.Net‬אבטחה ברשת‬
‫"בשבילי זה ‪ ,Bug‬בשביל איש אבטחת מידע זה ‪"Backdoor‬‬
‫הציטוט למעלה מתמצת בצורה טובה מאוד את הבדלי הגישה בין גופי הפיתוח לאנשי‬
‫אבטחת המידע ברוב הארגונים בישראל‪.‬‬
‫נציג אבטחת מידע בארגון ממשלתי סיפר על ניסיון שלהם להכניס את היבטי אבטחת המידע‬
‫כבר בתהליך הייזום של כל פרוייקט חדש‪ .‬גוף אבטחת המידע בארגון זה שייך לאגף‬
‫הביטחון‪ .‬לקח להם הרבה מאוד זמן להצליח להיות מעורבים בפרוייקטים בצורה טובה‬
‫ולהוריד את החיכוכים‪ .‬הם כתבו טופס מיוחד שיש למלאו על ידי מנהלי הפרוייקט ולהגישו‬
‫לאנשי אבטחת המידע ולאשר את המשך הפרוייקט ביחד איתם‪ .‬השאיפה בארגון זה היא‬
‫להגיע לשיתוף פעולה טוב בין הגופים‪" :‬להיות חלק ממחזור הפיתוח ולא נטל"‪.‬‬
‫המצב בארגון זה נחשב לטוב מאוד בראיה של איש אבטחת מידע‪ :‬אין כיום פרוייקט‬
‫אינטרנטי שעולה לאוויר ללא אישור שלהם‪ .‬במקרה מסויים "החזירו פרוייקט חצי שנה‬
‫אחורה" בגלל ליקויי אבטחת מידע שלא דווחו כהלכה לגורמי האבטחה בארגון‪.‬‬

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

‫‪6‬‬
‫על כך שולחן עגול בהמשך השנה‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫בגלל הרגולציה הארגון יכול להרשות לעצמו להחזיק מספר אנשי אבטחת מידע עם התמחות‬
‫בעולם האפליקטיבי‪ .‬אנשים אלה נותנים שירותי ערך מוסף לגופי הפיתוח ואף כותבים‬
‫בעצמם קטעי קוד בעייתיים במידת הצורך‪ .‬מדובר על צוות ("אבטחת מידע אפליקטיבית" –‬
‫בדומה ל‪ DBA -‬אפליקטיבי) המונה כ‪ 1% -‬מאנשי הפיתוח‪.‬‬

‫מנהל תחום הקשור לפיתוח בארגון פיננסי אחר סיפר איך זה נראה מהצד השני‪:‬‬
‫הוא תמיד חיי בתחושה שהמפתחים נמצאים במעין "אקווריום" ואין להם יכולת להרים את‬
‫הראש ולראות מה קורה בחוץ‪ .‬גם הוא מרגיש שהרגולציה עושה הרבה סדר ומביאה לייעול‬
‫של התהליכים‪ .‬מבחינתו שיתוף הפעולה בין אבטחת המידע לפיתוח הוא טוב "ברגע שאנשי‬
‫האבטחה מעורבים מראשית התהליך"‪ .‬משתתף נוסף מארגון זה (גם הוא מתחום הקשור‬
‫לפיתוח) סיפר על נקודות המגע העיקריות בין אנשי הפיתוח לאנשי אבטחת המידע‪ .‬לדבריו‪,‬‬
‫אין כמעט ויכוחים בכל הקשור לפונקציונליות הסופית ולאיפיון המערכת‪ .‬רוב הויכוחים‬
‫והחיכוכים הם על השאלה "איך להגיע לאותה פונקציונליות?" כלומר לגבי תהליכי הפיתוח‬
‫עצמם‪ .‬אנשי הפיתוח בארגון זה מכירים בצורך לשמור על סטנדרטים של פיתוח מאובטח‪,‬‬
‫אך את הדרך לשם הם לא תמיד רואים עין בעין עם אנשי האבטחה‪ .‬לדוגמא‪ :‬האם‬
‫המפתחים רשאים לראות נתונים כאלה ואחרים תוך כדי תהליך הפיתוח? האם בכלל ניתן‬
‫לבצע פיתוח בלי לראות את הנתונים?‬
‫כחלק מהדיון בנקודה זו שאלנו מה לגבי ערבול או מיסוך של נתוני ייצור במעבר לסביבות‬
‫פיתוח ובדיקות? התגובות סביב השולחן היו מאוד צוננות ועושה רושם שהניסיון עם פתרונות‬
‫לערבול נתונים לא היה טוב על פי נסיונם של משתתפים אלה‪.7‬‬
‫כמובן שלא בכל הארגונים קיימת תמיד אידאליה‪ .‬נציג מתחום הפיתוח בארגון פיננסי מספר‬
‫כי בעבר הוא "סבל מאוד" מהתערבות של אנשי אבטחת המידע בתהליכי הפיתוח שלו‪ .‬היום‬
‫הם נמצאים בסטאטוס יותר רגוע ומחפשים את השפה המשותפת בין הגופים‪ .‬ברור לו כי גם‬
‫כאיש פיתוח כדאי לשלב את אנשי אבטחת המידע כמה שיותר מוקדם בתוך התהליך כדי‬
‫להמנע מחיכוכים ומריבות בהמשך‪.‬‬
‫משתתף זה העלה נקודה מעניינת מאוד סביב המקצועיות של הגורמים השונים‪:‬‬
‫מההתרשמות שלו קיים פער ידע בין אנשי הפיתוח לאנשי אבטחת המידע‪ .‬יש נושאים‬
‫שקשה למפתחים להסביר לאבטחת מידע והבדלי הידע האלה מביאים לחיכוכים‪ .‬לדוגמא‪:‬‬
‫כניסה של פרוייקט פיתוח מסויים לטכנולוגיות כמו ‪ AJAX‬או ‪" jQuery‬דיי סגורים" ולאיש‬
‫אבטחת מידע לא תמיד יש ידע מספיק כדי לחפש כשלים במערכות כאלה‪ .‬אנשי אבטחת‬

‫‪7‬‬
‫אין בהערה זו לחוות דעה‪ ,‬אלא להעביר את התחושה שהתקבלה סביב השולחן‪ .‬עושה רושם כי הבעיות‬
‫שהוצגו על ידי חלק מהמשתתפים בהקשר של מערכות לערבול נתונים אינן שונות גם מדיונים קודמים בעניין‪:‬‬
‫עקיבות של נתונים בחיבור של מספר מערכות ובסיסי נתונים וקושי באינטגרציה‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫המידע מנסים לעתים לנתב את הפיתוח לטכנולוגיות מוכרות להם כדי שיוכלו להכיר טוב‬
‫יותר את תהליכי הפיתוח ולנטר אותם‪ .‬פרוייקטים בעייתים במיוחד הם פרוייקטי ‪Main-‬‬
‫‪ .Frame‬תחום ה ‪ MF‬מתאפיין ברמת מומחיות גבוהה מאוד וידע אשר לא תמיד קיים‬
‫ברשותם של אנשי אבטחת המידע‪ .‬פיקוח על פרוייקטים אלה מאוד קשה באופן טבעי אם כי‬
‫נחשב ברמת סיכון נמוכה יחסית‪.‬‬
‫נציג תחום אבטחת המידע בארגון זה‪ ,‬האחראי בין השאר גם על היבטי הפיתוח המאובטח‬
‫מספר כי התחום גדל מאוד בשנים האחרונות‪ .‬הנהלים בארגון מדברים על שילוב אבטחת‬
‫המידע בשלב הייזום של כל פרוייקט רלוונטי והם רואים התקדמות גדולה בשנים האחרונות‪.‬‬
‫משתתף זה סיפר כי כל עוד הפרוייקט הוא פרוייקט מתוכנן‪ ,‬השילוב של אבטחת המידע‬
‫נעשה בצורה טובה יותר וכי בפרוייקטים חשובים קיימת ועדת היגוי שחברים בה כל הגורמים‬
‫הרלוונטים‪ .‬הבעיות מתחילות בפרוייקטים לא מתוכננים אשר לא תמיד מגיעים לידיעת גוף‬
‫אבטחת המידע‪.‬‬
‫נציג ארגון פיננסי נוסף העלה את הקושי הזה כקושי מרכזי בליווי פרוייקטים מצד אבטחת‬
‫המידע‪ .‬בארגון זה יש קושי בהגדרה של מה זה בדיוק "פרוייקט"‪ .‬במקרים שלא מוגדר‬
‫"פרוייקט" –אין אבטחת מידע מתחילת התהליך ומבחינתם של אנשי הפיתוח המיזם "סובל"‬
‫פחות מבירוקרטיות‪ .‬דוגמא לכך היא שינוי מסויים שהתבקש במערכת מסויימת בארגון‪.‬‬
‫כחלק מהשינוי ניתנו הרשאות גישה לנתונים רגישים‪ .‬בגלל שהשינוי לא הוגדר "פרוייקט"‬
‫הוא חמק מעיניהם של אנשי אבטחת המידע והם גילו את השינוי רק בדיעבד‪.‬‬
‫ואכן‪ ,‬במחקר שערכה חברת ‪ STKI‬לגבי נוהלי פיתוח בארגוני ‪ IT8‬עלה שישנו אחוז מכובד‬
‫על פעילויות שאינו מתוכנן (אינו הופיע בתוכנית השנתית)‪:‬‬

‫‪8‬‬
‫‪http://www.slideshare.net/pini/stki-application-developmentresearch‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫‪Regulation‬‬
‫‪15%‬‬

‫‪Planned‬‬
‫‪Unplanned‬‬ ‫‪Projects‬‬
‫‪Requests‬‬ ‫‪60%‬‬
‫‪25%‬‬

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

‫מאיזה שלב בפרוייקט חדש מעורבים‬


‫אנשי אבטחת המידע?‬
‫ישנם פרוייקטים‬
‫רלוונטים שלא‬
‫הייתי מודע‬
‫ברב הפרוייקטים‬
‫לקיומם עד שלב‬
‫הרלוונטים –‬
‫מתקדם מאוד‬
‫‪29%‬‬ ‫משלב הייזום‬
‫‪43%‬‬

‫ברב הפרוייקטים‬
‫הרלוונטים –‬
‫משלב‬
‫הפיתוח\עיצוב‬
‫\בניה‬
‫‪28%‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫מהתרשים למעלה עולה כי ברוב הפרוייקטים הרלוונטים‪ ,‬צוות אבטחת המידע מכיר ומלווה‬
‫את הפרוייקט‪ .‬עם זאת‪ ,‬חשוב לשים לב לממצא מאוד מדאיג‪ ,‬לפיו ‪ 29%‬ממנהלי אבטחת‬
‫המידע התוודו כי ישנם פרוייקטים "שנעלמו מהרדאר" שלהם עד שלב מתקדם מאוד (הכוונה‬
‫היא לפרוייקטים שבדיעבד היה צורך ללוותם מהתחלה)‪.‬‬
‫משתתף מארגון ממשלתי מסויים סיפר כי הוא אומנם מייצג את גוף הפיתוח‪ ,‬אך למעשה‬
‫עוסק לאחרונה באבטחת מידע כחלק מעיסוקו בפיתוח‪ .‬מההתרשמות שלו עולה כי יש שיתוף‬
‫פעולה טוב בין הגורמים‪ .‬משתתף אחר מתחום הפיתוח סיפר כי בהקשר זה כי הוא ומנהל‬
‫אבטחת המידע יושבים באותו חדר‪ .‬סידור זה‪ ,‬כשלעצמו‪ ,‬יכול למנוע רבים מהחיכוכים בין‬
‫הגופים ולקדם שיתוף פעולה פורה יותר‪.‬‬

‫שיפור תהליכי עבודה‬


‫שינויים ארגוניים מהווים מנוף לבחינה מחדש גם של יחסי הפיתוח עם אבטחת המידע‪.‬‬
‫ממצא זה עולה מדבריהם של חלק מהמשתתפים בדיון‪:‬‬
‫משתתף מתחום אבטחת המידע בארגון ממשלתי סיפר כי בארגונו לא תמיד עירבו את אנשי‬
‫אבטחת המידע בפרוייקטים חדשים‪ .‬כיום מתבצע מהלך גדול בארגון של הסבה מסביבת‬
‫פיתוח אחת לאחרת והוא בא ללמוד ולנסות לקדם שיפור בעבודה המשותפת עם אנשי‬
‫הפיתוח‪.‬‬
‫בארגון נוסף יש שינוי ביחסי העבודה בין הפיתוח לאבטחת מידע בעקבות שינוי ארגוני‪ .‬לפני‬
‫השינוי‪ ,‬אגף הפיתוח וממונה אבטחת המידע לא דיווחו לאותו מנהל‪ .‬כיום שניהם נמצאים‬
‫מתחת למנהל מערכות המידע והוא מעורב ברוב הפרוייקטים החשובים‪ .‬השיקול האם לשלב‬
‫את אבטחת המידע בפרוייקט מסויים היא שלו והחיים הרבה יותר פשוטים‪.‬‬
‫אחד המשתתפים סיפר על הדרך בה הוא "מזכיר" למפתחים את גוף אבטחת המידע‬
‫‪ PMO‬בארגון לגאנט והכניס תזכורות ודגלים של פניה‬ ‫בפרוייקטים‪ :‬הוא נכנס עם ה‬
‫לאבטחת מידע בשלבים שנראו לו חשובים‪ ,‬במיוחד בתחילת פרוייקט‪ .‬כך אחוז מאוד גבוה‬
‫מהפרוייקטים החדשים מגיע לידיעתו בזמן‪.‬‬
‫הערה חשובה נוספת בהקשר הזה מדברת על הראיה העסקית שיכולה להיות לאיש אבטחת‬
‫המידע‪ .‬חלק מהותי משלב האיפיון זה הסתכלות על הפונקציונליות של המערכת‪ .‬יש חשיבות‬
‫אבטחתית רבה אם מערכת מסויימת היא פנימית היום ומחר נחשוף אותה לאינטרנט‪ .‬אך עם‬
‫זאת‪ ,‬חשיבה מראש לגבי תכנון מערכת כזו ועצם הצורך בחשיפה שלה יכולה לחסוך בעיות‬
‫בהמשך הדרך‪ .‬המשתתף שהעלה את ההערה אומר כי לאיש אבטחת המידע חייבת להיות‬
‫אוריאנטציה עסקית בכל החלטה אבטחתית שלו‪ .‬דוגמא לכך היא המקרה הבא‪ :‬מערכת‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

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

‫הפיתוח הוא של השותפים\מוצרים‪ ,‬אבטחת המידע –של הארגון‬


‫בארגון מסויים איש אבטחת המידע המשתתף בדיון ציין כי במקור הוא היה איש פיתוח וכי‬
‫הוא מכיר מצויין את אופן הפעולה של "הצד השני"‪ .‬כחלק משיפור העבודה בארגון יש כוונה‬
‫לשלב מתודולוגיות ונהלים של פיתוח מאובטח‪ ,‬אשר עד היום טרם מומשו‪.‬‬
‫הנציג השני מארגון זה מגיע מגוף רוחבי הקשור לניהול פרוייקטים‪ .‬נציג גוף זה סיפר כי‬
‫בגוף הזה יש דגש חזק על בטיחות השירותים והמוצרים ולא על אבטחת מידע‪ .‬נושא‬
‫אבטחת המידע צריך לקבל יותר דגש ללא ספק‪ .‬בגלל אופי העבודה והממשק הרב עם גורמי‬
‫חוץ‪ ,‬קשה לא פעם להגדיר מהו רף המינימום בכל הקשור לאבטחת מידע ואיך בכלל ניתן‬
‫לאכוף אותו‪ .‬נקודה נוספת קשורה לבחירת הטכנולוגיה בכל פרוייקט ארגוני וזו‪ ,‬על פי נציג‬
‫זה‪ ,‬נגזרת מאופי הפרוייקט והגדרות הלקוח ולא משיקולי אבטחת המידע הפנים ארגוניים‬
‫(במידה ואלה לא הוגדרו מראש על ידי הלקוח)‪.‬‬
‫בארגון גלובלי מתלבטים לא מעט איך לשמור על רמה מינימלית של אבטחת מידע בחלקים‬
‫המגיעים משותפי פיתוח ומוצרים משלימים‪ .‬כל עוד הפיתוח נעשה "בבית" אין בעיה‪ .‬אבל‬
‫במידה ומדובר בפיתרון שמקורו בחברה חיצונית לא תמיד ניתן לבקש מהחברה לראות את‬
‫הקוד ולנתח אותו‪ .‬לסוגייה זו יש גם היבטים משפטיים ולא בטוח שניתן לעשות "הינדוס‬
‫לאחור" מבחינה חוקית‪ .‬דרך אחת לנסות ולפתור חלק מהבעיות היא לבצע הדרכות ולנסות‬
‫כן ליצור קשר עם חלק משותפי הפיתוח‪ .‬אופציות אחרות הן לבצע בדיקות חדירות מסוג‬
‫‪ 9blackbox‬אשר נחשבות ליקרות מאוד שכן הן צורכות זמן רב ומשאבים גדולים‪.‬‬
‫מערכות אופייניות בארגון זה מכילות כמות עצומה של שורות קוד וכדי לסרוק חלקים חשובים‬
‫בהן נעשה שימוש במערכות אוטומטיות לסריקת קוד (ראו התייחסות לכלים בהמשך)‪.‬‬

‫‪9‬‬
‫בבדיקות חדירות מסוג ‪ blackbox‬למבצע הבדיקות אין גישה לקוד עצמו והוא נאלץ למצוא פגיעויות או‬
‫חולשות בתנאים התחלתיים קרובים מאוד לאלה של גורם עויין אמיתי‪ .‬בטרמינולוגיה של מבצעי בדיקות‬
‫החדירות נהוגים שני ביטויים נוספים‪– Whitebox :‬בה למבצע הבדיקה יש את קוד המערכת (כאילו הוא פיתח‬
‫את המערכת בעצמו) ו ‪– Greybox‬בה למבצע הבדיקה יש חלקים מהקוד או פונקציונליות מסויימת של‬
‫המערכת‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

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

‫ארגון פיננסי מסויים סיפר כי המדיניות אצלם היא קניה ולא פיתוח מערכות חדשות‪ .‬כדי לגדר‬
‫את הסיכונים הכרוכים במערכות צד ג'‪ ,‬כדאי לנסות לסגור כמה שיותר פרטים במעמד‬
‫החוזה‪ .‬לגישה זו חיסרון מסויים‪ :‬לפעמים מקבלים מוצר המותאם מאוד לצרכי הארגון‪ ,‬מעין‬
‫גרסה ייחודית ובלעדית‪ ,‬שקשה לקבל עליה תמיכה (גם מהספק עצמו) בהמשך הדרך‪.‬‬
‫סוג אחר של בעיות רואים במערכות המפותחות לרשתות חברתיות‪ .‬כיום מבוצע הפיתוח על‬
‫ידי בית תוכנה קטן מאוד שהמרחק בינו לבין פיתוח במתכונת ‪ SDLC‬גדול מאוד‪ .‬בגלל אופי‬
‫הארגון והאיומים‪ ,‬נדרש בית תוכנה זה לעמוד בדרישות הפיתוח של ‪ .SDLC‬דרישה זו‬
‫האריכה את זמן העליה לאוויר של קמפיינים מסויימים פי ‪ 6‬מהמתוכנן (!!)‪ .‬במובנים עסקיים‬
‫מדובר על מחיר גבוה שהארגון שילם כדי לשמור על סטנדרטים גבוהים של אבטחת מידע‪.‬‬

‫משתתף אחר מהצד של אבטחת מידע בארגון עסקי סיפר כי בארגונו יש הרבה מאוד פיתוח‬
‫פנימי בארגון הן במערכות פנימיות והן במערכות בעלות ניראות אינטרנטית‪ .‬ארגון זה לא‬
‫כפוף לרגולציות משמעותיות והדבר מקשה מאוד על גוף אבטחת המידע‪ .‬קשה לכפות‬
‫תהליכי עבודה ופיתוח מאובטח והשיקולים המובילים ברוב הפרוייקטים הם שיקולי תחרות‬
‫ושיקולים עסקיים‪ .‬גם בארגון זה יש בעיה מאוד לא פשוטה בכל הקשור להתמודדות עם‬
‫מערכות המפותחות על ידי שותפים עסקיים של הארגון‪ .‬משתתף זה מספר על מספר רב של‬
‫מערכות שעלו לאוויר בשילוב עם מערכות צד ג' אשר לא פותחו לפי סטנדרטים מתאימים‪.‬‬
‫לחץ הזמן והרצון העסקי "להיות ראשון" מוריד בסדר העדיפויות את שיקולי האבטחה‪ .‬ברוב‬
‫המקרים נעשות בדיקות חדירות לאחר העליה לאוויר‪ .‬במקרים מסויימים בעבר נמצאו‬
‫מערכות עם לקויים וחולשות אבטחתיות ונדרשו תיקונים‪ ,‬אולם בשום מקרה לא ירדה‬
‫מהאוויר מערכת בשל ליקויי אבטחה שנמצאו בה‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫נאמן אבטחת מידע‬


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

‫נציגי גוף אבטחת מידע בארגון פיננסי סיפרו על חשיבות שיתוף הפעולה בין הפיתוח‬
‫לאבטחת המידע והרחיבו על הנעשה בארגונם‪" .‬כשיש תקלה כולם חוטפים"‪ .‬בארוע שהיה‬
‫לפני כמה שנים ובו דווח בתקשורת על תקלה אבטחתית במערכת מסויימת הוקפצו ותוזזו כל‬
‫הגורמים הקשורים בארגון במשך כמה ימים רק כדי לנסות ולאתר את מקור התקלה‪ .‬בדיעבד‬
‫התברר שלא נגרם כלל נזק‪ ,‬אך העלות הכוללת של עבודת הבדיקה המיותרת עלתה הון‪.‬‬
‫דוגמא זו ממחישה את הצורך בעבודה משותפת ברמה יומיומית בין הגופים השונים‬
‫הקשורים לפיתוח ותחזוקת מערכות‪.‬‬
‫בארגון זה ישנו דגש חזק על אמינות השירותים‪ .‬דגש זה מקדם בסדר העדיפויות את כל‬
‫התחום של אבטחת מידע ולכן הארגון "יכול להרשות לעצמו" מספר אנשי אבטחת מידע עם‬
‫התמחות בעולם האפליקטיבי‪ .‬אנשים אלה נותנים שירותי ערך מוסף לגופי הפיתוח ואף‬
‫כותבים בעצמם קטעי קוד בעייתיים במידת הצורך‪.‬‬
‫בארגון זה עובדים על פי מתודולוגיות ‪ SDLC‬על פי ‪ best practices‬של ארגון ‪OWASP‬‬
‫ופועלים על פי עקרונות ‪– CWE‬תקן בדיקת פגיעות במערכות‪.‬‬
‫בארגון מערבים נציג של אבטחת מידע כבר מתחילת הפרוייקט‪ .‬גם כאן‪ ,‬כמו ברוב הארגונים‬
‫במשק‪ ,‬אין לגוף אבטחת המידע יכולת לדעת על כל הפרוייקטים החדשים כבר מתחילתם‪.‬‬
‫כדי לצמצם למינימום את מספר הפרוייקטים "שנעלמים מהרדאר" של אבטחת המידע‪,‬‬
‫מוגדרים נהלי עבודה לצוותי הפיתוח וניהול הפרוייקטים ועל פיהם יש לדווח לגוף האבטחה‬
‫על כל פרוייקט חדש‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫כדי להוריד את העומס ולייעל את התהליך מעורבים אנשי האבטחה בנקודות מפתח חשובות‬
‫בפרוייקט‪:‬‬
‫בשלב הייזום –מעורבות עקרונית וראשונית‪ ,‬שלב האיפיון –מתן הערות של אבטחת מידע‬
‫במידת הצורך‪ ,‬בשלב הפיתוח –שהוא החלק הגדול של הפרוייקט בדר"כ‪ ,‬אבטחת המידע‬
‫פחות מעורבת‪ .‬שלב הבדיקות –אבטחת המידע משתלבת מחדש בבדיקות הקוד לאחר סיום‬
‫מחזור הפיתוח הראשון‪ .‬בשלב הבא מבוצעות בדיקות קוד אוטומטיות בעזרת כלים‬
‫אוטומטיים‪ .‬בשלב זה יושב איש אבטחת המידע שבוחן את הממצאים עם המתכנת ומסביר‬
‫לו את הממצאים‪ .‬השאיפה היא להביא להבנה ו"לגייס" את אנשי הפיתוח לחשיבה‬
‫אבטחתית יותר‪" .‬הופכים איש הפיתוח לנאמן אבטחת מידע"‪" .‬חשיבות הישיבה עם איש‬
‫הפיתוח היא עצומה‪ .‬הסקרנות הטבעית שלהם והרצון לייעל את עבודת הפיתוח במערכת‬
‫הבאה מביאה לשיתוף פעולה טוב מאוד ברוב המקרים"‪.‬‬
‫הממצאים שעלו בשלב הבדיקות עוברים לתיעוד ומעקב במערכת לניהול סיכונים‪.‬‬
‫השלב האחרון מבחינת אבטחת המידע הוא שלב בדיקות החדירות (‪- )PT‬שלב זה מיושם‬
‫על גרסת קוד בשלה מאוד שעברה לפחות סבב ‪ QA‬אחד‪.‬‬
‫כדי לנסות לקבל מושג על שיתוף הפעולה בין שני הגופים‪ ,‬שאלנו האם קיים בצוות ההיגוי‬
‫של אבטחת מידע בארגון נציג של אגף הפיתוח‪ .‬בוועדה זו נקבעים הנהלים וסדרי העבודה‬
‫הרוחביים בארגון בכל הקשור ליישום מדיניות אבטחת מידע‪ .‬כמו כן נקבעים שם נהלים‬
‫ספיציפיים לפרוייקטים ומערכות ארגוניות חשובות‪ .‬ברור‪ ,‬שהמצב ההפוך (נציג אבטחת מידע‬
‫בישיבות בנושאי פיתוח) מתקיים‪ .‬הדרך לראות עד כמה עובדים שני הגופים בשיתוף פעולה‬
‫טוב היא‪ ,‬בין השאר‪ ,‬לבחון את המעורבות השוטפת של אנשי הפיתוח בוועדת ההיגוי של‬
‫אבטחת המידע‪ .‬התפלגות התשובות במפגש מתוארת בתרשים הבא‪:‬‬

‫האם קיים אצלכם נציג אגף הפיתוח‬


‫בצוות ההיגוי הכללי של אבטחת‬
‫המידע?‬ ‫קיים –מגיע‬
‫לישיבות‬
‫באופן קבוע‬
‫ויש שת"פ‬
‫פורה‬
‫אחר\לא‬
‫‪20%‬‬
‫קיים‬
‫‪27%‬‬
‫לא קיים באופן‬
‫קבוע בצוות‬
‫קיים –לא תמיד‬ ‫ההיגוי –מגיע על‬
‫מגיע לישיבות‬ ‫פי צורך ויש‬
‫‪13%‬‬ ‫שת"פ פורה‬
‫‪40%‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫מהתרשים ניתן ללמוד כי ב ‪ 60%‬מהארגונים קיימת נוכחות מספקת של נציגי הפיתוח‬


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

‫תקציב אבטחת המידע בפיתוח‬


‫לאורך כל הדיון נשאלו המשתתפים לגבי נושא תיקצוב אבטחת המידע בכל הקשור למחזור‬
‫הפיתוח של מערכות חדשות‪ .‬במיוחד עניין אותנו לדעת האם התקציב הוא חלק מתקציב‬
‫הפרוייקט‪ ,‬חלק מתקציב אבטחת המידע בארגון או שלא מוגדר תקציב ספציפי לנושא?‬
‫מבדיקה בקרב הארגונים שהשתתפו בדיון עולה כי ב ‪ 48%‬מהמקרים‪ ,‬תקציב אבטחת‬
‫המידע מגולם בתוך תקציב הפרוייקט (כלומר העלות של הטיפול באבטחת מידע הנה מתוך‬
‫תקציב הפיתוח‪ ,‬למרות שברב המקרים אין סעיף תקציבי ספציפי לעניין)‪ ,‬ב ‪ 38%‬מהמקרים‬
‫מדובר על חלק מתקציב גוף אבטחת המידע ואילו ב ‪ 14%‬מהמקרים אין תקציב מוגדר‬
‫לנושא אבטחת המידע בתהליך הפיתוח או שנמצא תקציב ממקורות אחרים‪ .‬הערה‪ :‬מכיוון‬
‫שברוב הארגונים אין סעיף נפרד של תקצוב אבטחת מידע בתוך הפרוייקט‪ ,‬מדובר על‬
‫הערכה בלבד‪.‬‬

‫הממצאים מסוכמים בתרשים הבא‪:‬‬

‫איך מתוקצב נושא אבטחת המידע בכל‬


‫הקשור לפרוייקט חדש בארגון ?‬
‫לא מוגדר תקציב‬
‫ספציפי \ אחר‬
‫‪14%‬‬

‫חלק מתקציב‬
‫הפרוייקט‬
‫‪48%‬‬

‫חלק מתקציב‬
‫אבטחת המידע‬
‫בארגון‬
‫‪38%‬‬

‫שאלה אחרת שעלתה בפורום היא מהו החלק היחסי המוגדר לנושאי אבטחת מידע מתוך‬
‫כלל תקציב הפרוייקטים בארגון‪ .‬סעיף זה חולק למספר סעיפים עיקריים‪ :‬פרוייקטים חדשים‬
‫ופרוייקטים קיימים‪ .‬כמו כן התבקשו המשתתפים לבצע את האומדן לכל סביבה מהסביבות‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫הבאות‪ :‬פרוייקטי ‪ ,Main-Frame‬פרוייקטים במערכות פתוחות פנימיות ופרוייקטים‬


‫במערכות פתוחות הפונות לסביבת האינטרנט‪ .‬הממצאים מרוכזים בטבלה הבאה‪:‬‬

‫בפרוייקטים קיימים‬ ‫אחוז ההוצאה על אבטחת בפרוייקטים חדשים‬


‫מידע מתוך סך התקציב של‬
‫(תחזוקה)‬
‫פרוייקט נתון‬

‫‪1.5%‬‬ ‫‪1.33%‬‬ ‫פרוייקט בסביבת ‪MF‬‬


‫פרוייקט במערכות פנימיות\‬
‫‪4.15%‬‬ ‫‪5.45%‬‬ ‫אינטראנט בסביבה הפתוחה‬
‫‪7.25%‬‬ ‫‪9.33%‬‬ ‫פרוייקט במערכות אינטרנט‬

‫השונות בתשובות הייתה גבוהה יחסית וניתן לראות שישנם ארגונים בהם אחוז ההוצאה על‬
‫אבטחת מידע מתוך סך תקציב הפרוייקט יכול לנוע בין ‪ 0%‬בפרוייקטי ‪ MF‬ועד ‪ 40%‬או‬
‫‪ 50%‬באפליקציות אינטרנט רגישות‪.‬‬

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

‫דוגמאות לטכנולוגיות בשימוש‬


‫הדיון על טכנולוגיות וכלים בשימוש בארגונים ארך כ ‪ 20‬דקות בלבד‪ .‬עושה רושם שיש בעיות‬
‫דחופות יותר בתחום מהטכנולוגיה עצמה‪.‬‬
‫מבין הפתרונות שכן זכו לאיזכור חיובי ניתן למנות את ‪ Checkmarx‬אשר נחשבים לפיתרון‬
‫מוכר וטוב לתחום בדיקות הקוד האוטומטיות‪ .‬הביקורות ממי שציין את המוצר הזה היו‬
‫טובות מאוד‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫פיתרון אחר הוא ‪– Versafe‬סויטה של פתרונות הכוללים‪ ,‬בין השאר‪ ,‬יכולות לבדיקת קוד ו‬
‫‪ QA‬אבטחתי‪ .‬המוצר פותח על ידי המייסדים של חברת הייעוץ הישראלית ‪Bugsec‬‬
‫המתמחה בבדיקות קוד ומבדקי חדירות‪.‬‬
‫מוצר אחר שהוזכר הוא מוצר בשם ‪ Seeker‬שפותח על ידי מייסדי חברת ‪ Hacktics‬אשר גם‬
‫היא מתמחה בביצוע מבדקי חדירות למערכות וסקרי אבטחה‪ .‬כאן מדובר בפיתרון המריץ‬
‫בחלק מהמקרים התקפות מדומות על מערכות בפיתוח מתוך כוונה לאתר פגיעויות בהן‪.‬‬
‫הפיתרון יודע להקליט ולבצע תיחקור של המתקפה ולהשתלב בצורה יפה בתהליך הלמידה‬
‫של פיתוח המערכת ולשפר את אופן הפיתוח‪.‬‬
‫‪open‬‬ ‫פיתרון מעניין שהוזכר בהקשר של אכיפת מדיניות אבטחת מידע מול פתרונות‬
‫‪ source‬ויישומים שפותחו על ידי גורמים חוץ ארגוניים‪ ,‬בייחוד בהקשר של איתור קוד פתוח‬
‫ובחינת המשמעויות של סוג הרישוי של קוד זה‪ ,‬הוא של ‪.Blackduck‬‬
‫המשתתף שציין את הפיתרון הזה סיפר כי הוא מסוגל לסייע בהלבנה של החלקים הבעייתים‬
‫בקוד המקור‪ .‬בארגון זה מיושם הכלי בתצורת ‪ SAAS‬פעם בשנה משיקולי עלות‪.‬‬
‫במפגש הוזכרו בקצרה כמה כלים נוספים כגון ‪Fortify ,HP Dynamic Web Analyzer‬‬
‫ואחרים‪.‬‬

‫אבטחת מידע באקדמיה‬


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

‫על מה הויכוח? חלק מהאנשי אבטחת המידע בפורום טוענים כי יש ללמד לימודי אבטחת‬
‫מידע באופן פורמלי כמקצוע העומד בפני עצמו באקדמיה‪ .‬מסיים התואר יזכה באישור אקדמי‬
‫ויתרון בעיסוק כאיש אבטחת מידע‪ ,‬תוך קבלת רקע מקצועי במגוון היבטים אחרים של עולם‬
‫המיחשוב‪.‬‬
‫הקבוצה השניה גורסת כי יש לשלב את לימודי אבטחת המידע כחלק מתוכנית לימודים‬
‫סטנדרטית של מקצועות המחשב‪ .‬ניתן לעשות זאת במספר קורסים בסיסיים או כהתמחות‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

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

‫טיפים והמלצות לשיפור יחסי אבטחת המידע‪/‬פיתוח‬


‫בדיון עלו מספר טיפים לשיפור אבטחת המידע בהקשר של פיתוח‪:‬‬
‫שבו ודברו אחד עם השני ‪ -‬משתתף מתחום הפיתוח סיפר כי הוא ומנהל אבטחת‬ ‫‪‬‬
‫המידע יושבים באותו חדר‪ .‬דיאלוג הוא המפתח להתייעלות‪ .‬ללא ספק‪ ,‬רבות‬
‫מהבעיות והחיכוכים יכולים להמנע אם שני הצדדים ידברו אחד עם השני‪.‬‬
‫שתפו פעולה מהרגע הראשון –לאורך כל הדיון חוזר מסר זה משני המחנות‪ :‬יידוע‬ ‫‪‬‬
‫גוף אבטחת המידע ושילובו בתחילת כל פרוייקט מקילים מאוד על המשך התהליך‬
‫ומורידים עלויות פיתוח‪.‬‬
‫אימוץ סטנדרטים בעקבות רגולציות ‪-‬רגולציה באופן כללי עוזרת לאבטחה ועוזרת‬ ‫‪‬‬
‫לפיתוח מאובטח‪ PCI .‬היא דוגמא טובה מאוד לרגולציה אשר מעלה בצורה‬
‫משמעותית את המודעות לנושא‪.‬‬
‫"אנחנו על המפה" ‪-‬אחד המשתתפים סיפר על הדרך בה הוא "מזכיר" למפתחים את‬ ‫‪‬‬
‫גוף אבטחת המידע בפרוייקטים‪ :‬הוא נכנס עם ה ‪ PMO‬בארגון לתרשים הגאנט‬
‫והכניס תזכורות ודגלים של פניה לאבטחת מידע בשלבים שנראו לו חשובים‪ ,‬במיוחד‬
‫בתחילת פרוייקט‪ .‬כך אחוז מאוד גבוה מהפרוייקטים החדשים מגיע לידיעתו בזמן‪.‬‬
‫"אמץ" איש פיתוח ‪-‬רתימת איש פיתוח שיהווה רפרנט אבטחת מידע בתוך גוף‬ ‫‪‬‬
‫הפיתוח‪ .‬לדוגמא‪ :‬נציג גוף פיתוח בארגון מסויים מהווה רפרנט אבטחת מידע‪ .‬בין‬
‫השאר הוא מעורב בכתיבת נהלי אבטחת המידע הקשורים לפיתוח ולסקירת קוד‪.‬‬
‫החשיבות בגיוס של איש הפיתוח יכולה לתרום רבות להידוק היחסים בין הצדדים‪.‬‬
‫הכנס גורם מקצועי לעובי הקורה והוספת הדרכות – הכנסת יעוץ מקצועי לארגון‪ ,‬כזה‬ ‫‪‬‬
‫המכיר מצויין את המניעים והאתגרים של שני הצדדים יוכל לגשר בין הצדדים‬
‫("להרגיע" את גוף אבטחת המידע על ידי העלאת הידע המקצועי שלו בתחום‬
‫הפיתוח המאובטח ו"להרגיע" את גוף הפיתוח – על ידי מתן עצות פרקטיות לשיפור‬
‫תהליך הפיתוח תוך מתן תשומת לב לאבטחה)‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫נספח מיוחד –התייחסות ספקים לנאמר במפגש‬

‫התייחסות חברת אמן‬


‫(איש קשר‪ :‬דן פסטרנק‪) danp@aman.co.il :‬‬

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

‫התייחסות חברת ‪F5‬‬


‫(איש קשר‪ :‬גד אלקין‪) G.Elkin@F5.com :‬‬

‫‪" I think that their approach is good but is missing a key function - The last‬‬
‫‪round of checks should be done on the production system since the code on‬‬
‫‪production is many times different than the code on the test environment.‬‬
‫‪Another thing is to leverage network devices for things that can be developed‬‬
‫)‪(auth/auth‬‬
‫‪Last thing is that if you have a WAF, you could mitigate vulnerabilities fast‬‬
‫‪without taking dev resources, let the dev work out the fixing in their own time,‬‬
‫"‪this is an example where the security team can help dev reach milestones.‬‬

‫‪Also relevant:‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫התייחסות חברת ‪IBM‬‬


‫(אשת קשר‪ :‬אליה ויינברגר‪) e_weinberger@il.ibm.com :‬‬

‫אחת הבעיות שאיתה צריך מנהל אבטחת המידע להתמודד היא התראות שווא ‪,‬דבר שגוזל‬
‫לעיתים זמן רב בלנסות ולאמת אותן‪ .‬אחת הדרכים לצמצום התראות אלו וקבלת תוצאות‬
‫אמת הוא שילוב (קורלציה) של אנליזה סטטית ואנליזה דינמית‪.‬‬
‫שני הפתרונות יכולים לרוץ בנפרד ולספק תוצאות על פגיעויות‪ ,‬כאשר אנליזה סטטית סורקת‬
‫את הקוד עצמו ומחפשת מפגעים במעבר של המידע בין המתודות השונות ‪.‬‬
‫אנליזה דינמית מדמה התקפה של האקר אל מול האתר כאשר גם תשתיות האתר כגון בסיס‬
‫הנתונים ‪ web application,‬חשופים להתקפה‪.‬‬
‫אחת מנקודות התורפה של שתי השיטות הם ממצאי השווא עליהם שוקדים החוקרים‬
‫והמפתחים של המוצרים בנסיון לצמצם אותם‪.‬‬
‫השיטה להתגבר על הבעיה היא קורלציה (התאמה) של הממצאים משתי הכלים ‪,‬כאשר‬
‫לוקחים דוח של סריקה סטטית מעל סריקה דינמית ומבצעים קורלציה ניתן לוודא כי‬
‫הממצאים אכן מתריעים על מפגעים אמתיים ובכך להפחית משמעותית את התראות השווא‬
‫אחת מהחברות שמספקת פיתרון כזה היא ‪ IBM‬עם כלים ממשפחת ‪.Appscan‬‬

‫התייחסות חברת ‪Matrix‬‬


‫(איש קשר‪ :‬ארי רוזנבאום‪) ariro@matrix.co.il :‬‬

‫‪ .1‬עדכוני תוכנה ושינוי קונפיגורציה בשרתים פותחים פרצות חדשות‪.‬‬


‫‪ .2‬פיתוח קוד מאובטח לא מכיל הגנה מפני גניבת זהות‪ .‬אמצעים‪:‬‬
‫‪Phishing ‬‬
‫‪Pharming ‬‬
‫‪Key Logging ‬‬
‫‪Machine Trojan Infection ‬‬
‫‪:Application Access Control .3‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫‪ ‬יכולת לחסום גישת משתמש שאין ברשותו הגנה מפני גניבת זהות‪,‬‬
‫השתלטות על תחנה‪ ,‬הגנה מפני ‪ Key Logger‬וכדומה‪.‬‬
‫‪ ‬יכולת לחסום פעולות בהרשאות מסוימות‪.‬‬
‫‪:Application Restricted Zone - ARZ .4‬‬
‫‪ ‬הגדרת חלק מבודד באפליקציה שלא ניתן לגשת אליו ממקורות חיצוניים‬
‫(בדרך כלל החלק של האפליקציה שאחרי ה‪.)Login‬‬
‫‪ ‬סטנדרטים מתקדמים מסוג ‪ HTML5‬ופגיעויות בדפדפנים מאפשרים גניבת‬
‫מידע אישי‪ ,‬גניבת זהות‪ ,‬שליחת פקודות לאפליקציה וכדומה‪.‬‬
‫‪ .5‬שימוש בטכנולוגיה של ‪ Comitari‬מאפשר לארגון‪:‬‬
‫‪ ‬לקבל דיווחים ב‪ Real Time -‬על פרצות אמתיות באפליקציה שנוסו על‬
‫משתמשי האפליקציה‪.‬‬
‫‪ ‬הגנה מלאה מפני גניבת זהות‪.‬‬
‫‪ ‬דיווח על ניסיונות תקיפה וגניבת זהות של משתמשי האפליקציה‪.‬‬
‫‪ ‬סגירת מעגל האבטחה עם תוכנת הגנה ב ‪Client Side‬‬
‫‪ ‬מתן שכבת הגנה המספקת אבטחה לכל האפליקציות העושות שימוש ב‬
‫‪ browser‬וחוסכת את הצורך בפיתוח ייעודי לכל מערכת‬

‫חטיבת מוצרי התוכנה במטריקס מייצגת את פתרון האבטחה ‪. Comitari‬‬

‫התייחסות חברת ‪Ness‬‬


‫(אשת קשר‪ :‬דגנית בודק‪) Dganit.Bodek@ness.com :‬‬

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

‫‪: ActiveBase Security‬‬

‫פתרון תוכנה המאפשר מעקב והפעלת מדיניות אבטחה אקטיבית ובקרות גישה לבסיסי‬
‫הנתונים‪.‬‬
‫הפתרון מאפשר למנהל המערכת להפעיל חוקי הגנה ומיסוך נתונים דינאמי של נתונים‬
‫רגישים‪,‬‬
‫מידור בקשות המשתמשים בזמן אמת‪ ,‬יחד עם שמירת מעקב ותיעוד מפורט על כלל‬
‫השאילתות‬
‫(ואו על ביצוע פעולות ספציפיות) תוך מתן חיווי למשתמש והתראות לממונה\מנהל אחראי‬
‫במצבי חריגה‪.‬‬
‫המערכת פועלת באינטגרציה מלאה מול מערכת ניהול המשתמשים של הארגון (‪)LDAP‬‬
‫ומאפשרת זיהוי ומידור לפי שיוך המשתמש לקבוצות משתמשים ב ‪,ActiveDirectory‬סוגי‬
‫אפליקציות‪ ,‬זיהוי משתמש אפליקטיבי‪,‬‬
‫חסימת פקודות אסורות למשתמש אל מול בסיס הנתונים‪ ,‬ועוד‪...‬‬
‫בנוסף‪ ,‬הנתונים הרגישים ימוסכו בצורה דינמית עד לרמת השדה על פי ההרשאות שיוגדרו‬
‫לכל משתמש ‪.‬‬
‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫לצורך הדוגמא ‪ :‬לעובדים בסביבת הפיתוח כיום קיימת גישה חופשית למאגרי הנתונים של‬
‫הארגון‪,‬‬
‫עובדים אלו מסוגלים לצפות במידע מסווג כמו ‪ :‬נתוני שכר‪ ,‬ססמאות‪,‬מספרי כרטיסי אשראי‪,‬‬
‫מידע רפואי‪ ,‬וכו'‪,‬‬
‫כמו כן‪ ,‬מסוגלים לייצא מאגרי נתונים (למשל רשימת לקוחות החברה\כרטיסי אשראי) מחוץ‬
‫לארגון אף בהיבטים הפליליים ‪.‬‬
‫סביבה מוגנת ע"י ‪ ActiveBase‬לא תאפשר הצגת הנתונים הרגישים‪,‬‬
‫שימוסכו‪,‬יעורבלו‪,‬יוסתרו מפני הגורם הפנימי‬
‫שלא רשאי לצפות‪ ,‬וכמו כן תוגבל שליפת כמות הרשומות לפי הצורך‪ ,‬ולהיות מדווחת‬
‫ומתועדת לצורך בקרה ובדיקה עתידית ‪.‬‬
‫מערכת ‪ ActiveBase‬מותקנת במהירות ובקלות כאשר התקשורת אל בסיס הנתונים עוברת‬
‫דרכו באופן שקוף לאפליקציה ולבסיס הנתונים‪,‬‬
‫ואינו דורש שינוי באפליקציה‪ ,‬או כל שינוי תשתיתי‪ ,‬ומעניק הגנה מיידית על עשרות‬
‫אפליקציות ובסיסי נתונים בהתקנה בודדה ‪.‬‬

‫התייחסות חברת ‪Tescom‬‬


‫(אשת קשר‪ :‬אתי דביר‪) Eti.Dvir@Tescom-intl.com :‬‬

‫לדברי ניר לוי‪ ,‬נשיא קבוצת ‪ Tescom‬אבטחת מידע ואבטחת איכות הינה התמחות העומדת‬
‫בפני עצמה‪ ,‬אשר מהווה תשתית חיונית ונדרשת במרבית המגזרים ובארגונים בכל סדר‬
‫גודל‪.‬‬
‫חברת טסקום פעילה בתחום זה למעלה מ‪ 20-‬שנה‪ ,‬כיום ניכרת פתיחות והבנה בקרב‬
‫מקבלי ההחלטות לנושא אבטחת המידע והאיכות‪ ,‬כמו גם נכונות להשקיע בכך את‬
‫המשאבים הנחוצים ‪.‬‬
‫" המודעות בקרב לקוחות לחיוניות אבטחת מידע ואבטחת איכות החל משלב הייזום ועד‬
‫לשלבי ההשקה‪"/‬עליה לאוויר" כולל הופכים יותר ויותר למובנים בתוך התהליכים‪ ,‬ואני מברך‬
‫על כך‪.‬‬
‫אבטחת המידע כמו גם אבטחת האיכות נדרשים ברבדים השונים בתהליכים הארגוניים‪ :‬החל‬
‫מניתוב אינפורמציה פנימית דרך הקצאת הרשאות למשתמשים ויצירת הגנה על חומרים‬
‫פרטיים וכלה במניעת איומים חיצוניים‪ ,‬חדירות ופריצות‪ ,‬אשר מדווחים חדשות לבקרים‪.‬‬
‫אבטחת מידע ואבטחת איכות מייצגות את האינטרס הארגוני לבקרה‪ ,‬אכיפה והתנהלות‬
‫עקבית על פי אבני הייסוד של הפרויקט‪ ,‬תוך עמידה בתנאי איכות ‪ ,‬תקני רגולציות שונים‬
‫ובמסגרת הפרויקטאלית והתוכנית העסקית‪.‬‬