יישום של תקן PCI-DSS

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

להערכתי – לא נדרש ידע רב כדי להגיע למסקנה הזו – 2 דרישות שרוב הארגונים ימצאו שקשה מאוד לממשן הן דרישות 3, 10.

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

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

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

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

סיכום קצר של כנס PCI-DSS

כאן ציינתי מה זה PCI-DSS.

מספר תובנות מהכנס שהתקיים ביום חמישי, 19/9/08, בחסות חברות האשראי.

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

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

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

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

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

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

כיוון שמדובר בגוף עולמי חזק, אני מניח שלא יהיו הנחות או שינויים בלו"ז, וכדאי להתחיל לפעול במרץ לעמידה בתקן.

הגנה על בסיסי נתונים Database Security

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

הפתרון שנבחר

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

1. להיות 'הכי קרובים' למידע כך שאם מישהו מגיע למסד הנתונים שלא דרך רשת ה – LAN , הפתרון יתפוס גם עליו.

2. אפס שינויים בטופולוגית הרשת וביטול התלות באיש התקשורת, בפרט אם תהיה תקלה ברשת והנטייה שלו תהיה לעקוף את ה – DB FW.

3. שליטה מלאה של מנהל אבטחת מידע במוצר, ללא נגיעה של איש תקשורת (וגם לא של DBA).

4. החשש העיקרי היה של השפעה על ביצועים על בסיסי הנתונים. בינתיים זה בסדר.

מענה נדרש ו – Use Case

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

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

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

הממצאים

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

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

העובד מציג את השדות בטבלה זו ולאחר מכן מריץ את השאילתא:

 select customer_name, id_num, cc_num from Credit_Card_Tbl

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

 select customer_name, id_num, cc_num from Credit_Card_Tbl where rownum<100

הוא חוקר את הפלט ומגיע למסקנה שזה מה שהוא צריך.

עכשיו הוא ניגש לטבלה אחרת ומריץ את השאילתא הבאה:

 select customer_name, id_num from Customer_Tbl where customer_name like ‘%moshe cohen%’.

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

עכשיו הוא מריץ את השאילתא הבאה:

 select customer_name, id_num, cc_num from Credit_Card_Tbl where id=’31234567’.

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

IP: 192.168.1.200; PC: dev123; select customer_name, id_num, cc_num from Credit_Card_Tbl

IP: 192.168.1.200; PC: dev126; …

IP: 192.168.1.200; PC: dev123; select customer_name, id_num, cc_num from Credit_Card_Tbl where rownum<100

IP: 192.168.1.200; PC: dev152; …IP: 192.168.1.200; PC: dev123; select customer_name, id_num from Customer_Tbl where customer_name like ‘%moshe cohen%’

IP: 192.168.1.200; PC: dev126; …

IP: 192.168.1.200; PC: dev1823; …

IP: 192.168.1.200; PC: dev123; select customer_name, id_num, cc_num from Credit_Card_Tbl where id=’31234567'

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

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

כנס תקן PCI DSS

לאלה מכם שמעוניינים לשמוע על תקן PCI DSS (ולהתחכך במנהלים מובילים בשוק אבטחת המידע), יתקיים כנס בנושא בגן אורנים בתאריך 19/9/2008.

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

יש צורך ברישום מראש.