נספח: קריפטוגרפיה.

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

נספח א': קריפטוגרפיה

 

אלגוריתם (Algorithm) – סט חוקים מתמטיים ולוגיים המרכיבים את פונקציות ההצפנה.

צופן (Cipher) – בקריפטוגרפיה, שם נרדף לאלגוריתם.

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

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

ניתוח צפנים ( Cryptoanalysis ) – הפרקטיקה לזיהוי וגילוי "פגמים" במערכות הצפנה.

קריפטולוגיה ( Cryptology ) – תורת ההצפנה המבססת ניתוח צפנים ומערכות הצפנה.

קידוד\הצפנה ( Encipher ) – הפעולה המשנה נתונים לצורה בלתי ניתנת לקריאה.

פיענוח ( Decipher ) – הפעולה המשנה נתונים לצורה הניתנת לקריאה.

מפתח ( Key ) – רצף סיביות (Bits) המנחות את פונקציות ההצפנה באלגוריתם.

אשכולות מפתח ( Key Clustering ) – מצב בו שני מפתחות שונים יוצרים את אותו טקסט מוצפן מאותו טקסט לא מוצפן.

מרחב מפתחות ( Keyspace ) – הטווח של ערכים אפשריים ליצירת ולבניית מפתחות.

טקסט גלוי ( Plaintext ) – נתונים הניתנים לקריאה. לעתים נקרא גם טקסט-נקי Cleartext .

צופן החלפה, שיכול ( Substitution cipher ) – שיטת הצפנה העושה שימוש באלגוריתם המחליף\משנה ערך מסוים בערך אחר.

צופן סיטאלה ( Scytale cipher ) – כלי הצפנה עתיק-יומין העושה שימוש בנייר ומקל. שימש את הצבא היווני.

עיקרון קרקהופס ( Kerckhoff's principle ) – עיקרון המנחה שימוש באלגוריתמים ידועים ובתנאי ש-רק המפתחות יהיו בלתי-ידועים.

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

מחולל מספרים ( Number generator ) – אלגוריתם היוצר ערכים (מספרים) אשר משמש פונקציות הצפנה מסוימות וזאת ע"מ ליצור אקראיות.

צופן מפתח-רץ ( Running key cipher ) – צופן החלפה אשר יוצר מעין זרימת ערכי מפתח מקטעי טקסט מוסכמים לצדדים.

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

סטגנוגרפיה ( Steganography ) – שיטה להסתרת מידע ע"ג מדיה נראית (תמונה, וידאו...).

ניהול זכויות דיגיטליות ( Digital rights management – DRM ) – טכנולוגיית בקרת גישה אשר משמשת להגנה של תכנים בעלי זכות יוצרים.

צופן שחלוף ( Transposition ) – שיטת הצפנה המזיזה (ע"י תמורה) ערכים.

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

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

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

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

אלגוריתם אסימטרי ( Asymmetric algorithm ) – שיטת הצפנה העושה שימוש בשני מפתחות – ציבורי ופרטי. לעתים נקרא צופן מפתח ציבורי.

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

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

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

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

ערבוב ( Confusion )- תהליכי החלפה המשמשים פונקציות הצפנה ע"מ להגביר אקראיות.

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

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

מחולל זרם מפתחות ( Keystream generator ) – רכיב של אלגוריתם הזרמה אשר יוצר ערכים אקראיים למטרת הצפנה.

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

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

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

מעטפת דיגיטלית ( Digital envelope ) – הודעה אשר מוצפנת ע"י מפתח סימטרי כאשר המפתח הסימטרי מוצפן ע"י מפתח אסימטרי.

תקן הצפנת נתונים ( Data encryption standard, DES ) – צופן בלוקים סימטרי שנבחר ע"י NIST בשנת 1976 כתקן להצפנה. תקן זה עושה שימוש במפתחות בגודל 56 סיביות, בבלוקים בגודל 64 סיביות וב-16 סיבובי חישוב.

לוציפר ( Lucifer ) – הינו האלגוריתם שנבחר ל-DES. במשך הזמן שונה וכיום נקרא "אלגוריתם להצפנת נתונים" – Data Encryption Algorithm, DEA .

אלגוריתם להצפנת נתונים ( Data encryption algorithm, DEA ) – הינו האלגוריתם שנבחר לתקן הצפנת נתונים (DES). פועל ע"י שימוש במפתחות בעלי 56 סיביות, בבלוקים של 64 סיביות וב-16 סיבובי חישוב.

תקן הצפנה מורחב ( Advanced encryption standard, AES ) – תקן אמריקאי להצפנה אשר ייעודו להחליף את התקן להצפנת נתונים (DES). זהו צופן בלוקים סימטרי העושה שימוש בבלוקים של 128 סיביות ובמפתחות בגדלים שונים (128, 192, 256) סיביות.

ריינדל ( Rijndael ) – צופן בלוקים סימטרי אשר נבחר לשימוש בתקן המורחב (AES). עושה שימוש בבלוקים של 128 סיביות ובמפתחות בגדלים שונים (128, 192, 256) סיביות.

תקן הצפנת נתונים משולש ( TripleDES, 3DES) – צופן בלוקים סימטרי מסוג DES אשר מבצע פי 3 פעולות בבלוק נתון.

אלגוריתם בינלאומי להצפנת נתונים ( International data encryption algorithm, IDEA ) – צופן בלוקים סימטרי העושה שימוש במפתחות של 128 סיביות ובבלוקים בגודל 64 סיביות.

Blowfish – צופן בלוקים סימטרי העושה שימוש בבלוקים של 64 סיביות ובמפתחות בעלי גדלים שונים.

RC4  - צופן הזרמה סימטרי שפותח ע"י רון ריבסט (מיוצרי RSA). משמש את פרוטוקול SSL ו-WEP .

RC5  - צופן בלוקים סימטרי העושה שימוש בבלוקים בגדלים שונים (32, 64, 128 סיביות) ובמפתחות בגדלים שונים (0-2040 סיביות).

RC6 – צופן בלוקים סימטרי המבוסס על אלגוריתם RC5. עושה שימוש בבלוקים של 128 סיביות ובמפתחות בגדלים 128, 192, 256 סיביות.

אלגוריתם דיפי-הלמן ( Diffie-Hellman algorithm ) – האלגוריתם האסימטרי הראשון שנוצר. מיועד להחלפת ערכי מפתחות סימטריים. מבוסס על לוגריתמים במרחבים סופיים.

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

אלגוריתם אל-גמאל ( El Gamal algorithm ) – אלגוריתם אסימטרי המבוסס על אלגוריתם דיפי-הלמן. משמש להצפנה, חתימות דיגיטליות והחלפת מפתחות.

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

אלגוריתם תרמיל הגב ( Knapsack algorithm ) – אלגוריתם אסימטרי המבוסס על "בעיית תרמיל הגב" הידועה. אלגוריתם זה פוענח ונפרץ ולא נעשה בו יותר שימוש.

גיבוב חד-כיווני ( One-way hash) – תהליך הצפנה הלוקחת כמות שרירותית של נתונים ומייצרת ערך בעל גודל קבוע. משמש בעיקר להבטחת שלמות (Integrity).

קוד אימות מסרים ( Message authentication code, MAC) - פונקציית גיבוב (Hash) העושה שימוש במפתחות. משמשת בעיקר להבטחת שלמות נתונים ואימות השולח.

קוד אימות מסרים מגובב ( Hashed message authentication code, HMAC ) – פונקציית גיבוב העושה שימוש במפתח סימטרי לגיבובו. משמשת בעיקר להבטחת שלמות ואימות השולח.

MAC מבוסס צופן בלוקים ( Cipher block chaining message authentication code, CBC-MAC) – טכניקה ליצירת MAC ע"י שימוש בצופן בלוקים. משמשת בעיקר להבטחת שלמות ואימות השולח.

קוד אימות מסרים מוצפן ( Cipher message authentication code, CMAC ) – מבוסס MAC ומעניק הגנה רחבה יותר מאשר CBC-MAC.

קוד אימות מסרים משולב CBR/CBC ( Counter/CBC MAC ) – מצב צופן בלוקים המשלב מצבי CTR  ו- CBC-MAC. מפתח הצפנה יחיד משמש למטרות אימות והצפנה.

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

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

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

תקן חתימה דיגיטלית ( Digital signature standard, DSS ) – תקן אמריקאי המציג אילו אלגוריתמים מורשים ליצירת חתימות דיגיטליות בשימוש מדיני-ממשלתי. 

רשויות אישורים ( Certificate Authority, CA ) – חלק מה-PKI. מרכיב אשר יוצר ומתחזק תעודות דיגיטליות במשך מחזור חייהם.

רשויות רישום ( Registration authority, RA ) – חלק מה-PKI. מרכיב אשר מאמת את זהות מבקש התעודה הדיגיטלית.

רשימת ביטול אישורים ( Certificate revocation list, CRL ) – רשימה אשר מתוחזקת ע"י רשות האישורים כחלק מה-PKI, אשר מכילה מידע אודות כל התעודות הדיגיטליות אשר בוטלו.

פרוטוקול סטאטוס מקוון ( Online certificate status protocol, OCSP ) – שיטה לאוטומטיזציה של תחזוקה וניהול תעודות דיגיטליות מבוטלות.

תעודה\אישור דיגיטלי ( Certificate ) –זהות דיגיטלית כחלק מה-PKI. מיוצרת ומתוחזקת ע"י רשות האישורים ומשמשת לאימות (Authentication).

קישור מוצפן ( Link encryption ) – טכנולוגיה אשר מצפינה חבילות (Packets) שלמים (כולל ה-Headers וה-data payload) אשר נשלחים ללא אינטראקציה מצד השולח.

הצפנת קצה לקצה ( End-to-end encryption ) – שיטת הצפנה המשמשת לשליחת הודעות מוצפנות ויחידות  - ולא מצפינה את כל הפאקט.

הרחבת יכולות העברת מידע בדואר האלקטרוני ( Multipurpose internet mail extension, MIME ) – תקן המאפשר תמיכה\יכולת להעברת הודעות בצורה בינארית בהודעות דואר אלקטרוני.

Secure MIME, S/MIME – הרחבת תקן יכולת העברת מידע בדואר האלקטרוני – בצורה מאובטחת. מציגה שימוש בהצפנת מפתח ציבורי לאבטחת נתוני MIME.

Pretty Good Privacy, PGP – מערכת הצפנה שפותחה ע"י פיל צימרמן המשלבת הצפנת מפתח ציבורי למטרות דואר אלקטרוני והצפנת נתונים.

הצפנה קוונטית ( Quantum cryptography ) – שימוש בפונקציות של המכניקה הקוונטית למטרות של החלפת מפתחות.

HTTPS – שילוב של פרוטוקול ה-HTTP עם פרוטוקול SSL/TLS. מאפשר חיבור מאובטח בין צדדים ברשת האינטרנט. משמש בעיקר לעסקאות מקוונות ולגופים אשר מחויבים בהתקשרות מאובטחת.

עסקה אלקטרונית מאובטחת ( Secure electronic transaction, SET ) – "תקן" מסחר אלקטרוני (e-commerce) אשר פותח ע"י חברת Visa ו-MasterCard – ולא התקבל בקהילות הסחר האלקטרוני.

עוגיות ( Cookies ) – קבצי נתונים המשמשים דפדפנים ושרתים לשמירת הגדרות, מצבי נתונים ושיחות (Sessions).

Secure Shell, SSH – פרוטוקול רשת אשר מאפשר חיבור מאובטח למערכות מרוחקות. פותח למטרת החלפת פרוטוקול ה-Telnet שאינו מאובטח.

IPsec – תקן המוגדר כדה-פאקטו לפרוטוקול VPN. הינו סט פרוטוקולים המשמש לתקשורת IP מאובטחת (מוצפנת) וכן לאימות.

Authentication header protocol, AH – פרוטוקול כחלק מתקן ה-IPsec המשמש להבטחת שלמות ואימות.

Encapsulating security protocol, ESP  - פרוטוקול כחלק מתקן ה-IPsec המשמש להצפנה, הבטחת שלמות והבטחת זהות (אימות).

מצב תעבורה ( Transport mode ) – מצב בו מתאפשר לפרוטוקולי ה-IPsec לפעול, ובכך להעניק הגנה לתכולת הנתונים בחבילה (Packet data payload).

Tunnel mode - מצב בו מתאפשר לפרוטוקולי ה-IPsec לפעול, ובכך להעניק הגנה לכל החבילה, כולל ה-Headers וה-data payload.

Internet security associationand key management protocol, ISAKMP – פרוטוקול המשמש ליצירת framework לאימות בין חיבורי IP. בד"כ משמש את ה-IKE להחלפת מפתחות.

התקפה פאסיבית ( Passive attack ) – תקיפה אשר בד"כ מבצעת איסוף וגילוי נתונים ללא אינטראקציה ממשית בפעילויות ההתקשרות. דוגמא טובה הינה "רחרוח", Network sniffing.

התקפה אקטיבית ( Active attack ) – תקיפה אשר מבצעת אינטראקציה בפעולות העיבוד וההתקשרות.

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

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

Chosen-ciphertext attack – כחלק מניתוח צפנים, בתקיפה זו התוקף מתמקד בטקסט מסוים ויחיד – ובד"כ מצליח לפענחו ללא מפתח הצפנה ידוע.

ניתוח צפנים דיפרנציאלי ( Differential cryptanalysis ) – שיטה לניתוח צופן ע"י הבחנה בדפוסי השינוי בפלט כפונקציה של הקלט.

ניתוח צפנים לינארי ( Linear cryptanalysis ) – שיטה לניתוח צופן ע"י למידה וקירוב העתקות (לינאריות) סופיות בתהליך ההצפנה.

התקפת ערוץ צדדי ( Side-channel attack ) – תקיפה המשתמשת בנתונים שנאספו כגון זמנים וצריכת חשמל כדי לזהות פונקציות עיבוד ומידע רגיש.

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

התקפה אלגברית ( Algebraic attack ) – התקפה קריפטוגרפית (או כחלק מניתוח צפנים) אשר מנצלת חולשות פנימיות במבנים אלגבריים של פונקציות מתמטיות.

התקפה אנליטית ( Analytic attack ) – התקפה קריפטוגרפית (או כחלק מניתוח צפנים) אשר מנצלת חולשות במבנה אלגוריתמי.

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

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

Meet-in-the-Middle attack – להבדיל מ-Man-in-the-Middle attack , זוהי התקפה קריפטוגרפית המנסה לזהות ולגלות בעיות מתמטיות מ-2 קצוות שונים ( 2 different ends ).

 

התמודדות עם אירועי אבטחת מידע

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

• התכוננות – Preparation.
• זיהוי – Identification.
• הֲכָלָה – Containment.
• מיגור – Eradication.
• התאוששות – Recovery.
• הפקת לקחים – Lessons learned.

צעדי היסוד לטיפול באירוע אבטחת מידע

התכוננות - Preparation

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

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

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

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

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

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

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

זיהוי - Identification

• איך מזהים אירוע\תקרית?
• היה מוכן להתריע בהקדם – אך אל תקפוץ מיד למסקנות.
• "זאב-זאב" ...
• חפש עובדות. כל דבר הניתן להסקה ללא עוררין.
• יידע את האנשים הנכונים.

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

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

קריטריון SMART להשגת יעדים. האיור באדיבות psnz

אקסיומה ברורה היא; אם אין אחראי = אין בכלל אחריות = קבלת החלטות שגויות. אם קיים אירוע בסגנון "אתה יכול לבדוק את זה?" – אין צורך להזעיק את כל צוות הטיפול שכן הצוות מיומן לפעולות חירום "של ממש". לכן, מומלץ לקיים תרגולים ואימונים למנהלי הרשת ו\או מנהלי אבטחת המידע לצורך טיפול באירועים קטנים כאלו.
מטפלי אירועי אבטחת מידע העובדים במשרה שאינה מלאה – צריכים לקבל משימות המאפיינות בדיוק את מה שמצפים מהם: איכות חקירה, קבלת אחריות, איסוף ראיות ויצירת תיעוד.
לאחר הקביעה כי אירוע מסוים הינו אלה תקרית אבטחה, יש לנקוט בצעדים ע"מ לבנות ראיות לעבירה פלילית ו\או אזרחית. יש לזהות בהקדם האפשרי עדים ולקבל מהם הצהרות בכתב בדבר מה שהם ראו או שמעו (שוב, בהקדם – כאשר הזיכרון נחשב "טרי").
בנק' זו, יש לקבל החלטה; האם לערב את רשויות החוק. החלטה זו נקבעת ע"י הדרג הניהולי אלא אם מצוין אחרת בנהלי החברה. קיימות לא מעט חברות שיחליטו להכיל את התקרית. במצב זה, קיימות שתי גישות: הגישה הראשונה היא להכיל את התקרית ולמגרה מידית – וזאת ע"מ לשמור על יציבות אמון הלקוחות של החברה. הגישה השנייה מציבה מטרה אחרת – למידה, מעין גישה של Watch and learn.
בכל אופן, יש לבצע גיבוי בינארי מלא של המערכת לפני שינוי או התעסקות עם רכיבים העלולים להוות ראיות.

הכלה - Containment

אוקי, התכוננו לתקרית, זיהינו אותה אבל מה עכשיו?

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

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

מיגור - Eradication

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

לפני השבת המערכת לאוויר, מטפל האירוע חייב לתקן\לפתור את הבעיה. אחרת, הפרצה דרכה פעלה ההתקפה – עדיין קיימת. השמדת נתוני המערכת נחשבת לדרך קיצור. נכון, אמנם פעולה שכזו תנטרל כל קוד שהושתל – אבל ההזדמנות להידבקות חוזרת באמצעות אותו ערוץ (פרצה) – עדיין קיימת. רבים המקרים בהם אנשי אבטחת המידע מעדיפים פשוט להתקין מערכת חדשה והפלא ופלא – לאחר כמה ימים המערכת נפרצה שוב – ע"י אותו ווקטור פריצה. לכן, דרך הפעולה היעילה ביותר היא לקבוע ולזהות את סיבות התקרית – למצוא מהו אותו ווקטור פריצה (ערוץ הפרצה) ולמגר אותו.
אם וכאשר המערכת המסוימת נפרצה – ימים ספורים יעברו עד שכל האקר ברשת יעמוד בתור כדי לנסות להגיע לסיפוק לא ברור – וינסה לפרוץ לאותה מערכת. לכן, חשוב לא פחות למצוא את ערוץ הפריצה ולתקנו.
טריקים ישנים למיגור פריצות נשנות כוללים החלפת כתובת ה-IP ושינוי שם המערכת. לעתים הדבר עוזר אך לרוב, במיוחד כיום – ימצאו אתכם, No matter what.
סורקי חולשות, כגון Nessus, Nmap וכו., מסוגלים לזהות חולשות - הן ברשת הפנימית והן ברשת האינטרנט. קיימות תוכנות מסחריות (ומשום מה, גם יקרות) המעניקות יכולת זיהוי חולשות באופן מעמיק ביותר – ללא צורך בידע טכני מהותי. אם כסף מהווה מחסום, תמיד קיימת האפשרות לשכור מומחה המעניק שירותי בדיקה וסריקה – ולקבל באופן חד-פעמי דו"ח מפורט.
חשוב לי לציין כי Nmap הינה תוכנה בקוד פתוח וזמינה בחינם לכל דורש. באופן אישי הוא אחד החביבים עליי ובכלל – זהו כלי בעל עוצמה רבה.

דו"ח סריקה טיפוסי של Nmap

התאוששות - Recovery

• וודא כי בעת שחזור – אינך משחזר קוד נגוע (קרי קבצים ששונו בעת האירוע).

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

הפקת לקחים וקביעת המלצות

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

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



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