Sunday, December 31, 2006

עולם הVirii מתחיל להיכנס לתודעה

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

לאחרונה סוף סוף חל שיפור במצב . בהסמכת הCEH v5 כוללים עכשיו מודול שלם של וירוסים.
ההבנה כי רוב ההתקפות היום מבוססות וירוס או תולעת ( רוב ההתקפות בפועל הן התקפות NETWORK DDOS אבל הן הופכות לפחות ופחות אפקטיביות עם הIPS המתקדמים של ימינו. ) ההתקפות שאני מדבר עליהן - הן אותן התקפות אשר הינן אפקטיביות בסופו של דבר ומצליחות לגרום לDeniel Of Service למשאבים אפליקטיביים ולא רק לתשתית עצמה.

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

בגדול עולם הוירוסים חשוב להבנה כפי שכבר ציינתי , וחשוב להבין את הנושאים והפירוקים בתוכו. למשל סוגי הוירוסים המתחלקים לסוגים רבים כמו ZOO-VIRUSES אשר הינם וירוסים בני למעלה מ5 שנים ולכן נחשבים DEPRECATED וחברות אנטיוירוס מוציאות אותן מהמנועים שלהן ( כמובן שאפשר ליצור התפרצות מחודשת ) .
תחשבו במקרה כזה על וירוס שתוקף WIN98. ויש מוסדות כגון בתי ספר אשר לא משדרגים במשך שנים רבות מערכות , MICROSOFT כבר לא תומכת במע' ההפעלה ולכן אין PATCHES עדכניים ואם וירוס חוזר הוא יכול למוטט ארגון.
או למשל סוגים כמו WILD-VIRUSES שהינם מוטציות של וירוסים אשר יוצאות אחת אחרי השניה ומשתמשות בטכניוקות כמו POLYMORPHISM ועל ידי כך מבטלות את היכולת ליצור חתימה לוירוס ( דבר שיוצר בעיות בעיקר למערכות כמו AV-GATEWAY אשר אמורות לבדוק וירוסים ON-THE-FLY ).

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

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

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

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

Labels:

Sunday, December 24, 2006

אסקלציה - דלקת ריאות

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

אני מתחיל לחזור לעצמי , בטח תוך יום-יומיים אפילו אחזור לעבודה .

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

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

החיים ממשיכים.

Labels:

Saturday, December 16, 2006

Blended Threats

בכל פגישה שאני מגיע ללקוח לייעוץ , או במעמד יועץ צד שלישי לפרוייקט מסויים, תמיד אני נתקל בהרמת גבות בשלב מסויים. באימפלמנטציות יפות יותר כל הגופים דאגו למערכות שמסוגלות לטפל בכל סוג של מזיק בתוך התוכן ועד עמקי הDATA, נהלים מפה ועד הודעה חדשה, ומערכות AAA מעולות אשר יכולות לאתר הקשה על מקלדת מלפני 8 חודשים וכדומה. ואז אני תמיד שואל "איזה פיתרון בחנתם לצורך מתן מענה לאיומים מרובבים ?" ואז השתיקה הארוכה ...

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

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

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

ומה הבעיה בכלל ? הרי יש לי אנטיוירוס ואנטיספאם ואנטי אנטי אנטי ... ובכן תתפלאו , הם לא יתפסו התקפות כאלה במעל 80% מהמקרים. וזאת מפני שכל מנוע שכזה עובד לבד , אנטיוירוס חותם לבד שקובץ נקי , וגם מערכת האנטיספאם , הIPS יעבוד באותה צורה וכן הלאה. ולמעשה כל פתרון UTM שלא יהיה , לא יפתור את הבעיה מאחר והיא מחולקת על יותר מידי שכבות , כאשר באף שכבה אי אפשר לומר במדויק "כן , זו התקפה !". אולי חברה אחת או שתיים פנו לתת מענה אמיתי לבעיה זו ( על ידי כתיבת כל המנגנונים בעצמך , אתה מסוגל לבצע קונסילידציה של החלטות על סמך ניתוח משותף של כל המנועים , ורק כך תוכל לגלות את ההתקפה ).

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


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

בנוסף למאמר שלי בנושא UTM שפורסם באנגלית בבלוג הזה : גילשו למאמר

Labels: , , ,

Friday, December 15, 2006

Vista נפרץ , עם הוכחות

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

בעיקר הגרסה לארגונים. הגרסה לארגונים דורשת שתקים אצלך בארגון שרת KMS שהוא שרת ניהול מפתחות , עליו צריכים להיות 25 או יותר רשיונות לVISTA , מה גם שהתחנות לא רק מבצעות מולו את הרישום , הם גם מוודאות רישום בכל 180 יום באמצעות HEARTBEAT.

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

כמו כן , נמצא באינטרנט עותק VMWARE של שרת KMS שכזה , עם 25 רשיונות , שכל אחד יכול להריץ אצלו על VMPLAYER ולהפעיל את הVISTA שלו ( גרסאות הBUSINESS )

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

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

Labels: ,

Thursday, December 14, 2006

שפעת - אבטחת מידע ?

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

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

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

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

חולה אבל מבריא,
בארי.

Labels:

Monday, December 11, 2006

הזדהות חזקה Out Of Band

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

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

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

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

ובכן , החבר'ה בSECCES לקחו את העולם זה שנים קדימה . הרעיון הוא כזה ... הזדהות מחוץ למחשב. כן כן , לא להשתמש בTOKEN או בסיסמה או באלמנט דומה , תוך שמירה על עקרונות הOTP
( One Time Password - לאחר שימוש אחד לא ניתן להשתמש בסיסמה ). מה שהם עשו זה בעצם לבנות פרופילים של הזדהות לכל משתמש במערכת. למשל אני : יש לי טלפון נייד , יש לי כתובת אימייל , יש לי שלוחה במשרד ועוד כל מיני דוגמאות ... נניח שהטלפון הנייד הוא אימות 1 ,והשלוחה שלי היא אימות 2. במידה ואני צריך להזדהות באמצעות מערכת SECCES, מה שאני צריך לעשות זה להכנס שם משתמש ובקשת אימות . לצורך הענין המערכת הח מוגדרת לCHALLENGE אוטומטי ( מלא אפשרויות קונפיגורציה ), המערכת מחליטה לעבוד איתי באימות 1. מייד אני מקבל SMS שבו כתוב "סיסמתך החד פעמית היא : XXXXXX" , פעם אחרת המערכת בוחרת באימות מסוג 2 , ואני מקבל טלפון שאומר לי "סיסמתך החד פעמית היא : YYYYYY" . פשוט מדהים.

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

המערכת תוכננה לעבודה כרדיוס ( וככזאת - יכולה להתממשק לכל מערכת שיודעת לדבר מול רדיוס ), יש לה 2 אלמנטים : מערכת האימות ושרת הRADIUS RELAY.
המערכת בנויה בצורה מאוד מוקשחת וSUPER SECURE. בעצם השרת מולו מבצעים את שאילתת הרדיוס הוא קופסא טיפשה אשר רק יודעת לקבל בקשות, השרת החכם הוא שרת האימות והוא מבקש ממנה את הבקשות וגם שם בה תשובות , כלומר אם שמים אותה בDMZ , למכונת הRADIUS RELAY אין כלל צורך בחוקי גישה ממנה החוצה. חשוב לציין ששירותי ההתקשרות, כולל SMS או כל דרך אחרת תלויים בקיום של מערכות כאלה בארגון , או אצל ספק שירות.

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

האתר של SECCES הוא :
www.secces.com

Labels: , , ,

Saturday, December 09, 2006

הבטחה לאבטחה - eCommerce

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

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

אז ראשית קצת טכני, SSL הוא אכן פרוטוקול הצפנה יעיל. הוא מאפשר החלפת מפתחות בין שני
צדדים שהם Client\Server ועל ידי יצירת Session וירטואלי ( מאחר ובHTTP1.0 או ב1.1 לא קיים אלמנט הSESSION ) לערבל ולהצפין את המידע העובר בין הCLIENT לSERVER ולהיפך, ועל ידי כך למעשה ליצור טרנזאקציה בטוחה.

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

הבעיה היא ...
95% מהאתרים בארץ ובעולם אשר מבצעים טרנזאקציות של מידע שמור ואישי , כולל אתרי מסחר אלקטרוני , בנקים , שירותים פרטיים וכדומה , אינם מצפינים את החלפת שם המשתמש והסיסמה.
מה שנוצר בתהליך זה הוא שלמרות שאת המידע הרגיש שלי אי אפשר לגנוב On-The-Fly על ידי
Sniffing או Hijacking ( יש לי סייגים פה ) אבל ניתן לגנוב את שם המשתמש והסיסמה שלי שמשודרים PLAINTEXT עוד לפני שהעברתי פרט אחד !!! אם לאותו CRACKER יש את השם משתמש והסיסמה שלי , הוא לא צריך לחפש את האשראי שלי , כי הפרטים כבר מולו !!!.

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

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


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

Labels: , , ,

SSL VPN Access

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

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

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

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

בשנים האחרונות אנו רואים מספר אלמנטים של שימוש בSSL לצורך הקמת אותו תווך מוצפן, מדובר למעשה בשימוש בSSLv3 ( שהוא בעצם TLS המוגדר בRFC2246 ). למי שלא מכיר - SSL עובד בשכבת הSESSION והומצא על ידי NETSCAPE לפני מספר שנים שלא זכור לי לנקודה זו. ובכן המטרה בשכבת הSESSION הייתה לאפשר לעבוד עם SESSION COOKIES בדפדפנים ( שכן פרוטוקול HTTP אינו תומך בSESSION כלל ) . ובכן , על מנת לאפשר לאפליקציות רשתיות לרוץ על התשתית המוצפנת , עלינו לרדת כמובן שכבה, לכן הומצא הTLS שהוא Transport Layer Security שמאפשר לנו להצפין בשכבה הרביעית .

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

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

מובן שלכל פתרון יש היתרונות והחסרונות שלו , ומאוד תלוי איך אותו VENDOR בוחר ליישם את פתרון הSSL-VPN שלו. מנסיוני אין פתרון אחד שמתאים לכל ארגון , בסביבות מונחות יצרן אחד ספציפי יתכן שיתאים פיתרון אחד , בעוד לארגון אחר אשר דורש ניקוי בAV לתשתית הSSL שלו יתאים פתרון אחר. ישנם פתרונות המהווים PROXY מלא בין נקודת הגישה לאתר עצמו, ישנם פתרונות אשר מסוגלים לבצע בדיקות UTM וניקוי של מזיקים מהתווך המוצפן, וישנם אף פתרונות שמקימים סביבה נפרדת חד פעמית מוצפנת אשר אינה יושבת על הIO אלא בSANDBOX ייעודי. אין כאן כללים מנחים ויש לשקול כל פתרון לגופו.

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


** שימו לב , ישנו המשך שעיקרו טכני בתגובות למאמר זה.

Labels: , , ,

Friday, December 08, 2006

Hebrew ? A Train Of Thought

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

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

תהנו , ושבוע טוב לכולם.
בארי.

Labels: ,

Tuesday, December 05, 2006

How To Assure yourself by Common Criteria


There is a great deal of gray area around Common Criteria Certifications . not because they is anything wrong with them, But the opposite - RFP's come out for answers without asking For any legitimate source of information about the capabilities Of the product they request.

What happens is as follows :
When a firm\company needs a technological product , lets just Say - a firewall. They put out the specifications they require And ask for a certain throughput , vpn abilities , content Inspection abilities and so on . The integration\product provider usually answers this RFP by Implementing best knowledge and whitepaper cut-outs .

In that way - the firm\company that requested the product May get a product that is cheap but answers for all required Technical specifications , but the product itself is poorly Implemented and written , the documentation of the product Says that it supports just about everything and that the Product is "very secure and hardened"

Common Criteria comes as a legitimate standard of checking The entire process of product development , deployment And benchmarking , therefore giving a certification to a Product in such a way - that a customer can rely assured that He is getting a product of at least a certain level of standard Checks.

The 7 different steps of the Common Criteria are known as EAL "Evaluation Assurance Level" and is marked as such :
A product that gained EAL level of 4 may get the certificate Of "EAL4 Certified".

Therefore When requesting an RFI\RFP - one should request An EAL level that is the minimum for this product . by that The company assures itself it gets a product that satisfies Its needs.

There is some great information at the common criteria portal
( "http://www.commoncriteriaportal.org" ) . for instance You can read the user guide and get familiar with the different
Levels of EAL and the ways each level is checked at :
http://www.commoncriteriaportal.org/public/files/ccusersguide.pdf
http://www.commoncriteriaportal.org/public/files/ccintroduction.pdf

as a security engineer , when a customer asks me for consultancy about a product or a solution for securing an element of his IT\IS my first question for this product will always be : "What is its CC-EAL level certification" .

Always remember , when a standard is being requested , and the Product\solution you get is certified to that standard , you Usually get what you pay for , nothing less , maybe more.

Labels:

Monday, December 04, 2006

UTM – Antithesis For The Current Concept Technology


The world of IT security technologies has evolved greatly for the last 5 years.
By understanding the structure of the current threats that threatens the IT environment of corporate infrastructure – security vendors have created very highly crafted technologies to deal with these threats. We had some major breakthroughs with IPS technologies that currently serves both signature based and proactive scanning methods, Antivirus and AntiSpam technologies can now inspect information to the deepest levels . and there are more than enough URL filtering mechanisms that serves about every major company that require these kind of services to be implemented on their users surfing habits.

UTM is something pretty fresh In that aspect, we’ve seen it growing In the last
couple of years as a major aspect for creating “All-In-One” solutions. The concept is
brought to life by taking one machine that is taking care of stateful firewalling , advanced routing ,IPSec connectivity, and giving it the extra edge by allowing it to connect to modules such as the IPS, AntiSpam, Antivirus and the URL Filtering mechanism to create a full blown inspection gateway that scans just about everything that passes through it, and decide based on scan results if to pass the traffic or rather stop and log it and that point of entry.
Now lets look at the problem. By the UTM concept – our IT should be “secured”
If we are using a UTM device at our core network environment . but – what about
blended threats ? , what about attack and code mutations?
In the second half of 2005 , many analysts and security engineers have faced new
types of attacks , the blended ones , and the mutated ones. These attacks were crafted to skip from one method to the other , from one technology to the other , and IT security measures where if you had a virus , an antivirus solution would have taken care of it, And if you had a DoS attack , the Firewall would have taken care of it , but when an attack would have begun as an Exploit that injects a virus that later on sends out spam and infects other entities via IM , or via SMB – systems are useless to these attacks.

The problem with the UTM concept today – is that companies that manufacture
these solutions , are applying OEM solutions with other vendors . one could OEM with
the best-of-breed antivirus company for his AV module , and OEM with the best-of-breed IPS company for the IPS module and pass the traffic through the both of them . but ! and here is the problem – the modules of different vendors , could not speak to each other . each module of its own honorable vendor is written as a closed source application and can receive traffic from one end , check it and pass it through , but when the IPS module and AV module co-exist but cannot take mutual decisions on the traffic that passes through – blended threats could not be inspected in any way . mutations of the traffic will pass as if there was nothing there to stop them.

Let me explain further more : when the UTM device is used to establish a layer 3
up to layer 7 connection between two entities , it inspects the traffic . now – if there is a mutation attack of some kind ( here is just an example ) – a session is being established
via VPN between two entities , and runs just http traffic between the two. The
termination of the IPSec is being done by the UTM device , which cannot see up until
now if there was an attack hidden in the traffic that came through the IPSec tunnel . then the data is getting into the http server with a 0day exploit on it , so the IPS does not know it. And sends a file that was previously accepted by the UTM device because of the tunnel access control rules. Contains a virus , and the attacker entity is passing it through an IM service . the new crafted virus is the populating itself not via IM , but via SMB , and when that occurs – the virus manipulates itself to attack the core switch via a simple DDoS attack. no UTM device would stop this attack , no single entity to take care of one module will stop this attack. The solution is being send from one or two vendors today , that have come to
mind that if they write their own antivirus , they can manipulate it , and if the IPS code is their proprietary code , they could manipulate is , and where the URL filter is a service which they own . modifications and alterations could be performed . the main issue here is that if you are the sole vendor for all modules inside your UTM device , you can ask them to speak to each other , you could take access control decisions based o blended results of the traffic that passes through your device , and because of stateful technologies, you could understand the deep behavior of your traffic , and so – have access control decisions done by the deepest analysis available.

By creating a single-vendor solution , one is able to interconnect the different
security modules and create a real UTM device , in my terms – “Real UTM” is applicable only if the device , and the different modules come from the same vendor , so it could sanitize the traffic using decisions based on a matrix check of each packet.

The following diagram ( D01 ) shows how a current concept UTM device actually passes
the traffic :



On current UTM environments , the packet actually has to go through each and every
module as a stage of inspection. What may happen is that one module might not be
certain if the packet contains an attack and so not mark it as attack and pass it on. The attack will pass between the different “Best Of Breed” modules and no decision will be taken to drop the packet , because no module found a specific attack in the mechanism and if it could , it wouldn’t be able to tell the following module about the attack because of different technologies , and vendor code confidentiality.

The following diagram ( D02 )shows exactly what happens to a packet that runs through
what is considered a real utm :



What is clearly visible from this diagram , is that a packet that runs through a real
UTM mechanism , runs through each and every one of the modules . note : if a packet is being intercepted by the IPS mechanism – it will ask for the antivirus to check it too , and so on for the AntiSpam and every UTM module. And later on , the UTM mechanism will decide based on scan checks from all of the modules , if to pass it on , or to drop the packet. It is not session based , but packet based.
Now , what is happening in that environment is that each module can give some
kind of grading to the packet , even if it is not sure it is an attack . next , the UTM consolidation engine can grade the packet based on all of the modules , and have a sophisticated decision to drop or to accept the packet , and that is after a real deep inspection.

A new UTM RFC/Protocol is required.

One cannot realize how major vendors will exchange code parts between them,
But maybe some kind of a consolidation protocol is needed here . we had ICAP in the
past to check for different traffic methods, maybe now is the time to write a new protocol that inspection modules could grade traffic by , and a consolidated decision could be made.

In conclusion , the UTM world is a wonderful and insightful world, the best of the
vendors are doing a great effort in order to give us the best practice results and the solutions we require. But because of misleading assumptions ,that “attacks may be more sophisticated but they still spread in the same ways” the UTM world will not be complete. What should be the concept is “an attack can come In different ways and
blended ways , check them all and never skip a phase”.


Labels: , , ,


Well , after a long time of thinking about it , and a long period
Of time where I though about – how can I publish my thoughts
In the professional information security field . a field which is not
Only a job role for me , but a way of life . a friend of mine
Has suggested that I start a blog , and what a better way to do it
Than on a google community …

So I hope you will enjoy the stuff that I post here . most of it
Will be technical and security related . but I am sure that every now
And then ( just the way I am ) I will post personal stuff

See ya on my blog @ sectorix.blogspot.com

Labels:


About

    My Name is Barry Shteiman, im a devoted tech junkie, and this is my blog.
    E: barry.shteiman -at- gmail.com
    Twitter : bshteiman

Tags & Categories

Mailing List & RSS

Stay Updated  
Add to Technorati Favorites