הגנה בענן עם Cloud App Security

סדרת מאמרים לביצוע הגדרות, אינטגרציה עם מערכות נוספות, ניהול וביצוע בקרות ופעולות אבטחה וכן מענה לבעיות לאירועי אבטחה בשירות Microsoft Cloud App Security (בקצרה MCAS). המאמר של הגנה בענן עם Cloud App Security מביא אפשרויות מסוימות להגנה על פערים ובעיות בענן.

השאלה הראשונה, למה Microsoft Cloud App Security? אחרי בדיקה ועבודה יומיומית עם מערכות CASB שונות אפשר לומר שמערכת MCAS עדיפה ובעלת יתרונות רבים החל משלב ההטמעה, אינטגרציה עם מערכות Microsoft, אינטגרציה עם מערכות אבטחה צד שלישי, חיבור מול הסביבה המקומית וניהול יומיומי.

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

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

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

הגנה עם CASB

מה כל כך חשוב במערכת CASB? ברגע שאנו בענן גם אם באופן חלקי אנו חייבים לדעת מה מתרחש בכל רגע נתון ולכן מערכת CASB היא העיניים שלנו בענן.

הצריכה והפעולות שלנו בארגון בשירותי הענן נעשית על גבי ספקי ענן שונים (לעיתים Multi-Cloud), אפליקציות ענן מגוונות, שילוב בתצורה היברידית ונוספים. כאשר מחברים את כל הפעולות אשר מתבצעות ע”י משתמשי קצה, Guestים, אדמינים, קבלני משנה ועוד, אנו חייבים לדעת מה מתרחש.

תצורה עבודה עם מערכת CASB נחלקת למספר דגשים:

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

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

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

Protect – בשלב האחרון שלאחר איסוף, חקירת המידע ושליטה על הפעולות אנו כבר מבצעים הגנה על האפליקציות השונות שאנו מסווגים אותם שאפליקציות sanction/unsanction וע”י כך אנו מחילים פעולות מסוימות בכדי להגן על המידע, כגון: שליטה על הרשאות או אכיפת DLP ועוד.

הגנה באמצעות MCAS

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

האינטגרציה של MCAS עם מערכות מבוססות Microsoft בענן כדוגמת Azure Information Protection או Azure AD Condtional Access היא מובנת, אבל השילוב עם מערכות צד שלישי כדוגמת zScaler או OKTA נעשות בצורה שקופה כאילו הם חלק מהענן או מערכת נוספת של Microsoft.

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

כאשר עובדים עם מערכת MCAS (ובכלל CASB) ישנם תרחישים רבים שלהם אנו צריכים לתת מענה, בין היתר התרחישים הבאים:

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

במערכת MCAS ניתן להוציא פעולות כאלה תוך רגעים בודדים ולאחר מכן ניתן לצלול ולקבל בין היתר את המידע הבא:

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

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

סיכון מסוג Account TakeOver – תשתית MCAS מאפשרת זיהוי של Outlook Rules אשר נוצרו באופן מסוים ויכולים לכלול בין היתר חוקים, כגון: Forward All Email, Auto Forward, חוקים המוגדרים עם חשבון דואר חיצוניף חוק המוגדר ללא פרטים מלאים וכן הלאה אך הגרוע מכולים הם חוקי Outlook אשר מוגדרים באופן מוסתר ואפילו מוסתר ברמת משתמש הקצה.

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

סיכון מסוג Malicious folder manipulation – בעיה נוספת של תיבות דואר היא יצירת חוק Outlook אשר מעביר פריטים בין תיקיות שונות בתוך תיבת הדואר של המשתמש ע”י שימוש בפרמטרים שונים, בין היתר פרמטרים המוגדרים ע”י מזהים שונים כגון מילים או מספרים.

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

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

ארכיטקטורה כללית

מערכת MCAS מבוססת בענן בלבד אך מאפשרת לבצצע יישום מבוסס בתצורת ענן, תצורת Hybrid ואף תצורה מקומית. התצורה שהיא מבוססת API ישנםמספר אפשרויות ויתרונות:

• יישום מהיר ופחות מורכב מפתרון מקומי
• אינטגרציה מלאה מול שירות הענן השונים של: Office 365, Azure
• עבודה מול מרקט של 13,000 אפליקציות ויותר
• עבודה מול Firewall ומול Proxy רבים, כגון: Cisco, Bluecoat, Checkpoint, Squid ועוד
• זיהוי ותחקור מהיר של מידע ארגוני

מכיוון שתצורת MCAS מבוססת ענן החיבור אל שירותי הענן האחרים נעשה בתצורת API, תצורת API-based integration מאפשרת חיבור ישיר אל שירות Office 365 או שירות Azure באמצעות קונקטורים אפליקטיביים (App Connectors).
אותם קונקטורים אפליקטיביים שקיימים בשירות CAS מאפשרים את החיבור מול כל אותם קונקטורים שקיימים בשירות Azure ומאפשרים לקבל מידע פרטני על כל מידע ופעולה.
*קונקטורים בשירות Azure מסווגים לפי קונקטורים שונים, כדוגמת: Core, Enterprise, Triggers, Custom Connector.

החיבור של MCAS מול שירותי הענן של Azure ושל Office 365 קיים כבר ולכן היישום של CAS מצריך את שיוך השירות, ביצוע הגדרות מול Firewall וביצוע ארבעת השלבים Framework Security.
לאחר איסוף כל אותם לוגים ע”י שירות CAS באמצעות מנגנון Cloud Discovery מתבצע התחקור מול שירותי הענן ע”י API באמצעות הקונקטורים הקיימים.

איך עובד גילוי המידע (Cloud Discovery) – בתהליך של גילוי המידע ע”י מנגנון Cloud Discovery השירות מנתח את כל הלוגים, התעבורה והאפליקציות שעוברות דרך Firewall ארגוני ודרך האפליקציות הארגוניות בשירות הענן, ולכן הגילוי נעשה בשני קטגוריות/סוגי גילוי אשר קשורים אחד אל השני:

זיהוי אפליקציות (Discovery Apps) – הקטלוג (Cloud app catalog) של האפליקציות כולל מעל 15,000 אפליקציות אשר מדורגות ע”י 50 ערכים (לפחות) ומספקות נראות (visibility) מתמשכת של שירותי הענן ובכדי לתת מענה מול Shadow IT.
Cloud app catalog מדרג את הסיכון לכל אפליקציה ע”י פרמטרים, כגון: רגולציות, תקנים ועוד.  האפליקציות בענן מעודכנות ע”י תהליך שמתרחש כל הזמן:

• ביצוע מדיניות עפ”י SOC 2 בכדי לבדוק את המידע של האפליקציה
• בדיקת המידע ע”י אלגוריתם שונה בכדי לבדוק כותרות שונות על גבי פרוטוקולים, כדוגמת HTTP
• ניתוח מידע של ערכים כדוגמת Encryption at rest
• פעולה שמתבצעת על גבי אפליקציה מסוימת עובדת עדכון מול הקטלוג

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

זיהוי תעבורה ולוגים (Traffic Logs) – בשלב הזיהוי של לוגים ותעבורה אשר יוצאת מתוך Firewall ארגוני מאפשר לנו לנצל ולנתח את המידע מול שירות CAS ולכן ככל שהמידע יותר מפורט כל הראות (visibility) שלנו בשירות יהיה טוב יותר.
יחד עם זאת ישנם Firewall מסוימים אשר אינם יכולים לספק מידע מסוים בתוך הלוגים, כדוגמת: Firewallשל Cisco ASA אינו יכול לתת מידע לגבי כמות מידע שהועלו או הורדו (Amount of uploaded or downloaded data) ולכן אינו יכול לתת דפוסי צריכה ושימוש.

מנגנון Cloud Discovery דורש לוגים מבוסס web עם הערכים הבאים:

• זמן ותאריך הפעולה
• מקור של כתובות IP
• מקור של משתמשים שונים
• כתובות IP ייעודיות
• קישורים ייעודים
• סה”כ כמות מידע
• פעולות

בכדי לבצע גילוי של תעבורת לוגים אנו נדרשים לתמוך בדרישות הבאות:

• תמיכה בסוגי Firewall\Proxy השונים
• מבנה הלוגים שקיימים  לפי סטנדרטים
• לוגים עד 90 יום
• לוגים תקינים שמכילים מידע לגבי התעבורה

לסיכום

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

מאמרים נוספים שיעלו בקרוב:

• אינטגרציה של MCAS מול Azure Sentinel
• איך להגדיר zSccaler מול MCAS
• הגדרת OKTA מול MCAS
• כתובות, רשתות סיכונים ותיוגים
• חיבור מול Azure AD Conditional Access ויישום forward proxy
• חיבור מול Microsoft Defender ATP
• MCAS והגנה על המידע עם AIP
• MCAS ומענה לרגולציה
• ומאמרים How-to נוספים

מאמרים נוספים של אבטחת מידע

מאמרים נוספים של אבטחה בענן