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

• ארצות הברית אחראית כמעט לחמישית מהסריקות (18%)
• מהמדינות הבאות הגיעו כמעט מחצית הסריקות: ארה"ב, טאייוון, רוסיה, סין, קוריאה וברזיל
• כמעט 4% מהסריקות הגיעו ממדינות מוסלמיות/ערביות (בין השאר: פקיסטן, סעודיה, אירן, מרוקו, מצריים, אלג'יריה, כוויית, ירדן ועוד)

הטבלה הבאה מציגה את 30 המדינות המובילות בסריקות:

]]> http://ciso1.wordpress.com/2012/01/26/%d7%94%d7%aa%d7%a4%d7%9c%d7%92%d7%95%d7%aa-%d7%a1%d7%a8%d7%99%d7%a7%d7%95%d7%aa-%d7%a8%d7%a9%d7%aa-%d7%9e%d7%9e%d7%93%d7%99%d7%a0%d7%95%d7%aa-%d7%a9%d7%95%d7%a0%d7%95%d7%aa/feed/ 5 ciso1 ממוצע סריקות לפי מדינה http://ciso1.wordpress.com/2012/01/15/%d7%94%d7%92%d7%a0%d7%94-%d7%9e%d7%a4%d7%a0%d7%99-cyber-terror/ http://ciso1.wordpress.com/2012/01/15/%d7%94%d7%92%d7%a0%d7%94-%d7%9e%d7%a4%d7%a0%d7%99-cyber-terror/#comments Sun, 15 Jan 2012 20:19:18 +0000 CISO1 http://ciso1.wordpress.com/?p=327 ]]> כמו הרבה ביטויים אחרים, סייבר טרור נהיה טרנד חם לאחרונה. כאילו האקרים ממרוקו ואירן לא השחיתו לנו אתרים לפני שלוש וארבע שנים. אפשר להיזכר באיומים שהיו לקראת ספטמבר האחרון שלא יצא מהם הרבה.

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

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

• חסימת תקשורת מארצות שאין איתן עסקים. ניתן לחסום תקשורת משם במערכות IPS או Firewall מתקדמות בהגדרות פשוטות. סביר להניח שניתן לחסום תקשורת מכל מדינות ערב באופן גורף ללא חשש. אם הארגון שלכם אינו בינלאומי ואינו עוסק במסחר מקוון, אפשר לשקול לחסום תקשורת מכל מדינה מחוץ לישראל.
• סגירת פורטים שאינם בשימוש, להם ה – Firewall מאזין. אם יש לכם אתר אינטרנט שעובד פורט 80 ועוד פורט או שניים להתחברות מרחוק לרשת החברה, אפשר לחסום את כל הפורטים האחרים.
• להפעיל הגנות DoS ב – Firewall, IPS או כל רכיב אחר בעל תכונה כזו שמותקן ב – Gateway.
• לבצע גיבויים שוטפים (כל שעה) לכל השרתים הפונים לאינטרנט. ולהיות ערוכים ומתורגלים לשחזור מהיר של השרתים.
• להגדיר נוהל מפורט לתגובה במקרה פגיעה מהתקפת סייבר. על הנוהל להחיל גם תגובה ברמה העסקית – יידוע מנהלים רלוונטיים וכדומה. רצוי גם לתרגל אותו, לפחות על יבש.

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

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

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

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

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

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

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

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

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

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

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

רציתי לעניין אותך ואת מי שמתעניין (חברי הבלוג )בנושא PCI להגיע למפגש בקבוצת .net security user group .

המפגש יתקיים ב-06/01 בשעה 17:30 בבית מיקרוסופט, רח' הפנינה 2 רעננה. הכניסה חופשית !!!
בכנס הקרוב אני מתכוון להעביר הרצאה בנושא תקן PCIDSS ומה המשמעויות כלפי אנשי הפיתוח.
להלן פירוט הנושאים במפגש:
- what is PCI and why we need it
- pci 1 -12 top review
- pci and application security relevance
- net implementation for pci requirements
- key management implementation
במידה וישנם נושאים ספציפיים שמעניינים אותך לגבי התקן, אתה מוזמן לשלוח לי -yaron@2bsecure.co.il ואני אנסה לשלב המסגרת המפגש הקרוב.

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

לצערי, עדיין לא גיבשתי פתרון להתמודד עם הבעיה הזו.

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

ה – Listener  הינו רכיב תוכנה של Oracle המאפשר תקשורת בין המשתמש לבסיס הנתונים.  מכאן שלרכיב זה יש חשיבות מאוד גבוהה באבטחת מידע. גורם זדוני שפוגע ברכיב זה, פוגע למעשה בתקשורת לבסיס הנתונים. הוא דומה ברעיון ל – Socket של פרוטוקול TCP/IP אשר מאזין לתעבורת רשת בפורט מסוים. בברירת מחדל, ה – Listener  מוגדר להאזין על תעבורה המגיעה על פורט 1521.

היעדר אבטחה על ה – Listener  עשויה להוביל לסיכונים הבאים:

• מניעת שירות (DoS) לבסיס הנתונים. פורץ יוכל להפסיק את פעולת הרכיב. בנוסף, פורץ שמשיג שליטה ב – Listener  יכול להגדיר ל – Listener סיסמא לא מוכרת ולמנוע מ - DBA לשלוט להבא ברכיב.  דרך נבזית נוספת היא הגדרת Timeout של שניה אחת להתחברות לבסיס הנתונים. מהר מאוד, כמות הפניות להתחברות לבסיס הנתונים (דרך ה – Listener) תהיה גבוהה מאוד ותוביל למניעת שירות.
• גניבת מידע רגיש. הפורץ יכול להגדיר כתיבת Trace על פעולות מול בסיס הנתונים. למשל, פעולת החלפת סיסמא. במקרה כזה, ה – Trace עשוי לתעד את הסיסמא החדשה באופן נגיש לפורץ.
• גישה לא מורשית (פריצה) לשרת. פורץ יוכל  להגדיר כתיבת קובץ שידרוס את קובץ .rshosts שמגדיר לאיזה כתובות IP מותרת גישה. דריסת הקובץ אפשרית מכיון של – Listener  יש הרשאה גבוהה על השרת.

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

• לשדרג את בסיס הנתונים לגרסת Oracle מתקדמת. ככל שהגרסה מודרנית יותר, כך הרכיב מאובטח יותר בברירת מחדל. תת גרסה מתקדמת של 10g תאפשר, למשל, חיבור ל – Listener  על בסיס משתמש של מערכת הפעלה LOCAL OS AUTHENTICATION כדי למנוע ניהול הרכיב מרחוק (ובכך לאפשר פריצה).
• התקנת טלאי (Patches) אבטחת מידע של אורקל.
• לשנות את ה – TNS Port בו הוא מאזין לפורט שאינו ברירת מחדל.

לסיום, חשוב תוודאו שבזמן שמאבטחים את בסיס הנתונים, מטפלים גם בהקשחת ה – Listener.

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

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

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

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

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

אז מה פרטי היום ומה ציבורי? והאם לפרט אין יותר אחריות על המידע?

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

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

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

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

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

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

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

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

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

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

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