מבוא לאבטחת מידע (“סייבר” ושטויות שכאלו) – חלק ב’

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

לא עניתי אבל על השאלה המתבקשת: “מה עושים?” כיצד מתגוננים ו/או מתכננים מערכות תוכנה מאובטחות יותר[א]?

– על שאלות אלו אנסה לענות בפוסט הנוכחי.

מודל ה-CIA

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

  • Confidentiality (סודיות) – מניעת חשיפה לא מורשית של מידע.
    • אבני יסוד בהגנה: Authentication (אימות זהות), Authorization (ניהול הרשאות), והצפנה.
  • Integrity (שלמות הנתונים) – מניעת שינוי לא רצוי של נתונים, זיוף נתונים, או השחתת נתונים. הידיעה שנתונים שמשתמשים ניגשים אליהם הם אותנטיים ולא שונו ע”י גורם עויין.
    • אבני יסוד בהגנה: חתימה דיגיטלית, Authentication, ו Audit (רישום הגישות לנתונים)
  • Availability (זמינות) – ווידוא שניתן לגשת לנתונים בכל זמן.
    • אבני יסוד בהגנה: יתירות, וגיבויים / Disaster Recovery.
לשם המודל אין קשר לארגון הביון המרכזי, אולי מלבד מהכוונה לגרום לשם להיות קליט יותר.
המודל עוזר לנו לחשוב על האלמנטים שיש לאבטח על מנת לספק “אבטחת נתונים”, ורק שילוב של שלושתם – באמת מספק אבטחה
.
למשל: נניח שיש גורם שמצפין את המידע שלי בהצפנה כפולה: ה Confidentiality בשמיים – לא ניתן לגשת למידע. אבל אם גם אני לא מסוגל לגשת למידע, כי אין לי את המפתח להצפנה (Availability) – אז מה הטעם?!זה בדיוק מה שתוכנות ransomware עושות – והן פוגעות באבטחת המידע שלנו, אפילו שהן “רק מצפינות אותו עוד יותר” (כי לנו אין את מפתח ההצפנה, ויהיה עלינו לשלם כופר על מנת לקבל אותו).

4 עקרונות יסוד נוספים

מודל ה CIA הוא שימושי – אך כנראה הוא המודל הבסיסי ביותר שניתן לחשוב עליו. להלן קבוצה של עקרונות יסוד חשובים שליקטתי. העקרונות הללו הם ה Design Principles היסודיים, בחשיבה על תכנון מערכת כמערכת מאובטחת.

Non-Repudiation (אי-התכחשות)

בכל גישה למשאב ו/או ביצוע פעולה, חשוב מאוד שיהיה ברור מי האדם שביצע את הפעולה.
הידע מי ביצע את הפעולה מאפשר לנו להגביל פעולות מסוימות (Access Control => Confidentiality), יכולת ניטור הפעולות (Monitoring => Anomaly Detection) ויכולת לבוא “בחשבון” עם מי שביצע פעולה לא ראויה (Forensics => התרעה).
את אי-ההתכחשות משיגים ע”י:
  • Authentication (אימות זהות) – ארחיב עליה בהמשך.
  • Audit או לוגים – רישום מה קרה ומי עשה את זה ומתי.
דרכים מצוינות “למסמס” אי-התכחשות הן:
  • לחלק את אותו username והססמה לקבוצת אנשים – ואז לא ניתן לדעת מי מהם ביצע את הפעולה, או האם הקבוצה בעצם התרחבה ללא “כוונת המשורר”.
  • להשתמש במערכת ב”משתמשים טכניים” (technical users) להם יש הרשאות עדיפות ואיתם מבצעים את הפעולות הרגישות – תוך כדי שממסכים מי המשתמש האמיתי שיזם את הפעולה.
    • דוגמה: הפקודה “sudo bash” בלינוקס.
    • דוגמה נוספת: משתמש הפעיל חישוב של דו”ח / תהליך במערכת, והמערכת מעבירה SQL Query למשתמש טכני (שלו יש גישה מלאה לבסיס הנתונים – כי למשתמש לא נתן כזו גישה! חס ושלום). כשנגלה שמשהו לא טוב קרה בבסיס הנתונים ע”י המשתמש הטכני – לא נדע לקשר זאת לגורם אנושי.
כמה מלים על ססמאות כאמצעי אימות-זיהוי (Authentication)
לכאורה הדרך הקלאסית לזהות משתמש הוא לבקש ממנו שם משתמש וססמה. מן צירוף שרק המשתמש יודע, ואם מישהו הקליד אותו – זהו בוודאי המשתמש!
אבל:
  • לבני האדם יש דברים חשובים יותר בחיים משינון ססמאות מורכבות. רובנו “נופלים” לאותן ססמאות חוזרות (12345, password, querty, וכו’) – מה שמקל על תוקף פוטנציאלי “לנחש” את הססמה שלנו. בעזרת “מילון” / סטטיסטיקה של הססמאות הנפוצות ביותר, ואולי ע”י כמה פרטי רקע שניתן למצוא עלינו ברשת. פעמים רבות יהיה ניתן “למצוא” את הססמה שלנו גם בלי להכיר אותנו באופן אישי.
    מכירים את המסכים עליהם מודבק פתק PostIt עם הססמה למערכת?
  • בעזרת תוכנת מחשב פשוטה ניתן לנסות ולנחש את הססמה שלנו ב Brute force: פשוט לנסות שוב ושוב עוד קומבינציות. אולי מילון של 8000 ססמאות נפוצות (יש כאלו לשפות דיבור שונות), ואולי לנסות את כל האפשרויות לאורך זמן. עדיין קיימות מערכות רבות שלא ינסו לחסום את המשתמש, גם כאשר הוא מנסה להיכנס למערכת עם אלפי ססמאות שונות בכל שעה, ובמשך ימים רבים.
    • ה Password Strength Meter של My1Login יעריך את חוזק הססמה כנגד Brute Force וייתן כמה טיפים. למשל: מדוע הססמה “MyPasswordIsStrong” היא חלשה למדי.
  • חלק מהחלשות שלנו כבני אנוש הן חולשות חברתיות, אותן תוקפים יודעים לנצל – מה שנקרא Social Engineering.
    • אם מישהו ממש נחמד יבקש מכם עזרה – לא תעזרו לו?
    • נניח שלא. אם הוא יעשה משהו טוב עבורכם ואז יבקש עזרה בחזרה – לא סביר יותר שתעזרו לו בחזרה? לא תתנו לו “רק לדקה” את הגישה שלכם למערכת כדי לעזור לו “במצוקה”?
    • יש סיפור על בחור אירופאי שחדר ל CIA אי שם בשנות ה-90 עם אפס אמצעים. הוא ראה בספר הטלפונים את מרחב מספרי הטלפונים של ה CIA (כולם מתחילים ב….) והתקשר באופן אקראי למשתמשים. הוא הציג את עצמו כאיש IT ואמר שהוא ממש מתנצל, אבל בשל בעיה הוא חייב לנתק אותם לכמה שעות מהמערכת.
      “אבל זה לא אפשרי! אני חייב לעבוד!” – רטן עובד ה CIA האקראי בצד השני.
      “אתה יודע מה…” גילה אמפתיה חברית איש ה-IT מדומה “תן לי את הססמה שלך ואני אסדר לך משהו. אבל אל תגלה לאף אחד!”. כמה עובדים נידבו את שם המשתמש והססמה שלהם לקול בטלפון (שבכלל מקורו באירופה) – הכל מרצון טוב להמשיך לעבוד ולא להתבטל…
      התוקף, חדר למערכת, כמשתמש לגיטימי – מתחת לרדאר של כל אמצעי ההגנה (שהיו מקובלים אז).
מה אפשר לעשות?
עולם האבטחה נוטה לחלק את סגנונות אימות זהות המשתמש לשלושה Authentication Factors:
  • Something you Know – כמו ססמה או שם חיית המחמד הראשונה שלכם.
  • Something you Have – למשל כרטיס עובד, קוד שנשלח למכשיר הטלפון (הטלפון = something you have), או Certificate שמותקן על המחשב האישי (עדיף נייד).
  • Something you Are – למשל מדדים ביומטריים כמו: טביעת אצבע, חתימה, קול, צילום רשתית (זה כבר לא מדע בדיוני), צורת הליכה (שמסתבר שהיא דיי ייחודית – כמו טביעת אצבע), וכו’.
דרך אחת לחזק את יכולת האימות היא לחזק Factor ספציפי: לתת ססמה ארוכה, או לשאול אודות שם הילדה שישבה אתכם לשולחן בכיתה ג’. חיזוק שכזה הוא לעתים מתיש, וגורם למשתמשים “למאוס” בשיטה ולנסות לחפש קיצורים – מה שבד”כ לא טוב לרמת האבטחה.דרך מקובלת יותר היא לבצע Multi-Factor Authentication (בקיצור: MFA), כלומר לאמת את המשתמש ע”פ 2 Factors שונים של אימות זהות: ססמה וגם קוד שנשלח לטלפון. השילוב הזה (נניח לגישה מהבית / בעשות לא אופייניות) הוא לא מטריד כ”כ, אך הוא מקשה מאוד על תוקף פוטנציאלי להתחזות אליכם.
דוגמה נפוצה אחרת ל MFA הן מכשיר כספומט שדורש גם כרטיס אשראי וגם קוד PIN.

MFA הוא סוג של Defense-In-Depth – עקרון שעליו נדבר בהמשך.

Implicit Deny (בסלנג: “נופל סגור”)

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

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

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

Defense In Depth (הגנה לעומק)

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

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

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

  • קיר בטון חלק בגובה 4 מ’ – הקשה מאוד לטיפוס.
  • שדה של ברזנטים מחודדים (spike mats, נקרא “הדשא של סטאלין”) שמקשה מאוד על ריצה והופך נפילה למסוכנת.
  • גדר חשמלית.
  • מחסומי טנקים – שנועדו לחסום מעבר של רכבים.
  • 302 מגדלי שמירה עם שומרים חמושים שלא יהססו לירות בדמות לא ברורה.
  • פטרול של שומרים מלווים בכלבי תקיפה + שביל גישוש (שביל עם חול מיושר) ברוחב 6 עד 15 מ’ שאדם שיעבור דרכו ישאיר עקבות – וכך ידעו על הימצאותו.
    • שביל הגישוש הוא יתיר לגדר החשמלית – לזיהוי חדירה של גורם לא מורשה למרחב.
  • מרחב גדול שהושטח על מנת להסיר מקומות מחבוא אפשריים – בו דמות שעוברת תהיה בולטת. נקרא “רצועת המוות”.
  • תעלה למניעת מעבר כלי רכב.
    • זוהי הגנה יתירה למחסומי הטנקים, שהזכרנו קודם לכן.
  • קיר בטון חלק בגובה 4 מטר עם גדר תיל בראשו – החומה שגבלה עם גרמניה המערבית.
לעבור את חומר ברלין היה קשה מאוד – זה היה מנגנון הגנה אפקטיבי. רוב הנמלטים דרך חומת ברלין – היו בכלל שומרים שהוצבו בחומה.
האם לא היו בריחות ממזרח גרמניה למערב? היו. הם פשוט מאוד התבצעו במקומות אחרים ולא בברלין. זה מלמד אותנו עוד עיקרון חשוב באבטחה – חוזק האבטחה הוא כחוזק החוליה החלשה ובהחלט לא כחוזק החוליה החזקה במערכת. תוקפים אינטלגנטים תמיד ינסו לנצל את הנסיבות והאפשריות הקיימות – כנגדכם.
עוד חומה מפורסמת ש”פספסה” את העיקרון היא החומה הסינית (המרשימה!!) שמשתרעת למערב סין ואכן עצרה התקפות ממערב, אך לא עצרה את פלישת המונגולים לסין – מהצפון. (בוודאי אתם מכירים עוד דוגמאות היסטוריות דומות…).
בעולם התוכנה, Defense In Depth נראה יותר כמו התרשים הבא: ריבוי כלים ותהליכים, עם מידה מסוימת יש יתירות ביניהם (redundancy) – כך שכישלון של כל רכיב במערכת, לא יותיר את המערכת חשופה:
Layered Security (נקרא גם “Castle Approach”)

האם אתם יודעים כיצד נראו טירות בימי-הביניים?
אם אתם חובבי היסטוריה ולחימה – בוודאי שאתם יודעים!

בדרך כלל היו לטירות 2 או 3 חומות, בהם שערים.
כל חומה, סיפקה רמה אחרת של אבטחה – שהתאימה לה.

למשל:

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

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

דוגמה מהעולם האמיתי

באופן דומה למדי, אנו מתכננים את ה Data Center המודרני. (הערה: אני מתייחס ל Data Center בענן, בו לא צריך לערבב את הנושא של תחנות-קצה של העובדים כמו ב On-Premises):

האינטרנט

מחוץ ל Data Center שורר האינטרנט – מלא באיומים ופורעי חוק.

כדרך קבע bots עוינים (יש גם bots ידידותיים. למשל: מנוע חיפוש, או כל אלו שעשיו מפתחים לפייסבוק) שפועלים באינטרנט ומנסים לגשת ל Data Center שלנו:
  • הם סורקים את ה ports שפתוחים לאינטרנט, ומנסים לזהות פגיעויות ידועות (באגים, קונפיגורציה לא מספיקה, וכו’).
  • מנסים להפיץ תולעים, סוסים טרויאנים, או Malware (נוזקות) מסוגים שונים ומשונים.
  • אוספים מידע על המערכת שלנו ואופי השימוש בה. מידע שיוכל לשמש כיתרון עבור התוקף האינטליגנטי.
מכאן אנו משתמשים (לצורך הדוגמה – בפועל זה משתנה ממערכת למערכת) ב3 שכבות של רשת: DMZ, רשת אמצעית, ורשת פנימית. בכניסה לכל רשת יש “שער” זהו רכיב הגנה בסיסי בשם Firewall.ה Firewall בוחן את כל ההודעות ברמת ה (Internet Protocol (IP (+ התייחסות ל port של tcp) ומסנן תעבורה שמזוהה כעוינת ע”פ חוקים שהוגדרו לו. למשל:

  • חסימת הודעות משובשות / שלא עומדות בתקן הפרוטוקול (ניסיונות לאתגר את אמינות המערכת שלנו).
  • חסימת הודעות שמקורן ב ip address של תוקף / לא בטוח. או שאנו מגדירים את הכתובות הללו בעצמנו על פי ניסיון עבר, או שאנו מנויים לשירות חיצוני שעוקב ומעדכן אותנו על כתובות כאלו.
  • חסימת תעבורה שמיישמת התקפות נפוצות: למשל – לשלוח הודעה שבה כתובת השלוח היא הכתובת שלנו, כך שננסה לענות לעצמנו (וכך נעמיס את עצמו סתם).
ה DMZ (קיצור של demilitarized zone = “איזור מפורז”)
ה DMZ הוא שכבת הגנה ראשונה שמסננת את ה Traffic מהאינטרנט. ב Data Center בענן, יהיו ב DMZ מעט מאוד שרתים – שתפקידם הוא בעיקר בקרה והגנה (ומכאן השם).
ה DMZ נוגע ב 2 Firewalls:
  • אחד שמחבר את ה DMZ לאינטרנט – וכולל חוקי הגנה גנריים ובסיסיים (כפי שציינתי למעלה)
  • אחד שמחבר את ה DMZ לרשת הפנימית יותר, ומאפשר רק תעבורה מתוך השרתים שלנו – כאלו שסיננו את התעבורה בצורה מקיפה יותר ואישרו אותה.
על אילו שרתים מדובר:
Reverse Proxy – שרת שמעביר תקשורת פנימה ובחזרה (התשובות של השרתים שלנו), אך מסתיר את הכתובות האמיתיות של השרתים הפנימיים (Network Address Translation). מדוע להסתיר את מבנה הרשת הפנימית שלנו? כדי להקשות על תוקף לנהל התקפה. למשל: תוקף החדיר Malware לשרת הפנימית אך הוא לא יודע מה לפקוד עליו כי הוא לא מכיר את השמות האמיתיים של השרתים.
זה התפקיד הראשון של ה Reverse Proxy אבל התפקיד החשוב שלו הוא להיות איתן.
איתן? כן. שרתי האינטרנט שלנו (nginx ,tomcat, וכו’) הם מורכבים, ולא תמיד מתוחזקים ו/או מקונפגים בחשיבה על Security. לא תמיד מעודכנים בעדכוני האבטחה האחרונים. התוצאה – יש בהם הרבה פגיעויות, שחלק מהן אולי מוכרות לתוקפים.
ה Reverse Proxy הוא שרת פשוט למדי שמתוחזק בחשיבה על Security ומעצם כך כמות הפגיעויות שלו נמוכה משמעותית. יש לעדכן אותו ואת מערכת ההפעלה עליו הוא רץ בצורה תדירה.
אנו מעדיפים שה Traffic העוין מהאינטרנט קודם כל ייתקל בשרת מעודכן שכזה – ועליו וינסה עליו את “הטריקים שלו” ( – ולא יצליח) מאשר שייתקל בתוכנה שלנו שאותה יותר קשה להחזיק עמידה ומעודכנת.
Web Application Firewall (בקיצור WAF) – היא הגרסה המודרנית יותר של Reverse Proxy, שכוללת גם את סט היכולות הקלאסי של Reverse Proxy. בדומה ל Firewall, ש”מבין” תעבורה של פרוטוקול IP (פרוטוקול האינטרנט) ויודע לסנן ע”פ חוקים תעבורה בעייתית, ה WAF “מבין” HTTP ויודע לסנן תעבורה בעייתית: תעבורה שמנסה להגיע ל URLs לא תקינים, שמנסה לסרוק רנדומלית URLs עם HTTP Method חשוד (למשל: קריאה ל DELETE על כל ה URLs הידועים של המערכת).
התעבורה הנ”ל יכולה להיות תקינה לחלוטין מבחינת ה Firewall (פרוטוקול IP), אך דיי ברור שהיא עוינת ברגע שמתבוננים בה ברמת ה HTTP. על מנת “לסנן” HTTP יש “להרכיב” את ה packets של IP לכדי הודעת HTTP request, מה שנעדיף לעשות על תוכן שכבר עבר סינון ראשוני של Firewall.
הערה: עבור מערכות שאינן בענן (on-premises) תפקיד ה DMZ הוא מעט שונה (למשל: מכיל שרתי אינטרנט ציבוריים), לא אכנס להבדלים אלו ברמת הפוסט.
רשת אמצעית

ברשת הפנימית הראשונית – אנו מציבים את שרתי הווב שלנו. אלו שמתקשרים עם המשתמשים (דרך ווב או דרך APIs). התעבורה שמגיעה עליהם עברה כבר סינון של ה Firewall החיצוני וה Reverse Proxy (או WAF), וה Firewall שבכניסה לרשת מאפשר רק לתעבורה כזו להיכנס (ע”י חסימת כל כתובות ה IP מלבד אלו של ה Reverse Proxy / WAF).ברשת הפנימית נמצא באופן טיפוסי את הרכיבים הבאים:

Proxy – פרוקסי הוא שרת אינטרנט שמאפשר גישה החוצה אל האינטרנט. עצם הצורך בגישה הוא עסקי ולא דווקא נוגע לאבטחה. בנוסף, ה Proxy לרוב מבצע Caching לתוכן HTTP שניגשים אליו הרבה – וכך משפר את הביצועים של הרשת.
היבט האבטחה של ה Proxy הוא שניתן להגדיר עליו כללים: להיכן אסור לצאת / לשלוח הודעות. ההגדרות יכולות להיות הן ברמת ה IP (כתובת IP) או ברמת ה HTTP (כלומר: URL Pattern).
כאשר יש תוקף שהצליח לגשת לרשת הפנימית שלנו, הוא יצטרך הרבה פעמים לגשת חזרה לאינטרנט. או על מנת לקבל הוראות נוספות לגבי התקיפה, או בכדי לשלוח את המידע שנגנב – חזרה לתוקף. אם נצליח לחסום כתובות IP בעייתיות – אזי נוכל להקשות על התוקפים ולעתים אף לסכל את ההתקפות שלהם.
ה Proxy הקלאסי הוא רכיב דיי בסיסי עם רשימת Deny סטטאטית שיש לנהל בצורה ידנית.
Identity Detection / Prevention System (בקיצור IDS/IPS)
רכיבים אלו מאזינים לתעבורת הרשת לרשת הפנימית (זו שעברה סינון ראשוני ע”פ חוקי Firewall / WAF) ולזהות דפוסים חריגים או כאלו שנראים כמו התקפה פוטנציאלית. ההבדל המהותי בין IDS ל IPS הוא ש IDS, ברגע שזיהה משהו שנראה לו כמו התקפה יעלה Alert – לאנשי ה DevOps / Security. ה IPS יכול לקחת גם החלטה לחסום את תעבורת הרשת ולעצור את ההתקפה (במידה של זיהוי שגוי – הוא יעצור תעבורה לגיטימית).
החלוקה ל IDS/IPS היא דיי מלאכותית וסביר יותר למצוא כלי שיכול לעשות גם וגם, כאשר בד”כ הוא מעלה התראות, במקרים מסוימים “בודק את המשתמש” (מאט את התשובות אליו או מציג בפניו מבחן Captcha), ורק במקרים קיצוניים – חוסם.
יש חפיפה מסוימת בין WAF או Firewall חכמים ובין IDS/IPS, אבל כפי שציינו קודם לכן בפוסט – יש ייתרון ביתירות הזו בדמות Defense In Depth. כלי אחד שכשל – לא יגרום למערכת שלנו להיות חשופה.

Physical Security – זה גם חלק מהעניין. מקור: onthetech.com
רשת פנימית
ברשת הפנימית אנו מציבים את בסיסי הנתונים שלנו. בסיסי הנתונים הם שרתים שמחזיקים Assets רגישים ביותר (המידע שלנו!) ואנו יודעים לנטר בצורה דיי ברורה איזה תעבורה אמורה להגיע אליהם. במקרה שלנו: רק תעבורה מתוך שרתי הווב/אפליקציה שאישרנו. כל שרת אינטרנט – רשאי לגשת ל DB מסוים מאוד.
אם כן, Firewall פשוט יכול לספק הגבלה הדוקה על הכללים הללו ולאפשר רק את התעבורה הרצויה. בד”כ לא נמצא מוצרי הגנה נוספים ברמת הרשת בתוך הרשת הפנימית – כי התעבורה כבר מסוננת היטב.
סביר יותר שכאן נמצא כלי monitoring (למשל, אבל לא רק HIDS או Agents שונים) שמותקנים על שרתי ה DB עצמם ומנטרים את ההתנהגות על המערכת.

מה הצעד הבא?

מודל ה CIA והעקרונות הנוספים שהצגתי הם הבסיס: הם חשובים מאוד, אבל אין דיי בהם בכדי להכווין אותנו כיצד להגן על מערכת מורכבת.
חשבו על הארגון / המוצר שלכם – האם ברור לכם כבר אילו צעדים מעשיים חשוב לקחת בכדי להגן עליו בצורה טובה מספיק? באיזה עדיפות ובאיזה סדר?
– אני מניח שלא. וגם אם כן – אתם כנראה רואים תמונה חלקית מאוד של המצב.
לשם כך נוצרו מודלים (“Frameworks”) שעוזרים למי שמשתמש בהם לתכנן מקצה לקצה – כיצד להקים ולתחזק מערך הגנה.
למשל, מודל ה NIST Cybersecurity Framework מגדיר את היסודות (cores) הבאים:

לכל יסוד, יש קטגוריה של כללים ו guidelines – איך להשיג אותה, אשר מורכבת מהירככיה של מדריכים שהולכים ונהיים מפורטים כיצד לכסות את התחום.
למשל: אתם רוצים לאבטח את גישת ה SSH לשרתי הפרודקשיין שלכם? אפשר לחפש בקטלוג המדריכים של NIST ולמצוא את NIST.IR.7966 – מדריך בן 50 עמודים שממצה את הנושא עד תום!
המדריך מתאר את עיקרי הטכנולוגיה מאחורי פרוטוקול / כלי SSH, את החולשות, ואת תחומי ההגנה (“Control Areas”) המומלצים על מנת למתן / לבטל את החולשות הללו. למשל:
  • ניהול חשבונות
  • אכיפת גישה
  • צמצום גישה (Least Privilege principle)
  • Audit וניטור
  • ניהול סיכונים (בהיבט ה SSH)
  • זיהוי ואימות משתמשים.

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

הרעיון של רוב ה Frameworks הוא לא להציע רשימה שטוחה של אמצי-אבטחה (Controls) – בנוסח “חייבים את הכל!”.
הגישה הבוגרת היא לאזן בין צרכים עסקיים לאבטחה – ע”פ ניהול סיכונים שמותאם לארגון / מוצר ולצרכים הייחודיים שלו. ע”פ הגישה הזו: ניתן (ולעתים אף חשוב) לקחת סיכונים – כל עוד מנהלים אותם.
מקור: https://rofori.wordpress.com
חוץ מ NIST CSF (קיצור של Cyber Security Framework) – אלו עוד Framework פופולריים קיימים?

לרוב מחלקים אותם ל-3 קטגוריות:
  • Frameworks רגלוטוריים – אותם המדינה מחייבת על ארגונים מסויימים.
    • למשל: HIPAA לארגונים המחזיקים מידע רפואי, SOX – לחברות בורסאיות בארה”ב, NERC CIP – לחברות החשמל בצפון אמריקה, וכו’
  • Frameworks רגלוטוריים למחצה – אשר ארגון מקבל על עצמו כחלק מחוזה / הסדר מסחרי.
    • הדוגמה הכי נפוצה: PCI-DSS של חברות האשראי. אם אתם מנהלים מידע על כרטיסי אשראי ואתם לא עומדים ברמת ההגנה של ה Framework / או בסטנדרטים שלו (למשל: לא יותר מ 1% מהעסקאות שאתם סולקים הם לא-לגיטימיות) – חברות האשראי עלולות להפסיק לעבוד אתכם. עבור ארגונים רבים – זהו עניין קיומי.
    • יש Frameworks קצת פחות ידועים בעולם עריכת הדין, חשבנאות, וכו’.
  • Voluntary Frameworks – שהארגון בוחר לאמץ ביוזמתו בגלל צרכים כאלו או אחרים.
    • ISO/IEC 27001 – הוא ה Framework הנפוץ בתחום, ובד”כ אימוץ שלו כולל הסמכה ע”י גוף שהוסמך לכך (חברות ייעוץ שונות).
      • הוא נחשב בסיסי, נדרש לעתים על מנת להיות ספק של ארגונים גדולים. דיי “מרובע” בתפיסות שלו, בעיקר מסביב לתהליכים.
      • יש לו 2 גרסאות תקפות: 2005 – גרסה מאוד ממוקדת תהליכים (“Plan-Do-Check-Act”) והתיעוד שלהם (למי שמכיר ISO 9000), וגרסאת 2013 – שנחשבת יותר גמישה ומעשית.
    • NIST SP800-53 (נקרא גם NIST 800 series) – הוא תקן אבטחה לו נדרשים גופים ממשלתיים בארה”ב (ועוד כמה מדינות שאמצו אותו כתקן) – אבל גם זמין לכל דורש.
    • (ISC)2 Common Body of Knowledge (CBK) – זה בעצם ה Framework ה”פנימי” של הסמכות ה CISSP – ההסמכה ה”נחשבת” בעולם אבטחת המידע.
    • (DHS Cyber Resilience Review (CRR – עוד Framework אמריקאי (יש רבים כאלו), הפעם של הארגון לבטחון המולדת (DHS).
    • CIS Critical Security Controls (כרגע בגרסה 6.0) – תקן “פתוח”, שנוצר ע”י קבוצה של מומחי-אבטחה בלתי תלויים, וללא מטרות רווח, ש”מחוייבים לחופשיות האינטרנט”.
      • לעתים מזוהה עם חברת SANS – שמסייעת להפיץ אותו.
    • OWASP TOP 10 – זהו לא Framework, אלא ניתוח תלת-שנתי של 10 ההתקפות הנפוצות ביותר על שרתי ווב, מידע פרטי, מובייל, וכו’ (יש מספר גרסאות של הדו”ח). אם אתם רוצים להתחיל עם הבסיס של הבסיס – זה המקום.
    • וכו’ וכו’
אם אתם רוצים להקים מערך הגנה שלם (לא מושלם. שלם) ומאוזן – כדאי להשתמש ב Framework כנקודת התייחסות.
“אני מבין באבטחת מידע, ועובד לפי השיטה שלי” – היא לרוב לא גישה שמגיעים איתה רחוק, אלא אם מדובר במומחה אמיתי, שכבר ה Frameworks הללו מאחוריו. אם יש לכם ספק – שאלו את “המומחה” לאילו Frameworks הגישה שלו דומה, ומה ההבדלים. מעניין.

אם אתם פשוט כותבים תוכנה ומנסים לאבטח אותה, ולא לאבטח ארגון שלם – כנראה ש OWASP זה השלב הראשון, ו ISC^2 / CIS / NIST – הם המקומות להמשיך וללמוד מהם /לקבל מהם מושג וכיוון.

סיכום

המידע הזה עשה לי הרבה סדר בראש כשנתקלתי בו.
במשך שנים הכרתי כל מיני סוגי התקפות (DDOS, ARP Poisoning, או CSRF) – אך לא היה לי כל סדר מה יותר חשוב ממה, ובאיזה אופן כדאי להתגונן.

אני מקווה שהפוסט הזה עשה מעט סדר. עולם אבטחת המידע (“סייבר”) הוא גדול ומורכב. יש תחומי מומחיות של Penetration Testing, איתור וניתוח Malware, מודיעין, Reverse Engineering, ועוד.

אני? אני ניסיתי רק לתת את הבסיס.

שיהיה בהצלחה!

—–

[א] לא קיימת מערכת מוגנת ב 100%, וגם אם תיאורטית היה ניתן ליצור אותה – היא לא הייתה משתלמת עסקית. מחירי האבטחה עולים בצורה מעריכית – ככל שאנו הולכים ומתקרבים ל”אבטחה מושלמת”.

Published

2 תגובות בנושא “מבוא לאבטחת מידע (“סייבר” ושטויות שכאלו) – חלק ב’”

השאר תגובה