Archive for the 'Firewall' Category

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.

 

מודעות פרסומת
07
דצמ
12

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

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

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

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

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

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

רשת טרמינלים

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

חסימת תקשורת

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

מיילים

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

חוויית משתמש

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

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

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

26
ינו
12

התפלגות סריקות רשת ממדינות שונות

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

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

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

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

15
ינו
12

הגנה מפני Cyber Terror

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

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

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

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

תרשים סיכונים מערכות/מנגנוני הגנה ומניעה

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

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

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

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

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

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

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

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

האפקטיביות של בקרות מפצות

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

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

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

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

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

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

04
מרץ
11

טיוב חוקי ANY ב – Firewall

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

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

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

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



אוקטובר 2018
א ב ג ד ה ו ש
« ספט    
 123456
78910111213
14151617181920
21222324252627
28293031  
מודעות פרסומת