שלום לכם.
בפוסט זה אציג את ששת השלבים המוסכמים לטיפול והתמודדות עם\ב- אירועים (או ליתר דיוק – תקריות) בסביבות הדורשות אבטחת מידע. שימו לב למילה מוסכמים , שכן אין זה תקן, הוראה או חקיקה המבססים את סדר ומהות השלבים. שלבים אלה מהווים בסיס לאסטרטגיות פעולה ולכן ייעודם לשמש כמעין מצפן, מפה המנחה את איש\אשת אבטחת המידע בעת תקריות.
אני סבור כי רבים יסיקו כי ביצוע כל ששת השלבים, יעניק להם את הביטחון כי הטיפול בתקרית בוצע ביעילות ובאופן מקצועי. אין זה נכון וזהו לא הרעיון. ע"מ לטפל באירועים באופן מוצלח, אכן, יש לעקוב אחר השלבים אך בנוסף וביתר חשיבות, יש להתאים את אותם שלבים לארגון\עסק וכן לסוג התעשייה של אותו ארגון\עסק.
ששת השלבים\הצעדים בעת טיפול בתקרית אבטחת מידע הם (לפי סדר) :
בנוסף, ההכנה צריכה להתחשב בסוגיות הבאות:
חשוב שלצוות הטיפול באירוע תהיה משענת תומכת מהדרג הניהולי. לא נרצה שבזמן אירוע, יהיו ספקות לגבי החלטות ומהלכים שצוות הטיפול באירוע מקבל.
ציוות אנשים הוא מרכיב לא פחות קריטי בשלב ההכנה. יש חשיבות גבוהה ליכולת יעילה בעבודה בצוות. נתקלתי לא מעט בראשי-צוות שמעדיפים לעבוד "סולו", כגיבורים. לרוב, ההחלטות שיתקבלו במצב זה יהיו פזיזות והפתרונות שיוענקו לא יהיו יעילים.
אנחנו עדיין בשלב ההתכוננות;
סביבת מחשב הינה סביבה מורכבת. לא כל אחד יודע לתפעל את כל מערכות ה-UNIX ונגזרותיה. אף שיכול להיות לך ידע ורקע מוצק בסביבות אלו, אנחנו עדיין בני אדם, ומה לעשות – זיכרוננו מתעמעם עם הזמן. הכנת רשימות בדיקה, Checklists – המתארות כיצד להשבית או לגבות שרת כזה או אחר – יכול ובד"כ מסייע במניעת טעויות, ולא מן הנמנע שגם יפחית את המתח והלחץ בקרב צוות הטיפול.
אם עבדתם כמנהלי מערכת, אני בטוח שצקצקתם בלשונכם בכל פעם שנדרשתם ליצור חשבונות בעלי הרשאות ניהוליות הזמינים לאחרים. חרף זאת, בעת אירוע חירום, סביר כי המטפל באירוע יזדקק לגישה למערכות קריטיות. נכון, בד"כ ארגונים רבים ירצו למנוע מתן גישה נוסף למערכותיהם הקריטיות. ישנם כמה ארגונים בארץ שבמסגרת מדיניותם, סיסמאות למערכות קריטיות נשמרות במעטפות סגורות – ובתוך כספות. ארגונים אלה טוענים כי למרות הסרבול במדיניות זו – שיטה זו פועלת היטב עבורם. שימו לב שבשיטה זו קיימת אחריות כפולה:
כדי להבין את הפרדיגמה עמה אנו מבססים את תהליך פעולותינו, נדגים כיצד פועלים מכבי-האש עת לחיצת כפתור האזעקה; תחילה, כבאים שכבר מיומנים בזיהוי סממני שריפה מגיעים למקום – מפנים אנשים ומבצעים מעין פעולות זיהוי להמצאות בעירה. רק אח"כ, ורק האחראי על זירת האירוע – מורשה לאשר כניסה מחודשת לבניין – אם זה לצורך כיבוי או לצורך חזל"ש. כלומר, הצורך להיות מוכנים לתקרית – במינימום הוצאות מיותרות – מיושמת בפרדיגמה שכזו. תחילה, מגיעים גורמים מיומנים המזהים את המצב, סיטואציה – ורק אח"כ, האחראי הוא זה שקובע את המשך הטיפול. כך או כך, במצב זה, קיימים שני מנגנונים לזיהוי האירוע.
אין פסול בהתרעה מוקדמת, במיוחד אם עיקר תפקידך הוא להיות במצב ערנות. אך בארגונים רבים ובחברות גדולות, התרעות שווא מתורגמות להפסד כספי. אם תתריע לעתים קרובות ולאחר מכן תודיע "לא משנה, חשבתי שזה משהו רציני..." ובהנחה כמובן שלא תפוטר – סביר כי משל ה-"זאב, זאב" יחול עליך, ובעת אירוע משמעותי חמור – לא יתייחסו להתרעותיך ברצינות.
אקסיומה ברורה היא; אם אין אחראי = אין בכלל אחריות = קבלת החלטות שגויות. אם קיים אירוע בסגנון "אתה יכול לבדוק את זה?" – אין צורך להזעיק את כל צוות הטיפול שכן הצוות מיומן לפעולות חירום "של ממש". לכן, מומלץ לקיים תרגולים ואימונים למנהלי הרשת ו\או מנהלי אבטחת המידע לצורך טיפול באירועים קטנים כאלו.
מטפלי אירועי אבטחת מידע העובדים במשרה שאינה מלאה – צריכים לקבל משימות המאפיינות בדיוק את מה שמצפים מהם: איכות חקירה, קבלת אחריות, איסוף ראיות ויצירת תיעוד.
לאחר הקביעה כי אירוע מסוים הינו אלה תקרית אבטחה, יש לנקוט בצעדים ע"מ לבנות ראיות לעבירה פלילית ו\או אזרחית. יש לזהות בהקדם האפשרי עדים ולקבל מהם הצהרות בכתב בדבר מה שהם ראו או שמעו (שוב, בהקדם – כאשר הזיכרון נחשב "טרי").
בנק' זו, יש לקבל החלטה; האם לערב את רשויות החוק. החלטה זו נקבעת ע"י הדרג הניהולי אלא אם מצוין אחרת בנהלי החברה. קיימות לא מעט חברות שיחליטו להכיל את התקרית. במצב זה, קיימות שתי גישות: הגישה הראשונה היא להכיל את התקרית ולמגרה מידית – וזאת ע"מ לשמור על יציבות אמון הלקוחות של החברה. הגישה השנייה מציבה מטרה אחרת – למידה, מעין גישה של Watch and learn.
בכל אופן, יש לבצע גיבוי בינארי מלא של המערכת לפני שינוי או התעסקות עם רכיבים העלולים להוות ראיות.
טיפול באירוע יכול להיות פלילי או לא חוקי. לא מעט אנשי אבטחה המטפלים באירועי אבטחה מסתבכים בצרות בגלל החוק. לדוגמא, אם אתה חושד כי מישהו מוריד תכנים פדופילים – לא תוכל להוריד את אותם קבצים ולבחון אותם. בנוסף, יש צורך בנקיטת זהירות כדי לא לעבור על חוק הפרטיות. אם למשל אתה מייצג ספקית אינטרנט – אין לך את הזכות להעביר מידע אישי אודות הלקוח רק בגלל שמישהו טוען שאותו הלקוח ביצע עבירה כזו או אחרת.
רשלנות נקבעת במקום אחד – בית המשפט. ע"פ הגדרה, "רשלנות היא התנהגות שבמהלכה אדם גרם נזק מבלי שהיה מודע לטיב מעשיו, לנסיבות, או לתוצאות המזיקות של התנהגותו, כאשר האדם הסביר היה יכול להיות מודע לפרטים אלו בנסיבות דומות. שלא כבדיני הנזיקין, במשפט הפלילי אין די ברשלנות כדי להטיל אחריות פלילית, אלא אם יש הוראה מפורשת בחוק המתייחסת לעבירה הנדונה." במילים אחרות, חברות הפועלות באופן "סביר" להגנתן, קרי מייצרת נהלים וכללים ברורים – בדיעבד לאירוע – סביר להניח שההגדרה לא תחול עליהן.
כאשר מכילים את האירוע, דבר ראשון יש לאבטח את הסביבה. לאו דווקא באופן פיזי. יש לבצע גיבוי בכל המערכות המושפעות מהאירוע. אם הכונן הקשיח המקורי אינו יכול להוות ראייה (מפאת דרישה לזמינות וכו.) – יש להכין מס' עותקים של אותו גיבוי. עותק אחד יהווה ראייה ועותק שני לניתוח התקרית. בשלב זה, יש גם לקבוע האם לנתק את אותה מערכת ספציפית מהרשת או לנתק את הרשת כולה. בנוסף, יש לבצע שינוי מקיף של כל הסיסמאות – לא לפני שמבצעים גיבוי בינארי לכלל המערכות – וזאת בשביל למצק את הראיות כפי שהן.
אם וכאשר המערכת המסוימת נפרצה – ימים ספורים יעברו עד שכל האקר ברשת יעמוד בתור כדי לנסות להגיע לסיפוק לא ברור – וינסה לפרוץ לאותה מערכת. לכן, חשוב לא פחות למצוא את ערוץ הפריצה ולתקנו.
טריקים ישנים למיגור פריצות נשנות כוללים החלפת כתובת ה-IP ושינוי שם המערכת. לעתים הדבר עוזר אך לרוב, במיוחד כיום – ימצאו אתכם, No matter what.
סורקי חולשות, כגון Nessus, Nmap וכו., מסוגלים לזהות חולשות - הן ברשת הפנימית והן ברשת האינטרנט. קיימות תוכנות מסחריות (ומשום מה, גם יקרות) המעניקות יכולת זיהוי חולשות באופן מעמיק ביותר – ללא צורך בידע טכני מהותי. אם כסף מהווה מחסום, תמיד קיימת האפשרות לשכור מומחה המעניק שירותי בדיקה וסריקה – ולקבל באופן חד-פעמי דו"ח מפורט.
חשוב לי לציין כי Nmap הינה תוכנה בקוד פתוח וזמינה בחינם לכל דורש. באופן אישי הוא אחד החביבים עליי ובכלל – זהו כלי בעל עוצמה רבה.
זכרו, אחרי שטיפלתם (בהצלחה, או לא) במערכת נגועה, כל דבר נוסף שייהרס – יהיה באחריותכם. וודאו כי בעל המערכת מאשר כי היא (המערכת) חזרה לפעילות מלאה. עשו כל מאמץ לוודא כי המערכת עובדת כראוי לפני עזיבתכם ממקום האירוע.
ההחלטה האם להחזיר את המערכת לפעילות מלאה היא של בעלי המערכת. בתור איש אבטחת מידע המטפל באירוע, תוכל לתת עצות והמלצות אבל דה-יורה, ההחלטה היא של הבעלים.
לאחר השלמת הדו"ח, יש לקיים ישיבת צוות. המטרה העיקרית תהיה להגיע להסכמה בנוגע לכתיבת תמצית המנהלים (מה שבאמת מעניין את הדרג הניהולי) בדו"ח.
ומה לדעתכם הכי חשוב שיהיה בתמצית המנהלים? כמובן, כסף. כמה הארגון חוסך ומתייעל כאשר קיימים נהלים ופרוצדורות לטיפול בתקריות.
סביר להניח כי בעת כל תקרית, ייקרו טעויות. למדו מהן. שפרו את התהליכים שביצעתם וחזרו חלילה.
עד כאן להיום, חברים. הצגתי לפניכם את ששת צעדי היסוד בעת טיפול באירועי אבטחת מידע. זכרו כי הרעיון הוא להתאים את השלבים לצרכי הארגון\עסק שלכם.
להפתעתי, קיבלתי מיילים רבים המתייחסים לפוסטים שונים. המון תודה למי שטרח, התעניין ושלח לי הערות, שאלות ותגובות. בפוסטים הבאים אתמקד בנושאים יותר טכניים. עד אז, חג שמח וכשר לכולכם.
בפוסט זה אציג את ששת השלבים המוסכמים לטיפול והתמודדות עם\ב- אירועים (או ליתר דיוק – תקריות) בסביבות הדורשות אבטחת מידע. שימו לב למילה מוסכמים , שכן אין זה תקן, הוראה או חקיקה המבססים את סדר ומהות השלבים. שלבים אלה מהווים בסיס לאסטרטגיות פעולה ולכן ייעודם לשמש כמעין מצפן, מפה המנחה את איש\אשת אבטחת המידע בעת תקריות.
אני סבור כי רבים יסיקו כי ביצוע כל ששת השלבים, יעניק להם את הביטחון כי הטיפול בתקרית בוצע ביעילות ובאופן מקצועי. אין זה נכון וזהו לא הרעיון. ע"מ לטפל באירועים באופן מוצלח, אכן, יש לעקוב אחר השלבים אך בנוסף וביתר חשיבות, יש להתאים את אותם שלבים לארגון\עסק וכן לסוג התעשייה של אותו ארגון\עסק.
ששת השלבים\הצעדים בעת טיפול בתקרית אבטחת מידע הם (לפי סדר) :
- התכוננות – Preparation.
- זיהוי – Identification.
- הֲכָלָה – Containment.
- מיגור – Eradication.
- התאוששות – Recovery.
- הפקת לקחים – Lessons learned.
 |
| צעדי היסוד לטיפול באירוע אבטחת מידע |
התכוננות - Preparation
- תכנון הוא הכול. תכנון נכון הוא היסוד המנחה טיפול מוצלח באירוע לא מתוכנן. זכרו זאת!
- נהלים ומדיניות
- לכל ארגון ועסק קיימת גישה ע"פיה יש לטפל בתקריות. יש לעבוד ע"פ גישה זו.
- לא לשכוח כי קיימים נהלים בין-ארגוניים. לדוגמא, נהלים ומדיניות בין חברת-אם לבין חברות-בת.
- קבלת אישור ותמיכה מהדרג הניהולי.
- ציוות. בחירת אנשי המקצוע לטיפול בתקרית.
- זיהוי גורמים נחוצים מחוץ לארגון\עסק. לדוגמא, עורכי-דין, משטרה.
בנוסף, ההכנה צריכה להתחשב בסוגיות הבאות:
- האם בעת אירוע אבטחת-מידע – החברה תיידע את רשויות החוק או שמא תגיב בשקט.
- האם בעת אירוע אבטחת-מידע – החברה תמגר מידית את האירוע או שמא תכיל אותו, תלמד את מאפייניו, ותנסה ללקט ראיות.
חשוב שלצוות הטיפול באירוע תהיה משענת תומכת מהדרג הניהולי. לא נרצה שבזמן אירוע, יהיו ספקות לגבי החלטות ומהלכים שצוות הטיפול באירוע מקבל.
ציוות אנשים הוא מרכיב לא פחות קריטי בשלב ההכנה. יש חשיבות גבוהה ליכולת יעילה בעבודה בצוות. נתקלתי לא מעט בראשי-צוות שמעדיפים לעבוד "סולו", כגיבורים. לרוב, ההחלטות שיתקבלו במצב זה יהיו פזיזות והפתרונות שיוענקו לא יהיו יעילים.
אנחנו עדיין בשלב ההתכוננות;
- יש לעדכן את תכנית ההתאוששות מאסון.
- העריכו את צוות הטיפול. רצוי ומומלץ לתגמלם.
- יש להכין רשימת בדיקה (Checklist) ופרוצדורות.
- יש לוודא כי קיימת תכנית התקשרות בזמן חירום.
- יש לוודא כי סיסמאות ומפתחות הצפנה קריטיים יופקדו אצל גורם מהימן.
- חשוב ולא פחות – לבצע תרגולים.
סביבת מחשב הינה סביבה מורכבת. לא כל אחד יודע לתפעל את כל מערכות ה-UNIX ונגזרותיה. אף שיכול להיות לך ידע ורקע מוצק בסביבות אלו, אנחנו עדיין בני אדם, ומה לעשות – זיכרוננו מתעמעם עם הזמן. הכנת רשימות בדיקה, Checklists – המתארות כיצד להשבית או לגבות שרת כזה או אחר – יכול ובד"כ מסייע במניעת טעויות, ולא מן הנמנע שגם יפחית את המתח והלחץ בקרב צוות הטיפול.
אם עבדתם כמנהלי מערכת, אני בטוח שצקצקתם בלשונכם בכל פעם שנדרשתם ליצור חשבונות בעלי הרשאות ניהוליות הזמינים לאחרים. חרף זאת, בעת אירוע חירום, סביר כי המטפל באירוע יזדקק לגישה למערכות קריטיות. נכון, בד"כ ארגונים רבים ירצו למנוע מתן גישה נוסף למערכותיהם הקריטיות. ישנם כמה ארגונים בארץ שבמסגרת מדיניותם, סיסמאות למערכות קריטיות נשמרות במעטפות סגורות – ובתוך כספות. ארגונים אלה טוענים כי למרות הסרבול במדיניות זו – שיטה זו פועלת היטב עבורם. שימו לב שבשיטה זו קיימת אחריות כפולה:
- מנהלי המערכות צריכים לוודא כי המעטפות מתעדכנות תדיר.
- המפעילים, או במקרה שלנו – מטפלי האירוע, חייבים לעדכן את מנהל המערכת בכל שינוי שעשו, ומעל הכול – לעולם לא להשתמש בחשבון בעל הרשאות קריטיות ללא הסכמה מראש.
זיהוי - Identification
- איך מזהים אירוע\תקרית?
- היה מוכן להתריע בהקדם – אך אל תקפוץ מיד למסקנות.
- "זאב-זאב" ...
- חפש עובדות. כל דבר הניתן להסקה ללא עוררין.
- יידע את האנשים הנכונים.
כדי להבין את הפרדיגמה עמה אנו מבססים את תהליך פעולותינו, נדגים כיצד פועלים מכבי-האש עת לחיצת כפתור האזעקה; תחילה, כבאים שכבר מיומנים בזיהוי סממני שריפה מגיעים למקום – מפנים אנשים ומבצעים מעין פעולות זיהוי להמצאות בעירה. רק אח"כ, ורק האחראי על זירת האירוע – מורשה לאשר כניסה מחודשת לבניין – אם זה לצורך כיבוי או לצורך חזל"ש. כלומר, הצורך להיות מוכנים לתקרית – במינימום הוצאות מיותרות – מיושמת בפרדיגמה שכזו. תחילה, מגיעים גורמים מיומנים המזהים את המצב, סיטואציה – ורק אח"כ, האחראי הוא זה שקובע את המשך הטיפול. כך או כך, במצב זה, קיימים שני מנגנונים לזיהוי האירוע.
אין פסול בהתרעה מוקדמת, במיוחד אם עיקר תפקידך הוא להיות במצב ערנות. אך בארגונים רבים ובחברות גדולות, התרעות שווא מתורגמות להפסד כספי. אם תתריע לעתים קרובות ולאחר מכן תודיע "לא משנה, חשבתי שזה משהו רציני..." ובהנחה כמובן שלא תפוטר – סביר כי משל ה-"זאב, זאב" יחול עליך, ובעת אירוע משמעותי חמור – לא יתייחסו להתרעותיך ברצינות.
- קבע מי אחראי. מי המטפל העיקרי בתקריות.
- קבע האם אירוע כזה או אחר – הינה תקרית שיש לטפלה.
- אם ניהלתם פרויקט בעבר, סביר כי נתקלתם בקריטריון SMART. השתמשו בו.
- זהו ראיות או עדים אפשריים.
- בצעו גיבוי נקי של המערכת.
 |
| קריטריון SMART להשגת יעדים. האיור באדיבות psnz |
אקסיומה ברורה היא; אם אין אחראי = אין בכלל אחריות = קבלת החלטות שגויות. אם קיים אירוע בסגנון "אתה יכול לבדוק את זה?" – אין צורך להזעיק את כל צוות הטיפול שכן הצוות מיומן לפעולות חירום "של ממש". לכן, מומלץ לקיים תרגולים ואימונים למנהלי הרשת ו\או מנהלי אבטחת המידע לצורך טיפול באירועים קטנים כאלו.
מטפלי אירועי אבטחת מידע העובדים במשרה שאינה מלאה – צריכים לקבל משימות המאפיינות בדיוק את מה שמצפים מהם: איכות חקירה, קבלת אחריות, איסוף ראיות ויצירת תיעוד.
לאחר הקביעה כי אירוע מסוים הינו אלה תקרית אבטחה, יש לנקוט בצעדים ע"מ לבנות ראיות לעבירה פלילית ו\או אזרחית. יש לזהות בהקדם האפשרי עדים ולקבל מהם הצהרות בכתב בדבר מה שהם ראו או שמעו (שוב, בהקדם – כאשר הזיכרון נחשב "טרי").
בנק' זו, יש לקבל החלטה; האם לערב את רשויות החוק. החלטה זו נקבעת ע"י הדרג הניהולי אלא אם מצוין אחרת בנהלי החברה. קיימות לא מעט חברות שיחליטו להכיל את התקרית. במצב זה, קיימות שתי גישות: הגישה הראשונה היא להכיל את התקרית ולמגרה מידית – וזאת ע"מ לשמור על יציבות אמון הלקוחות של החברה. הגישה השנייה מציבה מטרה אחרת – למידה, מעין גישה של Watch and learn.
בכל אופן, יש לבצע גיבוי בינארי מלא של המערכת לפני שינוי או התעסקות עם רכיבים העלולים להוות ראיות.
הכלה - Containment
אוקי, התכוננו לתקרית, זיהינו אותה אבל מה עכשיו?
- המטפל באירוע ידאג לא להפוך את המצב לגרוע יותר.
- יש לאבטח את סביבת האירוע (מחשב, סביבת עבודה וכו.).
- יש ליצור גיבוי.
- (אפשרי אך לא נחוץ) ניתוק המערכת מהרשת כולה.
- שינוי סיסמאות.
טיפול באירוע יכול להיות פלילי או לא חוקי. לא מעט אנשי אבטחה המטפלים באירועי אבטחה מסתבכים בצרות בגלל החוק. לדוגמא, אם אתה חושד כי מישהו מוריד תכנים פדופילים – לא תוכל להוריד את אותם קבצים ולבחון אותם. בנוסף, יש צורך בנקיטת זהירות כדי לא לעבור על חוק הפרטיות. אם למשל אתה מייצג ספקית אינטרנט – אין לך את הזכות להעביר מידע אישי אודות הלקוח רק בגלל שמישהו טוען שאותו הלקוח ביצע עבירה כזו או אחרת.
רשלנות נקבעת במקום אחד – בית המשפט. ע"פ הגדרה, "רשלנות היא התנהגות שבמהלכה אדם גרם נזק מבלי שהיה מודע לטיב מעשיו, לנסיבות, או לתוצאות המזיקות של התנהגותו, כאשר האדם הסביר היה יכול להיות מודע לפרטים אלו בנסיבות דומות. שלא כבדיני הנזיקין, במשפט הפלילי אין די ברשלנות כדי להטיל אחריות פלילית, אלא אם יש הוראה מפורשת בחוק המתייחסת לעבירה הנדונה." במילים אחרות, חברות הפועלות באופן "סביר" להגנתן, קרי מייצרת נהלים וכללים ברורים – בדיעבד לאירוע – סביר להניח שההגדרה לא תחול עליהן.
כאשר מכילים את האירוע, דבר ראשון יש לאבטח את הסביבה. לאו דווקא באופן פיזי. יש לבצע גיבוי בכל המערכות המושפעות מהאירוע. אם הכונן הקשיח המקורי אינו יכול להוות ראייה (מפאת דרישה לזמינות וכו.) – יש להכין מס' עותקים של אותו גיבוי. עותק אחד יהווה ראייה ועותק שני לניתוח התקרית. בשלב זה, יש גם לקבוע האם לנתק את אותה מערכת ספציפית מהרשת או לנתק את הרשת כולה. בנוסף, יש לבצע שינוי מקיף של כל הסיסמאות – לא לפני שמבצעים גיבוי בינארי לכלל המערכות – וזאת בשביל למצק את הראיות כפי שהן.
מיגור - Eradication
- תקן את הבעיה עוד לפני השבת המערכת לאוויר.
- זהה וקבע נסיבות וסימפטומים.
- שפר את מערך ההגנה.
- בצע ניתוח חולשות (Vulnerability Analysis).
אם וכאשר המערכת המסוימת נפרצה – ימים ספורים יעברו עד שכל האקר ברשת יעמוד בתור כדי לנסות להגיע לסיפוק לא ברור – וינסה לפרוץ לאותה מערכת. לכן, חשוב לא פחות למצוא את ערוץ הפריצה ולתקנו.
טריקים ישנים למיגור פריצות נשנות כוללים החלפת כתובת ה-IP ושינוי שם המערכת. לעתים הדבר עוזר אך לרוב, במיוחד כיום – ימצאו אתכם, No matter what.
סורקי חולשות, כגון Nessus, Nmap וכו., מסוגלים לזהות חולשות - הן ברשת הפנימית והן ברשת האינטרנט. קיימות תוכנות מסחריות (ומשום מה, גם יקרות) המעניקות יכולת זיהוי חולשות באופן מעמיק ביותר – ללא צורך בידע טכני מהותי. אם כסף מהווה מחסום, תמיד קיימת האפשרות לשכור מומחה המעניק שירותי בדיקה וסריקה – ולקבל באופן חד-פעמי דו"ח מפורט.
חשוב לי לציין כי Nmap הינה תוכנה בקוד פתוח וזמינה בחינם לכל דורש. באופן אישי הוא אחד החביבים עליי ובכלל – זהו כלי בעל עוצמה רבה.
 |
| דו"ח סריקה טיפוסי של Nmap |
התאוששות - Recovery
- וודא כי בעת שחזור – אינך משחזר קוד נגוע (קרי קבצים ששונו בעת האירוע).
זכרו, אחרי שטיפלתם (בהצלחה, או לא) במערכת נגועה, כל דבר נוסף שייהרס – יהיה באחריותכם. וודאו כי בעל המערכת מאשר כי היא (המערכת) חזרה לפעילות מלאה. עשו כל מאמץ לוודא כי המערכת עובדת כראוי לפני עזיבתכם ממקום האירוע.
ההחלטה האם להחזיר את המערכת לפעילות מלאה היא של בעלי המערכת. בתור איש אבטחת מידע המטפל באירוע, תוכל לתת עצות והמלצות אבל דה-יורה, ההחלטה היא של הבעלים.
הפקת לקחים וקביעת המלצות
- צרו דו"ח. יש לנסות להשיג קונצנזוס אם מדובר בצוות.
- קיימו ישיבה ודונו על הלקחים שהופקו.
- קבעו המלצות ושלחו אותן לדרג הניהולי.
לאחר השלמת הדו"ח, יש לקיים ישיבת צוות. המטרה העיקרית תהיה להגיע להסכמה בנוגע לכתיבת תמצית המנהלים (מה שבאמת מעניין את הדרג הניהולי) בדו"ח.
ומה לדעתכם הכי חשוב שיהיה בתמצית המנהלים? כמובן, כסף. כמה הארגון חוסך ומתייעל כאשר קיימים נהלים ופרוצדורות לטיפול בתקריות.
סביר להניח כי בעת כל תקרית, ייקרו טעויות. למדו מהן. שפרו את התהליכים שביצעתם וחזרו חלילה.
עד כאן להיום, חברים. הצגתי לפניכם את ששת צעדי היסוד בעת טיפול באירועי אבטחת מידע. זכרו כי הרעיון הוא להתאים את השלבים לצרכי הארגון\עסק שלכם.
להפתעתי, קיבלתי מיילים רבים המתייחסים לפוסטים שונים. המון תודה למי שטרח, התעניין ושלח לי הערות, שאלות ותגובות. בפוסטים הבאים אתמקד בנושאים יותר טכניים. עד אז, חג שמח וכשר לכולכם.
