משולש CIA: סודיות, שלמות וזמינות

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

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

#מהו משולש CIA

כל תכונה עונה על שאלה אחרת:

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

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

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

#למה שלוש תכונות ולא אחת

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

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

#סודיות: הקובץ שדלף

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

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

#בקרות אופייניות לסודיות

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

#בדיקה אופציונלית: הצפנה בפעולה

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

printf 'Patient: J. Example, diagnosis: placeholder\n' > record.txt
export DEMO_PASS='lab-only-passphrase'
openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:DEMO_PASS -in record.txt -out record.enc
od -A x -t x1z record.enc | head -3
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:DEMO_PASS -in record.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:wrong -in record.enc -out /dev/null

על המחשב שבו זה הורץ (Windows 11, ‏Git Bash, ‏OpenSSL 3.2.4), הפלט היה:

000000 53 61 6c 74 65 64 5f 5f e4 81 09 19 9d 68 fe de  >Salted__.....h..<
000010 54 5b 6c 39 12 1a 38 01 b3 03 ac b8 66 be 3b 4b  >T[l9..8.....f.;K<
000020 68 ae 58 39 8f 74 f1 59 23 27 09 fe b7 cf cc 58  >h.X9.t.Y#'.....X<
Patient: J. Example, diagnosis: placeholder
bad decrypt
D4C00000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../openssl-3.2.4/providers/implementations/ciphers/ciphercommon_block.c:107:

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

#שלמות: ההורדה ששונתה

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

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

#Hashes: זיהוי שינוי

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

הפקודות בהמשך יוצרות קובץ, רושמות את ה-hash שלו ב-SHA-256 ומשנות את התוכן שלו:

printf 'Transfer: 10.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt
printf 'Transfer: 1000.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt

הפלט שהתקבל:

f5ff0bd125880721c12f4eeecd95eb1a03fbc98f61dbd4ea2235cd7c902aa936 *transfer.txt
486ca9f3224c8003ff043ae09f3d1bc6cbe5008859a81c08e95da91945812b04 *transfer.txt

ל-hash השני אין שום דבר משותף עם הראשון, למרות שהשינוי היה אפס אחד נוסף. הבדיקה הופכת לשימושית כשמחזיקים את ה-hash הצפוי ומשווים אליו. שומרים את ה-hash המקורי בקובץ release.sha256, ואז מאמתים:

sha256sum -c release.sha256

עבור הקובץ המקורי הפקודה הדפיסה release.txt: OK. אחרי שינוי הקובץ היא הדפיסה:

release.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

הפקודה יוצאת עם סטטוס 1, כך שסקריפט יכול לעצור עליה.

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

#חתימות דיגיטליות: הוכחה מי פרסם

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

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

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out release.sig release.txt
openssl dgst -sha256 -verify pub.pem -signature release.sig release.txt

על הקובץ המקורי האימות הדפיס Verified OK. אחרי שהקובץ שונה, אותו אימות הדפיס Verification failure, ואחריו שורות שגיאה של OpenSSL שכוללות נתיבי מקור. השורות האלה הושמטו כאן.

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

#בקרות אופייניות לשלמות

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

#זמינות: האתר שנפל

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

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

#בקרות אופייניות לזמינות

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

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

#איך שלוש התכונות ממופות לבקרות

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

#שיטה לשימוש חוזר

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

#תרגיל על נייר: סיווג עשרה אירועים

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

1. מחשב נייד נגנב מרכב. הדיסק שלו לא מוצפן, ורשימת הלקוחות שעליו קריאה.
2. אתר מראה מגיש installer ששונה. משתמשים שמשווים את ה-hash שלו ב-SHA-256 לערך שהספק פרסם מוצאים חוסר התאמה.
3. כופרה מצפינה את שרת הקבצים של החברה. עובדים לא יכולים לפתוח קבצים משותפים במשך שלושה ימים.
4. עובד שולח בטעות גיליון שכר לכתובת אימייל פרטית.
5. הצפת תעבורה פוגעת באתר הציבורי של החברה. לקוחות מקבלים timeouts במשך שש שעות.
6. גורם פנימי עורך רשומת העברה כך שהסכום מופיע כ-1,000 במקום 10. שום רשומת לוג לא מתעדת את השינוי.
7. תוקף משיג בפישינג את הסיסמה של מנהל מסד נתונים ומוריד את טבלת הלקוחות.
8. שירות התזמון של בית חולים רץ על שרת יחיד בלי שרת בהמתנה. כשל דיסק מפיל אותו ליום.
9. דף תשלום שולח את המחיר מהדפדפן לשרת, והשרת מקבל אותו. משתמש משנה את המחיר מ-100 ל-1, וההזמנה נרשמת ב-1.
10. פורטל תמיכה מציג שמות וכתובות של לקוחות אחרים לכל משתמש מחובר.

#תשובות

1. C. הנתונים היו קריאים לכל מי שהמחשב הנייד בידיו. הצפנה במנוחה הייתה מגינה עליהם.
2. I. הקובץ ששונה כבר לא תואם ל-hash שפורסם. השוואת ה-hash זיהתה את השינוי.
3. A. העובדים איבדו גישה לקבצים שלהם. ההצפנה שהכופרה מבצעת גם משנה את הקבצים, כך שאפשר לטעון גם ל-[I]. התיאור מתמקד בהשבתה.
4. C. נתוני שכר הגיעו לכתובת מחוץ לחברה. זו טעות של חשיפה, והיא עדיין אובדן סודיות.
5. A. התעבורה מנעה מלקוחות לגיטימיים להגיע לאתר.
6. I. הרשומה שונתה בלי הרשאה, והלוג החסר פוגע גם באחריותיות.
7. C. סיסמה גנובה הובילה לחשיפת טבלת הלקוחות. אימות הוא בקרת סודיות, ולכן גניבת הסיסמה היא הפגיעה הראשונה.
8. A. לשרת היחיד לא היה failover, ולכן דיסק אחד שנכשל עצר את השירות.
9. I. השרת סמך על ערך בשליטת המשתמש, ולכן ההזמנה הרשומה כבר לא תואמת למחיר האמיתי. לעולם לא נותנים לצד הלקוח לקבוע מחיר.
10. C. נתונים אישיים של לקוחות אחרים היו גלויים למשתמשים שלא הורשו לראות אותם.

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

#טעויות נפוצות

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

#איך ממשיכים

קוראים במלואם את סעיפי המבוא של NIST SP 800-12 Rev. 1 ואת הגדרות ההשפעה ב-FIPS 199. הם משתמשים במילים שנלמדו כאן, וזה יקל על קריאת המסמכים הפורמליים.

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

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

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

#מקורות

• NIST, An Introduction to Information Security, NIST SP 800-12 Rev. 1, June 2017: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, February 2004: https://csrc.nist.gov/pubs/fips/199/final