יום שני, 23 בפברואר 2009

ניהול יעיל של אבטחת מידע בעשור הראשון של המאה ה – 21 מרובת הרגולציות באמצעות הסמכה לתקן אבטחת מידע ת"י 27001

בהתקרב סיומו של העשור הראשון של המאה ה-21 מוצאים עצמם ארגונים רבים במדינת ישראל נאבקים בסיוט חדש: חובת הציות לערב רב של חוקים ודרישות רגולטוריות שבדרך זו או אחרת משפיעים על מערכות המידע בארגון.
לציית כמובן צריך. הסיכון שבאי ציות הנו העמדה לדין, שבסיומו עלול למצוא עצמו הארגון משלם קנס בן מאות אלפי ש"ח, סכום שבעתות הידוק החגורה עלול להיות מכה קשה וכואבת ובעיקר מיותרת.
אבל תהליך ההכנה של הארגון עלול להיות ארוך, קשה, מורכב ויקר. הסיבה העיקרית עלולה להיות שהארגון לא השקיע בעבר בנושא אבטחת מידע וכעת בטווח זמן קצר יחסית נאלץ לסגור פער גדול. באם ההתמודדות הייתה עם הוראה רגולטורית אחת, ניתן להתמודד באופן סביר. אלא שעל הארגונים בסקטורים השונים "מתנפלות" רגולציות שמספרן גדל והולך. חלקן "תוצרת הארץ".
החוקים עליהם מבוססת אבטחת מידע במדינת ישראל הנם:
1. החוק והתקנות להגנת הפרטיות. שני עדכונים מהותיים בחוק זה. האחד בשנת 1996 והשני בשנת 2005. עדכונים נוספים במהלך השנים שלאחר 2005. בימים אלה משגר רשם מאגרי המידע במשרד המשפטים הודעות על הפעלת הקנס המנהלי, וכדאי לשים לב לעניין זה.
2. החוק להסדרת הביטחון בגופים ציבוריים. בשנת 2005 עובר עדכון בעיקר על מנת לכלול את גופי התשתיות החיוניות (התוספת הרביעית לחוק).
רגולציות עיקריות במדינת ישראל:
1. הוראת המפקח על הבנקים לעניין ניהול תקין של טכנולוגיית המידע, משנת 2003. ההוראה חלה על תאגידים בנקאיים.
2. הוראת המפקח על הביטוח באגף שוק ההון במשרד האוצר לעניין ניהול סיכוני אבטחת מידע החלה על גופים מוסדיים (חברות ביטוח, וקרנות פנסיה וגמל).
חקיקה בעולם הרלוונטית לחלק מהארגונים במדינת ישראל:
1. חוק סרבנס-אוקסלי (SOX). הן המפקח על הבנקים והן המפקח על הביטוח אימצו את עקרונות החוק ומחייבים את הארגונים הסרים לפיקוחם לעמוד בחלק מדרישות החוק, למרות שאין במדינת ישראל חקיקה מחייבת לעניין זה.
רגולציות בעולם המחייבות חלק מהארגונים במדינת ישראל:
1. בזל II. רגולציה לסקטור הבנקאי שעיקרה ניהול סיכונים, בין היתר סיכונים תפעוליים. מרכיבי ניהול סיכוני טכנולוגיית המידע כלולים (עפ"י הגדרת המונח סיכון תפעולי) במסגרת הסיכונים התפעוליים.
2. PCI-DSS. רגולציה שמקורה בחברות כרטיסי האשראי. מטרתה לאפשר, בהתקיים תנאי סף מסויימים, לקבוע דרישות מינימום בתחום אבטחת המידע עבור סוחרים וספקי שירותים בעולם כרטיסי האשראי.
ארגון אשר רגולציה כזו או אחרת מושת עליו יפעל באופן כללי בצורה הבאה:
1. מיפוי הדרישות למול יחידות ארגוניות רלוונטיות בארגון. לדוגמה: דרישות לדירקטוריון, דרישות להנהלה, דרישות ליחידת טכנולוגיות המידע, דרישות למנהל אבטחת המידע וליחידתו וכד'. תוצר השלב: טבלת דרישות למול יחידות ארגוניות בארגון.
2. בחינת הדרישות בפועל – דוח סטאטוס המציג את הפער בין כל דרישה לבין המצב בפועל בארגון. תוצר השלב: דוח פערים עפ"י יחידות בארגון למול הדרישות.
3. תוכנית עבודה לסגירת/צמצום הפערים – כמקובל. כולל לו"ז, משאבים, סדרי עדיפויות , אחראים על הבצוע, אבני דרך ותהליכי דיווח ובקרה על התקדמות.
ככל שהחוק הנדון או הרגולציה מפורטת יותר כך הדרישות ברורות יותר, אבל בה בעת תהליך איתור הפערים מורכב וארוך יותר. כך גם תתארך לה מן הסתם "רשימת המכולת" להצטיידות לעמידה בדרישות.
בהינתן חקיקה/רגולציה חדשה (לאומית, או אימוץ דרישה בינלאומית) בהיקף של לפחות אחת לשנתיים, ימצא עצמו מנהל אבטחת המידע מהר מאד עוסק ללא הרף באיתור פערים למול דרישה שאיננה מתבססת ברוב המקרים על מתודולוגיה אבטחתית מספיק רחבת היקף, שכן חקיקה או רגולציה נולדים מתוך צורך לספק מענה להתרחשות ספציפית או רק לסקטור ספציפי..
והדוגמאות הרי הן לפניכם:
1. חוק הגנת הפרטיות להגנה של צנעת הפרט ללא התייחסות בכלל למידע עסקי,
2. חוק SOX (סרבנס-אוקסלי) לאמינות הדיווחים החשבונאיים, ולא לכלל מערכות המידע בארגון,
3. רגולציית בזל II מתייחסת רק לתאגידים בנקאיים,
4. הוראת המפקח על הבנקים לניהול תקין של מערך ה-IT בבנקים מתייחסת באופן ספציפי למספר מאד מצומצם של הבטי אבטחת מידע בבנקים. לדוגמה אין כל התייחסות להיבט האנושי.
5. הוראת המפקח על הביטוח לגבי גופים מוסדיים, חלה רק עליהם. בהמשך בדומה לסקטור הבנקאות תחול בסקטור הביטוח הוראת Solvency II העוסקת בניהול סיכונים בדומה לבזל II.
כל חקיקה או רגולציה הנה רלוונטית למקטע כזה או אחר, בין סקטוריאלי או בחתך אחר, אך עיקר הבעיה שאיננה רגולציה יחידה ובחלוף השנים הארגון מוצא עצמו נדרש לעמוד ביותר משתיים ואפילו שלוש חקיקות/רגולציות שונות בתחום אבטחת מידע ואבטחת טכנולוגיית המידע.
על מנת להימנע מהקשיים והעלויות הגבוהות אשר כבר נדרשות וימשיכו להידרש לכל הפחות בעתיד הקרוב ממעגלים גדלים והולכים של סקטורים, מומלץ לאמץ גישה שבה ניהול סיכוני טכנולוגיית המידע מתבסס על תקן אבטחת מידע בינלאומי, תקן 27001/27002.
תקן 27001/27002. הנו תקן לניהול סיכוני טכנולוגיית המידע האמור לספק מענה לכל סוגי הארגונים בכל מדינות העולם. ככזה ברור שאיננו מספק מענה ככתבו וכלשונו, ונדרשות התאמות החל מרמת המדינה, המגזר והארגון הספציפי. התקן אומץ ע"י מכון התקנים הישראלי ככתבו וכלשונו. היתרון המשמעותי של התקן הנו אי תלותו בסקטור או ארגון מסויים. בכך תהליך ההתייחסות לאבטחת מידע באמצעות התקן מחייב התאמתו לארגון הספציפי, תוך שילוב של דרישות חוקיות / רגולטוריות הרלוונטיות לאותה מדינה / אותו סקטור / ארגון. התקן מאפשר מתן מענה מותאם לכל ארגון בהיבטים הרחבים של ניהול סיכוני המידע והשימוש בטכנולוגיית המידע ומאפשר שילוב "תוך כדי תנועה" ושילוב תקופתי של רגולציות / חקיקות הן ברמה הלאומית והן ברמה הבינלאומית.
דווקא הליך זה מספק את הסיכוי המיטבי למימוש טוב, רחב ומלא של ניהול סיכוני טכנולוגיית המידע. התקן כולל את מכלול הדרישות לייסוד, הטמעה, הפעלה, ניטור, סקירה תחזוקה ושיפור של מערכת מתועדת לניהול אבטחת המידע בארגון. בכך כולל התקן למעשה את כל הבקרות אשר על הארגון להפעיל בנושא הטיפול בסיכוני סודיות, זמינות, שרידות, שלמות ואמינות של השימוש במידע ובטכנולוגיית המידע בהבטים הפיזיים, המחשוביים, האנושיים והתהליכיים לאורך כל מחזור החיים של השימוש במידע ובמערכות טכנולוגיית המידע. חשוב לציין שיש לשלב בתהליך מתחילתו את הדרישות החוקיות/רגולטוריות על מנת למנוע כפל/סתירה ביישום התקן.
התהליך הנדרש כולל על כן התאמה של מרכיבים רבים עפ"י המבנה, תהליכי העבודה ומרכיבי הטכנולוגיה בארגון ואיננו מאפשר כלל וכלל אימוץ אוטומאטי של דרישות.
כדוגמה ניתן לציין את החובה לבצע סיקרי סיכונים ע"י גורמים חיצוניים, מקצועיים ובלתי תלויים בהתאם להערכת הסיכונים של מערך טכנולוגיית המידע, ובתדירות כפי הנדרשת ע"י הרגולטורים, המפקח על הבנקים לתאגידים בנקאיים, והמפקח על הביטוח לגופים מוסדיים. לעומת זאת, בתקן לא קיימת חובה שהסקרים יבוצעו ע"י גופים חיצוניים. זו אחת האפשרויות אבל אין הכרח. על כן שילוב הדרישות במקרה זה יגדיר את תהליכי הביקורת הבאים: קיום הנהלים וביצוע הפעילויות המתחייבות מהם יכול להתבצע ע"י גורמים פנים ארגוניים (בלשון 27001: מבדק פנימי), בעוד שסקרי הסיכונים עצמם, המהווים את מבדק הבקרות האבטחתיות חייב להיעשות בידי גורמי חוץ עפ"י דרישת הרגולאטורים.
27002 הנה תורת האבטחה עפ"י מכון התקנים הבינלאומי, תורה שאומצה גם היא ככתבה וכלשונה ע"י מכון התקנים הישראלי. תורה זו מסבירה "מה כוונת המשורר" (מכון התקנים) בכל בקרה ובקרה המנוסחת ב-27001 וכיצד מכון התקנים מניח שיש ליישמה.
ראוי לציין ששני המסמכים מהווים התפתחות של שני מסמכים שהיוו את התקן הקודם ונודעו במספרם 17799. אלו התבססו על תקינה בריטית BS7799 מסוף העשור הקודם, אשר מקורה במסמכים פנימיים לניהול אבטחת המידע בחברת של הבריטית.
יישום התקן הכולל גם תהליך של הסמכה פורמאלית ומתמשכת של הארגון לתקן 27001 מהווה אם כך את "אבן הראשה" לציות לכל אחד מהחוקים/רגולציות ההולכים ומתפתחים החל מתחילת המאה הנוכחית ואשר באופן ישיר או עקיף מתייחסים לנושאי מידע וטכנולוגיית מידע.
המשמעות אם כך הנה שעל מנת להימנע מזעזועים גדולים שמשמעותם הקצאה לא מתוכננת של משאבים ומיקוד יתר לטווח קצר לנושאי ניהול סיכוני טכנולוגיית המידע (שיגרור לאחריו מיקוד חסר בטווחים הבינוני והארוך), על ארגונים להיערך להסמכתם לתקן אבטחת מידע 27001, וזאת מומלץ שיבוצע ככל האפשר בטרם יידרשו לעמוד בחקיקה/רגולציה מגזרית. תהליך כזה יביא את הארגון להתאמה אופטימלית של ניהול סיכוני המידע וטכנולוגיית המידע כאשר חקיקה/רגולציה ספציפית עשוייה בדרך כלל להוסיף אולי תוספת שולית (בעיקר התמקדות לסעיף זה או אחר, אך קשה להניח שתתווסף דרישה אבטחתית חדשה לחלוטין שלא נדרשה כבר ויושמה), אך לא לגרור את הארגון לפרוייקט במועד שלא תוכנן על ידו ובלוחות זמנים שעלולים לשבש תוכניות ארגוניות אחרות.

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

יום שבת, 14 בפברואר 2009

הבלוג בנוי משני מרכיבים

שלום לכולם,

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

יום שבת, 7 בפברואר 2009

לאן פניה של אבטחת המידע בפרוס שנת 2009

לאן פניה של אבטחת המידע?
כל תחילת שנה אותן הכותרות: יותר מודעות, יותר מנהלי אבטחת מידע, יותר כלי אבטחת מידע, יותר מהכל. כן, גם יותר פריצות, יותר איומים, יותר צרות. האם זה הגיוני, או שמשהו מאד, אבל מאד לא מתאים פה.
אבטחת מידע אמיתית נמצאת ככל הנראה במקום אחר:
1. אבטחה משולבת בתהליך פיתוח המוצר.
2. אבטחה המשלבת את גישת התוקף באופן אינטגראלי בתהליך, לאורך כל מחזור החיים.
שני אלו אינם מבוצעים הלכה למעשה וזהו לצערי סוף המחזה...
(1) לא מבוצע כיוון שגם היצרנים וגם הלקוחות אינם מעוניינים בשלב זה. שני סקרים שהתפרסמו בשנים 2005-2007 הצביעו על כך. באחד נבדקה רמת ירידת ערך המניה של חברות תוכנה יום לאחר פרסום vulnerability עם Patch. הסתבר שהמניה אומנם יורדת, אך לא מספיק. בתגובה לסקר זה אמר מי שהיה אז סגן נשיא אורקל לפיתוח: Time to market is more important than security
סקר דומה שנערך לגבי דעתם של הלקוחות (של מוצרי טכנולוגיית המידע) שנה ויותר לאחר מכן, הצביע על מגמה דומה. רק באם הכיס "יחטוף" מנה יותר רצינית (בדומה למה שחטפה מיקורוספט לאחר code red ו-Nimda, כאשר גרטנר יצאה בהמלצה לנטוש את IIS ולעבור ל-iPlanet ו-Apache... בחודש ספטמבר 2001), נראה שינוי בכיוון זה.
(2) לא מבוצע כי קיים קבעון מחשבתי מוחלט בין המגינים שרואים את תהליך ההגנה כמתחיל בנקודה מסויימת ומסתיים היכן שהרגולציה/חוק/BEST PARCTICE מסתיים. כל הקיימים והמוכרים היום בשוק האזרחי (הוראה 357, הוראה 257, PCI ,GLBA כל דבר) בנוי בדיוק בשיטה של מכאן ועד לנקודת הסיום. מה פסול בשיטה זו? התוקף מחוץ לתמונה בכל תהליך בניית תוכנית ההגנה. אבסורד מוחלט. מפניו מגינים, אבל את אופן התקיפה וצורת החשיבה שלו משאירים לסוף (אם בכלל). בסוף, זה מאוחר לשנות משהו ממשי בכל מערך ההגנה.
ואז מה עושה הפורץ? קורא וצוחק צחוק ענק. כי נקודת ההתחלה שלו, היא נקודת הסיום של עבודת המגן. על כן "כאילו" כל ההגנה שקופה. דומה לסוגי תקיפת Social Engineering, גם הם הופכים את ההגנה לשקופה...
האמריקנים עלו על הבעיה ומנסים לעשות משהו בנושא בשנה הקרובה. השאלה כמה זמן ייקח לסובב תעשייה שלמה לכיוון הנכון...
בנתיים, עושים מה שאפשר לעשות עם האמצעים הקיימים. זה יותר מאשר לא לעשות כלום, אבל זה לא ממש לייצר אבטחה אמיתית.
ולמרות האמור לעיל, שתהיה לנו שנה טובה ומאובטחת.
יאיר
הערת הכותב:
זוהי לי התנסות ראשונה בכתיבת בלוג, ומאמר ראשון בבלוג שלי.
הרבה שנים עסקתי בכתיבה של מסמכים עבור מעסיקי ועבור לקוחותיהם, שהם לקוחותי, וממשיך לעשות כן.
יחד עם זאת, חשבתי שהגיע הזמן גם לשתף את הקהל הרחב יותר במחשבותי.
מקווה שאהיה מקורי ומעניין. בת זוגתי העירה לי שייתכן ואתקל בדעות מנוגדות לשלי. עניתי שזו בדיוק אחת מהמטרות של כתיבת הבלוג. לשמש במה גם לדעותי וגם לדעות אחרות. זו הדרך הנכונה ללמוד, וכבר נאמר בעבר: מכל מלמדי השכלתי.