פוסט אישי

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

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

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

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

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

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

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

וכך באופן מקרי לחלוטין, נסגר לו מעגל.

ניהול אבטחת מידע - מה זה ניהול אבטחת מידע ומה מיקומה בארגון: חלק א'

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

את מה מנהל מנהל אבטחת מידע?
טוב , אז הרבה שאלות ותהיות וצריך כמובן להתחיל מאיזושהי פינה וללכת שלב שלב באופן סדור.
במאמר הראשון הדגמנו שבהתייחס להגדרה המאד מאד נפוצה ומקובלת של אבטחת המידע, דהיינו אספקת מענים ל-CIA (סודיות - Confidentiality, שלמות ואמינות - Integrity, זמינות ושרידות -Availability), מדובר ברוב רובם של המקרים בשלושה ראשי חץ שונים. אפשר להזיל דמעה ולהתאבל עד מחרתיים, מכרו לנו לוקש... ה-CIA הינה דרישה כוללת לארגון. כיצד זה ממומש זו כבר שאלה אחרת. זה ששכחו את הסיפא, איך מממשים זו אופרה אחרת. על כן ככל הנראה ישנם שלושה מנהלים שונים שמטפלים בנושא. אחד מטפל ב-C, אחד מטפל ב-I והאחרון מטפל ב-A.
ברוב רובם של המקרים אנו קוראים למנהל המטפל ב-C (סודיות), מנהל אבטחת המידע. זו טעות. הוא אחראי על הטיפול במרכיב הסודיות של אבטחת המידע. נוכל לקרוא לו מנהל אבטחת המידע רק ואך ורק אם הוא יהיה מנהל של כל שלושת המרכיבים, ה-C, ה-I וה-A.
אם הבעיה הזו לא מספיקה על מנת "להפיל אותנו לקרשים", הנה צצות שתי בעיות נוספות.
הראשונה אסקור בקצרה, ואז אתעלם מנה... ה-CIA איננו כולל את כל ניהול סיכוני השימוש במידע ובטכנולוגיית מידע. הלוואי שטיפול מלא ב-CIA היה הכל אבל זה לא. לדוגמה: הסיכון שמערכת שסודיותה מטופלת כיאות, הנתונים בה שלמים ואמינים והיא פועלת בזמינות הנאותה ואף הוגדרה בתוכנית להמשכיות לשעת עסקית, פשוט לא עושה את מה שהארגון חשב שהיא תעשה הינו סיכון נוסף ו-CIA לא מטפל בו... אמרתי ועזבתי את הבעיה הזו.
הבעיה השניה הינה שאם ניקח את התקן הישראלי/בינלאומי לניהול אבטחת המידע, 27001/27002 ונפרק אותו לרכיביו המעשיים, נראה שקיימת חלוקה נוספת על זו שכבר נגזרת מהגדרת האבטחה כפי שהוסברה לעיל.
מסתבר שישנן דרישות בתקן שעל מנת למלא אותן, צריך מנהל אבטחת המידע להיות לא פחות מאשר המנכ"ל, כיוון שעל מנת למלאן על מנהל אבטחת המידע להיות מנהל משאבי אנוש, שכן ישנן דרישות אבטחת מידע לשלבי גיוס כוח אדם, הטיפול בו במהלך עבודתו בארגון ולפני תום העסקתו. אח"כ מנהל אבטחת המידע צריך להיות גם מנהל הרכש, שכן ישנן דרישות המופנות לתהליך הרכש. בתהליך הרכש נרכשות טכנולוגיות מידע וטכנולוגיות אחרות להן השלכה על אבטחת המידע של הארגון. כמובן שמנהל אבטחת המידע צריך להיות גם קצין הביטחון, שכן קיימות דרישות למערך האבטחה הפיזי של הארגון. מנהל אבטחת המידע צריך להיות גם היועץ המשפטי של הארגון, שכן לא מעט מהתשתית לביצוע עבודתו הינם חוקים ורגולציות, לאומיים ובינלאומיים.
נשמע מופרך?
אז תאמינו או לא, היה כבר נסיון כזה במדינת ישראל. הוא נכשל.
בחוק הגנת הפרטיות הישראלי שנחקק בשנת 1981 והתקנות על פיו הותקנו בשנת 1986 נקבע כי מנהל המאגר הוא אחראי על אבטחת המידע במאגר המידע ומנהל המאגר הינו לא אחר מאשר מנהל הארגון. אומנם ניתנה לו הסמכות להסמיך מישהו אחר, אבל באם לא הסמיך הוא מנהל המאגר והוא האחראי לאבטחת המידע במאגר המידע. וסמכותו כוללת החל מאבטחה פיזית ועד לאבטחה במערך המיחשוב. זה לא הצליח.
בתיקון בשנת 1996 כבר הוסיפו את ממונה אבטחת המידע כאחראי על אבטחת המידע בנוסף על מנהל המאגר.
אז בואו נחזור לעולם המציאות.
ניהול אבטחת המידע הינו:
א. ברוב רובם של הארגונים ניהול של מרכיב ה-C – סודיות, במסגרת המשולש C – סודיות, I - שלמות ואמינות, A – זמינות ושרידות.
ב. איננו כולל אחריות ניהולית לדרישות בתחומי הרכש, כוח אדם (כולל מהימנות כוח האדם), ייעוץ משפטי וכיוצ"ב. בתחומים אלה אבטחת המידע הינה לכל היותר גורם מנחה המבקש כי דרישות אבטחת המידע בתחומים הללו ישולבו במסגרת תהליכי העבודה שהאחריות הניהולית לתהליכים אלו מסורה בידי מי שמנהל את התהליך. לדוגמה: מנהל משאבי אנוש לגבי תהליכים באגף משאבי אנוש.
ג. שני תחומים הינם יוצאים מן הכלל: ביטחון פיזי ובטיחות. אלו למעשה תחומים מקצועיים שמעמדם דומה למעמד אבטחת המידע. מעגל האבטחה הפיזי שמסופק לעובדים ולנכסים (עוד ללא התייחסות ספציפית לנכסי טכנולוגיית המידע), משמש בסיס לחלק מעבודתו של מנהל אבטחת המידע עצמו. לדוגמה: האבטחה שמסופקת ע"י מערך השומרים בבניין, אופן וסדרי עבודתם מספק אבטחה גם למחשבים בבניין. וזאת מבלי שמנהל אבטחת המידע דרש ולו דרישה אחת. יחד עם זאת, זה עשוי שלא להספיק באם מצוי בבניין אזור חשוב יותר, דהיינו מרכז חישובים, שלו יש להעניק תשומות אבטחה פיזיות מיוחדות. על כן, בתחומים אלו יש צורך בשיתוף פעולה של שלושת גורמי הניהול הללו על מנת ליצור שילוב אופטימאלי של רצף אמצעי אבטחה פיזיים ומיחשוביים בשילוב אמצעי בטיחות. יש לציין שככל שאנו מתקדמים על ציר הזמן, יותר ויותר אמצעי אבטחה פיזיים הופכים הם עצמם להיות דיגיטליים. לדוגמה: מצלמות. בעבר אנאלוגיות והיום דיגיטליות. במצב זה מוצא עצמו מנהל האבטחה הפיזית פורס אמצעי אבטחה שמנהל אבטחת המידע מנחה אותו כיצד יש להגן עליהם מפני תקיפות של פורצי מחשב. סימביוזה מעניינת.

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

1. ניהול אבטחת מידע הינו באופן מעשי ניהול של אחד ממרכיבי אבטחת המידע, מרכיב הסודיות. האם זה מעט מדי? ובכן ממש לא. על מנת לממש את מרכיב הסודיות, מנהל אבטחת המידע נדרש להיות מעורב בכל אחד מהמרכיבים הטכנולוגיים: ארכיטקטורת פריסת מערכת המידע, מערך התקשורת, מערכות ההפעלה בשרתים, בתחנות הקצה, היישומים, תהליכי העבודה, רמת החוסן של המערכת ועוד. מרכיב הסודיות הינו המרכיב רחב ההיקף הגדול ביותר מבין השלושה. זו אחת הסיבות שנדרש מנהל ייחודי ומקצועי לסעיף זה. אין זה בהכרח אומר שהוא הסעיף היקר ביותר.
2. שני המרכיבים האחרים מתחלקים בדרך כלל באופן הבא:
א. מנהל מערכות המידע אחראי על מרכיב ה-I (שלמות ואמינות), בעיקר עפ"י החלטות המתקבלות בשלבי הפיתוח של מערכות מידע חדשות, או תוך כדי עדכונן. מנהל אבטחת המידע עשוי לתרום לנושא. לדוגמה: באמצעות שילוב שימוש בכלים ייעודיים שהוא "נושא באמתחתו". חתימה דיגיטלית הינו אחד מהם. אך נחזור ונדגיש, מנהל אבטחת המידע איננו האחראי להשגת ושימור מרכיב ה-I במסגרת אבטחת המידע.
ב. מרכיב ה-A מתפצל מעשית לשניים:
§ מרכיב הזמינות, דהיינו יכולתה של מערכות טכנולוגיית מידע לספק שירות בשגרה בהתאם לרמת השירות שנקבעה עבורה. רכיב זה שהינו באחריות מנהל מערכות המידע מהווה פן תפעולי יומיומי של אחריותו.
§ מרכיב השרידות, דהיינו יכולתו של הארגון להפעיל את מערך טכנולוגיית המידע לאחר התרחשות אסון לדוגמה השבתת המערך עקב חדירת קוד זדוני, או חבלה פיזית או כל תרחיש אחר. בדרך כלל ובארגונים גדולים במדינת ישראל, מנהל בכיר ברמת חבר הנהלה נקבע כמי שאחראי לנושא זה ועל כתפיו פיתוח, יישום ותרגול התוכנית שקרויה כיום: התוכנית להמשכיות עסקית. Business Continuity Plan – BCP. מנהל מערכות המידע הינו איש המפתח בתוכנית זו בכל הקשור למערך טכנולוגיית המידע. יש לזכור שתוכנית BCP כוללת מרכיבים נוספים על מערכות המידע עצמן, כגון: היכן יעבדו העובדים בהינתן תרחיש שבו הנכס הפיזי (הבניין) נהרס או הפך לבלתי נגיש, מיהם העובדים שיעבדו, כיצד יינתנו שירותי משרד לארגון ועוד מגוון נושאים שאינם בתחום הידע והאחריות של מנהל מערכות המידע. מנהל אבטחת המידע ברוב המקרים איננו אחראי לתוכנית זו. אין זה אומר שאין לו תפקיד במסגרתה. ההיפך הוא הנכון. תפקידו לשלב את דרישות האבטחה בתוכנית בדיוק כפי שהוא עושה זאת במערך טכנולוגיית המידע הפועל בשגרה בארגון..
3. לגבי בטחון ובטיחות, שני תפקידי ניהול מקבילים לניהול אבטחת המידע אשר נדרשים לשיתוף פעולה הדוק ביניהם על מנת לאפשר מתן מענה משולב אופטימלי ויעיל.
4. הנחייה מטעם מנהל אבטחת המידע לשאר הגופים בארגון כגון משאבי אנוש, רכש וכד' באשר לדרישות אבטחת המידע (כפי שאלו נגזרים מתחום אחריותו) אשר הם מתבקשים לשלב בתהליכי העבודה שלהם כפי שהוגדרו בתחומי אחריותם.

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

ניהול אבטחת מידע - דבר המחוקק והרגולטור הישראלי בנושא - מאמר שני בסדרה

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

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

2. חוק הגנת הפרטיות 1996:
בשנים 1994-1996 בוצע תיקון רחב היקף בחוק הגנת הפרטיות, שנודע לימים כתיקון מס' 4. התיקון כלל הוספת דרישה למינוי "ממונה אבטחת מידע"
סעיף 17 ב לחוק קובע כי: הגופים המפורטים להלן חייבים במינוי אדם בעל הכשרה מתאימה (מה זה בדיוק, לא מפורט...) שיהיה ממונה על אבטחת מידע (להלן - הממונה):
(1) מחזיק בחמישה מאגרי מידע החייבים ברישום לפי סעיף 8;
(2) גוף ציבורי כהגדרתו בסעיף 23; (גם זה לא בדיוק ברור מיהם כל הגופים הציבוריים. על כן, מנהל אבטחת מידע גש ליועץ המשפטי של הארגון בו הינך עובד וקבל מענה בדוק אם הארגון הוא גוף ציבורי כהגדרתו בסעיף 23 כן או לא...)
(3) בנק, חברת ביטוח, חברה העוסקת בדירוג או בהערכה של אשראי.
מבלי לגרוע מהוראות סעיף 17, הממונה יהיה אחראי לאבטחת המידע במאגרים המוחזקים ברשות הגופים כאמור בסעיף קטן (א).
לא ימונה כממונה מי שהורשע בעבירה שיש עמה קלון או בעבירה על הוראות חוק זה.
מדובר בציון דרך חשוב בתולדות העיסוק באבטחת מידע במדינת ישראל.
הייתה זו הפעם הראשונה שהמחוקק בחקיקה ראשית חייב ארגונים גדולים, שבהם כמויות מידע גדולות למנות גורם מקצועי שיקבל אחריות על אבטחת המידע האישי באותם ארגונים. מקוצר היריעה לא אכנס לכל הפרטים, כמו גם למשמעות המעשית בשטח. אבל כן, זה היה ניצן ראשון של התפתחות העיסוק בנושא בצד האזרחי של מפת המיחשוב במדינת ישראל.
המעניין הוא שאין דרישה למינוי ממונה על הגנת הפרטיות. אז נתפסה אבטחת המידע והגנת הפרטיות כאותו הדבר. היום אנו כבר יודעים שנדרשים שני בעלי מקצוע שונים.

3. חוק להסדרת הביטחון בגופים ציבוריים - 1998:
שנתיים לאחר קבלת התיקון בחוק הגנת הפרטיות המגדיר תפקיד חדש בחלק מהארגונים במדינת ישראל, תפקיד הממונה על אבטחת המידע האישי המוגן עפ"י החוק והתקנות להגנת הפרטיות, מתקבל בכנסת החוק השני המרכזי לענינינו, החוק להסדרת הביטחון בגופים ציבוריים.
החוק קובע כי גוף ציבורי הינו "כל גוף המנוי בתוספות, ולגבי משרד ממשלתי המנוי בתוספות – לרבות יחידות הסמך שלו;"
ממונה ביטחון הינו "מי שמונה על פי חוק זה להיות אחראי על ארגון פעולות אבטחה ועל
הפיקוח עליהן בגופים המפורטים בתוספות"; ומי שמונה יהיה כפוף במישרין למנהל הגוף הציבורי או לסגנו.
פעולות אבטחה מוגדרות כ"פעולות לשמירה על בטחונו של אדם, בטחון הציבור או בטחון המדינה, לרבות שמירה על רכוש. לענין גופים המנויים בתוספות הראשונה והשניה – גם פעילות לאבטחת מידע שחשיפתו עלולה לפגוע בבטחון המדינה וכן פעולות למניעת פגיעה בכל אחד מאלה."
ובמילים פשוטות, מינו את קצין הביטחון של גופים ציבוריים כגון : משרדי הממשלה, רשויות ממשלתיות, חברות התשתית (מקורות, חברת חשמל, בזק ועוד. נא לזכור אנו
ב-1998, לא 2011!!!) כאחראי לאבטחת המידע הביטחוני בגופים אלו.
אין סתירה בין חוק הגנת הפרטיות ובין החוק להסדרת הביטחון בגופים ציבוריים. עוסקים בסוגי מידע שונים בתכלית השינוי. הראשון במידע אישי, השני במידע ביטחוני.

4. בנק ישראל, המפקח על הבנקים, הוראת ניהול בנקאי תקין מס' 357 – ניהול תקין של טכנולוגיית המידע - 2003 :
עוברות חמש שנים עד שמשתנה משהו במגזר האזרחי. המפקח על הבנקים רואה את הפער בין הגנת הפרטיות ומי שממונה עליה בבנק "ממונה אבטחת המידע" ובין הצרכים האמיתיים של הבנק בהתמודדות למול האיומים והסיכונים ההולכים ונערמים. אנו כבר בעידן האינטרנט וחיבור לקוחות למערכות המידע הבנקאיות, ונדרש בעל מקצוע שיהיה לו גם תואר וגם מעמד בכיר מספיק על מנת לקדם את הנושאים בבנק. נפתח עידן "מנהל אבטחת המידע" במדינת ישראל.
הגדרת אבטחת מידע חסרה ברגולציה זו, אם כי היא ניתנת להצגה מזווית אחרת, זווית המענה הנדרש, כפי המופיע בהוראה:
תאגיד בנקאי יישם אמצעי אבטחה פיזית ולוגית למניעה, גילוי תיקון ותיעוד של חשיפות במערך טכנולוגיית המידע ודיווח עליהם בהתאם להערכת הסיכונים ותוך התייחסות גם להיבטים הבאים:
1. זיהוי ואימות (אלו סוגי בקרות אבטחת מידע בתחום המניעה)
2. סודיות ופרטיות (מרכיב ה-Confidentiality במודל ה-CIA).
3. שלמות ומהימנות הנתונים (מרכיב ה- Integrity במודל ה-CIA).
4. מניעת הכחשה (סוג בקרה בתחום הגילוי והתיעוד).
קיבלנו דרישות בתחומים הפיזיים והמחשוביים בקטגוריות מניעה, גילוי תיקון ותיעוד בנושאי CI, אין A. זו איננה טעות. נושא הזמינות והשרידות קיים בהוראה, אבל הוא איננו חלק מאבטחת מידע. ואכן במערכת הבנקאית במדינת ישראל, נושא הטיפול בתוכנית להמשכיות עסקית (שהוא מענה השרידות) איננו בתחום האחריות של מנהל אבטחת המידע של התאגיד הבנקאי.
ההוראה דורשת מהנהלת תאגיד בנקאי למנות "מנהל אבטחת מידע" שיהיה כפוף לחבר הנהלה (כן הוא יכול להיות כפוף למנהל מערכות המידע בבנק ובתנאי שזה האחרון חבר בהנהלת הבנק). הדירקטוריון וההנהלה חייבים לקבוע ולאשר מדיניות לניהול טכנולוגיית המידע שהפרק הראשון בה הוא "אבטחת מידע". הרגולטור לא כתב איך יראה מסמך המדיניות כולו, או פרק אבטחת המידע, והשאיר זאת לבנקים עצמם.
ומה קורה עם הממונה לאבטחת המידע מחוק הגנת הפרטיות שהתאגידים הבנקאיים חוייבו למנות בשנת 1996? שוב מקוצר היריעה ניתן לומר בקיצור שאין בעיה. מנהל אבטחת המידע עפ"י הרגולציה יכול למלא גם את תפקיד הממונה. ומה עם הגנת הפרטיות נשאל? בבנקים ישנו תפקיד "קצין ציות", זה היה באחריותו ונשאר באחריותו.
אם נבחן מהי ההשפעה הישירה של המהלך בהיבט הרוחבי של על מגזרי המשק, אזי לדעתי ההשפעה שולית כיוון שמדובר במספר מצומצם של ארגונים, תאגידים בנקאיים במדינת ישראל שחלקם כבר מינו מנהל אבטחת מידע והוא כבר היה כפוף לחבר הנהלה. מסיבה זו איננו יוצר שינוי דרמטי בנוף הניהולי של אבטחת המידע. גם בתוך הבנקים, מקצתם מצייתים להוראה ככתבה וכלשונה עוד טרם שיצאה לאור, מקצתם יצייתו ומקצתם "מתחכמים". בואו נשאיר את "מנהל אבטחת המידע" בדרג נמוך ונגדיר ערוץ היררכי חדש " מנהל מקצועי למנהל אבטחת המידע" המנהל המקצועי הוא חבר הנהלה, אבל מנהל אבטחת המידע מאחר והוא מנהל זוטר, מנהלו איננו חבר הנהלה... טריק חמוד שתוך כמה שנים נעלם מהנוף.
הערה נוספת: הוראה זו איננה, אני חוזר ומדגיש איננה נקודת מוצא מספקת לנושא אבטחת מידע בתאגיד בנקאי. היא הוראה כללית לניהול תקין של טכנולוגיית המידע ובתחום אבטחת המידע עוסקת במספר מאד מאד מאד מצומצם של נושאים.
אין בכך כדי לגרוע מחשיבות פריצת הדרך בנושא ניהול אבטחת מידע כמו גם נושאים ממוקדים נוספים בתחום אבטחת המידע, כגון, הערכת סיכונים, סקרי בטיחות, בנקאות בתקשורת.

5. החוק להסדרת הביטחון בגופים ציבוריים עדכון לחוק (מס' 2) משנת 2005:
הצעת התיקון לחוק הוגשה בשנת 2002. התיקון התקבל רק בשנת 2005. מכיוון ש"תוך כדי" נכנס הנושא של אבטחת מערכות מיחשוב חיוניות שלא היה בתכנון המקורי של תיקון מס' 2 לחוק זה. על כן שינוי שמטרתו הייתה רק לתקן ולשפר הפך להיות אבן הראשה של מהפיכה של ממש בניהול אבטחת מידע במדינת ישראל.
על כן, ניתן לומר כי מהותו של השינוי הינה הכללת נושא ההגנה על מערכות ממוחשבות חיוניות, אשר באותה העת עדיין פעלו כולן בגופים ציבוריים ועל כן המיקום הנאות של הנושא היה בחוק הנ"ל.
בדברי ההסבר להצעת החוק נכתב כי: "מוצע להבחין בין "פעולות אבטחה פיזית", הכוללות פעולות הנוגעות לשמירה על ביטחונו של אדם ועל הרכוש במבנה של הגוף הציבורי, לבין "פעולות אבטחת מידע" הנוגעות לשמירה על מידע מסווג המצוי בידי הגוף הציבורי; המונח "פעולות אבטחה" כולל את שני סוגי הפעולות; אבחנה זו נדרשת כדי להבהיר את חלוקת האחריות בין המשטרה לשב"כ באשר למתן הנחיות מקצועיות ביחס לגופים המפורטים בתוספת השניה לחוק ולהבהיר כי הנחיות מקצועיות שענינן אבטחה פיזית יינתנו על ידי נציג המשטרה ואילו הנחיות מקצועיות שענינן אבטחת מידע יינתנו על ידי נציג השב"כ. (סעיף 7 לחוק המוצע)
הנוסח שהתקבל לבסוף בחוק הינו:
"פעולות לאבטחת מידע - פעולות הדרושות לשם שמירה על מידע מסווג של גוף ציבורי או מידע כאמור המצוי אצלו, וכן פעולות למניעת פגיעה בכל אחד מאלה";
ו"פעולות לאבטחת מערכות ממוחשבות חיוניות - פעולות הדרושות לשם שמירה על מערכות ממוחשבות, שגוף שהסמיכה הממשלה קבע שהן מערכות ממוחשבות חיוניות, על מידע האגור במערכות אלה ועל מידע מסווג הקשור למערכות אלה, וכן פעולות למניעת פגיעה במערכות או במידע כאמור;"
ממונה הביטחון, דהיינו קצין הביטחון של הגוף הציבורי נותר האחראי על אבטחת המידע (אם כי מהנוסח של המילים בחוק לא לגמרי ברור מהו "מידע מסווג" או "מידע כאמור המצוי אצלו" אלו דורשים פרשנות משפטית) וישנו תפקיד נוסף: "הממונה על הפעולות לאבטחת מערכות ממוחשבות חיוניות".
ישנה גם חלוקת עבודה מסודרת בין גופים מנחים, משטרה, שב"כ, מלמ"ב.
אלא שכאן מתחיל ריבוי של בעלי אחריות לאבטחת מידע בחלק מהגופים הציבוריים במדינת ישראל.
גוף ציבורי שיש לו מידע אישי (בכולם יש) והוא גם כלול בהגדרת גוף שיש לו מערכות ממוחשבות חיוניות יש לו עכשיו שלושה אחראים לאבטחת מידע:
1. ממונה לאבטחת מידע עפ"י חוק הגנת הפרטיות שאחראי על אבטחת המידע האישי. התקנות העומדות לרשותו מעודכנות באותה השנה 2005, אבל אויה! העדכון הינו מינהלי ולא טכנולוגי. מהיכן ישאב ידע מקצועי לביצוע עבודתו? מהתקנות משנת 1986??? בעיה!
2. קצין הביטחון האחראי על המידע המסווג ביטחונית באותו הגוף הציבורי. הנחיות מקצועיות יסופקו לו מגורמי ביטחון הרלוונטיים.
3. ובאם הוחלט שיש צורך למנות אחראי להגנת המערכות הממוחשבות החיוניות אז יש סיכוי שיהיה מנהל שלישי. וההנחיות לאבטחת המידע כאן יסופקו שוב ע"י גורם ביטחוני..
עברו 6 שנים, נוספו והורדו גופים והניהול הכפול והמשולש ממשיך לו.

6. הוראה לניהול סיכוני אבטחת המידע של הגופים המוסדיים המפקח על הביטוח באגף שוק ההון של משרד האוצר – ספטמבר 2006
ושוב חוזר הכדור למגזר האזרחי. במשך כשנתיים ובעקבות ההוראה של המפקח על הבנקים, פועל המפקח על שוק ההון להכיל על מגזר הביטוח הוראה המטפלת באבטחת מידע לחברות הביטוח. הוראה לובשת ופושטת צורה ומתרחבת לכלול לא רק את חברות הביטוח אלא את "הגופים המוסדיים" מונח הכולל בנוסף לחברות הביטוח את קופות הגמל וקרנות ההשתלמות.
אבטחת המידע בהוראה זו תטפל בנושאי זמינות ושרידות (Availability), אמינות שלמות ודיוק (Integrity) וסודיות (Confidentiality).
בהיבט ניהול אבטחת המידע המצב דומה להוראה של המפקח על הבנקים ומשפרת אותה.
סעיף 2.1.3 בהוראה קובע כי:
א. הנהלת הארגון תמנה את אחד מחברי ההנהלה בעל כישורים מתאימים, בכפיפות למנכ"ל אשר יהיה ממונה על נושאי אבטחת המידע בארגון (להלן – "הממונה"). אין בהוראה זו כדי לפגוע בחובת מינוי ממונה לפי סעיף 17ב לחוק הגנת הפרטיות.
ב. הממונה יהיה אחראי על פיקוח ובקרה על הפעילות המתבצעת בתחומי אבטחת מידע וכן על בקרה על תכנית עבודה בנושא אבטחת המידע בהתאם למדיניות אבטחת המידע של הארגון.
ג. הנהלת הארגון תמנה מנהל אבטחת מידע שיהיה כפוף לממונה בנושאי אבטחת המידע בארגון ותעמיד לרשותו את המשאבים הדרושים לניהול אבטחת מידע.
כלומר ישנה היררכיה:
1. מנהל אבטחת מידע שיוכל לתפקד כי הארגון נדרש להעמיד לרשותו המשאבים לכך.
2. מנהלו הינו חבר הנהלה (כפוף למנכ"ל) שיש לו אחריות במסגרת ההנהלה לאבטחת מידע.
אין פגיעה בממונה אבטחת המידע עפ"י חוק הגנת הפרטיות
בדרך כלל אין כפל תפקידים ומנהל אבטחת המידע והממונה על אבטחת המידע הינם אותו אדם.
במהלך אוגוסט 2010 מתפרסם מסמך "ניהול טכנולוגיות מידע בגופים מוסדיים" המספק מעטפת רחבה של ניהול טכנולוגיית המידע בגוף מוסדי וכך נותן קונטקסט להוראתו הקודמת שעסקה רק באבטחת המידע.

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

מסקנות:

1. המסקנה העיקרית לדעתי היא שנדרש שהמחוקקים והרגולטורים יחשבו על הגופים אשר כפופים לרגולציות/חקיקות הללו וישקלו שקול היטב כיצד למזער את הבלבול הניהולי של נושאי משרות מנהלי/ממוני אבטחת המידע.
2. לא בכל חקיקה /רגולציה נושא הניהול מפורט בצורה ברורה. ניהול מכיל:
א. את המיצוב הארגוני של נושא המשרה. שלושה מהארבעה שמים דגש ומציבים עמדה ברורה בעניין זה. חוק הגנת הפרטיות איננו מתייחס לסוגיה זו כלל וכלל. ווידוי אישי: כותב שורות אלה היה אחד ממעצבי הסעיף הזה בשנת 1996 בתיקון לחוק הגנת הפרטיות בתפקידו כנציג משרד הבריאות בישיבות וועדת החוקה חוק ומשפט שדנה ועיצבה את נוסח התיקון לחוק עד להבאתו להצבעה בכנסת. ראינו אז הישג ענק בהשגת המטרה של קיבוע בחקיקה ראשית את עצם החובה למנות איש מקצוע לאבטחת מידע במערכות הציבוריות הגדולות, בנקים וחברות ביטוח. לא הקדשנו אז מחשבה מספקת לנושא מיקום הממונה.
ב. את תחומי האחריות במישור CIA (סודיות, שלמות ואמינות, זמינות ושרידות) ובמישור אבטחה פיזית למול אבטחת המחשבים. חוק הגנת הפרטיות מתייחס למעשה לכל ה-CIA וכוולל התייחסות לדרישות לאבטחה פיזית ומיחשובית, חוק להסדרת הביטחון נחזה להתייחס ל-C בלבד וקיימת הפרדה בין פעילות אבטחה פיזית ופעילות אבטחת מידע, הוראת המפקח על הבנקים לC ול-I בלבד ומחייבת אספקת מענה פיזי ומיחשובי, והוראת המפקח על הביטוח שוב לכל ה-CIA. גם הוראה זו מתייחסת לפן הפיזי והמיחשובי.
אתם מוזמנים להשוות את סעיף ב עם הסיום של הפוסט הראשון ולראות שבפועל המציאות קצת שונה.
לנושא האבטחה הפיזית למול אבטחת מערכות טכנולוגיית המידע אתייחס באחד מהפוסטים הבאים.

ניהול אבטחת מידע - במה יעסקו הפוסטים.ולהתחלה: CIA בין תאוריה למציאות

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

לפני שניגש לניהול אבטחת המידע יש לברר ביתר דיוק מה זה בדיוק "אבטחת מידע".
נוח להתבסס על התקן הישראלי הבינלאומי ISO 27001. בתקן זה נקבע כי אבטחת מידע הינה: "שמירה על חסיון, כלילות (INTEGRITY) וזמינות של מידע..."
הגדרה זו מקבילה לתפישה הרווחת של שלושת עמודי התווך של אבטחת המידע:
סודיות - Confidentiality
אמינות ושלמות - Integrity
זמינות ושרידות - Availability
וכל העוסק בנושא יודע מזה עשרות בשנים לדקלם: אבטחת מידע זה CIA. יופי נחמה...
אלא מאי?
אבטחת מידע איננה מושג מופשט, מדובר בתהליך ארגוני שיש לנהלו.
האומנם זהו תהליך אחד?
לכאורה כן, שנינו ולמדנו: אבטחת מידע זה CIA... נכון, אבל...
יש חלוקת אחריות מאד ברורה וטבעית של שלושת האותיות הללו.

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

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

זמינות ושרידות - Availability
אני מרשה לעצמי לפרק את נושא ה-Availability לשני תת נושאים: זמינות (Availability) ושרידות (Survivability).
זמינות ממש אבל ממש לא קשורה לאבטחת המידע. זמינות הינה דרישה תפעולית לשימוש השוטף במערכות המידע. זמינות טובה הינה פועל יוצא של תכנון נכון של עומסים על מערך התקשורת, יכולות העיבוד, מהירויות זיכרון וכדומה. בז'רגון המקצועי נקרא לכך: Capacity Planning. מעולם לא היה באבטחת מידע. זהו תחום מקצועי של מערכות המידע, ומתחלק בין הפיתוח והתפעול. נ-ק-ו-ד-ה.
שרידות יכולה להיות קשורה לאבטחת מידע, אלא שבפועל בארגונים הגדולים בישראל זה בדרך כלל לא. השרידות מורכבת משתי תוכניות:
א. "תוכנית להמשכיות עסקית – Business Continuity Plan"
ב. "תוכנית התאוששות מאסון – Disaster Recovery Plan"

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

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

מה בין רגישות המידע במערכת ובין חיוניותה של המערכת (קריטיות המערכת)

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

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

ונחזור לעניינינו בפוסט זה.
רגישות מידע במערכת או סודיות המידע במערכת הינו מדד לעוצמת הנזק שתגרם לארגון אם מידע מסווג של המערכת ייחשף בפני מי שאיננו זכאי להיחשף אליו, ויהיה זה גורם פנימי או חיצוני. הנזק הינו בעצם חשיפת המידע לבלתי מורשה והוא בלתי הפיך. מידע מסווג שנחשף לגורם לא מורשה = נזק. ניתן לבצע הערכת נזקים (לכמת כמה נזק נגרם), אך לא ניתן להחזיר את המצב לקדמותו, המידע כבר מצוי גם ברשות הגורם האחר.
חיוניות (קריטיות) המערכת הינה עד כמה הארגון יכול לתפקד ללא אותה המערכת מאחר וזו הושבתה, לאחר שעבדה ושירתה את הארגון. סיבת השבתתה איננה רלוונטית לרמת חיוניותה. במידה והארגון התכונן כראוי לאירוע כזה (התכונן כראוי, משמע, הגדיר מהו משך הזמן המכסימלי שיכול לסבול אי פעולת המערכת, כיצד פועל בזמן שהמערכת מושבתת, כיצד מתכונן להעלאת המערכת בתום הזמן המכסימלי שיכול לפעול בלעדיה וכיצד מפעיל את המערכת לאחר חלוף פרק הזמן המכסימלי לאי פעילותה). נזק נגרם, אך במסגרת ניהול משברים זהו נזק שנלקח בחשבון וניתן לו המענה שהוגדר מראש.
מעיון בשני ההסברים לשני הנושאים, סודיות מידע במערכת וחיוניות מערכת ניתן להבין שמדובר בשני פרמטרים בלתי תלויים האחד בשני. אם כך הוא הדבר, אזי אמורים להימצא ארבע קטגוריות שונות של מערכות:
1. מערכת שבה המידע מסווג והמערכת חיונית לתפקוד השוטף של הארגון. (מסווגת וחיונית).
2. מערכת שבה המידע מסווג ואיננה חיונית להתנהלות השוטפת של הארגון. (מסווגת ולא חיונית)
3. מערכת שבה המידע איננו מסווג והיא חיונית להתנהלות השוטפת של הארגון. (חיונית ואיננה מסווגת)
4. מערכת שבה המידע איננו מסווג והמערכת איננה חיונית להתנהלות השוטפת של הארגון. (איננה חיונית ואיננה מסווגת)
נראה דוגמאות לארבע סוגי המערכות:
1. במערכת בנקאית, המערכת באמצעותה מבצע פקיד הבנק את פעילותו כאשר מולו יושב לקוח, (נהוג לקרוא למערכת מרכזית זו "המערכת הסניפית"). הפעילות של הפקיד כרוכה בגישה למידע הלקוח המצוי במחשבי הבנק ומן הסתם זהו מידע המוגן עפ"י החוק להגנת הפרטיות כמידע על מצבו הכלכלי של אדם, דהיינו, מידע מסווג. יחד עם זאת, באם המערכת מושבתת בשעות שבהן אמור הסניף לעבוד, הפקיד איננו מסוגל לשרת את הלקוח, על כן, זו מערכת חיונית להתנהלות העסקית השוטפת של הבנק.
2. מערכת השכר של הארגון. במערכת נאגר מידע המוגן עפ"י החוק והתקנות להגנת הפרטיות, מידע על מצבו הכלכלי של אדם, דהיינו, מידע מסווג. יחד עם זאת, במידה ומערכת השכר מושבתת ומדובר בטווח התאריכים שבהם חובה עפ"י החוק לשלם שכר לעובדים, ניתן לשלם להם את שכרם גם מבלי שהמערכת תפעל. לדוגמה, באמצעות העברת מקדמה בגובה לדוגמה השכר הקודם. כאשר המערכת תחזור לפעול, יבוצעו החישובים המדוייקים וישולם הפרש הכולל לדוגמה שעות נוספות וכד'.
3. מערכת המציגה את שערי הבורסה במהלך המסחר בבורסה. המידע איננו סודי, ההיפך הוא הנכון, מטרת הצגת המידע הינה להנגישו לציבור. יחד עם זאת השבתת המערכת עלולה לגרום להפסקת המסחר בבורסה מכיוון שהמידע על שערי המניות הנסחרות הינו חיוני לתהליך העסקי של קניה ומכירה של מניות בבורסה.
4. מערכת המאפשרת עריכת חישובים פיננסיים מפורטים למטרות סימולציה בלבד. אין בה כל מידע מסווג ובאם איננה פועלת מאחר ומדובר בסימולטור בלבד אין פגיעה בתהליך העסקי העיקרי של הארגון.
הדוגמה ממחישה היטב (לדעתי) את העובדה שסודיות המידע במערכת וחיוניותה של מערכת הינם שני פרמטרים בלתי תלויים.
ישנו גם הבדל בולט נוסף:
לסודיות ישנו ביטוי מוחשי ומעשי למול משתמשים. הסיווג מוצג באמצעות כותרת מילולית. לדוגמה: "סודי-אישי". הכותרת מודפסת על דוחות או על תווית המודבקת על מדיה מגנטית או אופטית ניידת או על מחשב נייד/SMARTPHONE. מטרתה פשוטה ותכליתית: להגדיר באמצעות הכותרת ובאמצעותה בלבד את כל תכולת המדיה נושאת הכותרת בהיבט סודיות המידע, וזאת ללא כל צורך לעיין בתכולה עצמה. גורם מוסמך בארגון יכול על כן להגדיר בפשטות מהן דרישות ההגנה לאותו נשא מידע בהתאם לכותרת וללא צורך להכיר תכולה ספציפית של כל דוח מודפס/מחשב נייד/מדיה מגנטית או אופטית ניידת.
לחיוניותה של מערכת אין כל צורך ליצור כותרת. אין זה מעניינו של משתמש במערכת להכיר את חיוניותה של המערכת. עליו להכיר כיצד הוא עובד במערכת בשגרה ומהם תהליכים חלופיים במידה והמערכת מושבתת. אין ולא אמור להיות לכך ביטוי בצורת כותרת למערכת או למדיה מגנטית או אופטית ניידת המהווה מרכיב שבו נעשה שימוש במערכת.

אחרי החדשות בשבועות האחרונים נראה שבאמת אין אבטחת מידע

תקיפות מקוונות ניתנות לחלוקה לארבע קטגוריות עיקריות:
1. תקיפות להשגת רווח כספי. אלו מבוצעות בעיקר ע"י פושעים (כולל פשע מאורגן) ויעדיהן אתרים פיננסיים כדוגמת בנקים או חברות סליקת כרטיסי אשראי, או אתרים שבהם מתבצעת פעילות כספית.
2. תקיפות ע"י גורמי מדינה או סוכנויות ביון למטרות מגוונות. ביניהן ניתן למנות:
א. איסוף מידע מודיעיני באמצעות שתילת קוד זדוני המשמש כאמצעי האזנה או דלף מידע באופן כלשהו,
ב. פגיעה במערכות שלטוניות כדוגמת אתרי ממשל זמין של מדינות.
ג. פגיעה במערכות המחשוב של תשתיות חיוניות (כדוגמת מתקפות על מערכות ביטחוניות, תעשייה ביטחונית, כורי
גרעין ומערכות הולכת חשמל).
בהקשר זה יש לציין שהמונח "תשתיות חיוניות" שונה ממדינה למדינה ומשתנה גם במהלך השנים. כך למשל בארה"ב הכריזו במהלך שנת 2010 על החברות המייצרות את רכיבי התשתית לתחנות הכוח החשמליות (דודים, טורבינות וכד') כחלק ממגזר התעשייה המשוייך גם הוא לתשתיות חיוניות.
3. "האקטיוויסטים" שמטרתם להציג עמדות פוליטיות ויעדם עשוי להיות מגוון מטרות בהתאם לסוג הקבוצה. לאחרונה קבוצת פורצים המכונה אנונימוס פעלה כנגד חברת SONY וממשלת טורקיה אשר לדברי קבוצת הפורצים פועלת לאכיפת צנזורה מקוונת.
4. אלה שעושים זאת "בשביל הכיף" או פשוט "להראות להם" שאין להם אבטחת מידע. בשבועות האחרונים קבוצת פורצים המכנה עצמה LulzSec עולה לכותרות בשל פעילות פריצה ברמה יומית.
נראה שבשבועות האחרונים, כאילו כל ארבע הקבוצות שבעבר פעלו כל אחת בזמנה היא והותירו לנו "מרווח נשימה" כלשהו בין תקיפה לתקיפה, החליטו "בינן לבין עצמן" שהגיעה העת "לשבור שגרה" או "לשבור את האשלייה של אבטחת מידע" לרכז מאמצים ולהראות כל אחת ממניעיה היא ש"אין אבטחת מידע".
התקיפות על Codemasters ו-Citibank משוייכות לקטגוריה הראשונה. בתקיפה על Citibank, כ-360,000 לקוחות הבנק יודעו שחשבונותיהם מצויים בסיכון אחרי שפורצים בלתי מזוהים זכו לגישה לנתוניהם. לדברי הניו יורק טיימס הפריצה ל-CitiBank התאפשרה עקב כשל אבטחה בסיסי ומביך מאד באתר הציבורי הבנק. לדברי הידיעה, לקוח לגיטימי שהתחבר לחלק האתר שבו מזינים מספר החשבון בכתובת הדפדפן, יכול היה לשנות את מספר החשבון ולקבל נתוני חשבון אחר. הפורצים השתמשו במחולל מספרי חשבון וכך השיגו פרטיהם של מאות אלפי לקוחות.
תקיפת מערכות המחשוב של קרן המטבע הבינלאומית משוייכת ככל הנראה לקטגוריה השנייה. כך גם התקיפות שבוצעו על יצרנית מוצרי אבטחת המידע RSA (בחודש מרץ) שגררה וגוררת אחריה שרשרת של פגיעות בחברות מהגדולות בארה"ב ובעולם לייצור אמצעי לחימה מתקדמים כגון חברת לוקהיד-מרטין (יצרנית מטוס העתיד של חיל האוויר הישראלי, ה-F-35) וחברת L3. חברת החדשות FOX הודיעה ב-1 ליוני כי חברת גרומן יצרנית מערכות לחימה אמריקאית גדולה נוספת החליטה לפי שעה לא לאפשר יותר גישה מבחוץ למערכותיה. האם זה נקיטת אמצעי זהירות לפני (תוצאה אפשרית של תהליך ניהול סיכונים) או מסקנה של אחרי (תוצאה אפשרית של תהליך ניהול משברים). השימוש באמצעי הזדהות השונה מקוד משתמש וסיסמה כדוגמת האמצעי שנמכר ע"י חברת RSA נפוץ יותר בשימוש בגישה מרחוק למערכות הארגון, ופחות נפוץ בשימוש יומיומי בהזדהות מקומית ברשת הפנימית של הארגון.
שניים מארבעת הבנקים הגדולים באוסטרליה (ANZ ו-Westpac) הודיעו כי יחליפו את רכיבי ההזדהות החזקה של RSA ללא עלות ללקוחותיהם. הבנק השלישי (Commonweal) הודיע כי הוא שוקל את צעדיו והבנק הלאומי של אוסטרליה ממלא פיו מים (בנתיים)...
הערה: בשנת 2005 פירסמה חברת Yankee Group מחקר שהצביע שכמות הפגיעויות במוצרי אבטחת מידע מתקרבת לכמות הפגיעויות במוצרי התשתית של טכנולוגיית המידע (מערכות הפעלה ובסיסי נתונים) שמוצרי האבטחה אמורים להגן עליהם. ועל כן, על יצרניות מוצרי האבטחה להיערך לספק טלאי אבטחה למוצריהן באותו האופן שיצרניות מוצרי טכנולוגיית המידע נערכו. באותה המידה על לקוחות מוצרי טכנולוגיית ואבטחת טכנולוגיית המידע להיערך גם הם בהתאם. כעת עברו 6 שנים ועלינו מדרגה. על יצרניות מוצרי אבטחת המידע לוודא כי רמת האבטחה בחברתן מספקת על מנת שניסיון פגיעה בהם לא יפגע בלקוחות שרכשו את מוצריהן.
כאמור פעילותה של אנונימוס מזוהה עם הקטגוריה השלישית. הם עלו לכותרות לפני מספר חודשים כאשר פגעו בחברות כרטיסי אשראי וחברות סליקה אשר הודיעו שיפסיקו לספק שירותים פיננסיים לויקיליקס, עקב בבדלפות של מסמכים סודיים.
קבוצת LulzSec מזוהה (בשלב זה) עם הקטגוריה הרביעית. כמות הפריצות הנזקפות "לזכותה" עולה מיום ליום בקצה מסחרר. פריצה למערך הבריאות האנגלי (NHS), לאתר הסנאט של ארה"ב, לשלוחה של ה-FBI (Infragard), ובעצם נראה שהם יפרצו "לכל מה שזז".
למרות שהנזקים מהפריצות של שתי הקבוצות המשוייכות לקטגוריות השלישית והרביעית מזעריים לעומת נזקי הקבוצות הפועלות בקטגוריות הראשונה והשנייה, דווקא הן אלו התופסות את הכותרות.
ייתכן ובכך על הארגונים לשנות במשהו את ההתייחסות המזלזלת (יחסית) לסיכון הקרוי "סיכון תדמיתי".
סיכון תדמיתי איננו כלול בסיכוני אבטחת המידע הקלסיים: סודיות (Confidentiallity), שלמות ואמינות (Integrity), זמינות ושרידות (Availability). גם הרבה יותר קשה, עד בלתי אפשרי לכמת אותו.
התוצאה הכוללת הינה ש"אין אבטחת מידע". כמות הפריצות עולה בכל יום. אין יום בלי דיווחי פריצה מסוג זה או אחר. אין יום כתבתי? משעה לשעה הולכים ומתרבים דיווחי הפריצה בכל יום. זה איננו (FUD-(Fear Uncertainty Doubt שבהם הואשמו יועצי ומנהלי אבטחת המידע, כאילו הם סתם צועקים "זאב, זאב", אבל כלום בעצם לא קורה... זו המציאות. יהיו הסיבות אשר יהיו, חוסר מקצועיות, רשלנות, זדוניות, שילוב תקיפות מסוגים שונים, מה שתרצו. זה כבר לא משנה.

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

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

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

כך זה לא יכול להימשך.

Why Information Technology Security (referred henceforth as ITS) isn't a success story after so many rules, standards and regulations?

This post will be written in the English language as it will be used for a dual purpose:

1.As an answer to Mr. William Beer, Director of PwC London and Leader of Pwc's OneSecurity Practice, who was one of the speakers in the Tel-Aviv University conference on "Cyber warfare – international, political and technological challenges" that took place on June 9th. The title of his talk was: "Cyber - New rewards and risks to businesses and governments. Why a different approach is needed".

2.To be able to reach more audience than only the Hebrew readers of my posts.

I'll appreciate it very much to get readers comments on this post.

As a matter of fact, I believe the question has two answers.
The first is easy for me to write, as I'm quite sure about it.
For the second I have some speculations and I would like to read your remarks to my post, before I'll write mine.

Question: Why don't we have good ITS?

1.BECAUSE NO ONE REALLY WANTS IT. AMAZING. Don't you think?

This needs of course an explanation. So here it comes.
To achieve good ITS you have to invest money and time. These two elements are critical factors in a super fast growing need for more and more Information Technology, as this is the engine that drives modern society. No one argues that the correct starting point to integrate ITS should be the development phase of a product. Adding ITS to an IT product during that phase, and I mean what we professionals call "SECURITY by DESIGN" will achieve products with a much better ITS when they are deployed. BUT, you have to pay with MONEY and TIME. The product will be more expensive to develop and it will take more time to bring the product from the beginning of the development phase to selling it on the market. This means: BIG TROUBLE for ITS. The first magic phrase in the Information Technology world is "Time To Market". Only if a product developer MUST but really MUST add ITS he'll sacrifice "Time to Market" for "Better security". The same goes for the second magic phrase "Lower Costs" or its equivalent "Return On Investment". Consumers of Information Technology buy with the pocket. They're after cheaper products with better ROI. Adding ITS in the development phase makes the product more expensive for buying. (At that phase no one includes the costs of future security vulnerabilities/patch management etc.) As to ROI, this is a controversial issue for itself and I'm not going to handle it in this post.
What is the "really must" I mentioned before? Money. If the product maker will loose money because of not enough ITS in the product, it might make a difference for him. What might be "Not enough ITS"? Obviously, vulnerabilities discovered in the product when it is used by customers.
During the previous decade numerous of surveys and a lot of research was done and published around the subject that can be called: "How much will IT makers suffer for not having good ITS in their products"?
One of the important and leading works on the subject was a paper titled: "Impact of Software Vulnerability Announcements on the Market Value of Software Vendors – an Empirical Investigation" presented at the Fourth Workshop on the Economics of Information Security held on the campus of Kennedy School of Government Harvard University 2 - 3 June 2005.
Link to the paper: http://infosecon.net/workshop/pdf/telang_wattal.pdf

Link to a securityfocus article about the paper: Study: Flaw disclosure hurts software maker's stock http://www.securityfocus.com/news/11197

The study analyses the financial impact on the stock price value of SW makers following the announcement of a vulnerability in one of the company's product.
The bottom line could be summarized as follows:
Most of the announcements were followed by the SW maker's stock falling compared to NASDAQ market average. BUT, "…The researchers did show that, compared to the effect of other types of product related defects, the disclosure of software flaws seems to have the least impact…" and even more disturbing data comes ahead: "…The two researchers found that the 0.63 percent decrease fell below the estimated 2.1 percent drop in the stock price of companies that were victims of public security breaches, or the estimated 0.81 percent drop in the stock price of auto makers that recalled their vehicles."
To conclude the bad news for ITS in SW makers here is the response of Amit Jasuja, vice president of product management for database maker Oracle's security group cited in the aforementioned securityfocus article: "So even if there is a connection between public vulnerability disclosure and stock price, the penalty for having vulnerabilities may not be high enough to convince product managers to spend more time on security".
A year or so later comes the second blow, as a survey showed that the customers of the IT product makers favor too "Time to Market for IT products" over "Better security but later on the market".

To conclude: The market forces don't give good ITS a fare chance. NO ONE HAS ENOUGH INTEREST.

In this case, there is only one way left: outside intervention.
Who can do it?
Governments by enacting laws, other statutory institutions by passing regulations, standards institutions by creating new standards. Seems to be a perfect solution. We have in the last years a lot of laws, regulations, standards on the market. All about ITS. So why doesn't the situation improve significantly?

The answer, to my opinion is that most of all these effortsare aimed at the "end of the chain", the CUSTOMER of the Information Technology products and not aimed primarily at those that stand in the beginning of the chain, e.g. the HW and SW makers. Vulnerabilities in products are not a result of how the customer implements the SW. It is the SW itself that is the cause. But, to my best knowledge NO government has enacted a rule that puts a fine of lets say 1,000,000 $ for each vulnerability found in a piece of SW product.
Lots of rules exist to punish institutions that their Information Technology infrastructure has been breached whatever the cause is and confidential data stolen. Other rules fine for not implementing parts of legislation. Who are the only punished institutions?
The Information Technology CUSTOMERS. Only they.
Why is it so?
I'm waiting for your suggestions before writing the 2nd reason. Maybe you have an idea.