ארכיון עבור דצמבר, 2009

30
דצמ
09

דליפת מאגר נתונים – אגרון

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

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

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

מודעות פרסומת
21
דצמ
09

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

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

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

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

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

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

כמה נקודות שהמסמך מכסה:

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

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

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

18
דצמ
09

טכנולוגיות חדשות להגנה על המידע במחשבים…

אני שוקל לרכוש לארגון שלי:

att00005.jpg

15
דצמ
09

סוגי מתקפות Web Services ומנגנון הגנה

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

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

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

הבעיה העיקרית בשימוש ב – WS נובעת מניצול מתקפות לפני ביצוע Parsing. למעשה, בשלב הזה השרת קלט את הקבצים אך טרם יכול לבדוק אותם. מתקפות אלה מכוונות בעיקר ל – DoS. קרי, לפגוע בשירות ע"י הפלת השרת. למשל ע"י סוגי המתקפות הבאים: XML bomb, Buffer Overflow. אני לא מכיר מספרים מדויקים, אבל נהוג לחשוב כרגע שרוב המתקפות בתחום השירותים מכוונות ל – DoS. זה יכול להוביל להפלת שרת ואפילו אתר Web.

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

בעתיד אפרט יותר לגבי יכולות XML FW.




דצמבר 2009
א ב ג ד ה ו ש
« נוב   ינו »
 12345
6789101112
13141516171819
20212223242526
2728293031  
מודעות פרסומת