Archive for the 'הזדהות והרשאות' Category

13
ספט
14

סיכונים בהפעלת שירותי רשת

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

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

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

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

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

השימוש ב – UDP מעצם טבעו אינו מאפשר הזדהות (Authentication) של המקור. בנוסף, המידע נשלח ב – Clear Text כך שניתן להאזין לו ע"י Sniffer. לכן, לפני ש – CISO מאשר הפעלת שירות כזה, כדאי שיבחן את וקטור התקיפה והאפשרות לשלוח מידע כוזב ע"י גורם לא מורשה, והסיכונים והתועלות הנובעים משירות רשת כזה. במקרים בהם ניתן להפעיל שירות מסוים על גבי TCP, רצוי לעבוד במוד זה. במקרים בהם ניתן לשלוח את המידע על גבי תווך מוצפן (למשל IPSEC), מומלץ מאוד להגדיר את התווך כמאובטח.

 

מודעות פרסומת
01
ספט
13

אבטחת מידע ב – SAP

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

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

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

  • טרנזקציות המאפשרות ניהול הרשאות (כגון SU01). חשוב לבקר באופן שוטף מי מקבל הרשאות אלה (רק מנהלי/מיישמי ההרשאות). מומלץ לנטר במערכת ה – SIEM הגדרת SU01 למשתמשים.
  • טרנזקציות המאפשרות עדכון נתונים בטבלאות בייצור. בניגוד לבסיסי נתונים SQL כגון Oracle, MS-SQL, בעולם ה – SAP ניתן לגשת לנתונים ישירות לטבלאות (קצת כמו אקסל). טרנזקציה SE16, ונוספות, מאפשרות גישה כזו. זה סיכון שאסור לאפשר (למעט מקרי חירום) וחייבים לחסום אותו.
  • הרשאות המפרות את עיקרון הפרדת הרשויות (Segregation of Duties). ארגון לא אחראי יאפשר בשמחה לעובד אחד גם להקים ספק, גם ליצור דרישת תשלום לאותו ספק, ולבסוף לסגור את הספק במערכת. נשמע מעולה, לא?
  • ממשקים אל ומהמערכת שאינם מאובטחים. כמו כל מערכת אחרת, האם הממשקים מוגבלים בהרשאות גישה? האם מידע רגיש (למשל, כרטיסי אשראי) עובר באופן מוצפן?
  • כתיבת קוד מעבר לקיים בחבילת הבסיס (למשל ABAP ב – SAP) שחושף את המערכת לפרצות אבטחה.
  • התקנת טלאי אבטחה לתשתית המערכת.

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

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 נכשלים או מתעכבים מאוד בהטמעתן. על כך בפוסט הבא (כשאמצא זמן להשלים אותו).

31
מאי
13

למה צריך NAC?

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

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

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

  • התחברות לא מורשית של אורח לרשת החברה
  • חיבור מחשב ארגוני (או מחשב אורח מורשה לחיבור) לרשת כאשר המחשב אינו עומד במדיניות האבטחה ומסכן את הרשת (כגון אנטי וירוס לא מותקן)
  • חיבור מחשב מורשה כאשר התקנים מסוימים פתוחים (כגון USB או WiFi)
  • שליחת התראות (ל – SIEM או במייל) כאשר מחשב שאינו מורשה מחובר לרשת

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

05
מרץ
13

סיכונים בתוכנות איפוס סיסמאות Self Service Password

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

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

להלן מספר סיכונים שמיפיתי בבחינת פתרונות שונים:

  • לא כל המערכות האלה מאובטחות בעצמן. למשל, ראיתי בעבר מערכת שעובדת על HTTP, כלומר תשדורת הסיסמא עוברת באופן לא מוצפן. כך ששימוש בתוכנה לא מאובטחת תאפשר לפורץ להשיג שליטה על סיסמאות של עובדים אחרים.
  • ישנם מנהלים שרוצים לחשוף מערכת כזאת גם לאינטרנט. זה יאפשר לכל העולם לנסות לדוג שם משתמש וסיסמא ולחדור לרשת הארגונית.
  • מערכת כזאת מאפשרת לבצע סוג של Brute Force כדי לאפס סיסמא של עובדים. ניצול מתקפת Social Engineering יביא לתוצאה דומה לנקודה הקודמת.
  • הגדרת שאלות אבטחה ('סבתא') חלשות לצורך זיהוי המשתמש, כגון מה הצבע האהוב עליך (רוב האנשים יבחרו כחול, אדום, ירוק או צהוב), יחליש מאוד את רמת האבטחה. למי שמתעניין בפוליטיקה האמריקאית בוודאי יזכור שכך פרצו לחשבון המייל של שרה פיילין אשר התמודדה על תפקיד סגן נשיא ארה"ב.

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

03
יול
12

כיצד לבצע סקירת הרשאות?

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

פירוט הקשיים בסקירת הרשאות:

  1. גזירת הרשאות מהמערכות. כדי שמנהלים יוכלו להורות על הסרת הרשאות, הם צריכים קבצים המרכזים את ההרשאות במערכת עליהם הם אחראיים. או לחלופין, גישה למסך המציג להם את ההרשאות. רגע, כיצד שולפים את ההרשאות? איזה מידע מהטבלאות מרכיב בכלל את ההרשאות?
  2. מאשרי הרשאות. או במילים אחרות: פוליטיקה. המנהלים העסקיים ינסו להתנער מהחובה הזו. לא ישתפו פעולה. לא יסקרו את הרשימות בצורה מעמיקה. לא יספקו בזמן את התוצרים. יחזירו לכם שאלות קנטרניות. או בכלל יטענו שהם לא מבינים והם לא הכתובת הנכונה (וזה לאחר שאתם ממתינים חודשיים לתשובות מהם).
  3. מעקב ובקרה. כיצד מנהלים את כל התהליך הזה? למי כבר העברנו את הרשימות, מי נתן תשובה מלאה ומי רק חלקית? למי צריך להפיק רשימה טובה יותר? באיזה מערכת כבר הסירו הרשאות?
  4. הסרת יתר של הרשאות. המנהל משה דווקא שיתף פעולה באופן מפתיע. מתוך 400 רשומות, הוא הורה על הסרת 50 הרשאות. ביצעתם. טלפונים זועמים ממשתמשים: "למה הורידו לנו הרשאות? אנחנו צריכים לבצע תשלומים וזה היום האחרון בחודש. דחוף!" לאחר בדיקה, גיליתם שמשה הורה על הסרת 10 הרשאות (מתוך ה – 50) שלא היו צריכים להיות מוסרות. משה התלהב יותר מידי.

 

מספר המלצות לייעול התהליך:

  1. תיעוד של התהליך: החל מהפעם הראשונה, תתעדו כל פעולה, כל מידע על גזירת הרשאות במערכת מסוימת. תפיקו לקחים בתוך הפרויקט ובטח לאחריו. אל תסמכו על כך שבפעם הבאה זה ילך יותר טוב. בלי תיעוד, לא יהיה שיפור. מניסיון.
  2. תתחילו בקטנה. תבחרו שתי מערכות מייצגות ותבצעו רק עליהן את התהליך עד סופו. לאחר מכן, תתפרסו על שאר המערכות.
  3. ישיבות סטטוס: תירתמו הנהלה בכירה לתהליך טרם תחילתו, ודווחו להם סטטוס התקדמות פעם במספר שבועות. בקשו את עזרתם מול מנהלים סוררים שאינם משתפים פעולה.
  4. מידע HR: אל תצאו לדרך בלי לגזור מידע HR המפרט שיוך ארגוני לכל עובד. לכל רשימת הרשאות תצמידו (בגוף הרשימה) את השיוך הארגוני של כל עובד. המנהל סוקר הרשאות בעיקר על סמך שיוך ארגוני ולא על סמך שם או ת.ז.
  5. טבלאות ניתנות לפילטור: ספקו יכולות פילטור נוחות לרשימות. זה יקל על הסוקרים ויקצר את התהליך. זה גם יאפשר לכם לטייב את המידע לפני שאתם מעבירים אותו לסקירה.
  6. מערכות הרשאות: ישנן מספר מערכות בשוק המספקות יכולות ניהול קמפיין סקירת הרשאות. ההטמעה שלהם לא זולה, אבל בטווח הארוך הם מקצרים זמנים בכל סקירה, מביאים לשיתוף פעולה טוב של כולם. קחו בחשבון שפרויקט הטמעה של מערכת כזו יקח לפחות שנה. לא פרויקט של שבועיים.
  7. תתעדו (כבר אמרתי).



דצמבר 2018
א ב ג ד ה ו ש
« ספט    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
מודעות פרסומת