מנהל מערכות המידע במרכז הרפואי BIDMC על לקחים שהפיק בנושאי אבטחה. (מאמר מתורגם).

 המקור בקישור הבא:

  http://www.healthcareinfosecurity.com/cio-halamka-on-security-lessons-learned-a-7292            

פריצות ואירועי חירום אבטחתיים אחרים עשויים להיות זרזים משמעותיים ביצירת שינוי, כך אומר גו'ן הלמקה, מנמ"ר  Beth Israel Deaconess Medical Center - BIDMC בבוסטון, ארה"ב. הארגון נקט במספר צעדים על מנת לשפר את אבטחת המידע והפרטיות לאור מספר אירועים.

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

Healthcare Information and Management Systems Society.  

לאירוע גניבת המחשב הנייד:

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

כתוצאה מהאירוע, המרכז הרפואי החמיר את מדיניות ההצפנה לכל המכשירים בבעלות המרכז הרפואי, כמו גם לרכיבים בבעלות פרטית המשמשים אותם במסגרת עבודתם (Bring Your Own Device - BYOD). חברי צוות במרכז הרפואי חייבים להצהיר כי רכיביהם האישיים מוצפנים לפני שמאושר להם שימוש בהם במסגרת העבודה.

Bombing Aftermath – תוצאות פיגוע הפצצה

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

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

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

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

כתוצאה מהסקר הארגון יישם מספר שינויים.

שינוי באופן שבו הארגון מנהל את הסיכון הפנימי. למרכז הרפואי לא הייתה שיטת ניהול סיכונים פורמלית. מצב זה היקשה על השוואה שנה על גבי שנה. במענה הארגון אימץ את האמור בפרק:
                                                                                               A Framework for Managing Risk

במסמך:

           NIST 800-66 : An Introductory Resource guide for implementing HIPAA Security Rule

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

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

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

Cloud Precautions –  זהירות בענן

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

לדוגמה, נחסמת הגישה לDrop Box מכיוון שהספק איננו מוכן לחתום על הסכם שותף עסקי (Business associate), שהנה דרישה של HIPAA. המשמעות של ספק שמכריז על עצמו כ-שותף עסקי הנה שהוא מקבל על עצמו את דרישות חוק ה-HIPAA Security Rule. למשתמשים יש עכשיו בחירה של שני ספקי שירותי ענן לשמירה ושיתוף קבצים: מערכת אכסון ענן פנימית ושירותי צד ג' של ספק ששמו לא נמסר, אך אותו ספק הסכים לחתום על הסכם שותף עסקי – Business Associate כפי שחוק ה-HIPAA מחייב.

שופרו גם בקרות גישה לרשת על מנת למנוע גישה לרכיבים בלתי מזוהים. שימוש בזיהוי ביומטרי של טביעת בוהן Biometric thumb print authentication תוטמע על מנת לציית לדרישת הרגולציה של ה -Drug Enforcement Agency - DEA 

על מנת למנוע שיגור רשומות חולים באופן לא מאובטח באמצעות דוא"ל בין רופאים, מסמכים קליניים משוגרים באופן אוטומטי באמצעות פרוטוקול מאובטח: Direct secure messaging protocol.

תובנות שמסייעות

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

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

הערת המתרגם:

אין זו הפעם הראשונה שמנמ"ר זה פורס בפני הציבור אירועים שקרו ב-BIDMC והלקחים שהפיק. האירוע המפורסם ביותר היה בשנת 2002 עת קרסה מערכת התקשורת במרכז הרפואי והחזירה אותו בבת אחת עשרות שנים לאחור. את האירוע תאר מספר שנים מאוחר יותר בקישור הבא:

                       http://geekdoctor.blogspot.co.il/2008/03/caregroup-network-outage.html

The CareGroup Network Outage

מאמר מתורגם – "פריצות במגזר הבריאות בארה"ב עברו את 1,000 האירועים. מומחים מספקים תובנות לגבי לקחים[1]

הרישום הפדרלי של אירועי פריצה עיקריים למאגרים רפואיים בארה"ב עבר את רף 1,000 האירועים הרשומים. הרישום כולל רק את אלו המשפיעים על לפחות 500 או יותר אנשים. הרישום הנו חובה ע"פ חוק ה-HITECH האמריקני ומבוצע החל מספטמבר ¹2009.

רקע:

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

1.      HIPAA – Health Insurance Portability and Accountability Act: כולל שני "תת חוקים". האחד לנושא הגנת הפרטיות והשני לנושא אבטחת מידע.

2.      HITECH –  Health Information Technology for Economic and Clinical Health act אשר נחקק כחלק מחוק רפורמת הבריאות של הנשיא אובמה. משדרג נושאים ב-HIPAA. 

לאחרונה נוסף חוק שלישי (תוספת ל-HIPAA). ה-HIPAA OMNIBUS, אשר בין היתר מחייב "שותף עסקי – Business Associate" של מי שמחזיק רשומה רפואית פרטנית (לדוגמה ספק שירותי גיבוי או ספק שירותי ענן...) לציית לדרישות HIPAA.

אבל לענייננו המרכיב החשוב ביותר הנו חוק ה- Breach Notification Final Rule(שנחקק במסגרת ה-(HITECH מאוגוסט 2009, ואשר מחייב ישויות החייבות לעמוד ב-HIPAA לדווח למשרד הבריאות האמריקני על אירוע אשר פגע בפרטיות או באבטחה ובמהלכו התאפשרה גישה בלתי מורשית למידע הרפואי המוגן באופן שהשימוש או החשיפה מהוות סיכון משמעותי בתחום הכלכלי, התדמיתי או נזק אחר (HARM) לאדם שנפגע. גולת הכותרת הנה שכאשר מדובר בלמעלה מ-500 יחידים באירוע בודד, האירוע לא רק מדווח למשרד הבריאות אלא גם הופך לפומבי באתר האינטרנט של משרד הבריאות ("קיר הבושה – Wall of Shame")[2].

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

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

עשרת האירועים החמורים ביותר משפיעים על כ-18.4 מיליון אנשים, יותר מחצי מסך של 31.5 מיליון אנשים שעלולים להיות קורבנות של 1,010 אירועי פריצה עיקריים המדווחים מאז שהוחלה החובה החוקית בספטמבר 2009.

 

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

לדברי בריאן אוונס מחברת הייעוץ טום וולש, "עשרת האירועים העיקריים מצביעים על חשיבותה של ההצפנה להגנה על מידע המצוי בתנועה או במנוחה. מאחר ופתרון ההצפנה מסופק כיום כמענה "out of the box" (ללא עלות) או כתוסף מוצר צד ג' (בעלות נמוכה יחסית), אזי נתן לצמצם באופן משמעותי את הסבירות של פגיעה. להבטיח שהצפנה מיושמת באופן הנכון הנה צעד בסיסי שכל הארגונים חייבים לבצע".

 

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

 

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

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

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

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

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

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

לקחים שנלמדו

לקחים מרכזיים שנתן להפיק מהאירועים העיקריים הנ"ל:

לדברי מקמילן:

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

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

3.        למרות שרק כ-20% מכלל הפריצות משויכות לאירועים בשותפים עסקיים (Business associates), המספר קופץ דרמטית ל-50% כאשר מצמצמים את ההתייחסות רק לפריצות העיקריות, דהיינו אלו שבהן הפגיעה הנה במספר הגדול ביותר של מטופלים. אלו עדיין מספר שניים בחיוב הכספי ב"קיר הבושה". (הפרשנות שלי למשפט זה הנה שהשותפים העסקיים עד לאחרונה לא שילמו קנסות כספיים כבדים, ועל כן הם שניים בחשבון הקנסות שעליהם לשלם).

תחת החוק החדש HIPAA Omnibus Rule שנכנס לתוקף בשנה שעברה, שותף עסקי  אחראי לציות מלא ל-HIPAA ועל כן במקרה של הפרה הנו בר תביעה באופן ישיר, וכמו הישויות המכוסות (Covered entities), נתון לפעילות אכיפה של הגורם המוסמך בארה"ב. אלו עשויים לכלול קנסות עד לגובה של 1.5 מיליון USD להפרה בודדת של HIPAA.

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

לדברי מקמילן הרבה שותפים עסקיים אינם מאמינים שהם שותפים עסקיים (ע"פ הגדרת המונח ב-HIPAA), או שהם מנסים להגביל את אחריותם כיוון שהם מאמינים שרק חלק מהחוק חל עליהם. שותפים עסקיים אינם מבצעים ניתוח סיכונים (Risk Analysis) כפי שמבצעות הישויות המכוסות המקבילות. בקיצור, הם "אינם בעניין"... עדיין.

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

 

צופה פני עתיד

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

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

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

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

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

 

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

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

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

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

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

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

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

---

[1] קישור למאמר המקורי: http://www.healthcareinfosecurity.com/health-breach-tally-tops-1000-incidents-a-6891

 

[2] קישור ל"קיר הבושה - Wall of SHAME": http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html

מתי ואיך הפכתי למידען-משהו אישי הפעם וזה קשור מאד לאריק שרון ז"ל. הפוסט הזה מוקדש לזכרו.

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

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

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

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

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

(1) מי שחשבתי שיודע, לא יודע, והמשמעות שאני צריך לסמוך הרבה מאד על יכולותי להגיע למידע בעצמי 

(2) כאשר לא יודעים, לא ממציאים, אומרים "לא יודע". גם אם צריך להגיד "לא יודע" לבכירים ביותר.

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

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

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

1. בחירת אלו נתונים גולמיים ייעשה בהם שימוש.

2. בחירת אלו נתונים גולמיים לא ייעשה בהם שימוש.

3. בחירת אופן הצגת הנתונים הגולמיים שהוחלט לעשות בהם שימוש.

4. הצגת שורת הסיכום אשר אמורה לשרת את המטרה אשר בגינה נכתב המסמך.

 

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

ומילה אחת נוספת על אותה שנה, שנת 1972 והשנה שלאחריה, 1973.

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

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

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

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

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

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

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

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

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

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

 

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

                                                                                       Confidentiality , Integrity , Availability.

מה לא כלול בהגדרה הזו?

מי אחראי על מה בחלוקת האחריות הארגונית:

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

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

עכשיו, בואו נשלב בין שני הנושאים לעיל. מה קיבלנו?

-          טיפול במישור הפיזי של סיכוני סודיות, שלמות ואמינות, זמינות.

-          טיפול במישור המיחשובי של סיכוני סודיות, שלמות ואמינות וזמינות.

בדרך כלל הפתרון המקובל הנו:

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

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

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

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

המענה על כן קיים מאז ומעולם, אין פה שום חידוש, אלא שברמה הסמנטית יש עיוות. ישנם כל הזמן איומים חדשים ולא סיכונים חדשים, כן גם כאן הסמנטיקה חיונית[1]. אויבים חדשים עלולים גם הם לצוץ, סדרי העוצמה של איומים קיימים עלולים להשתנות, טכנולוגיות עשויות לקום וליפול, מבנה ארגוני עשוי להשתנות וכד', כמו גם מענים המתפתחים כדי לספק מענה לאיומים ולסיכונים כל אחד בנפרד ובמשולב.

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

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

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

                       The Inslaw Affair / PROsecutors Management Information Systems-PROMIS

זוהי תקיפת APT מצוינת. רק שהיא מתחילה מתישהו בשנות ה-70 של המאה הקודמת...

הרי בלי אינטרנט אין APT. תתעוררו בבקשה, עידן האינטרנט לא המציא את ה-APT

סיימנו בזאת את הדיון באבטחת מידע? עדיין לא.

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

עד כאן הכל טוב ויפה.

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

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

1.       את הטיפול הרפואי אני מקבל במרפאה של הקופה. המטפל עושה שימוש במערכות המידע של הקופה.

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

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

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

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

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

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

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

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

 בזאת סיימנו למיטב הבנתי את הדיון באבטחת מידע.

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

השאלה כמובן האם קיימים תחומים כאלה? לדעתי כן.

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

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

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

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

היום מכשיר רנטגן קרוי CR – Computerized Roentgen או DR – Direct Roentgen.

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

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

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

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

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

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

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

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

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

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

אבטחת/הגנת מידע זה לא. אני מקווה שלפחות בכך הצלחתי לשכנע.

הגנה בסייבר זה גם לא, אבל זה תפס. אז נגיד...

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

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

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

---

 

[1]  איום – Threat: הפוטנציאל להתרחשות "משהו לא טוב" ("נזק"). סיכון – Risk: מה עלול לקרות אם יתממש הנזק. לדוגמה: חדירת קוד זדוני זה איום. הסיכון מאיום זה הנו משולש: שיבוש מידע, שיבוש עד השבתת יכולת הפעילות, גניבת מידע. האיום לא חייב להתממש או עלול להתממש בכל קומבינציה אפשרית של מרכיבי הסיכון. כמו כן, סיכון אחד יכול להתממש מיותר מאיום אחד. לדוגמה: השבתה יכולה להתממש עקב חדירת קוד זדוני או מטעות אנוש או מפעולה זדונית של פצחן (האקר).