על קצה המזלג: מה חשוב לדעת על ISO 27001
חלק שני מתוך שלושה
מאת מאורו ישראל, חבר במועצה המייעצת של GSECTRA, מבקר ראשי ומוסמך ISO 27001
תכנן – בצע – בדוק – פעל
בשלב התכנון מכינים רשימה של כל השיפורים שמבקשים ליישם וקובעים תאריך יעד לכל שיפור. הרשימה אינה "פתוחה" משום שעלולים להחמיץ משהו או להתייחס יתר על המידה, או פחות מדי, לאחת הסוגיות. תקן ISO 27002 מסייע בכך. באמצעות 133 אמצעי בקרה לאבטחה מכסים את כל צרכי המערכת. אמצעי הבקרה מתארים את הדרישות אך לא מסבירים כיצד ליישם אותן. צריך לזכור שהיישום אינו חלק מהתקן. התקן אינו קובע "יש לרכוש פיירוול של Checkpoint"! הוא אומר "יש ליישם התקן להגנה על הרשת הפנימית מפני חדירות מבחוץ".
שלב התכנון נפתח בדרך כלל בניתוח סיכונים ומתמקד רק בסוגיות שמסייעות להתמודד עם הסיכונים ולצמצם אותם. אפשר גם להחליט "לקחת את הסיכון", "לעקוף את הסיכון" (למשל באמצעות ויתור על השירות – מקבלים החלטה להפסיק את השימוש ב-Wi-Fi או ב-Facebook) או "להעביר את הסיכון הלאה" (למשל באמצעות ביטוח).
בניתוח הסיכונים נלקחים בחשבון קריטריונים של זמינות, סודיות ושלמות. התוצר של הניתוח הוא כמובן הנתונים שעליהם יש להגן. ניתוח הסיכונים וצורת הניהול שלו אינם חלק מהתקן (ISO27001) אבל הם נדרשים כדי להוכיח שהשיטות מקוריות. אפשר להסתייע בתקן האופציונלי ISO 27005 כדי לערוך ניתוח סיכונים בצורה נכונה. יצוין כי תקן ISO 27001 הוא דרישת חובה לקבלת הסמכה. התקנים ISO 27002 או ISO27005 הם בגדר אופציה מומלצת.
לאחר שמתארים את התוכנית ואת ההיקף שבה תופעל, באמצעות מסמכי מדיניות אבטחה (דרישות) שמכסות 133 אמצעי בקרה, יש למנות אדם שיהיה אחראי לאבטחת המידע – למשל מנהל אבטחה ראשי – ולקבל תקציב ומחויבות ניהולית במסמך כתוב וחתום. את שלב הביצוע מנהלת מחלקת המיחשוב, אשר מיישמת את דרישות האבטחה באמצעות חומרה, תוכנה ונהלים.
לאחר מכן מגיע השלב החשוב ביותר, לדעתי: שלב הבדיקה. לאחר שהושלם היישום, צריך מישהו – מחוץ לתחומיה של מחלקת המיחשוב – לבדוק אם היישום עומד בדרישות שנקבעו בשלב התכנון. זאת באמצעות הליך ביקורת שמורכב משלושה שלבים, כמו בעולם החשבונאות: דרישות – שיטות אימות – ראיות.
אפשר להציב מאות דרישות במסגרת 133 אמצעי הבקרה לאבטחה. בביקורת לא בודקים שהאבטחה תקינה… אלא שהדרישות יושמו. התשובה יכולה להיות רק "כן" או "לא". אם התשובה היא לא, יתכן שמדובר ב-"ליקוי חמור", "ליקוי קל" או "הערה". "ליקוי חמור" משמעותו שבעקבות היישום, רמת ההגנה על המערכת מפני מתקפה גרועה מאוד. יתכן, למשל, שבביקורת התגלה שבחלק מהמחשבים לא פועלת תוכנת אנטי-וירוס… "ליקוי קל" משמעותו שהדרישה לא יושמה אך האבטחה לא נפגעה פגיעה קשה. יתכן, למשל, שסיסמאות מנהל המערכת לא הוחלפו במשך 6 חודשים. אין ספק שזה לא טוב אבל זה פחות חמור מהדוגמה הקודמת.
"הערה" היא ליקוי או יישום שאינם מתיישבים עם השיטות הטובות ביותר: יתכן, למשל, שהסיסמאות של המשתמשים כוללות רק שישה תווים ואינן משלבות בין אותיות למספרים. זה לא נורא משום שלמשתמשים יש סיסמאות סבירות, אבל בסופו של דבר הן לא יעמדו בפני מתקפה ממושכת מסוג Brute force attack. בשלב הפעולה, שניתן לכנות למעשה שלב התיקון, מתווים תוכנית פעולה לצמצום הליקויים. על התיקון של כל ליקוי מפקידים אחראי, מגדירים כיצד יתוקן הליקוי וקובעים תאריך יעד. את מפת הדרכים מגישים להנהלה כדי לקבל תקציב וכן הלאה….לאחר שמתחילים לסובב את גלגל דמינג – תכנן, בצע, בדוק, פעל – משפרים את האבטחה ויוצרים ניהול אבטחה של מערכות מידע כמוסבר בתקן ISO27001.
מאורו ישראל משמש כמומחה לאבטחת מידע מזה למעלה מ-25 שנים, ובין השאר עסק בקורסים להגברת המודעות לאבטחה, פריצה אתית וביקורות אבטחה. כיום מאורו הוא מומחה ידוע ברחבי העולם לאבטחת מידע, עורך בלוגים ומרצה.
