|
5 (ג) – מאגר מידע שחלה עליו רמת האבטחה הגבוהה, בעל המאגר אחראי לכך שייערך סקר לאיתור סיכוני אבטחת מידע (להלן – סקר סיכונים); בעל מאגר המידע ידון בתוצאות סקר הסיכונים שיועברו לו, יבחן את הצורך בעדכון מסמך הגדרות המאגר או נוהל האבטחה בעקבותיהן, ויפעל לתיקון הליקויים שהתגלו במסגרת הסקר, ככל שהתגלו; סקר סיכונים כאמור ייערך אחת לשמונה עשר חודשים לפחות.
|
במסגרת הפרויקט יוטמע מנגנון Guardium Vulnerability Assessment for Databases. מנגנון זה מבצע סריקות לצורך איתור פגיעויות (vulnerabilities) בשכבת בסיסי הנתונים עפ”י הסטנדרטים המקובלים בעולם אבטחת המידע (STIG, CVE, CIS וכד’), יחשב ציון לכל בסיס נתונים יפיק דוחות כולל המלצות לתיקון. הפעלת כלי זה לעיתים תדירות וביצעו המלצות לסגירת החשיפות והפגיעויות יאפשרו לממונה אבטחת המידע של הלקוח לשמור באופן קבוע על רמת חשיפה נמוכה ומנוהלת – וזאת בהתאם לחומרת החשיפה ורמת הקריטיות של בסיס הנתונים.
|
|
10 (א) במערכות של מאגר מידע אשר חלה עליו רמת האבטחה הבינונית או הגבוהה, ינוהל מנגנון תיעוד אוטומטי שיאפשר ביקורת על הגישה למערכות המאגר (בתקנה זו – מנגנון הבקרה), ובכלל זה נתונים אלה: זהות המשתמש, התאריך והשעה של ניסיון הגישה, רכיב המערכת שאליו בוצע ניסיון הגישה, סוג הגישה, היקפה, ואם הגישה אושרה או נדחתה.
|
עם השלבים הראשוניים של הפרויקט תוטמע בקרת גישה (Auditing) על בסיסי הנתונים של הלקוח. ה-Audit יאסוף את זהות המשתמש כפי שמדווח ע”י בסיס הנתונים (OS User, DB User), תאריך ושעה של ניסיון גישה (Timestamp), כתובת רשת של מקור הגישה, רכיב המערכת (Object, ו\או Field) שאליו בוצע ניסיון הגישה, סוג הגישה (Command), היקפה (Records Affected), והאם הגישה הצליחה או נדחתה (Successful).
יודגש כי רכיב IBM Guardium הינו משלים, אך לא מחליף, את רכיבי ההגנה ובקרת הגישה של האפליקציות. אי לכך, במסגרת הפרויקט יוגדרו “גישות בטוחות” (Trusted Connections) – אלה גישות של האפליקציה עצמה. רמת התיעוד של גישות בטוחות תפחת מרמת התיעוד של גישות לא בטוחות.
להלן רשימת אפליקציות שנתמכות Build In במוצר:
- BO-WI – Business Objects / Web Intelligence
- EBS – Oracle E-Business Suite
- PeopleSoft
- SAP Observed
- SAP DB
- SIEBEL Observed
- SIEBEL DB
|
|
10 (ב) מנגנון הבקרה לא יאפשר, ככל יכולתו, ביטול או שינוי של הפעלתו; מנגנון הבקרה יאתר שינויים או ביטולים בהפעלתו ויפיץ התראות לאחראים.
|
מערכת IBM Guardium מסופקת בתצורה של Hardened Virtual Appliance עם יכולות ניטור עצמי. לא ניתן לערוך את תוכן ה-Audit Database לאחר איסוף ה-Audit. כמו כן, המערכת מגיעה עם יכולות ניטור עצמי (Self-Monitoring) ומדווחת על ניסיונות התחברות למערכת או ניסיונות כיבוי סוכני המערכת. מחיקה / שינוי של Audit מבוצעת ע”י תהליכים פנימיים של המוצר ומייצרים Log בהתאם.
|
|
10 (ג) בעל מאגר מידע יקבע נוהל בדיקה שגרתי של נתוני התיעוד של מנגנון הבקרה, ויערוך דוח של הבעיות שהתגלו וצעדים שננקטו בעקבותיהן.
|
מערכת IBM Guardium מכילה רכיב המאפשר לממונה בדיקה שגרתית של נתוני התיעוד של מנגנון הבקרה. רכיב ה-Audit Process מאפשר תזמון אוטומטי והפקת דוחות הבקרה המבוססים על נתוני התיעוד. דוחות אלה ישלחו עפ”י תזמון אוטומטי שיוגדר לממונים הרלוונטיים לידיעה או אישור. במסגרת הפרויקט ישופעלו Audit Processes אלו, ובעלי התפקידים הרלוונטיים יקבלו דוחות חריגים.
|
|
(ד) נתוני התיעוד של מנגנון הבקרה יישמרו למשך 24 חודשים לפחות.
|
המערכת מנקה מידע היסטורי באופן אוטומטי (בד”כ הנתונים הגולמיים נשמרים בשרתי המערכת למשך כחודש).
המענה לדרישה ניתן ב-2 רמות:
- במסגרת ה-Audit Process המערכת שומרת את הפלט של דוחות הבקרה בשרת קבצים חיצוני בצורה של דוח (קובץ PDF או CSV).
- על מנת לאפשר תחקור היסטורי של מידע גולמי במידת הצורך, תוך כדי עמידה בתקנה 10 ב’ שלעיל, באפשרות המערכת להוציא מידע גולמי (דחוס, מוצפן וחתום דיגיטלית) לשרת קבצים חיצוני תוך כדי שמירת נתוני הגיבוי (metadata) בקטלוג הפנימי של המערכת. במידת הצורך ניתן לבצע ייבוא של הקובץ ההיסטורי חזרה לשרת המערכת ולתחקר אותו.
|
