Archive for the 'הגנה על בסיסי נתונים' Category

01
ספט
13

אבטחת מידע ב – SAP

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

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

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

  • טרנזקציות המאפשרות ניהול הרשאות (כגון SU01). חשוב לבקר באופן שוטף מי מקבל הרשאות אלה (רק מנהלי/מיישמי ההרשאות). מומלץ לנטר במערכת ה – SIEM הגדרת SU01 למשתמשים.
  • טרנזקציות המאפשרות עדכון נתונים בטבלאות בייצור. בניגוד לבסיסי נתונים SQL כגון Oracle, MS-SQL, בעולם ה – SAP ניתן לגשת לנתונים ישירות לטבלאות (קצת כמו אקסל). טרנזקציה SE16, ונוספות, מאפשרות גישה כזו. זה סיכון שאסור לאפשר (למעט מקרי חירום) וחייבים לחסום אותו.
  • הרשאות המפרות את עיקרון הפרדת הרשויות (Segregation of Duties). ארגון לא אחראי יאפשר בשמחה לעובד אחד גם להקים ספק, גם ליצור דרישת תשלום לאותו ספק, ולבסוף לסגור את הספק במערכת. נשמע מעולה, לא?
  • ממשקים אל ומהמערכת שאינם מאובטחים. כמו כל מערכת אחרת, האם הממשקים מוגבלים בהרשאות גישה? האם מידע רגיש (למשל, כרטיסי אשראי) עובר באופן מוצפן?
  • כתיבת קוד מעבר לקיים בחבילת הבסיס (למשל ABAP ב – SAP) שחושף את המערכת לפרצות אבטחה.
  • התקנת טלאי אבטחה לתשתית המערכת.

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

מודעות פרסומת
01
מאי
12

10 חוקים לניטור וחסימה במערכת DLP

אחת התופעות הידועות והמרגיזות אצל חברות אינטגרציה, בכל הקשור בהטמעת מערכות, היא שהן מתקינות מוצר עם סט בסיסי ומובנה של חוקים ועוזבות. מבחינת חברות אלה, הן סיימו את העבודה והצדיקו את הכסף. מבחינת הארגון, אין לו שימוש אמיתי בחוקים אלה. כבר ציינתי את זה כאן בעבר. זה בערך כמו התחנה המרכזית החדשה בתל אביב שעמדה במשך שנים רבות ללא שימוש (אבל היא הייתה בנויה/מותקנת).
ביקשו ממני לציין חוקי תוכן שכדאי ליישם במערכת DLP – חוקים שיתנו ערך מוסף אמיתי לארגון. אומנם לא כל מערכות DLP מגיעות עם אותן יכולות, אך אני מניח שניתן להגדיר את סט החוקים הבא במערכות המובילות היודעות לנטר תכנים (בניגוד למערכות שיודעות רק לחסום התקני זכרון).
חשוב להכיר את יכולות המערכת מעבר להגדרות חוקים בסיסיות. לרוב, ניתן להגדיר סף (Threshold) שקופץ רק כשעוברים אותו (למשל מעל 5 חזרות של תוכן מסוים באותו מייל). ניתן גם להחריג יחידות ארגוניות או משתמשים בודדים מחוקים מסוימים.
בדוגמאות הבאות ניתן להגדיר לא רק את ערוץ המייל, אלא גם ערוצים נוספים כגון FTP, Web Post, התקני זכרון ניידים ועוד. המערכות יודעות לתמוך במגוון ערוצי תקשורת.

אז הנה מספר חוקים:

  1. שליחה של מספרי כרטיסי אשראי. חשוב להפעיל, במידה וניתן, בדיקת תקינות למספרים (בדומה לתעודות זהות, גם למספרי כרטיסי אשראי יש חוקיות) כדי למנוע התראה על מספרים שאינם תקינים (שאינם בהכרח כרטיסי אשראי). חוק חשוב לתקן PCI.
  2. שליחה של מספרי תעודות זהות. גם כאן להפעיל בדיקת תקינות ולוודא שמדובר בתעודות זהות.
  3. שליחה של תנאי העסקה – שכר, משכורת.
  4. שליחה של מידע רפואי (צריך ליצור במערכת מילון של מושגים רפואיים רגישים).
  5. שליחת קבצים מספריות ברשת שסומנו כרגישות. למשל, משאבי אנוש, ספריות של אפליקציות עסקיות, הנהלה ודירקטוריון, שיווק.
  6. שליחה אל נמענים מהעיתונות כדי לאתר הדלפות.
  7. שליחה אל נמענים מחברות מתחרות. האם זה תקין שעובד בחברת סלולר אחת ישלח מייל לחברת סלולר מתחרה?
  8. שליחה של סיסמאות. נזהה את זה בין השאר ע"י הביטויים: סיסמא, סיסמה, סיסמאות, admin ועוד.
  9. שליחה של נתוני עמלות. סוכן מכירות של החברה ינסה להשיג ממקור פנים נתוני עמלות של סוכנים מתחרים.
  10. שליחה של שאילות לבסיסי נתונים. נזהה ע"י הימצאות כל הביטויים הבאים: select, from, where
19
דצמ
11

תרשים סיכונים מערכות/מנגנוני הגנה ומניעה

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

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

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

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

הערות כלליות:

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

 הערות על מערכות:

  • DB FW: ניתן להגדיר הרשאות גישה עפ"י יוזר מערכת הפעלה, יוזר בסיס נתונים, כתובת IP, שם מחשב ועוד. יכול לאפשר מניעת גישה לשדות רגישים או ניטורם. מאפשר לנטר ולחסום נסיונות Brute Force.
  • DLP: יכול לחסום התקני זכרון נתיקים, למנוע או לנטר שליחה/שמירה של מידע רגיש על סמך ביטויים/תכנים או ספריות ברשת.
  • הצפנת כונן קשיח משלב ה – Boot: מונעת אפשרות לאתחל את המחשב באמצעים עוקפי מערכת הפעלה של הכונן.
  • AFW: מגן בפני התקפות בקלטים באפליקציה, בפלטים ובניצול חולשות על השרת, מניעת התקפות DoS.
  • XML FW: מגן בפניות ל – Web Services כנגד התקפות XML המובילות ל – DoS, מניעת זליגה דרך SQL Injection.
08
נוב
11

עקיפת Listener

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

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

לצערי, עדיין לא גיבשתי פתרון להתמודד עם הבעיה הזו.

28
אוק
11

סיכונים הנובעים מ – Listener

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

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

ה – Listener  הינו רכיב תוכנה של Oracle המאפשר תקשורת בין המשתמש לבסיס הנתונים.  מכאן שלרכיב זה יש חשיבות מאוד גבוהה באבטחת מידע. גורם זדוני שפוגע ברכיב זה, פוגע למעשה בתקשורת לבסיס הנתונים. הוא דומה ברעיון ל – Socket של פרוטוקול TCP/IP אשר מאזין לתעבורת רשת בפורט מסוים. בברירת מחדל, ה – Listener  מוגדר להאזין על תעבורה המגיעה על פורט 1521.

היעדר אבטחה על ה – Listener  עשויה להוביל לסיכונים הבאים:

  • מניעת שירות (DoS) לבסיס הנתונים. פורץ יוכל להפסיק את פעולת הרכיב. בנוסף, פורץ שמשיג שליטה ב – Listener  יכול להגדיר ל – Listener סיסמא לא מוכרת ולמנוע מ – DBA לשלוט להבא ברכיב.  דרך נבזית נוספת היא הגדרת Timeout של שניה אחת להתחברות לבסיס הנתונים. מהר מאוד, כמות הפניות להתחברות לבסיס הנתונים (דרך ה – Listener) תהיה גבוהה מאוד ותוביל למניעת שירות.
  • גניבת מידע רגיש. הפורץ יכול להגדיר כתיבת Trace על פעולות מול בסיס הנתונים. למשל, פעולת החלפת סיסמא. במקרה כזה, ה – Trace עשוי לתעד את הסיסמא החדשה באופן נגיש לפורץ.
  • גישה לא מורשית (פריצה) לשרת. פורץ יוכל  להגדיר כתיבת קובץ שידרוס את קובץ .rshosts שמגדיר לאיזה כתובות IP מותרת גישה. דריסת הקובץ אפשרית מכיון של – Listener  יש הרשאה גבוהה על השרת.

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

  • לשדרג את בסיס הנתונים לגרסת Oracle מתקדמת. ככל שהגרסה מודרנית יותר, כך הרכיב מאובטח יותר בברירת מחדל. תת גרסה מתקדמת של 10g תאפשר, למשל, חיבור ל – Listener  על בסיס משתמש של מערכת הפעלה LOCAL OS AUTHENTICATION כדי למנוע ניהול הרכיב מרחוק (ובכך לאפשר פריצה).
  • התקנת טלאי (Patches) אבטחת מידע של אורקל.
  • לשנות את ה – TNS Port בו הוא מאזין לפורט שאינו ברירת מחדל.

לסיום, חשוב תוודאו שבזמן שמאבטחים את בסיס הנתונים, מטפלים גם בהקשחת ה – Listener.

 

08
מרץ
10

מה לנטר בבסיסי נתונים

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

  • מספר כשלונות בהתחברות לבסיס נתונים (בעיקר בסביבת ייצור)

  • התחברות ליוזרים המגיעים עם התקנת המערכת (Default Users)

  • התחברות דרך כלי SQL (למשל sqlplus) לבסיס נתונים בייצור

  • התחברות לבסיס נתונים בשעות לא סבירות

  • התחברות מכתובות IP לא מקובלות

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

  • ביצוע עדכון טבלאות ע"י משתמש שאינו אפליקטיבי 

(אם יש לכם עוד רעיונות לניטור אירועים, אתם מוזמנים לכתוב בתגובות.) 

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

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

30
נוב
08

ניסיון עקיפת 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 על טבלאות רגישות וטבלאות חדשות.



אוגוסט 2018
א ב ג ד ה ו ש
« מאי    
 1234
567891011
12131415161718
19202122232425
262728293031  
מודעות פרסומת