יומן אבטחה

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

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

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

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

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

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

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

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

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

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

קישורים:

אתר משרד המשפטים, מכיל את החוק והתקנות.

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

פרולוג

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

Common Criteria על רגל אחת

בראשית ברא אלוהים את השמים ואת הארץ וכמה שנים אחר כך נולד המחשב. אי שם בשנות ה-80 (אל תתפסו אותי במילה) נולד בארצות הברית ה-Orange Book שהיה מעין תקן אבטחה אמריקאי למערכות מידע. מי שעוד זוכר את חלונות NT, זוכר שהיא עמדה ב-C2 של ה-Orange Book (שוב, בעיקר מהזיכרון). בשנות ה-90 המציאו האירופאים את ה-ITSEC שהיה דומה ל-Orange Book, אך של אירופה (בסופו של דבר, בתיאור הזה מתמצים רוב ההבדלים בין אירופה וארצות הברית...). באמצע שנות ה-90 הוחלט לייצר תקן אחיד, הלא הוא ה-Common Criteria (להלן CC) שהוכרז גם כתקן ISO (מספר 15408). התקן מגדיר את תהליכי הבדיקה שמערכת צריכה לעבור על מנת לקבל רמת תקינה מסוימת. לא מדובר על תקן שאומר איך צריך לבנות מוצר מאובטח, אלא במקום החברה מצהירה על רמת אבטחה, קונפיגורציה בה רמת אבטחה זו מתממשת והנחות יסוד ומעבדת בדיקה בלתי תלויה בוחנת האם המוצר עומד בהצהרות היצרן. רמות הבדיקה האפשריות הנן EAL1-7 המונח EAL מציין Evaluation Assurance Level) ולמעשה רמת בדיקה זו מתארת את המידה בה המעבדה בדקה את הצהרות היצרן. בעקרון היצרן מגדיר את רמת האבטחה בה הוא רוצה לעמוד, אך שלא יובן מכך שהכל פרוץ. התקן כן מגדיר דרישות ומציג סדרת מאפייני אבטחה מהם בדרך כלל היצרנים בוחרים את יעדי המימוש שלהם. חלק מתהליך הבדיקה הנו לבדוק שהצהרות האבטחה של היצרן (Security Target - ST) הגיוניות ובעלות עקיבות פנימית ולאחר מכן לבדוק שיעד הבדיקה (Target Of Evaluation - TOE) עומד בהצהרות אבטחה אלה. בעיקרון בתקן יש גם אפשרות לעשות שימוש בפרופילי אבטחה (PP) מובנים. להבדיל מיעדי אבטחה (ST) שהנם ספציפיים למערכת מסוימת, ה-PP תקף לקבוצת מוצרים (נניח Firewall Protection Profile).

האם ה-CC טוב? תלוי. למוצרי Microsoft יש CC לרמה EAL 4 שהיא רמה יחסית גבוהה (רוב המוצרים לא יגיעו מעבר ל-5) ובכל זאת אנו לא חושבים שמדובר במוצרים הכי מאובטחים בעולם. זה מביא אותי לחלק הבא של הרשימה

Common Criteria - מה זה בשבילנו (הצרכנים)?

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

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

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

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

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

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

מקור: CSOOnline

לאור המקרים האחרונים של הונאות במרכזי Call Center בהודו, תוקם רשות חדשה. כנראה כיוון שהעתיד הוורוד של המדינה הפך להיות פחות וורוד לאור המקרים (כך על פי Forrester לכל הפחות).

מקור: CRMBuyer

אזכרתי את הנושא בעבר כאן