אבטחת מידע במוסד רפואי נוסח שנת 2017

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

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

 

מודעות פרסומת

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

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

שנת 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 . וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

למה לא BYOD

האם ארגונים מאפשרים כיום לעובדים לחבר במשרד מחשבים ניידים פרטיים שלהם לרשת? הרוב המוחלט לא. זה עדיין טאבו שארגונים לא מוכנים לשמוע עליו. לא בטוח שזה יישאר כך לעד.
האם עד לפני שלוש-ארבע שנים ארגונים אפשרו לעובדים לסנכרן טלפונים פרטיים שלהם לתיבת המייל? היום תופעת ה – Bring Your Own Device (או BYOD) נפוצה והרבה ארגונים מאפשרים זאת לעובדים במטרה לחסוך עלויות רכש. הרבה ארגונים מאפשרים לעובדים שלהם לסנכרן את המכשירים החכמים הפרטיים (טלפון או טאבלט) למייל.

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

1. כאשר עובד עוזב את הארגון, הוא לוקח עימו את המכשיר שלו. נכון שהארגון אמור לבטל את סנכרון המיילים למכשיר. אך מה עם כל המיילים שכבר שמורים על המכשיר? ויותר מזה, מה עם מסמכים רגישים שהיו מצורפים למיילים שהעובד צפה ושמר על כרטיס הזכרון? הם נותרים שמורים על המכשיר גם לאחר ביטול הסנכרון. תחשבו שמנהל מכירות שומר את קובץ הלקוחות או קובץ ZIP עם הסכמים עם ספקים ועמלות, ועובר לארגון מתחרה.
2. כאשר המכשיר הינו פרטי, עולות בעיות משפטיות בחדירה לפרטיות. המכשיר הפרטי מכיל תכנים פרטיים רבים לצד תכנים עסקיים. עד להיכן יכול הארגון לנהל ולבקר את תכני המכשיר? עם הזמן, אני בטוח שיהיו מקרים שעובדים שעזבו יתבעו את המעסיק הקודם על חדירה לפרטיות.
3. כאשר המכשיר הוא פרטי, לארגון אין רצון ויכולת למחוק את המכשיר של העובד שעזב. במכשיר ארגוני, המחיקה לא מצריכה את אישור העובד שעזב.
4. אי אפשר לדרוש מהעובד שלא להתקין תוכנות מסוכנות על מכשירו הפרטי. נכון שגם במכשיר ארגוני קשה לכפות מניעה כזו, אך ניתן להגביל בנוהל התקנת תוכנות שכאלה ובמידת הצורך אפשר ליישם נוהל מחיקת מכשיר ארגוני ללא צורך בהסכמת העובד מעבר להסכמתו הראשונית בעת הנפקת המכשיר.
5. לבסוף, החסכון מאי רכישת טלפון חברה עבור עובד אינו כה מוחשי כפי שנדמה בהתחלה. עדיין ישנן עלויות תפעול (OPEX) רבות. העובדים פונים לתמיכה גם בתקלות שאינן קשורות למיילים והטכנאים מוצאים את עצמם מקדישים זמן רב על תקלות אלה.

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

סיכונים הנובעים ממערכת MDM בענן

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

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

• ממשק הניהול של המערכת נגיש לכל אחד בעולם. אם גורם זר מצליח להשיג את נתוני ההזדהות לממשק (בין אם ע"י גניבת סיסמא או ע"י מתקפת XSS וכל דרך אחרת), הרי שהוא יכול להשבית את השירות לארגון שלם. במצבים מסוימים ייתכן והוא גם יצליח לרשום מכשיר שאינו שייך לארגון אל השרת הארגוני. או שמישהו יחליט למחוק לחלוטין (Remote Wipe) מכשירים מתוך רוע לב.
• פתיחת גישה ל – Active Directory למערכת בענן. בארגון גדול, לא ירצו לנהל משתמשים מקומיים במערכת, אלא לקשר את המערכת למשתמשים המוגדרים ב – AD. רגע, אתם רציניים? לפתוח את AD הארגוני לספק שירות זר המספק פלטפורמה משותפת לעוד אלפי לקוחות?

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

MDM זה לא בהכרח פתרון אבטחה לטלפונים חכמים

פוסט קצר כדי לעשות קצת סדר בנושא.

ישנם מנהלים המבלבלים בין השניים. ראשי התיבות של MDM הם Mobile Device Management והם מתייחסים ליכולות ניהול של הטלפונים משרת מרכזי. הניהול כולל נושאים תפעוליים ולוגיסטיים. פתרון MDM אינו חייב לכלול יכולות אבטחת מידע למכשירים.

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

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

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

ממליץ לכם על השוואה עדכנית למוצרי MDM בלינק הבא.

 

סקירת והסרת הרשאות

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

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

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

 

כיצד מנהלים סקירת הרשאות:

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

 

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

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

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

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

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

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

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

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

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

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

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