לדף הכניסה של ישרא-בלוג
לדף הראשי של nana10
לחצו לחיפוש
חפש שם בלוג/בלוגר
חפש בכל הבלוגים
חפש בבלוג זה
 

יומן אבטחה

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

מלאו כאן את כתובת האימייל
שלכם ותקבלו עדכון בכל פעם שיעודכן הבלוג שלי:

הצטרף כמנוי
בטל מנוי
שלח

RSS: לקטעים  לתגובות 
ארכיון:


12/2006

Common Criteria


דרך גיא מזרחי הגעתי לבלוג של בארי שטיימן* שנראה בעל פוטנציאל מעניין. בארי כותב רשימה על 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 עצומה (עשרות עד מאות אלפי דולרים) ורוב חברות התוכנה בכלל לא מרשות לעצמן לעבור הסמכה. אם תעברו על רשימת המוצרים המוסמכים תמצאו שם בעיקר מוצרי אבטחה (בהם זה כמעט תנאי סף כדי להתחיל למכור) ומוצרים של חברות ענק. רוב החברות שיוצאות במכרז הרי לא קונות מוצרי מדף כמו שהם אלא אחד מהשניים - מוצרים מבוססי מוצרי מדף או מוצרים שפותחו עבורן. בפועל כל ההתאמות האלה לא עוברות כל הסמכה ולא סביר לדרוש מחברה שמפתחת לכם מוצר תוכנה במאתיים אלף דולר להשקיע עוד מאה חמישים אלף דולר ושנת עיכוב כדי לעמוד בתקן. כך שנתקעתם למעשה עם השאלה האם יש למוצר הסמכה או לא והאם למוצרים המתחרים יש הסמכה או לא. אם לאף אחד אין, כנראה שלא סביר לדרוש הסמכה. אם לאחרים יש ולמוצר הזה אין, צריך לשאול מדוע זה המצב.

 

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

נכתב על ידי , 8/12/2006 22:32   בקטגוריות חוקים ותקנות, אבטחת מידע כללי  
7 תגובות   הצג תגובות    הוסף תגובה   הוסף הפניה   קישור ישיר   שתף   המלץ   הצע ציטוט



כינוי: 

גיל: 50




65,379
הבלוג משוייך לקטגוריות: אינטרנט
© הזכויות לתכנים בעמוד זה שייכות לעומר טרן אלא אם צויין אחרת
האחריות לתכנים בעמוד זה חלה על עומר טרן ועליו/ה בלבד
כל הזכויות שמורות 2025 © עמותת ישראבלוג (ע"ר)