מחזור חיי פיתוח תוכנה Development Software SDLC :LifeCycle

הגדרת תכנה

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

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

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

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

דגמים של פיתוח תוכנה

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

הגדרת אבטחת יישומים

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

מחזור חיי פיתוח תוכנה: SDLC: SOFTWARE DEVELOPMENT LIFECYCLE

מחזור חיי פיתוח תוכנה (SDLC) מגדיר צעדים (או משימות) לפיתוח תוכנה:

1. הגדרת דרישות למערכת.
2. אפיון ועיצוב המערכת. 
3. יישום המערכת (כתיבת הקוד)
4. בדיקת המערכת והטמעתה
5. העברת המערכת לסביבת היצור.
6. עדכון ו/או תחזוקה של המערכת.
7. הסרת / החלפת המערכת במערכת חדשה

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

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

כללי אצבע לפיתוח מאובטח

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

התקפות אפשריות ברמת הקוד והפיתוח

1. 1Buffer overflow \ Code Reuse Attack – הצפת מידע, קריסת המערכת ושליטה עליה
2. 2Injection – הזרקת קוד (הדוגמה המוכרת והנפוצה ביותר: SQL Injection)
3. 3Covert Channel – יכולת להעביר מידע בין תהליכים שאינם אמורים להיות מורשים
4. Time of Check/Time of Use – באגים שנוצרים במערכת עם הזמן (כדוגמה, תעודות אבטחה עם תוקף, השתנות מערכת ההפעלה עליה רצה התוכנה וכו').
5. 5Developers’ Shortcuts (Backdoors) – ניצול חולשות במערכת שהמפתח לא חשב עליהן ו\או שהמפתח השאיר לעצמו לטובת תחזוקה מקומית ומרוחקת.

דרכים אפשריות כדי להימנע מתקיפות ברמת הקוד והפיתוח

1. תחזוקה ומעקב אחר אירועים חריגים (עומסים, הודעות לא טרביאליות (למשל, חלון CMD שנפתח ונסגר).
2. הורדת והתקנת עדכונים (כמובן שיש לשים לב למקור הורדת העדכון - ספק העדכון).
3. שדרוג המערכת.
4. גריטה (בשלב מסוים המערכת אינה תואמת את המציאות הטכנולוגית ו\או ספק התוכנה לא יספק עדכוני אבטחה רלבנטיים)

סוגי אבטחת יישומים

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

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

עקרונות הפיתוח המאובטח

בכל שלבי מחזור חיי המערכת צריכים להישמר העקרונות הבאים

1. עקרון החולייה החלשה: הרכיב החלש ביותר אבטחתית קובע את חוזק מערכת ההגנה כולה. נקודת החולשה נקבעת גם על ידי מידת החשיפה לאיום, ולא רק מהאיום עצמו.
2. הרשאה מינימאלית: כל פעולה במערכת צריכה להתבצע בהרשאה מינימאלית הניתנת לפרק הזמן הקצר ביותר. הענקת הרשאות גבוהות מהנחוץ הופכת את המערכת המאובטחת לחשופה ופגיעה יותר.
3. פשטות: עקרון זה הופך את המערכת לצפויה יותר וקלה יותר לבדיקה. מערכת מורכבת קשה יותר לבדיקה, מבחינת הגנת סייבר, מאחר והגנת סייבר עוסקת באירועים צפויים פחות. פשטות עוזרת להבנת אופן השימוש, איתור בעיות פוטנציאליות, קלות בתחזוקה והפחתת מקומות פוטנציאליים לטעות.
4. מצב ברירת מחדל בטוח: על המערכת להגדיר מה מותר ולשלול כל פעולה אשר אינה צפויה או אינה עונה על תנאי מוגדר. עדיפה מערכת נעולה עם מידע אמין מאשר מערכת נגישה עם מידע חשוד.
5. נקודות גישה מוגבלות ושמורות: יש להגביל את מספר נקודות הגישה למערכת ולהגן על נקודות אלו.
6. הגנת עומק: על המערכת להבנות על מספר קווי הגנה ולהגן גם על קווי הגנה אלו זאת על מנת למנוע תלות בנקודה קריטית, אפקט הדומינו והתפשטות הנזק. על כל תהליך להיות בנוי משלבים אשר בכל אחד מהם מוטמע מנגנון אבטחה (אימות, מניעת זליגה, רישום השם לקובץ לוג וכו').
7. שימוש ברכיבים קיימים: הסתמכות על מנגנוני אבטחה ידועים הופכת את המערכת לבטוחה ואמינה יותר. 'המצאת גלגלים' הינה מתכון למערכת חלשה.
8. הגבלת החלטות משתמשים: קבלת החלטות בנושאי הגנת סייבר אינה נתונה לשיקול דעתו של המשתמש.
9. השארת ראיות: על המערכת להשאיר ראיות להתקפה – ראיות אשר תאפשרנה לשקם את הנזק, לאתר את מקור הפגיעה הנחוץ למניעה עתידית.
10. הצפנה: יש לשמור הן על סודיות אלגוריתם ההצפנה והן על סודיות המפתח. יש להקפיד על תכנון אופן שמירת המפתחות והגנת הגישה אליהם.
11. פרטיות וחשאיות: יש למנוע דליפת מידע אודות אמצעי האבטחה המיושמים במערכת ובכך לגרום לתוקף לנוע באזור לא מוכר.
12. הפרדת רשויות: מערכת הבקרה ומערכות אבטחת המידע צריכות להיות מחוץ להישג ידו של הגורם המבוקר. עקרון זה תקף לגבי קבצי חיווי ואמצעי גילוי ומניעה שונים.

שלבי פיתוח מערכת מאובטחת

א. הגדרת הדרישות למערכת – Requirements

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

1. שמירה על פרטיות המשתמשים.
2. שמירה על חיסיון הנתונים.
3. שמירה על שלמות המידע.
4. שמירה על אמינות המידע.
5. שמירה על זמינות המערכת.
6. שמירה על שלמות תהליכים עסקיים.
7. יכולת לשחזר אירועי א.מידע.
8. מניעת התכחשות משתמשים לביצוע פעולות.
9. זיהוי חזק של משתמשים.
10. זיהוי חזק בין תת מערכות ומערכות חיצוניות (בסיס נתונים, שירותי רשת וכד').

ב. שלב אפיון ועיצוב המערכת – Design

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

לאחר ששלב האפיון מסתיים יש לעשות בדיקת הגנת סייבר (Review Design)

בין היתר, מסמך האפיון אמור לתת מענה למימוש המנגנונים הבאים:

1. הצפנת נתונים רגישים
2. בחירת מנגנון זיהוי משתמשים.
3. תיעוד אירועי הגנת סייבר.
4. תיעוד פעולות משתמשים.
5. תיעוד פעולות תחזוקת מערכת.
6. שיטת ההרשאות ומימושה.
7. מנגנון נעילת משתמשים.
8. מדיניות ניהול  משתמשים.
9. ממשקים מאובטחים למערכות נוספות.
10. פירוט של רכיבי צד שלישי אשר יהיו בשימוש.

תכנון מנגנוני הגנה בשלב אפיון ועיצוב המערכת

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

1. מניעה
2. גילוי
3. תגובה

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

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

ניתוח עלות/תועלת וקביעת קדימויות

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

ג. שלב יישום המערכת – Implementation

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

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

עקרונות מונחים למימוש מנגנוני הגנה

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

• תיעוד מערכת מלא הכולל: רכיבים, מבנה נתונים, נתיבי תקשורות, תיאורים דינמיים ותלויות ברכיבי צג שלישי (מערכות הפעלה, רכיבים מוכנים וכו').
• התאמה לתכנון, יש לבדוק שמימוש המערכת נעשה לפי קווים המנחים.
• בקרת איכות
• Review Code -יש לעשות בחינת קוד על ידי מומחה אבטחה.

בחינת מימוש לשגיאות נפוצות

יישום מערכות אבטחה סובל משגיאות טיפוסיות שחוזרות במערכות רבות. קיימים מקורות רבים הסוקרים בעיות בסביבות ספציפיות (בשפות כגון: ,#C++,C, C Java , או במערכות הפעלה כגון: OS2, Unix, WinNT וכדומה). הרשימה המובאת להלן סוקרת מספר בעיות נפוצות מבלי להתייחס לסביבת יישום מסוימת:

• שגיאות תנאי: שגיאות הנוצרות בעקבות בדיקה חסרה או לא מספקת של תנאי זרימה. על פי רוב כתוצאה של בדיקה חסרה של פרמטרים, נתונים שהוקלדו על ידי המשתמש, קודי סטטוס שמוחזרים ממערכת ההפעלה וכן הלאה. שגיאות תנאי גורמות כיום ליותר מ %90 של בעיות האבטחה ביישום מערכות. כל בעיות ה - Overflow Buffer נובעות מבדיקה לא מספקת, או חסרה לחלוטין של פרמטרים למערכת.
• מצבי אטומיות: שגיאות שנוצרות כאשר לא הובאה בחשבון הפרעה בזרימת התוכנית. במקרים רבים קיימת הנחה, שזרימת התוכנית של תופרע. הנחה זו מוטעית לחלוטין במערכות מרובות משתמשים, בעלי משימות מרובות או מספר מעבדים. מצבי Conditions Race, מהווים אחד הגורמים המובילים לבעיות אבטחה. לדוגמא: מערכת שבודקת תאימות של שדה להנחות תחביר, אבל לא מביאה בחשבון שהמשתמש יכול לשנות את השדה בין זמן הבדיקה וזמן הכנסת המידע לבסיס הנתונים.
• דלתות אחוריות: שגיאות מכוונות שנוצרות כאשר מפתחי המערכת השאירו רכיבי בדיקה או תחזוקה שעוקפים את מערכת האבטחה, או לחלופין חושפים מידע חסוי על המערכת (מפתחות, סיסמאות וכדומה). ברוב המקרים מושארים דלתות אחוריות ללא כוונת זדון מצד צוות הפיתוח, אבל אין להוציא את האפשרות מכלל חשבון.
• מצבי קצה: סוג של שגיאת תנאי שנוצר כאשר המערכת אינה בודקת תנאי קצה: משאבים מצומצמים (זיכרון, מקום פנוי בדיסק, גישה בעומס גבוה) וכתוצאה פועלת באופן לא צפוי.
• גבולות בין רכיבים: כאשר מידע זולג מרכיבים מאובטחים לרכיבים ציבוריים, או כאשר קיימת אפשרות גישה בנתיב ההפוך, בעיית גבולות קורה פעמים רבות דרך השימוש במשאב משותף לדוגמא: כתיבת מידע חסוי לזיכרון משותף, מחייבת מחיקתו לפני שהזיכרון יעבור לשימוש רכיב אחר, או ייכתב ל- File Swap.
• שגיאות אינטגרציה: שגיאות שנובעות מבדיקה חסרה של סביבת היישום. כאשר שילוב המערכת ברכיבי סביבה יוצר מצב לא בטוח (למשל מערכת הפעלה ללא בקרת גישה, רכיבי צד ג' לא בטוחים, רכיבי תקשורת לא בטוחים וכד').
• זליגת מידע: כאשר המערכת "מנדבת" מידע פנימי ללא צורך שעשוי לסייע לתוקף למקד את ההתקפה לדוגמא: גרסה, משתמש נוכחי.

ד. שלב בדיקת המערכת והטמעתה

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

• Box-White - מעבר על קוד המקור של המערכת בהביטי הגנת סייבר, בדיקת תצורת המערכת, תצורת התשתית ותצורת הרשת. בדיקה זו יסודית ביותר ועלולה לקחת זמן רב (יחסית) במערכות גדולות. היתרון הנוסף של צורת בדיקה זאת היא בכך שלאחר שמתבצע שינוי במערכת, ניתן לבדוק Delta של השינוי בלבד ואין צורך לבדוק את כל המערכת מחדש.
• Box-Black - בדיקה זאת מהווה אינדיקציה על מצב המערכת מנקודת מבטו של הפורץ, היא פחות יסודית מקריאת קוד המקור, אך בדרך-כלל אורכת פחות זמן בצורה משמעותית.
• Box-Gray- שילוב של שתי השיטות הנ"ל, בו נבדקים רק חלקי קוד אשר הוגדרו כרגישים במיוחד ושאר המערכת נבדקת כמשתמש. היתרון של צורת בדיקה זו היא ביעילות שלה הן מבחינת זמן והן מבחינת היסודיות.

דגשים בביצוע הבדיקות:

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

העברת המערכת לסביבת הייצור:

את המערכת אשר אושרה ניתן להעביר לסביבת הייצור תוך כדי הקפדה על מספר כללי יסוד הבאים:

• יש להחליף את כל הסיסמאות של המערכת למזהים קשים לניחוש על פי מדיניות הסיסמאות של הארגון.
• יש לדאוג למחיקת כל קוד מערכת מיותר שנועד לצורכי Debug , כגון מחלקות עזר - classes utility - העוזרים לפתח את האפליקציה ולבצע בדיקות של המערכת.
• יש למחוק את כל חשבונות המשתמשים אשר היו קיימים במערכת.
• יש לדאוג להפרדה מלאה בין סביבת היצור לסביבות נוספות (פיתוח, בדיקות וכדומה) ולהשתמש במזהים שונים עבור כל סביבה.

ה. שלב עדכון ו/או תחזוקה של המערכת

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

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

ו. שלב הסרת / החלפת המערכת במערכת חדשה

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

בדיקות הגנת סייבר

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

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

בדיקות סקר קוד

• כל אתר חדש / גרסה חדשה נדרשים לעבור בדיקות וסקר קוד מקיפים כשלב מקדים לפני ביצוע בדיקות חוסן. מבדקי חדירות לאתרי/אפליקציות רשת (site/application web) הנחיות:
• מבדקי חדירות יבוצעו על כל גרסה של אתר / אפליקציה.
• מבדקי חדירות יבוצעו על גרסאות שסיימו את שלבי הפיתוח והבדיקות )QA– ) גרסאות סופיות/שחרור.
• האתרים/אפליקציות ייבדקו בסביבת ביניים (Stage) ולאחר אישור תקינותם יועברו לסביבת הייצור (Production.)
• בסיום המבדק יסווגו האתר/אפליקציית הרשת על פי הפירוט הבא:

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

מבדקי חדירות תקופתיים: אתר / אפליקציית רשת שלא עודכנה להם גרסה במהלך 24 חודשים נדרש לבצע מבדק חדירות מלא.

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

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

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

ציוד מיוחד: לעיתים קיימות גם מערכות, הדורשות ציוד חומרה או תוכנה מיוחדים לצורך

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

הנחיות נוספות: במחשבי ושרתי ייצור של המערכת לא יותקנו סביבות פיתוח וגרסאות Beta

הסרת מחלקות עזר: בזמן הפיתוח, נעשה לעיתים שימוש במחלקות עזר (classes Utility) העוזרים לפתח את האפליקציה ולבצע בדיקות של המערכת. צעד זה הינו חשוב בעת הפיתוח, אך יש להקפיד בעת המעבר לסביבת הייצור כי קבצים אלו יוסרו בשל העובדה כי הם מהווים פתח נוסף לאפליקציה, פתח אשר אינו נחוץ כלל לצורך ריצה תקינה של התוכנית. בנוסף, במידה ולא הושקעה מחשבה בעקרונות הגנת סייבר והם לא נלקחו בחשבון בעת כתיבת המחלקות, מצב זה עלול להוביל ליצירת "דלת אחורית" (Door Back) במערכת.

קבצי Debug בייצור: יש לוודא כי הגרסה המקומפלת של האפליקציה בסביבת הייצור הינה גרסת ה-Release ולא גרסת ה-Debug. גרסת ה-Debug של האפליקציה מכילה מידע אשר מאפשר בעזרת הכלים המתאימים לקבל בחזרה את קוד המקור של האפליקציה (Reverse Engineering).

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

EOL

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

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

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

דגשים לפיתוח מאובטח

1. שימוש נכון בשורת הפקודה: הרבה תוכניות מקבלות קלט משורת הפקודה. פונקציות כגון getuid ו-setgid עלולות להיות בשימוש ע"י משתמש לא אמין. לכן, פקודות אלו צריכות להגן על עצמן משימוש לא נאות דרך שורת הפקודה. תוקפים עלולים לשלוח נתונים דרך שורת הפקודה, ולכן יש צורך בווידוא הקלטים ולא לתת שימוש ישיר בפונקציות עצמן.

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

3. שמות קבצים: לא מעט פעמים לא שמים לב לשמות קבצים, למרות שיש להם משמעות רבה הן כקלט והן כסטנדרט. יש להימנע (בהעדר סיבה מוצדקת) מקליטת שמות הקבצים המכילים את ".." (ספריה אחת למעלה), וכן נדרש להימנע משינוי או יצירת ספריה חדשה ע"י איסור השימוש בתו "/". נדרש גם להימנע משמות קבצים המכילים wildcards כגון "*", "?" וכדומה. מניעות נוספות הן שימוש בקו מוביל ("-") אשר עלול להתפרש כפרמטר, שימוש ברווחים אשר עלול להתפרש כשני קבצים נפרדים, שימוש בתווים שאינם תואמים לתקן UTF-8 ועוד.

4. תכני הקובץ: מה יכיל קובץ? נניח שנרצה לקלוט נתונים מתוך קובץ אשר יינתן ע"י המשתמש. מה יהיה בו? יש לוודא כי תוכן הקובץ חוקי ותואם למערכת.

5. BUFFER OVERFLOW: רבות נאמר ונכתב על Overflow Buffer ,ובכל זאת, חשוב להזכיר את הנושא. נדגיש את הנושאים העיקריים בשפת .C Overflow  Buffer נגרם כאשר קלט באורך מסויים נכתב לתוך buffer שגודלו קבוע וקטן יותר מאורך הקלט. קלט כזה יכול להתקבל ע"י המשתמש ישירות, וכן מגורמים נוספים אשר נובעים מעיבוד הקובץ. אם ה-buffer מכיל משתני סביבה של כותב התוכנית, נוכל לדרוס אותם ע"י Overflow  Buffer וכן כתיבת משתני סביבה משלנו. התוצאה היא שנוכל להריץ קוד זדוני כלשהו. שפות תכנות גבוהות יותר חסינות מכך, מפני שהן מכילות מנגנוני הגנה שונים כגון שינוי גודל ה- buffer או הכנסה לתור אחר, כשישנה חריגה מהגודל המקורי. לשפת C אין הגנה כזו, וניתן ליצור בעיות דומות ע"י שימוש לא נכון בשפת ++C.

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

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

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

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

10. הגבלת המידע הנגיש: במידת האפשר, יש להקטין למינימום את כמות המידע הלא-רלוונטי שניתן לגשת אליו. למשל, בעת גישה לקריאה ממסד נתונים, רצוי לאפשר את קריאת המידע הרלוונטי (שאותו המשתמש בסופו של דבר אמור לקרוא).

11. הגבלת כמות המשאבים המאופשרת: יש למנוע ממשתמש לגזול את משאבי המערכת, ע"י שימוש מסיבי בהם. כלומר, במידה וישנו שימוש רב מדי במשאב מסויים, יש להוריד ממנו את ההרשאות המתאימות לכך, או להגביל את המשאב ע"י מסירתו למשתמש אחר, כדי למנוע רעב בתוך המערכת.

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

13. RACE CONDITIONS: גישת שני תהליכים למשאב משותף תוך פרק זמן קצר מאוד, עלולה לגרום למצב של Condition Race. במצב זה, תגובת המערכת עלולה להיות לא מוגדרת, מה שעלול בסופו של דבר לגרום לפרצה במערכת. על-מנת להימנע ממצב זה, יש למנוע מפעולות לא אטומיות אשר יאפשר לשני תהליכים לנסות להשתמש באותו משאב באותו פרק זמן. 

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

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

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

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

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

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

19. פידבק ואינפורמציה מהמערכת  (מיעוט באינפורמציה מיותרת): יש צורך למעט באינפורמציה אשר מוחזרת מהמערכת. במידה ומדובר במשתמש לא אמין, יש צורך להחזיר הודעת שגיאה או הצלחה בלבד. במידה והמשתמש אמין, יש צורך להחזיר הודעה על מהות השגיאה, אך לא לפרט היכן היא הייתה (למשל, "שורה מספר 231 גרמה לשגיאה מכיוון ששם הקובץ הכיל 28 תווים ולא 21").

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

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

בדיקת אבטחת יישומים

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

ניתוח משטח תקיפה באפליקציות Attack Surface Analysis in Applications (OWASP)

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

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

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

יתרונות ניתוח משטח התקפה:

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

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

משטח ההתקפה של אפליקציה:

1. הסכום של כל הנתיבים לנתונים/פקודות לתוך האפליקציה והחוצה ממנה, וכן:
2. הקוד שמגן על הנתיבים הללו (כולל חיבור משאבים ואימות, הרשאה, רישום פעילות, אימות נתונים וקידוד)
3. כל הנתונים החשובים שבהם נעשה שימוש באפליקציה, כולל סודות ומפתחות, קניין רוחני, נתונים עסקיים קריטיים, נתונים אישיים ו-PII, וכן
4. הקוד המגן על הנתונים הללו (כולל הצפנה וסיכומי בדיקה, ביקורת גישה ובקרות שלמות נתונים ובטיחות תפעולית).

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

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

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

Microservice ו-Cloud Native Applications

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

כלי קוד פתוח כגון Scope או ThreatMapper מסייעים בהדמיית משטח ההתקפה.

זיהוי ומיפוי משטח ההתקפה

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

• טפסים ושדות של ממשק משתמש (UI).
• כותרות HTTP וקובצי Cookie
• ממשקי API
• קבצים
• מאגרי מידע
• אחסון מקומי אחר
• דואר אלקטרוני או סוגים אחרים של הודעות
• ארגומנטים של זמן ריצה
• נקודות הכניסה/יציאה

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

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

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

אתה יכול גם לבנות תמונה של משטח ההתקפה על ידי סריקת האפליקציה. עבור אפליקציות אינטרנט אתה יכול להשתמש בכלי כמו OWASP ZAP או Arachni או Skipfish או w3af או אחד מהכלים או השירותים הרבים של בדיקות דינמיות מסחריות וסריקת פגיעות כדי לסרוק את האפליקציה שלך ולמפות את חלקי האפליקציה הנגישים דרך האינטרנט. כמה חומות אש של אפליקציות אינטרנט (WAFs) עשויות גם להיות מסוגלות לייצא דגם של נקודות הכניסה של היישום.

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

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

ניהול משטח ההתקפה

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

• מה השתנה?
• מה אתה עושה אחרת? (טכנולוגיה, גישה חדשה,...)
• אילו חורים יכולת לפתוח?

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

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

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

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

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

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

עבור למאמר הבא