Archive for the 'הפרדת רשתות' Category

10
דצמ
15

התקני IoT והסיכונים הנובעים מהם

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

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

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

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

האיומים הנובעים מהם הם אותם איומים הנובעים ממערכות אחרות, אך במספר הבדלים:

  • הרכיבים האלה עשויים להיות מחוברים ישירות לאינטרנט באופן העוקף את ה – Firewall
  • לא בטוח ש – Firewall יודע לתת מענה אבטחתי לרכיבים אלה
  • הרכיבים האלה נבנו ללא תשתית אבטחה מספקת

נציין כאן מספר איומים הנובעים מהתקני IoT:

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

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

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

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

  • להגדיר מדיניות הכנסת רכיבי IoT לארגון (שתאפשר כניסה מאוד מבוקרת ושתחסום כניסה של רוב ההתקנים האלה).
  • בדיקה קפדנית של רמת האבטחה של כל התקן חדש (או דגם חדש של מוצר שכבר קיים ברשת).
  • התקנת רכיבים כאלה מחוץ לרשת הארגונית, או בסגמנט רשת מבודד. למשל, מצלמות IP שממוקמות פיזית מחוץ למשרד ונגישות לקהל לא מבוקר, או מצלמות אלחוטיות.
  • בדיקה שהיצרן משחרר טלאי אבטחה באופן מסודר. זה יעיד בין השאר על שימוש ברכיבים רגישים פנימיים בתוך המוצר, כגון רכיב הצפנה ושרת Web, המבוססים על סטנדרטים בשוק.
  • הגדרות ACL קפדניות לממשק הניהול של התקנים אלה. להגביל את כתובות ה – IP היכולות לתקשר עם ההתקנים ואת השירותים (פורטים) הפתוחים.
  • במידה וניתן, להגביל גישה של התקנים אלה עם מערכת NAC מתקדמת (לא על בסיס כתובת MAC).
  • לבדוק אילו הגדרות פנימיות בהתקן ניתן להפעיל במטרה לצמצם את הסיכון.

 

מודעות פרסומת
07
מרץ
15

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

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

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

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

 

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

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

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

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

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

 

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

 

25
יונ
14

התגוננות בפני התקפות סייבר Cyber Defense

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

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

התפיסה שיושמה ונוסתה, כוללת את המרכיבים הבאים (רשימה חלקית וראשונית).
הפרדת רשתות: הרגולציה בתחום אבטחת מידע בגופים פיננסיים בארץ, הינה מהמתקדמות בעולם. אחת הדרישות הכי חשובות במספר רגולציות (בנקים, ביטוח) מחייבת הפרדה או חציצה בין רשתות ארגוניות פנימיות לבין רשתות ציבוריות/אינטרנט. החציצה מונעת תקשורת החוצה. (לכל היצרנים/ספקים, מוצר פרוקסי אינו נחשב פתרון כזה.) בשפה תקשורתית, ניסיון ליצור צינור תקשורת החוצה בכל מיני פורטים (80, 443, 22, 21 ועוד) ייחסם ע"י ה – Firewall.
גלישה לאינטרנט תיעשה ע"י פתרונות גלישה מאובטחת. העברת קבצים ע"י פתרונות כספות. וכך הלאה. בטכנולוגיה של היום, הפגיעה בחוויית המשתמש אינה גדולה (חוץ מתלונות מפונקות ע"י עובדים שלא מעניין אותם שהארגון יישאר פרוץ). החריגה היחידה שציינתי בעבר נוגעת לשימוש במייל, שבמקרה זה הפגיעה במשתמשים גדולה ולא מספקת פתרון מקובל מבחינת עלות תועלת.

מעטפת/רכיבי הגנה חיצוניים: כל אותם רכיבים שהיו נהוגים בתפיסת אבטחת המידע הכוללת, רלוונטיים גם כאן. מערכת IPS להגנה מפני התקפות חיצוניות על הרשת, שרת WAF להגנה על אתרי אינטרנט, מערכת סינון תכנים (Content Filtering) ואנטי ספאם, מערכת הגנה נגד APT, הגנה מפני DDoS.
מהיכרות שלי עם ארגונים, ובעיקר עם מנהלי מערכות מידע ומנהלי תשתיות, הם חוטאים בכל קשור לרכיבי האבטחה. במקום לנצל 100% מיכולות החסימה של המוצרים האלה, הרבה הגדרות (לפעמים 50%) אינן מופעלות מהחשש לפגוע בשירות או מכך שזה יביא לעבודה מיותרת בעיניהם. החטא הזה מוביל לכך שפורצים מצליחים ע"י כך לנצל פרצות במעטפת החיצונית. אקווריום אטום "למעט" שני חורים זה עדיין אקווריום דולף. חייבים לחסום הכל, בלי פשרות. מנהלים, תעבדו יותר קשה.

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

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

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

  • צרו רשימת כתובות חשודות. לרשימה זו הכניסו כתובות שביצעו Port Scanning, שלחו מיילים חשודים שהכילו נסיונות Phishing או כתובות שה – WAF זיהה כמקור לתקיפה לאתר החברה.
  • הגדירו חוק המתריע על פתיחת תקשורת (מה – Firewall) לכתובת המצויה ברשימת הכתובות החשודות.
  • חוק המתריע על Port Scanning.
  • חוק המתריע על נסיונות תקיפה (מה – WAF) על האתר. אפשר לעדן את החוק ע"י סינון סוגי מתקפות מסויימים/רלוונטיים או רמת קריטיות של התקפות.
  • חוק המתריע על נסיונות DoS/DDoS (מה – IPS).
  • חוק המתריע על שליחת מייל למעל X נמענים (ממערכת האנטי ספאם). אפשר להוסיף חוק דומה המזהה שליחת מיילים לעובדים רגישים העשויים להיות מושא לנסיונות Phishing (מנהלי רשת, מנהלים בכירים, עובדים בעלי הרשאות רגישות).
  • חוק המתריע על מספר תחנות הנגועות בוירוס או מתקפת APT.
  • חוק המתריע על תקשורת לכתובות הידועות כשרתי Command & Control.

מערך ניטור SOC: חיברתם את כל המערכות והשרתים ל – SIEM וראיתם שמתקבלים חיווים טובים ויש התראות על אירועים חשודים. מה עושים עם כל זה?
כדי להתגונן באופן יעיל מפני התקפות סייבר, יש חשיבות גבוהה להקים מוקד SOC אשר יטפל בהתראות השונות שקופצות במערכת בתוך פרק זמן קצר. במוקדי SOC טובים, המוקדנים יידעו לטפל גם באופן אקטיבי באירועים. למשל, לחסום כתובות IP חשודות ב – Firewall, ב – WAF או ב – IPS, למחוק משרת הדוא"ל מיילים שזוהו כהתקפות Phishing, ואפילו לנתק מהרשת או להעביר לסגמנט רשת מבודד תחנות קצה חשודות.
חשוב להגדיר, בכתב, נהלי טיפול באירועים לכל סוג אירוע שהוגדר לו חוק ב – SIEM, וגם לתרחישים נוספים שאין להם חוקי SIEM. הנהלים יגדירו למי מדווחים, מתי פועלים אקטיבית וכיצד.

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

  • נסיונות חדירה ע"י מייל Phishing המכילים לינקים לאתרים זדוניים והמכילים צרופות המכילות סוסים טרויאניים שעשויים לאפשר מתקפות APT.
  • נסיונות חדירה לרכיבי תשתית ברשת הארגונית.
  • נסיונות חדירה אפליקטיביים ותשתיתיים לאתר האינטרנט.
  • נסיונות חדירה למערכת ה – VPN לגישה מרחוק.
  • נסיונות חדירה ל – IVR.

 

13
אוג
13

האתגרים בהטמעת מערכת NAC

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

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

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

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

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

רוצים לשתף בקשיים? אתם יותר ממוזמנים לרשום בתגובות.

03
יול
13

שיטות אימות ב – NAC

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

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

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

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

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

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

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

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

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

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

07
דצמ
12

גלישה מאובטחת והפרדה מהאינטרנט

אם בשנה-שנתיים האחרונות המונח התקפות סייבר הפכו לביטוי חביב ע"י עיתונאים (מבלי שהם ואנחנו בטוחים למה הכוונה), הרי שעכשיו ארגונים מתחילים להפנים את הסכנות הנובעות מהתקפות כאלה. אם בעבר היה 'מספיק' שרת AV ומערכת Firewall להגן על הרשת, כיום הארגון נדרש להגן על עצמו מפני התקפות APT. אם בעבר התקינו ביציאה מהרשת, לכיוון האינטרנט, שרת Proxy, היום מבינים שקיימים סיכונים רבים לקישור הרשת הפנימית ישירות לאינטרנט (גם עם פרוקסי).

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

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

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

תיאור קצר של הארכיטקטורה של פתרון הניתוק הלוגי (הגישה השניה) ולאחר מכן שרטוט סכמתי:

רשת טרמינלים

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

חסימת תקשורת

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

מיילים

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

חוויית משתמש

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

 השרטוט הבא מציג גרפית את ארכיטקטורת הרשת לגלישה המאובטחה.

 ארכיטקטורת גלישה מאובטחת

02
פבר
11

ניתוח (חוקי) Firewall

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

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

בואו נבחן דוגמא:

Action

Service

Destination

Source

Rule

Accept

ANY

ANY

Developers

85

 

 

 

 

.

.

.

Drop

P2P

ANY

LAN_NW

97

נאמר שחוק 97 היה במקור מספר 22. החוק אמור למנוע מהמשתמשים המוגדרים באובייקט LAN_NW (כל העובדים בארגון) מלגלוש לאינטרנט בפורטים הידועים כ – P2P.

יום אחד התלוננו אנשי הפיתוח שהם לא מצליחים לפתח רכיבים חדשים באתר החברה. איש התקשורת החליט שחוק 22 הוא הגורם לבעיה והוריד אותו ל – 97.

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

עוד דוגמא: איש התקשורת פתח בלי לשים לב NetBios מרשת ה – DMZ לרשת הפנימית, במקום לאפשר NBT רק ברשת הפנימית.

דוגמא נוספת: חוק אחר מאפשר גישה מהאינטרנט בפורט 23 לרשת הפנימית. לא רעיון טוב.

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

אז מה אפשר לעשות? אפשר לרכוש מוצר הנקרא Firewall Analyzer.

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

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

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

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

 




יולי 2018
א ב ג ד ה ו ש
« מאי    
1234567
891011121314
15161718192021
22232425262728
293031  
מודעות פרסומת