Archive Page 2

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

חדש: צור קשר

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

09
ינו
15

ניהול סיכונים וכימות הנזק

נוהגים לומר שניהול נכון של אבטחת מידע מחייב ניהול סיכונים אשר מאפשר להעריך האם יישום של בקרה מסוימת מצדיק את העלות אל מול התועלת הצפויה. זה נכון לכל דיסציפלינה ולא רק לאבטחת מידע.
את עלות יישום הבקרה קל יחסית לאמוד. בד"כ ישנה עלות הקשורה ברכש חומרה, תוכנה או רשיונות, וישנה עלות כח אדם ליישום הפתרון (ועוד מרכיבים חשבונאיים כמו פחת, תחזוקה שנתית, שטחי אחסון וכדומה).
לעומת זאת, את מידת הסיכון לארגון קשה מאוד להעריך. את הערכת הסיכון ניתן בגסות לחלק לשני מרכיבים. הנזק לארגון כתוצאה מזליגת מידע, אובדן זמינות או פגיעה באמינות הנתונים (CIA), שאמור להיות מתורגם לנזק כספי זה המרכיב הראשון. המרכיב השני זו ההסתברות שאירוע כזה יתרחש. מדובר בשני רכיבים שאין בשבילם נוסחה מתמטית שתנבא אותם. במקרה הטוב, מנהל כלשהו יעריך בצורה גסה את עוצמת הנזק ובמקרה הרע זה יישאר כהערכה איכותית ולא כמותית. גם את ההסתברות לא ניתן להעריך, ובפרט כאשר ההסתברות עשויה להשתנות כל הזמן כיוון שכלי הפריצה הממוכנים הולכים ומשתכללים כל הזמן.
מה בכל זאת ניתן לעשות כדי לקחת את ההערכות הגסות האלה רמה אחת יותר גבוהה (אבל עדיין לא מספקת)? התשובה היא לא הרבה. אפשרות אחת היא לחפש פרסומים על אירועים דומים המציינים מה היה גובה הנזק לארגון. למשל, כמה עלה לחברה מסוימת גניבת X מספרי כרטיסי אשראי ומכאן לגזור הערכה מעט יותר מושכלת לארגון. דוגמא נוספת, מה היו אובדן ההכנסות לחברה אחרת מכך שאתר האינטרנט שלהם הושחת או לא היה זמין.
אפשרות נוספת היא לחפש מחשבונים. אומנם בד"כ המחשבונים מותאמים יותר לשוק האמריקאי שם, כנראה, ההוצאות המשפטיות גבוהות יותר, אבל זו נקודת התחלה טובה. נתקלתי במחשבון נחמד של חברת Synantec ומכון The Ponemon Institute בלינק הזה. שחקו עם הפרמטרים השונים ונסו להתאים את התוצאות לארגון שלכם ותדביקו אותם לסיכונים השונים שלכם כך שבפעם הבאה תציגו הערכה ראשונית של נזק לכל סיכון. מול הערכות מספריות, יהיה למנהל הכספים או למנהל ה – IT יותר קשה להתווכח על הצורך בהוצאות הקשורות באבטחת מידע.

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.

 




ינואר 2018
א ב ג ד ה ו ש
« פבר    
 123456
78910111213
14151617181920
21222324252627
28293031