Archive for the 'PCI DSS' Category

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
מודעות פרסומת
05
דצמ
11

מפגש בנושא PCI

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

רציתי לעניין אותך ואת מי שמתעניין (חברי הבלוג )בנושא PCI להגיע למפגש בקבוצת .net security user group .

המפגש יתקיים ב-06/01 בשעה 17:30 בבית מיקרוסופט, רח' הפנינה 2 רעננה. הכניסה חופשית !!!
בכנס הקרוב אני מתכוון להעביר הרצאה בנושא תקן PCIDSS ומה המשמעויות כלפי אנשי הפיתוח.
להלן פירוט הנושאים במפגש:
– what is PCI and why we need it
– pci 1 -12 top review
– pci and application security relevance
– net implementation for pci requirements
– key management implementation
במידה וישנם נושאים ספציפיים שמעניינים אותך לגבי התקן, אתה מוזמן לשלוח לי -yaron@2bsecure.co.il ואני אנסה לשלב המסגרת המפגש הקרוב.

02
פבר
11

ניתוח (חוקי) Firewall

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

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

בואו נבחן דוגמא:

Action

Service

Destination

Source

Rule

Accept

ANY

ANY

Developers

85

 

 

 

 

.

.

.

Drop

P2P

ANY

LAN_NW

97

נאמר שחוק 97 היה במקור מספר 22. החוק אמור למנוע מהמשתמשים המוגדרים באובייקט LAN_NW (כל העובדים בארגון) מלגלוש לאינטרנט בפורטים הידועים כ – P2P.

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

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

עוד דוגמא: איש התקשורת פתח בלי לשים לב NetBios מרשת ה – DMZ לרשת הפנימית, במקום לאפשר NBT רק ברשת הפנימית.

דוגמא נוספת: חוק אחר מאפשר גישה מהאינטרנט בפורט 23 לרשת הפנימית. לא רעיון טוב.

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

אז מה אפשר לעשות? אפשר לרכוש מוצר הנקרא Firewall Analyzer.

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

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

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

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

 

16
נוב
10

עדכון לתקן PCI-DSS

שימו לב, ארגון PCI פרסם לא מזמן גרסה חדשה של תקן PCI-DSS – גרסה 2.0. מבנה התקן בגרסה החדשה לא השתנה – אותן 12 דרישות. בגרסה 2, ישנן מספר הבהרות לדרישות מגרסה קודמת, הנחיות חדשות לדרישות ושינויי עריכה.

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

הלינק לתקן.

הלינק לתמצית השינויים.

13
אפר
10

לוח זמנים ליישום תקן PCI-DSS

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

יש קצת אי בהירות והבדלים בין דרישות חברות האשראי לגבי המועדים. למיטב ידיעתי:

  • עבור חברות שהן Level 1 אין כרגע לו"ז.

  • עבור חברות שהן Level 2, המועד כנראה הוא סוף 2010 (לחברות שסולקות מול ויזה כדאי לוודא שזה המועד, מול מאסטרקארד זה בטוח המועד).

לחברות האשראי חשוב לראות התקדמות ביישום הדרישות. הן כנראה מבינות שקשה לעמוד בלו"ז, ולכן מתמקדות כרגע בבחינת ההתקדמות מול אבני הדרך המוגדרים ב – Prioritized Approach. 

18
אוק
09

PCI כמה זה עולה לנו

כמה עולה להביא את הארגון לעמידה בתקן PCI?

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

מישהו שאל כמה עולה לא להיערך לתקן PCI? אני לא בטוח שהערך הבא הוא מספר מהימן, אבל נאמר לי ע"י גורם כלשהו שבמקרה של גניבת מספרי כרטיסי אשראי חישוב הקנס לארגון הוא:

  • מספר הרשומות (מספרים) שנגנבו X $30 לרשומה.

 כלומר, אם נגנב בסיס נתונים שמכיל 100,000 רשומות, הקנס שיושת על הארגון יעמוד על 3 מיליון דולר! גם אם ערך הקנס נמוך יותר, זה עדיין הרבה כסף. וזה במידה והעונש יסתיים בקנס בלבד.

חשוב לזכור שבסיסי נתונים יכולים להכיל גם יותר ממיליון רשומות. כמובן שבמקרה כזה הקנס יהיה גבוה פי 10.

29
ספט
09

PCI DSS – פתרון בידוד "אי"

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

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

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

אך האם כל זה נדרש? התשובה היא לא בהכרח.

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

אז הנה שלוש גישות לפתרון חלק מהדרישות של תקן ה – PCI.

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

  2. בידוד לאי: הקמת סגמנט רשת (אי מבודד) לכל רכיב המעבד כרטיסי אשראי – שרת אפליקציה, שרת בסיס נתונים. באי הזה יישומו מנגנוני אבטחת מידע נוקשים, בעוד שבשאר הרשת הארגונית, אפשר ליישם אבטחה פחות נוקשה. ראו תרשים סכימתי:
    pci-island1.JPG

  3. העברת האי לגורם חיצוני: לאחרונה התחלתי לראות ניצנים ראשונים של פתרונות להוצאת כל כרטיסי האשראי מהארגון – עיבוד הנתונים ושמירתם. הארגון שומר במערכות שלו מזהים חד-ערכיים מול הגורם החיצוני המקושרים למספר כרטיסי האשראי ופעולות הסליקה. אומנם כאן נדרש תפירת ממשק מאובטח בין אפליקצית האשראי הארגונית לגורם הסליקה, אך מרגע זה הארגון הופך כמעט לא רלוונטי מבחינת תקן PCI. ראו תרשים סכימתי נוסף:
    pci-island2.JPG

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




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