Archive for the 'אבטחה אפליקטיבית' Category

28
יול
15

אפליקציות מובייל לא מאובטחות

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

שנת 2014 הייתה שנת המפנה עבור אפליקציות מובייל שבה עקפו את כול התוכנות האחרות שניגשו לאינטרנט מהמחשב האישי או מהדפדפן הקונבנציונלי. לצד זאת גם עלו בצורה משמעותית מספר הפגיעויות באפליקציות, שגרמו לעלייה חדה במספר התקיפות ובפעילות הפלילית באפליקציות השונות.  לפי פרסומי חברת האבטחה FireEye הייתה עלייה חדה של כ- 188% אחוזים בפגיעויות באפליקציות במכשירי אנדרואיד בהשוואה לשנת 2011 ועד 262% במכשירי IOS.

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

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

  1. (TTM (TIME TO MARKET קצר: שימוש במתודולוגיות פיתוח כגון Agile Development, גורם לכך שבממוצע TTM לאפליקציות מובייל מקוריים הוא בין 14-20 שבועות, נתון שתלוי גם במורכבות וגורמים אחרים של היישום. פיתוח מהיר שכזה מקשה על שילוב אלמנטים של אבטחת מידע.
  2. Code Reuse: מפתחי אפליקציות במובייל נוטים להשתמש באותם מנגנונים (קטעי קוד) המכונים reuse לקוד עצמו, דבר שאוטומטית מממש את קיומה של בעיית אבטחת המידע במגוון רחב של מוצרים (שימוש במנגנון פגיע שוב ושוב), דבר הגורר פגיעות רוחביות.
  3. שימוש בקוד פתוח: בקרב מפתחי אפליקציות מובייל, רווחת הדעה כי מנגנוני קוד פתוח הינם אוטומטית "בטוחים לשימוש ומאובטחים", דעה שכמובן אינה בהכרח נכונה ועלולה לגרור פגיעויות אבטחה מרובות ורוחביות באפליקציות שונות. שכן לעיתים קרובות מודולים של קוד פתוח מתוחזקים ע"י מפתחים בודדים אשר לא תמיד מודעים לעקרונות פיתוח מאובטח.

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

  1. בשלב התכנון מתן הנחיות אבטחת מידע עבור ארכיטקטורה מאובטחת של המערכת וכן תכנון מנגנוני הגנה שיתנו מענה לפרצות שעלו בשלב הניתוח.
  2. פיתוח בצורה מאובטחת לפי עקרונות ידועים (כגון: OWASP) והטמעת ליווי בפיתוח מאובטח (SDL- Security development lifecycle) כחלק משלבי הפיתוח והבדיקות.
  3. ביצוע מבדקי חדירה (Penetration Test) לקבלת תמונה של מצב אבטחת המידע באופן שבאמצעותה ניתן להעריך את רמת האבטחה של האפליקציה. על ידי הדמיה של התקפה מכוונת, ניתוח וחקירת מערכות, בדיקת תגובה של מערכות הגנה ועוד.
  4. ביצוע בדיקות אבטחת קוד אוטומטיות (Automated Code Analysis) לקבלת תמונה של מצב אבטחת המידע בתוך קוד האפליקציה והימנעות משגיאות אבטחה נפוצות ברמת התוכנה. המערכת סורקת בצורה אוטומטית את הקוד ומאתרת חורי אבטחה, על מנת לאתרם לפני התממשות הפריצה.
  5. שילוב בדיקות אבטחת קוד אוטומטיות כחלק מתהליך הפיתוח (Secure Development Life (Cycle – יש לשלב מערכות בדיקת קוד אוטומטיות כחלק אינטגרלי מתהליך הפיתוח (כחלק מתהליך ה-Build) ואף מומלץ לשלבם במערכת מעקב הבאגים כדי למנוע "זניחה/התעלמות" מפתחים מליקויי אבטחת מידע שאותרו.
  6. הגנה על תשתית האפליקציה ע"י תשתית (WAF (Web Application Firewall כחיץ בין האפליקציה לשרתי המערכת. מוצרי WAF נועדו להתמודד עם פרצות אפליקטיביות וכוללים מנגנון לזיהוי התקפות על המבוסס על למידת האפליקציה ועל חתימות.
  7. עדכון אפליקציות למובייל על מנת לתקן חולשות אבטחת מידע שמתגלות בשפות הפיתוח ובמכשירי המובייל בכדי להגן על האפליקציה והמובייל.

 

על כותב המאמר:
ליאור מזור, מהנדס תוכנה. בעל תואר ראשון B.sc למדעי המחשב ומתמטיקה, ניסיון של למעלה מ 9 שנים באבטחת מידע ביישום והטמעה של מערכות אבטחת מידע וניסיון בניהול פרויקטים בארץ ובחו"ל. מוסמך מת"י כ Leading Auditor לתקן ISO 27001, מוסמך CISSP . וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

מודעות פרסומת
21
אוק
14

המלך SSL מת, יחי המלך החדש TLS

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

בשבוע האחרון נפל דבר בעולם אבטחת המידע. הדבר הזה הוא כמו כוכב שביט שנופל על כדור הארץ, משהו שמשנה סדרי עולם. פירצה שהובילה לכך שפרוטוקול ה – SSL מת, והפודל מקשקש בזנב. מדובר בפירצה שהתגלתה ע"י חוקרי Google בפרוטוקול עצמו ולא בספרייה שמממשת קריפטוגרפיה. הפירצה כונתה POODLE וקיבלה את המזהה CVE-2014-3566. לא ניכנס לפרטים הטכניים, מי שמעוניין שיחפש באינטרנט.

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

בד"כ כשמתגלית פירצה, ניתן להתקין עדכון אבטחה שפותר את הבעיה. במקרה הזה, הבעיה נמצאה בפרוטוקול עצמו ולכן ההמלצה היחידה היא להפסיק להשתמש ב – SSL ולעבוד TLS. כיוון שאני מכיר את המוח הישראלי, אני רוצה להדגיש שיש צורך בביטול האפשרות לעשות שימוש ב – SSL; לא מספיק להגדיר/להפעיל TLS. אני אסביר בצורה מאוד כללית מדוע.

בתהליך ה – Negotiation, צד ה – Client וצד ה – Server מציגים לצד השני באיזה פרוטוקולים הם תומכים. הפרוטוקול המשותף הכי חזק בשני הצדדים נבחר – נאמר TLS v1.0. לכאורה הכל בסדר. הפירצה שהתגלתה אפשרה לתוקף באמצע (Man-in-the-Middle) להתחזות ולדווח שהוא תומך רק ב – SSL v3. זה מחייב את הצד השני להפסיק להשתמש ב – TLS. עכשיו, התוקף יכול לנצל את הפירצה שהתגלתה ב – SSL. לכן, הפתרון חייב להיות ביטול בקובץ ב – conf או ב – Registry של האפשרות לעשות שימוש ב – SSL.

 

01
ספט
13

אבטחת מידע ב – SAP

כמעט ואין כיום ארגון גדול שאינו עובד עם מערכת ERP לניהול הכספים, לאפליקציות עסקיות או לרצפת הייצור. שתי המערכות המובילות הינן SAP ו – Oracle Applications. המערכות האלה מאוד רגישות מבחינת אבטחת מידע שכן הן מנהלות כספים (ומהוות כר פורה למעילות וגניבות), מנהלות לקוחות (נתונים פיננסיים ונתונים הקשורים לצנעת הפרט) ועוד.

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

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

  • טרנזקציות המאפשרות ניהול הרשאות (כגון SU01). חשוב לבקר באופן שוטף מי מקבל הרשאות אלה (רק מנהלי/מיישמי ההרשאות). מומלץ לנטר במערכת ה – SIEM הגדרת SU01 למשתמשים.
  • טרנזקציות המאפשרות עדכון נתונים בטבלאות בייצור. בניגוד לבסיסי נתונים SQL כגון Oracle, MS-SQL, בעולם ה – SAP ניתן לגשת לנתונים ישירות לטבלאות (קצת כמו אקסל). טרנזקציה SE16, ונוספות, מאפשרות גישה כזו. זה סיכון שאסור לאפשר (למעט מקרי חירום) וחייבים לחסום אותו.
  • הרשאות המפרות את עיקרון הפרדת הרשויות (Segregation of Duties). ארגון לא אחראי יאפשר בשמחה לעובד אחד גם להקים ספק, גם ליצור דרישת תשלום לאותו ספק, ולבסוף לסגור את הספק במערכת. נשמע מעולה, לא?
  • ממשקים אל ומהמערכת שאינם מאובטחים. כמו כל מערכת אחרת, האם הממשקים מוגבלים בהרשאות גישה? האם מידע רגיש (למשל, כרטיסי אשראי) עובר באופן מוצפן?
  • כתיבת קוד מעבר לקיים בחבילת הבסיס (למשל ABAP ב – SAP) שחושף את המערכת לפרצות אבטחה.
  • התקנת טלאי אבטחה לתשתית המערכת.

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

14
אוק
12

עבודה בשיטת White List והפרשנות המקומית של אנשי הפיתוח והתשתיות

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

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

מה ההבדל בין רשימה שחורה ללבנה?
ברשימה שחורה מגדירים מה אסור. למשל, בלי כתום, ירוק וכחול. עוד דוגמא מעולם חסימת התקני זכרון: לחסום (כלומר, בלי) Disk-on-Key, CD-ROM, Floppy.
ברשימה לבנה מגדירים מה מותר. למשל, מותר (רק) לבן קרם, או מותר (רק) מדפסות רשת ומקלדת אלחוטית (ואף התקן אחר).

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

ההמלצה היא לעבוד עם רשימות לבנות ולא שחורות.

דוגמא לתכנות על בסיס רשימה לבנה: בדיקת קלטים באתרי Web. לאפשר קליטת תווים מותרים לפי סוג הקלט בלבד – למשל [0-9] עבור שדה תעודת זהות, וכמובן מותר אורך השדה רק בן 9 תווים. אם היינו עובדים כאן לפי רשימת שחורה (למשל ללא אותיות [a-z] [א-ת]) לא היינו מטפלים (חוסמים) תווים מסוכנים להתקפות SQL Injection כגון: ' -.

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

מספר דוגמאות:

  • הגדירו ששדה ת.ז. לא יכול להכיל אותיות, אך לא מנעו קליטת תווים מיוחדים (סכנה…).
  • חסמו העלאת קבצים דרך האתר מסוג exe, אך לא הגבילו סוגים אחרים הנחשבים מסוכנים, למרות שבמקור הגדרתי שמותר לעלות רק jpg, png, gif. התוכניתן תירץ זאת בכך שהוא חשב שהסכנה היא רק מקבצי exe (למרות שהיה מונח לו על השולחן האפיון הפתוח בעמוד שהגדיר את ה – White List.
  • ביקשתי סריקה ברשת של כל המחשבים מבוססי Windows לגילוי מחשבים ללא AV. קיבלתי רשימה של תחנות עבודה בלבד ללא שרתים. 

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

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

19
דצמ
11

תרשים סיכונים מערכות/מנגנוני הגנה ומניעה

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

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

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

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

הערות כלליות:

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

 הערות על מערכות:

  • DB FW: ניתן להגדיר הרשאות גישה עפ"י יוזר מערכת הפעלה, יוזר בסיס נתונים, כתובת IP, שם מחשב ועוד. יכול לאפשר מניעת גישה לשדות רגישים או ניטורם. מאפשר לנטר ולחסום נסיונות Brute Force.
  • DLP: יכול לחסום התקני זכרון נתיקים, למנוע או לנטר שליחה/שמירה של מידע רגיש על סמך ביטויים/תכנים או ספריות ברשת.
  • הצפנת כונן קשיח משלב ה – Boot: מונעת אפשרות לאתחל את המחשב באמצעים עוקפי מערכת הפעלה של הכונן.
  • AFW: מגן בפני התקפות בקלטים באפליקציה, בפלטים ובניצול חולשות על השרת, מניעת התקפות DoS.
  • XML FW: מגן בפניות ל – Web Services כנגד התקפות XML המובילות ל – DoS, מניעת זליגה דרך SQL Injection.
05
דצמ
10

קוד חיצוני באתר האינטרנט הארגוני

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

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

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

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

07
ספט
10

סיכונים לא קלאסיים בפיתוח Services

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

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

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

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

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

אני נוהג לבחון מסמכי אפיון לפני תחילת פיתוח. אני בוחן בין השאר:

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

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




ספטמבר 2018
א ב ג ד ה ו ש
« מאי    
 1
2345678
9101112131415
16171819202122
23242526272829
30  
מודעות פרסומת