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. תתעדו (כבר אמרתי).
27
יונ
12

סקירת והסרת הרשאות

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

מספר סיבות מדוע סקירת הרשאות חשובה:

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

 

כיצד מנהלים סקירת הרשאות:

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

 

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

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

05
פבר
12

חוזק סיסמא

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

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

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

כדי לבחור סיסמא שאינה קלה לניחוש אבל קל לזכור אותה, מומלץ לחבר שתי מילים קצרות (אפשר שני שמות) ולרפד את הסיסמא בתוכן קבוע. הריפוד (Padding) מאפשר להאריך את הסיסמא ולשנות אותה כך שתאפשר שינוי סיסמא כל פרק זמן הנדרש ממדיניות הסיסמאות.
למשל, לחבר שמות של ילדים/הורים/אחים: טלי, גיל (Tali, Gil) ולרפד בהתחלה עם ספרות:21. הסיסמא תהיה: 21TalGil. בהחלפת הסיסמא הבאה, הסיסמא תהיה: 22TaliGil ולאחר מכן 23TaliGil. כך, השגנו סיסמא מאוד חזקה – תשעה תווים – אך מאוד קשה לניחוש או פיצוח של כלי פריצה.

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

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

27
יונ
11

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

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

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

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

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

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

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




יולי 2020
א ב ג ד ה ו ש
 1234
567891011
12131415161718
19202122232425
262728293031