Archive Page 2

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

מודעות פרסומת
03
יונ
15

סיווג ותיוג מידע

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

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

לאחרונה נתקלתי בפרוטוקול שנקרא TLP שפורסם ע"י ה – CERT האמריקאי (חלק מארגון ה – DHS, ארגון בטחון הפנים שלהם). הפרוטוקול, שהינו ראשי תיבות של Traffic Light Protocol, מציע דרך הרבה יותר ידידותית למשתמש לסיווג מידע. צבע הסיווג מגדיר את רמת רגישות המסמך.

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

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

 

30
אפר
15

באג/תיקון Leap Second

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

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

כדאי שתיערכו לעדכן את המערכות שלכם לפני יוני וקבלו מהיצרנים Patch מתאים.

22
מרץ
15

המקור לדלף מידע בארגונים

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

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

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

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

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

התממשות האיום, שבו גורם יוציא מידע מסווג מהארגון ללא אישור, תלויה רבות בערוצי הוצאת המידע מהארגון ובנגישות שלהם למקור האיום לדלף מידע (העובדים). כגון: שליחת מיילים חיצוניים מתוך המייל הארגוני, שליחת מסרים אוטומטיים ממערכות הארגון באמצעות מערכת הפצה (מייל, פקס ו- SMS), הצגה וקבלת מידע באתרי הארגון, הדפסת מסמכים, גישה למייל הארגוני מהאינטרנט (OWA), מכשירי מובייל המחוברים למייל הארגוני (Active Sync), ממשקים פנימיים וחיצוניים, דיסקים/DOK כוננים וכד'.

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

כיצד ניתן להוריד את רמת הסיכון לדלף מידע בארגון שלך:

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

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

טכנולוגיה
רכישת כלים חזקים לשליטה בכל פעילות הארגון. פתרונות DLP – Data Leakage Prevention system מאפשרים לנו להגביל הוצאה של נתונים בנקודות הקצה בארגון ואף לשלוט בהפעלה של יישומים – על פי רשימה שחורה (לא מורשים) או לבנה (מורשים). מערכות ה – UTM (Unified Threat Management) למשל, שנחשבות כדור הבא של חומות האש (Firewalls), כבר הטמיעו את התכונות וכוללות יכולות סינון דואר אלקטרוני, סינון תכנים ושליטה ביישומים.

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

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

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

המידע הארגוני חָשּוב לך: חְשֹוב איך להגן עליו.

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

 

07
מרץ
15

פגיעה במידע בשירות מיקור חוץ

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

הוצאת שירותים עסקיים מצריכה לאפשר אחת מהשתיים:

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

 

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

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

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

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

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

 

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

 

24
פבר
15

Windows כבר לא מערכת ההפעלה הפרוצה מכולן

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

  1. Mac OS X: נמצאו 149 פגיעויות, 64 מתוכן בסיכון גבוה
  2. Apple’s iOS : נמצאו 127 פגיעויות, 32 מתוכן בסיכון גבוה
  3. Linux (ברמת Kernel): נמצאו 119 פגיעויות, 24 מתוכן בסיכון גבוה

 

שתי הפגיעויות (Vulnerabilities) שעשו הכי הרבה כותרות (לא בטוח שהן היו הכי חמורות) הן Heartbleed, ShellShock. אני אוסיף לרשימה את POODLE שחיסל את פרוטוקול SSL, למרות שזה לא שייך למערכת ההפעלה.
הדפדפן Internet Explorer ממשיך 'לככב' ברשימת האפליקציה הכי פגיעה (224 פגיעויות). שימו לב גם ל – Chrome וגם ל – Oracle Java.
לאור הפריצות הרבות שהיו ב – 2014, כדאי שתמשיכו לפצ'פץ'/להטליא את מערכות ההפעלה שלכם.

22
פבר
15

חדש: צור קשר

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




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