"הר" פתרונות האבטחה שאינו רלוונטי כל כך

Print Friendly, PDF & Email

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

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

המציאות פשוטה: גם אם תקים "הר" של Appliances לצרכי אבטחת מידע בכדי להגן על חדירה מבחוץ, הפורצים יכולים לעקוף את כל ההגנות הללו עם פעילות Phishing וכניסה למערכת עם פרטים גנובים. חשוב לזכור: הנקודה הכי חלשה ברוב הארגונים – היא המשתמשים, ולא יעזרו חידודי נהלים לא לפתוח לינקים, לא להוריד/להריץ קבצים במייל וכו' מהסיבה הפשוטה ביותר: אם משתמש קיבל מייל Phishing והוא הזין בו פרטי חיבור אמיתיים, ברוב המקרים הוא לא ירוץ למחלקת IT או אבט"מ לספר על כך. אחרי הכל, מדוע לו לחטוף על הראש? עדיף להפעיל ראש קטן ולהתעלם מכך.

הנקודה הכי חשובה בכל הסתכלות על אבטחת מידע היא Zero Trust. לא לתת שום Trust בין אם מדובר בתקשורת מבחוץ פנימה או בין שרתים או בין מכונות דסקטופ לשרתים. אחרי הכל, אם מאן דהוא הצליח להשיג פרטי גישת VPN למערכת שלכם, מהרגע שהוא מתחבר, הוא נמצא בתוך התשתית של החברה, גם אם יש לו הרשאות מוגבלות (גם עם הרשאות מוגבלות אפשר ליצור נזקים גדולים). יקח לחברה זמן להבין שהפורץ משתמש בפרטי גישת VPN שנגנבו בפעולות Phishing ממשתמש לגטימי, ומאותו רגע שהפורץ מחובר, גרימת הנזק היא פנימית, ה-Firewall וה-WAF שלך לא עוזרים במאומה באותו זמן – וכאן, כדאי לזכור, פורץ חכם לא יחפש לגרום מיידית נזק, אלא יחפש בתשתית נקודות חולשה או תשתית "צדדית" שעליה הוא יכול להתקין את ה-Payload ורק לאחר מספר ימים להפעיל זאת ולהתחיל לגרום נזק/להצפין תוכן או להעביר תכנים.

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

  • להיפטר מסיסמאות: סיסמאות היו ויהיו – מקור לאחד מכאבי הראש הגדולים, כולל כל ה-Policies ליצור אותם, החלפתם וכו'. גם במיקרוסופט ובחברות תוכנה אחרות הבינו זאת מזמן והם מציעים פתרונות שונים המבוססים על טביעת אצבע, Windows Hello, מפתחות כמו Yubikey של Yubico (או Tian של גוגל, ויש גם מפתחות המבוססים בכלל על קוד פתוח כמו Solokeys). בנוסף, שימוש במפתחות מאפשר להשתמש בהצפנות שונות (נתמכות בעיקר ב-Yubikey) ויחסית די קל להטמיע את הפתרונות בכל מערכות ההפעלה.
  • הצפנת תכנים: הסיוט הכי גדול לחברות מבחינת אבטחת מידע, הוא גניבה ו/או הצפנה באמצעות כופרה של המידע, וארגונים גדולים מאוד (חברות כמו קאנון, אוניברסיטאות, בתי חולים ועוד) חוו את הסיוט ונזק משמעותי נגרם לאותם ארגונים. אחד הפתרונות שניתן לבצע הוא הצפנה של רוב התכנים החשובים, וביצוע Decryption דרך Gateway שאליו מחוברים מספר מצומצם של משתמשים. ניתן לדוגמא לבצע זאת בעזרת הקמת LUN שיחובר למערכת לינוקס וירטואלית. מערכת הלינוקס תבצע encryption/decryption עם כלי כמו LUKS-2 או בכלים אחרים, ושיתוף (לאחר decryption) עם SAMBA. אפשר להתגונן נגד כופרה תוך שימוש ב-snapshots (במכונת הלינוקס בשימוש LVM).
  • ביצוע Snapshots – באופן עקרוני, Snapshots ברמת File systems לא אמורים לצרוך כמות משאבים גדולה ליצירה ולכן מומלץ ליצור Snapshots בפתרון האחסון ל-File systems בצורה תכופה מאוד (כל שעה לדוגמא, ובמקרים חשובים כמו הנח"ש – כל מחצית שעה). כך, אם ישנה התקפת כופרה, ניתן לשחזר מה-Snapshot במהירות במקום לשחזר מקלטות.
  • Pen testing הוא פתרון חלקי שלדעתי אינו מספק: לצערי לא מעט ארגונים וחברות שוכרים מישהו מחברה שיבצע בדיקות (Penetration testing), ורובם גם משתמשים באותם כלים וב-Kali Linux (מתי אנשים יבינו ששימוש ב-Kali Linux הוא "אות קין" שלמשתמש אין הבנה רצינית בלינוקס? כל הפצת לינוקס כוללת את כל הכלים הדרושים!) כדי לבצע את הבדיקות, ובמתודה זו הבדיקות והסריקות פשוט אינן מספקות את התשובה המלאה.
    בדיקות הקשחה וחדירה זה לא רק שימוש בכלים כמו nmap, nessus ו-1001 כלים נוספים, אלא לימוד כל המערכת ועבודה בצוות כדי לחשוב על נסיונות חדירה מכל מערכת שרצה בארגון, חולשות שקיימות לכל שרת, לכל Appliance ולכל ציוד (במיוחד ציוד ישן שאין לו עדכונים כבר מספר שנים – ציוד כזה מומלץ להחליף כמה שיותר מוקדם), מי הם האנשים בחברה שפעולות Phishing עליהם יכולות לגרום נזק מהותי, היכן ניתן לעצור או להאט דליפת מידע אם גורם כלשהו הצליח לפרוץ, האם יש עצירה אוטומטית של תעבורת Upload ל-IP שאינו white listed לאחר כמה מאות מגהבייט לדוגמא (כשהפורץ מנסה לגנוב כמה שיותר קבצים), ובקיצור – הכלים הם רק חלק קטן מהעבודה, ודרוש צוות רציני כדי לנסות לפרוץ (מבלי להגביל את הצוות, אבל עם הנחיה לגבות את הכל ולרשום כל גילוי ושינוי) ולא מישהו שהקים Kali Linux על מכונה וירטואלית ומכיר כמה כלים.
  • "קמצנות כרונית" של הרשאות: תופעה שקיימת בכל ארגון – עודף הרשאות שניתנו למשתמשים שונים, הרשאות שנפתחו "זמנית" ונשארו פתוחות או הרשאות שנפתחו ברמת worldwide (בלינוקס/יוניקס זה מוכר כ-777) בגלל שמישהו התעצל לחפש בגוגל ולקרוא איך מגדירים הרשאות בלינוקס. מאוד מומלץ לבצע אחת לחודש או לתקופה לעבור על כל ההרשאות (גם הרשאות מקומיות!) ולצמצם את ההרשאות. אם רוצים להשתמש לדוגמא ב-passwordless ssh, יש להגביל את החיבוריות להרצת פקודות מסויימות, כניסה מכתובות IP מסויימות, ועוד.
  • עדכוני תוכנה ללא תאריכון: אחת הבעיות שכתבתי לגביה שוב ושוב בבלוג זה – מנמ"ר מחליט שעדכונים יהיו אחת ל-X חודשים ותו לא. לך תסביר לאותו מנמ"ר שחולשות אבטחה מתגלות כל הזמן ויש לא מעט מקרים שיש צורך דחוף בהתקנת עדכונים, אחרת התשתית חשופה. דוגמא פשוטה: אם אתם משתמשים ב-vSphere, האם עדכנתם את הטלאי הדחוף הזה?

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

כתיבת תגובה

האימייל לא יוצג באתר.

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