פיתוח מאובטח לאפליקציות, כך תעשו זאת נכון

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

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

תמונה: flickr, cc-by, carlosluz

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

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

נקודות התורפה

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

כידוע, מרבית החברות מפתחות סל מוצרים שמטבעם מפותחים תחת אותה קורת גג ומתבססים ברובם על מתודולוגית פיתוח זהה, המשתמשת באותה טכנולוגיות פיתוח. מפתחי המוצרים עצמם נוטים להשתמש באותם מנגנונים (קטעי קוד) המכונים reuse לקוד עצמו, דבר שאוטומטית מממש את קיומה של בעיית אבטחת המידע במגוון רחב של מוצרים, דבר הגורר פגיעות רוחביות. עדות לכך ניתן היה לראות בכנס Hack in the Box שהתקיים לאחרונה באמסטרדם. בכנס הוצגו כשמונה פגיעויות במוצרי גוגל בין היתר ב-Google Analytics וב-Google Calendar שחלקן נובעות ממקור זהה של בעיות. זהו מקרה מייצג בו טעות אחת משליכה על מגוון מוצרים ומאפשרת לתוקף שמגלה פגיעות במוצר כלשהו, באופן טבעי ואפילו אוטומטי, להצליח לייצר התקפות מרובות דרך אותה פירצה שחוזרת על עצמה.

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

סדר עדיפות נמוך

תמונה: flickr, cc-by, sassy mom

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

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

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

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

הפתרון אם כך טמון בהגנה על אפליקציות באמצעות פיתוח מאובטח – כשהאבטחה היא חלק אינטגרלי מתהליך פיתוח התוכנה, כבר מיומו הראשון והיא משולבת במחזור החיים של המוצר על כל שלביו. למיקרוסופט מתודולוגיה לפיתוח מאובטח: SDL – Security development lifecycle המתייחסת גם לאבטחה בכלל, כחלק בלתי נפרד ממחזור החיים של פיתוח תוכנה, החל משלב הניתוח והתכנון, המשך בשלב המימוש (קידוד), הבדיקות והתחזוקה כדי לוודא כי האפליקציה אותה מפתחים נמצאת ברמת האבטחה הגבוהה ביותר.
פיתוח מאובטח משתלב במחזור הפיתוח כבר בשלב הניתוח, כשנבחנות הפרצות אליהן חשופה האפליקציה. באמצעות מודל איומים (STRIDE) ניתן לזהות את סוגי הפרצות אליהן חשופים ובאמצעות מודל נוסף (DREAD) מחשבים את חומרתם.

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

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

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

כתב אורח

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

הגב

Be the First to Comment!

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
wpDiscuz

תגיות לכתבה: