ניסיון עקיפת Database Firewall ע"י פקודות DML, DDL

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

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

create table TMP_TBL as select * from TBL

או יצירת טבלה ריקה ואז:

insert into TMP_TBL select kp1.* from TBL where …

כאשר ה – where ממלא את הטבלה הזמנית רק בנתונים שמישהו מעוניין בהם.

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

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

מה זה SIEM

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

ראשי התיבות של SIEM הם: Security Information and Event Management. מדובר בטכנולוגיה שהפריסה שלה נפוצה בעיקר בארגונים גדולים שכן ההטמעה מאוד מורכבת ומצריכה משאבים רבים.מספר דוגמאות יציגו את המטרה של SIEM יותר טוב מהסברים.

ניקח את המערכות הבאות: Firewall, Active Directory, אפליקציה אינטרנטית, בסיס נתונים Oracle. כל אחד מהם מייצר לדוגמא את ההתראות הבאות:

1. Firewall: סריקת פורטים (Port Scan) מכתובת חיצונית.

2. אפליקציה Web: לוגים על ניסיונות כושלים רבים במסך ההזדהות.

3. בסיס הנתונים: שליפת נתונים רגישים ע"י שרת האפליקציה מטבלאות רגישות שהאפליקציה אינה אמורה לגעת בהן.

4. AD: הוספת משתמש לקבוצת Administrators.

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

1. איסוף התראות (Event) ממערכות שונות בפורמטים שונים (פורמט לוג של FW שונה מזה של AD).

2. ניתוח התראות על סמך חוקים כתובים מראש.

3. הפקת חיוויים למפעילי המערכת על אירוע, כולל הצגת נתונים מלאים ורלוונטיים להתקפה.

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

עוד דוגמא קצרה:

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

• התראה מ – AD על החייאת חשבון משתמש שהיה Disabled,
• לוג של גישה מיוזר זה לטבלת שכר בבסיס הנתונים,
• לוג ממערכת מניעת זליגת מידע רגיש מיוזר אחר (לא זה שהוחזר לחיים) על שליחת מייל אל מחוץ לארגון עם תוכן המכיל נתוני שכר.

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