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

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

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

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

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

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



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

מצטער - אין כניסה. על בקרות גישה.

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

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

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

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

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

בקרת גישה

• בקרת גישה, כשמה היא, מבקרת וקובעת "מי יכול לעשות מה" .
• מי הם הסובייקטים? מי רוצה לגשת?
• מי הם האובייקטים? למי\מה רוצים לגשת?
• בקרת גישה מכוונת להגן על:
• סודיות.
• שלמות.
• זמינות.
• בקרת גישה מכוונת לצמצום סיכון כזה או אחר;
• Risk = Threat x Vulnerability

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

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

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

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

• סובייקט, Subject – ACTIVE. סובייקט (נתין, בעברית) הינו המשתמש, התהליך או ההתקן המשמש כישות פעילה במודל בקרת הגישה. הסובייקטים הסטנדרטים במערכות הפעלה כגון NDS (Novell), Windows NT 4.0 ו- Active Directory במערכת Windows -  מתחלקים ל-2 קבוצות עיקריות: מובנה או מותאם.
• סובייקטים מובנים (Built-In) יכולים להתקיים בכל מיני צורות ואופנים אך הם מוגדרים בעת פיתוח\תכנון מערכת ההפעלה.
• סובייקטים מותאמים User-defined נוצרים ע"י מנהל המערכת – באופן ידני.
• אובייקט – PASSIVE – הינו הישות הפאסיבית המכיל מידע. אובייקט יכול להיות קובץ, תיקייה, התקנים, פורטים (Ports) ועוד.
• חוקים – FILTERS – במערכת ההפעלה UNIX, החוקים הסטנדרטיים הם קריאה, כתיבה וביצוע Read/Write/Execute ובמערכות Windows Read/Write/Execute/No Access . במערכות הפעלה חדשות יותר, כגון Windows 2008, קיימים יותר מ-30 חוקים, הידועים יותר כהרשאות Permissions.
• התוויות – מהמילה תווית – Label. התוויה קובעת מהי רמת הרגישות של אובייקט. זהו אוסף חוקים הנקבע בתלות רמת הרגישות של האובייקט אל מול הסובייקט. מילה נרדפת בהקשר זה היא "רמת בטיחות". חשוב לדעת כי לא לכל בקרות הגישה קיימות התוויות. בנוסף, אין להתבלבל בין התוויה לבין הרשאה. התוויה מוגדרת כאוסף חוקים המתווספים לאוסף הקיים (להלן ההרשאה).

מודלי בקרת גישת

• מבוסס תפקידים, Role-Based.
• לעתים מוצג כטבלת\מטריצת הרשאות\גישות.
• מבוסס חוקים, Rule-Based .
• מבוסס רשומה, List-Based – שם נרדף לרשימות גישה, Access Control List.
• מבוסס "אסימון", Token-Based.
• מטריצת סיכונים, Risk Matrix .

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

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

סוגי בקרות גישה

 

בקרת גישה מנדטורית (כפויה) – Mandatory Access Control או MAC

• בקרת הגישה נשלטת ע"י המערכת. MAC דורשת עבודה רבה לתחזוקה וזאת משום שלכל הנתונים רמת רגישות מסוימת בעוד שלמשתמשים רמת סיווג אחרת – בהתאם לדרישת העסק\ארגון.
• כאמור, בקרת הגישה מבוססת על התווית רגישות וסיווג המידע.
• לכל ישות קיימת רמת גישה Access Level כאשר:
• ישות
• משתמשים.
• אובייקטים.
• רמת גישה
• סיווג – Classification .
• משתמש יכול לגשת לאובייקט רק אם הוא בעל רמת גישה מתאימה.
• הגישה נאכפת ע"י המערכת עצמה – ללא אפשרות ל-עוקפה.

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

מה בין MAC ל-DAC. תמונת קליפ-ארט.

דוגמאות ליישום MAC 

• SELinux
• SCOMP
• eTrust CA-ACF2 by CA

יתרונותיה של בקרת גישה מסוג MAC

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

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

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

בקרה מבוססת שיקול דעת – Discretionary Access Control או DAC

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

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

בסוג בקרה זה, בעל המשאב (קובץ, תיקיה, תוכנה...) הינו זה שמקצה את הגישה לאותו משאב. בעל המשאב יכול להיות המשתמש שיצר קובץ או תיקיה – וזה מחליט על סוגי ההרשאה, אם קיימים, לסובייקטים אחרים.
תחת בקרת DAC, נוכל לבטא את מדיניות האבטחה כדלקמן: ישנם בעלים (A) , ישנו אובייקט (B) , וישנם משתמשים אחרים (C) . אז:
DAC הוא: "הבעלים (A), מחליט למי מבין שאר המשתמשים (C) , יש רמת גישה כלשהי לאובייקט (B)" .

דוגמאות ליישום DAC :

• רוב מע' UNIX , מע' Windows ממשפחת NT – כולן משתמשות ב-DAC .

הדוגמא הכי קלאסית היא זו של מע' ההפעלה Windows. בעלים של קובץ יכול, ע"פ שיקול דעתו, להעניק הרשאה למשתמשים נוספים בנוגע לקובץ (או קבצים אחרים בבעלותו).
יישום הבקרה נעשה לעתים קרובות ע"י מטריצת גישה – Access Matrix . מטריצת גישה נותנת את היכולת להתאים גישת סובייקט לאובייקט – בעזרת העמודות ו\או השורות עליהן היא בנויה. מימוש בעזרת חלוקה לעמודות תיצור רשימות גישה, או ACL – Access control List.

קובץ X	משה	רינה	יוסי
R(Read only)			OWNER, RW(Read and Write)	יוסי
RW	R	R	R	ליאת
R		OWNER, RW		רינה

יתרונות DAC :

• נוח.
• קל לשימוש וגמיש (Flexible) .
• המשתמש מרגיש כי הוא נמצא בשליטה כלשהי.
• קל להבנה.
• מגדיר את המושג בעלות (Ownership) בבקרות גישה.
• מימוש ע"פ התאמה אישית.

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

חסרונות ה-DAC

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

בהתאם לחסרונות ה- DAC , נסיק כי הבקרה לא מיועדת לסביבות בהן מיושמות בקרות MAC.

בקרה ללא שיקול דעת – Non-Discretionary Access Control או NDAC

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

בקרת גישה מבוססת תפקידים – RBAC

• RBAC, Role-Based Access Control. כן, רבאק.
• ללא שיקול דעת.
• סמכות מרכזית\ריכוזית.
• ניהוליות מבוססת בסיסי נתונים.
• ההרשאות ניתנות לכל תפקיד ותפקיד.

נלקח מ-identitysander

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

דוגמאות ליישום RBAC

• בסיסי נתונים.
• גישה לבקשות שאילתה.
• מוצרי מיקרוסופט למיניהם:
• מיקרוסופט מיישמת RBAC במוצריה ע"י יצירת תפקידים כגון Data Reader\Data Writer

נמחיש; תחילה, נקצה תפקידים:

עובד פיתוח	עובד מ. אנוש	מנהל רשת
X	X	X	יוסי
	X		רינה
X			ליאת
X		X	משה

אח"כ, נקצה הרשאות:

קבצי פיתוח	עובדי החברה	משתמשי הרשת
R	R	OWNER, RW	מנהל רשת
	RW		עובד משאבי אנוש
OWNER, RW		R	עובד פיתוח

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