10 חוקים לניטור וחסימה במערכת DLP

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

אז הנה מספר חוקים:

1. שליחה של מספרי כרטיסי אשראי. חשוב להפעיל, במידה וניתן, בדיקת תקינות למספרים (בדומה לתעודות זהות, גם למספרי כרטיסי אשראי יש חוקיות) כדי למנוע התראה על מספרים שאינם תקינים (שאינם בהכרח כרטיסי אשראי). חוק חשוב לתקן PCI.
2. שליחה של מספרי תעודות זהות. גם כאן להפעיל בדיקת תקינות ולוודא שמדובר בתעודות זהות.
3. שליחה של תנאי העסקה – שכר, משכורת.
4. שליחה של מידע רפואי (צריך ליצור במערכת מילון של מושגים רפואיים רגישים).
5. שליחת קבצים מספריות ברשת שסומנו כרגישות. למשל, משאבי אנוש, ספריות של אפליקציות עסקיות, הנהלה ודירקטוריון, שיווק.
6. שליחה אל נמענים מהעיתונות כדי לאתר הדלפות.
7. שליחה אל נמענים מחברות מתחרות. האם זה תקין שעובד בחברת סלולר אחת ישלח מייל לחברת סלולר מתחרה?
8. שליחה של סיסמאות. נזהה את זה בין השאר ע"י הביטויים: סיסמא, סיסמה, סיסמאות, admin ועוד.
9. שליחה של נתוני עמלות. סוכן מכירות של החברה ינסה להשיג ממקור פנים נתוני עמלות של סוכנים מתחרים.
10. שליחה של שאילות לבסיסי נתונים. נזהה ע"י הימצאות כל הביטויים הבאים: select, from, where

סיכונים במחשוב ענן

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

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

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

1. מעילה/גניבה: אדמין עם הרשאות חזקות בחוות השרתים של הענן מסוגל להפעיל אפליקציות רגישות או להכנס לבסיסי נתונים רגישים ולבצע מעילה בכספי הארגון או לגנוב נתונים רגישים. כל זאת, ללא יכולת בקרה של הארגון.
2. תשתית לא מאובטחת: אם בארגון יש למנהלי הרשת בקרה על הקשחת שרתים, השרתים בענן עשויים שלא להיות בשליטת הארגון. ניצול פרצות בהקשחות השרתים עשוי לאפשר ניצולם לרעה.
3. היעדר אמצעי אבטחה נאותים: אם ברשת הפנימית אנחנו יכולים להתקין מערכות אבטחה כראות עינינו, בענן היכולת שלנו מוגבלת עד בלתי-אפשרית. רמת אבטחת המערכות שלנו עשויה לרדת באופן משמעותי ביציאה לענן.
4. ממשק ניהול פרוץ: כדי להקל על ארגונים, או עקב חוסר מודעות, ספק הענן עשוי לאפשר גישה לא מאובטחת כראוי ללקוחות השונים לצורך ניהול המערכות. סביר להניח שהאקר ינסה בראש ובראשונה להשיג גישה לממשק זה שיאפשר לו שליטה מלאה לביצוע פעולות זדוניות.
5. תקלות כלליות: תקלה בהגדרות או בתוכנה של הספק עשויות לפתוח, באופן זמני, פרצה רוחבית לכל המערכות המאוחסנות אצל הספק. לא מזמן פורסם מקרה כזה שאפשר, למשך כשעתיים, גישה לכולם ללא סיסמא.
6. שיתוף מידע: המידע המאוחסן ע"י הספק יושב בתשתית Storage משותפת. הגדרות לקויות עשויות לגרום לזליגת מידע בין לקוחות.
7. חבות משפטית: בשירותי ענן, לא ברור איפה השירות נמצא – באיזה מדינה חוות השרתים מותקנת. ייתכן גם שהשירות ינדוד בין חוות שרתים במדינות שונות באופן שקוף לארגון. במקרה של אירוע, מול איזה ישות משפטית ימוצה הדין, ולפי חוק של איזה מדינה? האם יש לארגון שליטה על בחירת הרשות השופטת?

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

קוד טכנאי בבקרת כניסה

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

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

כיצד מנהל אבטחת מידע חדש צריך להיערך – חלק ב'?

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

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

 

מיפוי נכסים והערכת סיכונים:

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

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

 הגדרת נהלי אבטחת מידע ראשונים:

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

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

 סקר סיכונים (רוחבי):

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

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

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

 התקנת מנגנוני אבטחה סטנדרטיים:

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

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

כנ"ל לגבי Firewall בכניסה לרשת והגדרת חוקים נכונה.

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

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

כיצד מנהל אבטחת מידע חדש צריך להיערך – חלק א'?

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

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

תחומי סמכות, אחריות וטיפול:

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

שיוך ארגוני וכפיפות מתאימים:

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

הגדרת מסגרת העבודה:

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

מדיניות אבטחת מידע:

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

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

חוזק סיסמא

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

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

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

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

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

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

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

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

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

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

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

הגנה מפני Cyber Terror

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

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

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

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

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

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

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

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

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

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

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

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

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

אבטחת מכשירים סלולריים/חכמים II

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

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

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

אבטחת אפליקציות ארגוניות. את תכונה זו גם נחלק לשניים. אפליקציות מבוססות Web (כגון פורטל SharePoint) ואפליקציות עסקיות כגון BI/DWH. אנחנו נראה בעתיד הלא רחוק מנהלים המעוניינים לקבל נתוני מכירות או מדדי שירות לאפליקציית ה – BI שעל המכשיר. ונראה עובדים שרוצים להשתמש במידע ארגוני מהפורטל בלי לפתוח את המחשב הנייד שלהם.

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