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

בפוסט שנקרא: " ניהול אבטחת מידע - מה זה ניהול אבטחת מידע ומה מיקומה בארגון: חלק א' " (מדצמבר 2011), הצגנו את הפער שבין המתודולוגיה הצרופה, אבטחת מידע הינה טיפול בנושאי סודיות, שלמות ואמינות, זמינות שרידות (Confidentiality – Integrity – Availability), לעומת המציאות שבה מנהל אבטחת המידע אחראי בפועל בחלק גדול מהארגונים רק על היבטי הסודיות (Confidentiality).

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

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

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

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

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

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

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

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

סטוקסנט, תוכנה ייעודית לפגיעה ברכיב פיזי במקרה זה צנטריפוגות במתקן העשרת אורניום באירן. בשנת 1982 ה-CIA פעל באופן דומה והחדיר תוכנה זדונית לרכיב SCADA שברה"מ גנבה/קיבלה מהמערב. התוכנה הזדונית גרמה לפיצוצו של צינור הולכת הגז הרוסי מסיביר לאירופה, פיצוץ השווה בעוצמתו לחמישית עוצמת הפיצוץ שהחריבה את הירושימה. הפיצוץ גרם לפגיעה קשה בכלכלה הסובייטית המתמוטטת.
מי שמחפש באינטרנט, ימצא את הסיפור תחת הכותרת: The Farewell Dossier
https://www.cia.gov/library/center-for-the-study-of-intelligence/kent-csi/vol39no5/pdf/v39i5a14p.pdf

וירוס להבה, תוכנת ריגול שהושתלה במחשבים אירניים ואחרים על מנת (ככל הנראה) לקבל מידע מקדים לקראת תקיפת סטוקסנט ותקיפות אחרות. גם במקרה זה אין חדש. מי שקרא את הספר "העין של וושינגטון" שבו נחשפת פרשת חברת Inslaw ותוכנת PROMIS (התוכנה הובאה לארץ ע"י כך נטען רפי איתן) מבין שכאז כן עתה, ארגוני ביון/ריגול עושים שימוש ביכולות (או בכשלים) של מערכות מחשוב למיצוי מידע ולשיגורו לגורמים אחרים.
באינטרנט יש הרבה מידע. אפשר להתחיל מויקיפדיה ומשם להמשיך...
http://en.wikipedia.org/wiki/Inslaw

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

1. הארגון והעולם החיצון:
1.1. עבודה מבחוץ לתוך מערכות המידע הארגוניות. השינוי המשמעותי ביותר הינו שרוב תהליכי העבודה אשר בעבר בוצעו רק כאשר המשתמש במערכת המידע מצוי בתוך חצרי הארגון (בלשון מערכות המידע: עובד ברשת הפנימית) מופעלים היום גם או רק כאשר המשתמש מצוי מחוץ לחצרי הארגון (בלשון מערכות מידע: עובד מבחוץ אל תוך הרשת הפנימית של הארגון).
1.2. המשמעות האבטחתית: ה-FIREWALL הארגוני, זה החוצץ בין הרשת הפנימית והעולם החיצון מאבד את משמעותו הייחודית. מירב הפעילות הלגיטימית מתבצעת מבחוץ לתוך הארגון. העולם החיצון, על כל איומיו וסיכוניו הופך לחלק מהארגון.
2. הארגון ורכיבי טכנולוגיית המידע:
2.1. שימוש ברכיבי טכנולוגיית מידע שלא בבעלות הארגון. מתרבה השימוש ברכיבי טכנולוגיית מידע שהמשתמש הינו בעליהם ולא הארגון. הכינוי לכך: Bring Your Own Device. הרכיב המוביל את השינוי הינו הסמארטפון. רכיב המשלב תקשורת סלולרית, מחשוב, GPS ועוד.
2.2. המשמעות האבטחתית: רכיב שאיננו בבעלות הארגון לא מוכלת עליו מדיניות אבטחת מידע ארגונית. הרכיב עלול להכיל תוכנות זדוניות שונות שיפגעו בארגון בעת חיבורו לרשת הארגונית. וגם, מידע מסווג ארגוני שיישמר עליו לא בהכרח יהיה מוצפן ועל כן לא מוגן מפני חשיפתו לבלתי מורשים.
3. מנהל אבטחת המידע, רכיבי טכנולוגיית המידע והמתקפות:
3.1. רמת הידע של מנהל אבטחת המידע על מצבם של רכיבי טכנולוגיית המידע הניגשים למערכות המידע הארגוניות והמתקפות עליהם ועליו. למרות אמצעי האבטחה הרבים, רכיבי טכנולוגיית מידע עלולים להיות מודבקים בתוכנות זדוניות מסוגים שונים. ללא יכולת קבועה של ידיעת מצבם של רכיבי טכנולוגיית המידע הניגשים למערכות המידע הארגוניות, ומעבר לכך, מצב המתקפות הקיימות והמתוכננות עליהם, מנהל אבטחת המידע נותר מגיב לאירועים שכבר התרחשו (אבטחה ריאקטיבית) ולא "מכין תרופה למכה" (אבטחה פרואקטיבית).
ומהם המענים שמנהל אבטחת המידע נדרש ליישם כעת ובעתיד הקרוב:
1. גישה דינמית לניהול סיכוני טכנולוגיית המידע
על מנת לספק מענה לשתיים מהבעיות שהוצגו לעיל, העולם החיצוני בתוך הארגון והשימוש ההולך ומתרבה ברכיבים שאינם בבעלות הארגון יש צורך בפרדיגמה חדשה של ניהול סיכוני טכנולוגיית המידע.
נקודת המוצא הינה שבסיכומו של יום, קיים משתמש אנושי אשר בידיו מצוי רכיב טכנולוגי כלשהו, המבקש גישה למערכת מידע ארגונית באמצעות תווך תקשורת כלשהו על מנת לבצע מטלה מסוימת בשימוש בנתוני הארגון.
מודל האבטחה הדינמי מממש מבדק ומענה בזמן אמת מהו הסיכון אליו נחשף הארגון בעת ביצוע גישה של משתמש קצה וכיצד מצמצמים את הסיכון. מדובר ביצירת "מטריצת איום" המתבססת על חישוב האיום שמייצר כל אחד מהרכיבים הנוטלים חלק בתהליך: 1-מקור הגישה: (א)-ציוד הקצה, (ב)-המשתמש, (ג)-המיקום בו מצוי הציוד, 2-תווך התקשורת, 3-יעד הגישה: (א)-רכיבי ה-IT, (ב)-מסד הנתונים, (ג)-צורת הגישה, (ד)-מטרת הפעילות. כבר היום מצויים בידינו מענים חלקיים. יש להשלים את המלאכה. חברת אינטל החלה בשנת 2009 בפרויקט חומש ל-5 שנים בנושא זה.
2. אבטחת מידע מבוססת מידע
אבטחת מידע איננה שונה מתחומי העיסוק האחרים בארגון. אם אנו מדברים היום על לדוגמה, רפואה מבוססת מידע, אזי באותו האופן יש לדבר על אבטחת מידע מבוססת מידע. במישור הארגוני עליו מופקד מנהל אבטחת המידע מדובר בשני נושאים:
1. נתונים על הדבקת רכיבי טכנולוגיית המידע המתקשרים למערכות המידע הארגוניות או על התרחשויות במערכות המידע הארגוניות.
2. מידע על מתקפות צפויות על רכיבי טכנולוגיית המידע בארגונו או בסקטור שאליו משתייך ארגונו.
נושאים אלו מטופלים כבר היום באמצעות כלי SIM ואיתור רכיבים נגועים באמצעות כלי מודיעין ייעודיים. יש להעמיק ולשכלל פעילויות אלו.

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

בפוסט זה אחרוג ממנהגי הקבוע ונקודת המוצא הינה אישית, אבל בסופו אקשור הנאמר לפוסטים האחרונים בתחום סיכוני טכנולוגיית המידע.
ביום שבת צפיתי בסרט בערוץ National Geographic. סרט עוסק בטביעתה של הטיטאניק וכותרתו: הטיטאניק – תיק סגור – Titanic – closed case. הסרט הינו מסעו של אדם אחד, ההיסטוריון והחוקר טים מלטין לחקר ההתרחשויות שהובילו לאסון טביעת הטיטאניק. הסרט מבוסס על ספר שנכתב על ידו: A very Deceiving Night.
אז מה חדש בסרט הזה?
הוא מנסה (ולדעתי מצליח) להסביר מה באמת קרה שם בלילה ההוא לפני 100 שנה.
הוא מפזר את ענן המסתורין סביב אולי השאלה החשובה ביותר. אבל בגלל חשיבותה כולם דלגו מעליה בצורה כזו או אחרת.
המונח שבלב העניין הוא "זמן ההתראה". והנה השאלה:
מה היה זמן ההתראה הצפוי בתנאי הראות שהיו באותו לילה לגבי קרחון בסדר גודל שהטיטאניק התנגשה בו? שהרי הסכנה הייתה ידועה, הוצבו תצפיתנים מיומנים, כולנו קראנו וראינו זאת. אבל אף אחד לא אמר לנו עד עכשיו, מה היה הצפי של פעולתם?
יש לציין ששני הצופים שהיו במשמרת בלילה ההוא שרדו את האסון, נצלו ועדויותיהם קיימות.
המענה הניתן בסרט הינו שזמן ההתראה הצפוי היה, נא לקרוא היטב: 20 דקות! זמן מספיק על מנת לסובב את הספינה ולמנוע התנגשות.
אז למה בפועל כפי שכולנו קראנו וצפינו זה ממש אבל ממש לא מה שקרה בפועל? זמן ההתראה ועד לתחילת ההתנגשות היה פחות מדקה (55 שניות ליתר דיוק).
איך ניתן להסביר את העובדה הזו?
קל לומר: הם לא היו ערניים, היו שתויים או כל מיני סיבות שאינן ענייניות. על מנת לקבל תשובה טובה צריך לרדת לפרטים. זה קשה, זה לוקח זמן וזה אולי לא תמיד הכי "תקשורתי". אבל חקר האמת חיוני על מנת להפיק את הלקחים הנכונים.
המענה נעוץ בחקירה יסודית של הרבה רישומים. עדויות ניצולי הטביעה (יש כאלו), עדויות של רב חובל ומספר אנשי צוות שהיו על אנייה שהייתה סמוכה מאד לטיטאניק (קליפורניאן), תיעוד רישומי אניות אחרות ששטו בנתיב קרוב לנקודת הטביעה (מאחר וזו זוהתה במדויק רק לפני 25 שנה אזי מסביר את האיחור הרב בניסיונות להתחיל בחקירה מעמיקה ומדעית) במספר הימים שבין לפני האסון ולאחריו, אלו אותרו בגרמניה, יומני רישומי מזג אוויר שמצויים באנגליה ועוד.
התוצאה מפתיעה.
הסיבה הינה ככל שהסרט מציג תעתוע אופטי, מיראז'.
אנו מכירים את התופעה כמתרחשת במדבר, כאשר עקב צירוף נסיבות נראה שקיים במרחק מה מאתנו אגם מים, אך זהו לא יותר מתעתוע אופטי, מקסם שווא.
זה קורה גם על פני המים, כאשר צירוף של נסיבות עלול לגרום לשינוי במיקום קו האופק ולגרום בכך לאי יכולת להבחין בעצמים על המים כמו אותו קרחון, אלא רק כאשר מאד קרובים אליו. אותו צירוף נסיבות עלול לעוות צורות (של אניות) וליצור מגוון שלם של אשליות אופטיות נוספות.
אין ביכולתי לשפוט עד כמה התאוריה המוצגת נכונה. על פניו נחזית להיות מוצקה ואמינה.
אם היא אכן מתארת נאמנה את מה שהתרחש באותו הלילה, אזי זהו אחד מאותם מקרים שנדרשת סבלנות ועבודת נמלים של "חוקר מקרי פשע" על מנת למצות מתוך תילי תילים של מילים, דעות, טעויות ודברי הבל את אותן העובדות שמאפשרות לקבוע מהי התקלה ואלו לקחים יש להפיק לעתיד.
הטיטאניק נבנתה כך שביכולתה לספוג נזק עד רמה מסוימת ולא לטבוע. הנזק שנגרם עקב ההתנגשות הצידית בקרחון היה מעבר ליכולת זו. ההתנגשות הצידית כפי שהתרחשה בפועל לא נחזתה שתתרחש כלל. משזו כן התרחשה, גורלה של הטיטאניק נחרץ.
מה כן היה יכול אולי למנוע את הטביעה?
אני יוצא מנקודת הנחה שהאיתור המאוחר של הקרחון היה בלתי נמנע. האם היה משהו אחר שהיה יכול למנוע את האסון?
נכון, זו שאלה בסגנון "מה היה קורה אלו?" ונכון זו חוכמה שלאחר מעשה. אבל אין לזלזל גם בה.
ככל שאנו יודעים היום, טיטאניק הייתה שורדת התנגשות חזיתית בקרחון.

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

בפוסטים קודמים ציטטתי מספר דוברים מרחבי העולם בחודשים האחרונים.
אפשר להוסיף מצגת שניתנה בחודש נובמבר האחרון בכנס במלטה ע"י Brian D. Snow. בריאן סנו עבד במשך 31 ב-NSA וכיהן שם בתפקידים טכנולוגיים בכירים.
הקישור סופק מהבלוג של גורו אבטחת המידע ברוס שנייר.

http://www.synaptic-labs.com/resources/streaming-videos/synaptic-labs-2012-annual-reports-video-series.html#a

Interesting video of Brian Snow speaking from last November. (Brian used to be the Technical Director of NSA's Information Assurance Directorate.)

ניהול סיכונים כולל וניהול סיכוני טכנולוגיית המידע

בשנים האחרונות ובעיקר מאז רגולציית בזל II (רגולציה לניהול סיכונים לתאגידים בנקאיים) שמציפה את המונח "סיכונים תפעוליים" מתחילה לפרוח מתודולוגיה החורטת על דגלה את המונח "ניהול כולל של הסיכונים בארגון" – Organizational Risk Management.
ישנם הרבה סיכונים לנהל בארגון. לדוגמה: סיכונים אסטרטגיים (קשורים להליכי קבלת החלטות על ניהול פעילויות הארגון), סיכונים טקטיים (קשורים לאופן שבו מממשים את הפעילויות הארגוניות), סיכונים תפעוליים (קשורים לאופן שבו מבוצעים או לא מבוצעים תהליכי עבודה), סיכונים פיננסיים (קשורים לאי התאמה בין כמות וזמינות מקורות כספיים לצורכי הארגון ולפעילויות שאינן נאותות בכספי הארגון), סיכונים משפטיים (קשורים להיעדר יכולת אכיפה של זכויות משפטיות), סיכוני ציות (קשורים לאי יכולת ציות לחוק/רגולציה), סיכון סקטוריאלי (במגזר רפואי – סיכוני רשלנות רפואית לדוגמה, במגזר האנרגיה – אי יכולת לספק את השירות או המוצר) וכך הלאה.
מה קורה עם סיכוני השימוש בטכנולוגיית המידע?
ובכן לכאורה, מאז בזל II סיכוני טכנולוגיית המידע כלולים בסיכונים תפעוליים. מדוע?
הגדרת סיכון תפעולי: "הסיכון שבהפסד הנובע מכישלון או אי התאמה של תהליכים פנימיים, אנשים או מערכות, או מאירועים חיצוניים".
מערך טכנולוגיית המידע מורכב ממערכות (חומרות ותוכנות טכנולוגיית המידע למיניהן), אנשים, ותהליכי העבודה אשר אותם מפעילים אנשים על אותן המערכות או שהמערכות מפעילות זו על זו. מאחר ועפ"י ההגדרה לעיל, טכנולוגיית המידע הינה לא יותר ממקרה פרטי של סיכון תפעולי, אזי בשיטת "הכל כבר כלול" לא צריך להתעמק באופן ייחודי ב"דבר הזה" שנקרא בשם טכנולוגיית המידע, הכל כבר מסודר תחת העולם הקסום של "הסיכונים התפעוליים".
ואז באה המציאות ומראה לנו שלא כך הם פני הדברים. מדוע?
אני מונה שתי סיבות ואתחיל מהקלה יותר:
כל הסיכונים כולם מתממשים רק בטכנולוגיית המידע או גם בטכנולוגיית המידע.
ככל שאנו מתקדמים על סרגל הזמן, כל הפעילויות החל מהטריוויאליות ביותר, כמו לוח הזמנים שלי, ועד לרמה האסטרטגית הכל מצוי שם בתוך טכנולוגיית המידע. על כן, סיכון יהיה זה משפטי, פיננסי, ואפילו אסטרטגי, קשור באופן זה או אחר ל"דבר הזה" שאנו רוצים להתעלם ממנו ולהחביא אותו בתוך קופסא אחרת. כן, גם הסיכון האסטרטגי אותו סופרלטיב, תהליך קבלת ההחלטות הרות הגורל, איך יתבצע ללא מערכות ה-BI וה-BIG DATA? כך שללא שמירת הסודיות, השלמות והאמינות, הזמינות והשרידות, ההתאמה לצורכי הארגון, הסקלביליות ועוד לא מעט נושאים שמיוחסים לסיכוני טכנולוגיית המידע הם התשתית למימושם של הסיכונים האחרים.
הסיבה השנייה היא היא הגורם שלדעתי לא ניתן לחבר את עולם סיכוני טכנולוגיית המידע לשום עולם סיכונים אחר. לטוב ולרע דרך אגב.
מהו היום רכיב טיפוסי שהולך וכובש את מקומם של שאר הרכיבים? הסמארטפון. כן, איזה שם חיבה לרכיב שמתאים לכיס, הכולל מחשב וטלפון סלולרי ועוד מיני מינים של גאדג'טים.
קשה להאמין, אך הרכיב התמים לכאורה הוא חרב פיפיות. מצד אחד משמש את בעליו לצרכיו, ובה בעת עלול לשמש מאן דהוא שיחדיר לתוכו קוד עוין לצרכים אחרים לחלוטין, בעוד בעליו של הסמארטפון החביב כלל איננו מודע שמה שהוא נושא בכיסו או בתיקו הינו כלי נשק שעלול להיות מופעל נגדו או נגד בני משפחתו או נגד, השד יודע מי.
יאמרו לי: גם מכונית היא צעצוע מסוכן. נכון הדבר, אלא שהמסוכנות ברוב רובם של המקרים נובעת מהאופן שבו הנוהג בה משתמש בצעצוע שקרוי מכונית ולא במהותה של המכונית.
מסוכנותם המובנית, המהותית של רכיבי טכנולוגיית המידע איננה נגזרת מהתנהגות המשתמש בהם, אלא מהעובדה שלא תוכננו כלל להתמודד עם היכולת להשתמש בהם למטרות שונות בתכלית, כמו לדוגמה: כתיבת קוד שמטרתו הצגת מצגת וכתיבת קוד שהוא קוד עוין (לדוגמה וירוס), שליחת דואר אלקטרוני לחבר ומשלוח דואר אלקטרוני שהוא ספאם או נועד לפתות אותי למסור מס' כרטיס אשראי לגורם עוין (דוגמה לפישינג), גלישה באתרי רשתות חברתיות או שימוש ברכיב כחלק מצבא מחשבים עוינים (BOTNET).
ההיפך הוא הנכון, רכיבי טכנולוגיית המידע נבנו בדיוק למטרה של שימוש מגוון. ההוכחה היא שהשימוש בהם הינו בכל תחומי החיים, בלא שנצטרך לשנות דבר ברכיב גופו. בואו נזכור, המחשבים האישיים הראשונים נבנו על מנת שניתן יהיה לשחק באמצעותם משחקים. אח"כ בא יישום הגיליון האלקטרוני לוטוס 1-2-3 והשאר היסטוריה.
מי העלה על דעתו שמחשבים אלו יהיו בכיסו של כל אדם?
מי מסוגל היה לחשוב באותה העת שהיצירתיות המופלאה הזו, המחשב האישי ידרוש מאתנו כעבור לא יותר מעשרות ספורות של שנים התמודדות להגנת תשתיות חיוניות, סיכון לקריסת מערכות שבשימוש יומיומי כמו בנקאות, בריאות, תקשורת וכד'?
זו מציאות חדשה. המחשב האישי שמתורגם כעת לסמארטפון, מחשב לוח, מחשב נייד, ועושר עצום של מגוון סוגי רכיבי טכנולוגיית המידע הינו רכיב רב שימושי, התועלות בשימוש בו רבות מספור וכך גם הסיכונים שנלווים לכך.
אין לכך אח ורע בכל עולם ניהול הסיכונים הסובב אותנו.
תקנו אותי עם אני טועה.
תעיזו ללכת עוד צעד אחד יחד איתי? אז הנה...
בכנס RSA בתחילת חודש מרץ בסן פרנציסקו, התקיים פנל שכותרתו:

Risk Management smackdown II: The wrath of Kuhn

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

http://www.readwriteweb.com/enterprise/2012/03/invasion-of-the-risk-managers.php

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

https://ae.rsaconference.com/US12/scheduler/eventcatalog/eventCatalog.do

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

Risk management is not bad, its evil, and it's actually the enemy of security.

צודק או טועה האדון בוב בלייקלי?
אולי נאמרו דבריו רק על מנת לעורר דיון, להעיר מוחות רדומים מתרדמתם...?

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

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

חג שמח.

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

פוסט זה יתייחס לשני מחקרים המתפרסמים זמן קצר לפני הפסח.
פסח, זמן טוב לרענן את המחשבה, מעבדות לחירות נאמר, אז גם של חשיבה.
אז מה היה לנו?
1. דוח שנתי של חברת וריזון הנושא את הכותרת: Verizon report on data breaches
2. מחקר קרימינולוגי מיהם פושעי המחשב. הקרימינולוג דר' מיכאל מקגוויר מהאוניברסיטה העירונית של לונדון וצוותו מציגים נתונים מעניינים ו"שוחטי פרות קדושות" בעניין זה. האומנם? המחקר מומן בידי חברת BAE systems Detica וכותרתו: Organized Crime In the Digital Age
הדוח של חברת וריזון אומר בלשון שאיננה משתמעת לשתי פנים: שכחנו את השיעור הראשון. כלומר, ארגונים שוכחים שהגנת המידע איננה מתחילה באמצעי אבטחה מתקדמים אלא ב-א. וכך לדבריהם רובם המכריע (מעל 90%) של מאות רבות של אירועי פריצה למערכות שנחקרו על ידם נגרמו כתוצאה של רשלנות, חוסר ידע מקצועי או טעויות פשוטות ולא דרשו מהפורצים רמה מקצועית גבוהה על מנת לפרוץ למערכות טכנולוגיית המידע הארגוניות. שורה תחתונה, השקעה יחסית קטנה הייתה מונעת אותם.
המחקר של הקרימינולוג מציג תמונה שבה הפשע המאורגן הפיזי והמיחשובי מתאחדים.
שלושה יסודות הבונים את העידן הנוכחי של הפשיעה הדיגיטלית הינם:
א. מי העוסקים בכך? התשובה היא שבקרוב ל-50% מהמקרים, זהו אדם מעל גיל 35 ופחות משליש הינם בני פחות מ-25.
ב. מה יכולותיהם? רובם אינם בעלי ידע מקצועי עמוק בתחום טכנולוגיית המידע.
ג. זה מצליח. ועוד איך מצליח.
מה הולך פה? הרי מספרים לנו השכם והערב שהאקרים זה חבר'ה צעירים, מומחי טכנולוגיית מידע והנה פה מדובר בתמונה הפוכה.
הסיבה היא פשוטה. הפשיעה הדיגיטלית (הממוחשבת) הפכה לפס ייצור של כלי תוכנה זמינים לרכישה באמצעות האינטרנט. חלק נכבד מהפשיעה מתבצעת על בסיס מודלים כלכליים שפותחו על מנת לשרת את עולם הסחר האלקטרוני המודרני והפשיעה הדיגיטלית "עלתה על הגל" ומצאה את מקומה באותם השיטות, רק למטרות "קצת" אחרות...
למה זה מצליח?
כי רכיבי טכנולוגיית המידע המצויים בידינו מלאים בכשלים הניתנים לניצול (פגיעויות), או לחילופין, ראה הדוח של וריזון בחלק הראשון של הפוסט...
קיצורו של דבר, חברת המידע והשפע המודרנית צריכה לתת לעצמה דין וחשבון.
המענה הינו ביצירת תהליכי אכיפה ושילוב ידע טכנולוגי בחדירה לעולם הפשע הדיגיטלי לצמצומו באופן פרואקטיבי ולא רק בשימוש בשיטות הגנתיות תגובתיות קלאסיות.
מהעבר השני, נדרש כי תשתיות טכנולוגיות המידע החל מייצורן וכלה בשימוש השוטף בהן יזכו לקבל את תשומות האבטחה הנדרשות.

נדרשת תפישה חדשה על מנת לאפשר המשך השימוש בטכנולוגיית המידע

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

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

ב-3 במרץ, כותבת אלינור מוריס מאמר ב-CNET שכותרתו:

Why the Security Industry never actually makes us secure

http://news.cnet.com/8301-27080_3-57389046-245/why-the-security-industry-never-actually-makes-us-secure/

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

The Wrong type of loop
http://www.computerweekly.com/blogs/david_lacey/2012/02/the_wrong_type_of_loop.html

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

PLAN – DO – CHECK - ACT

איננו מתאים לאבטחת מידע.
לפני שאמשיך, מספר מילים על David Lacey, כדי להבין מדוע יש לקחת את אמירותיו בהתייחס לתקן זה ברצינות.
David Lacey הינו אחד מאבותיו של תקן אבטחת המידע 27001/27002.
תקן זה תחילתו במסיבת עתונאים ב-30 בספטמבר 1993 בחברת של הבריטית.
ראו קישור:

Historical records from the birth of BS7799

http://www.computerweekly.com/blogs/david_lacey/2009/04/historical_records_from_the_bi.html

לפני למעלה משנה, בחודש ינואר 2011, הוא יוצא באמירה פרובוקטיבית:

Security: Best practice or ancient ritual?

Time to scrap ISO 27002 security standard says its author

http://www.computerworlduk.com/in-depth/security/3256436/security-best-practice-or-ancient-ritual/

אינני יודע אם זו הפעם הראשונה שהוא חושב כך, אבל ישנו קו ברור המתוח בין אמירתו לפני 14 חודש והאמירה הנוכחית: לדעתו, אנו שבויים בקונספט מוטעה.
האמירה הנוכחית מתייחסת למעגל הניהולי המהותי שב-27000 (החולק אותו עם שני תקני ניהול נוספים: תקן אבטחת האיכות ISO-9001, ותקן איכות הסביבה ISO-14001) שעיקרו: PLAN – DO – CHECK - ACT

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

לדוגמה, חברת סוני היא יפנית ומוסמכת לתקן בעת שנפרצה. דרך אגב, החדירה המאסיבית ביותר של התקן הינה ב...יפן. מה זה אומר על התקן? על יפן? על סוני? ואולי זה לא אומר כלום?
על פי מידע הקיים במרשתת (מרשתת, המילה העברית לאינטרנט) תקן 27001/27002 יעודכן במהלך שנת 2013. מה יכלול העדכון? יתווספו בקרות, יבוטלו בקרות. יבוצע איזשהוא "פריש-מיש" סמנטי כדי שהתקן יחלוק תפישה ניהולית וטקסטואלית אחידה עם בין 8 ל-12 תקנים נוספים, ולא רק שניים כפי שהמצב היום.
האם במסגרת מהלך זה יבוטל גם ה- PLAN – DO – CHECK – ACT. ימים יגידו.
בנתיים, מה החלופה המוצעת ע"י David Lacey?
לחלופה ראשי התיבות OODA, עבור: OBSERVE – ORIENT – DECIDE - ACT
רעיון זה פותח ע"י קצין בחיל האוויר האמריקאני בשם ג'ון בויד ומתאר (בין היתר) את האסטרטגיה של השגת נצחון בקרבות אוויר. ההשראה למעגל זה היתה האתגרים שהוצבו להפעלת הכוח האווירי האמריקני במלחמת וויטנאם.
לא אכנס כאן לדיון מהו בדיוק OODA והאם הוא הפתרון המתאים? הנכון? מה שחשוב לי להדגיש שבמקום "לעשות יותר מאותו הדבר"... (וזה בבירור לא עונה על הציפיות) צריך וחיוני לחשוב על מה צריך לעשות אחרת! (וגם מה לא צריך לעשות אחרת).
OODA בהיותה אסטרטגיה לקרבות אויר בהכרח טומנת בחובה תפישה של מהירות תגובה. יתר על כן, איך מנצחים בקרב אוויר? אחת הדרכים הינה להקדים את האויב, "להתלבש על תהליך ה-OODA" של היריב, ולחתוך אותו. מי שרוצה דוגמה, שילך ויראה שוב את הסרט : TOP GUN (אהבה בשחקים).
מספר הערות להבהרה, על מנת למנוע טעויות ואי הבנה ולהסביר מהן לדעתי אבני בניין לתפישה החדשה:
1. אינני מציע לזרוק את תקן אבטחת מידע 27002/27001 וסדרת התקנים הנלווית. ההיפך הוא הנכון. הסמכה לתקן הינה תהליך נכון, אבל "לא באופן עיוור". חובה לקרוא ולהבין את 27002. זו התורה האבטחתית, שם כתוב "למה התכוון ISO". אח"כ יש להפעיל שיקול דעת מקצועי וניהולי, לשלב את הרגולציות הרלוונטיות שמספקות תקדימים, לבצע את ההתאמות הארגוניות ועיקר העיקרים, להפעיל את הראש. לחשוב. לחשוב. לחשוב.
כיוון נכון ש-ISO נוקט הינו להוסיף תקנים מגזריים. כיום ישנם כבר שני תקנים מגזריים: 27011 למגזר התקשורת, ו-27799 למגזר הבריאות. תקן מגזרי שלישי למגזר הפיננסי (27015) נמצא בהכנה. תקינה מגזרית ממקדת דרישות מותאמות למגזר ומחייבת את יישומם, דהיינו, מצמצמת את מרחב חופש הפעולה של הארגונים במגזר לבחור שלא ליישם בקרה ספציפית. התקן הכללי, 27001 מספק חופש בחירה רחב מדי לארגון.
דוגמאות לשילוב רגולציות רלוונטיות:
א. הוראת ניהול בנקאי תקין 357 של בנק ישראל בעניין "ניהולה התקין של טכנולוגיית המידע" וההוראה לניהול סיכוני אבטחת מידע מטעם המפקח על הביטוח באגף שוק ההון במשרד האוצר מספקות לנו מענים לגבי (בין היתר) מספר סוגיות:
(1) חובת מינוי מנהל אבטחת מידע בכפיפות ישירה לחבר הנהלה (כל חבר הנהלה כולל מנהל מערכות המידע במידה והוא חבר הנהלה כמובן),
(2) חובת ביצוע סקר הערכת סיכונים למערך טכנולוגיית המידע כולו. בעקבותיו נדרש תכנון וביצוע סקרי סיכונים למערך זה וביצוע מבדקי חדירה מבוקרים ע"י חברות חיצוניות בעלות ידע ויכולת מקצועית בלבד,
(3) הצגת דרישות מינימום הכרחיות למתן גישה ללקוחות למערכות המידע וביצוע שאילתות לקבלת מידע ופעולות פיננסיות בחשבונותיהם, לדוגמה תוך כדי עשיית שימוש באינטרנט ("בנקאות בתקשורת"),
(4) התייחסות לדרישות בנוגע למיקור חוץ, לגיבוי והתאוששות.
ב. הנחיות הרשות למשפט טכנולוגיה ומידע (רמו"ט) אשר בשלוש השנים האחרונות החלה לייצר סדרת הנחיות (ובקנה גם שינוי חוק הגנת הפרטיות והוצאת צו המעדכן את דרישות אבטחת המידע למידע זה) בכל הנוגע לאבטחתו של מידע אישי המוגן עפ"י החוק והתקנות להגנת הפרטיות. הנחיות הנגישות לכלל באמצעות אתר האינטרנט של הרשות.
ג. פעילות משמעותית במגזר הבריאות שבוצעה במהלך השנים האחרונות ע"י מר איציק כוכב, ממונה הגנת המידע בשירותי בריאות כללית, ואשר כוללת הנחיות מפורטות להגנת מידע בתהליכי העבודה המורכבים והמגוונים בקופת חולים ובבתי חולים.
ד. תקן PCI-DSS מטעם חברות כרטיסי האשראי הקובע דרישות טכנולוגיות במידה ובארגון נאגר, מעובד או מועבר בתקשות מספר כרטיס האשראי.
הדוגמאות הללו (ויש נוספות) מספקות תשתית, תקדימים, מידע מקצועי תומך, תקראו לזה איך שנוח לכם, אבל בשורה התחתונה, יש הרבה ממה ללמוד, לא כל דבר צריך להמציא מהתחלה.

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

מי המתקיף? וזה הכי כואב: הטכנולוגה היא התוקף והמותקף בה בעת.

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

3. שתי התייחסויות למונח: מערך טכנולוגיית המידע מותקף ללא הרף:

א. מיהו מערך טכנולוגיית המידע, מי מחזיק/מפעיל אותו? מי אמור להגן עליו ואיך?
אנו נדרשים להתחיל לשאול שאלות שלא שאלנו בעבר ולספק תשובות ופתרונות.
זה שמדובר במחשבים הארגוניים זה ברור. האם זה כולל גם את המחשב/הסמארטפון הפרטי שלי? מה נדרש על מנת לבצע הגנה? איפה מתבצעת ההגנה? במחשב הארגוני/הפרטי? אצל ספק האינטרנט? במרחב האינטרנט? מה זה בכלל הגנה? ומה עם הפרטיות? שאלות עתידניות? לחלוטין לא. זה כבר קורה.
פרוייקטי I-Code באוסטרליה (החל מדצמבר 2010), ו – Bot-Frei בגרמניה (החל מאוגוסט 2010) מהעבר האחד, והפעילות של מיקרוסופט וממשלת ארה"ב למיגורם של BotNets מהעבר האחר מהווים הוכחה שבעולם החלו ניצני עידן חדש. זה בהחלט יותר מניצנים, יש גיבוי טכנולוגי ומשפטי לתהליכים אלו.
ב. מחייב שינוי בסיסי ועמוק של תפישת ההפעלה של טכנולוגיית המידע.
"עבודה תחת מתקפה", זה שם המשחק. חלק מהמתקפות ייעצרו לפני מערך טכנולוגיית המידע הרלוונטי לאספקת השירות, וחלקן יחדרו.
אלו שיחדרו, מערך טכנולוגיית המידע כולל מרכיבי האבטחה נדרשים להכיל את החדירה ולהתמודד איתה באופן המאפשר לטכנולוגיית המידע להמשיך לפעול, לספק את השירות (אם כי ברמה שעשוייה להיות מופחתת) ולטפל במפגע בו זמנית, עד לחזרה לכשירות מלאה וברצף תפעולי.
טכנולוגיית מידע שבעת שמצויה תחת מתקפה תחייב כמענה ברירת מחדל השבתה, איננה מהווה מענה מקצועי מספק בעידן החדש.

ניהול אבטחת מידע - הבהרה

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

בתאוריה: אבטחת מידע זה כל השלוש

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

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

IMFORMATION SECURITY ASPECTS OF BUSINESS CONTINUITY PLANNING

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

ותקנו אותי אם אני טועה.