Friday, March 26, 2010

first impressions of Google’s Skipfish WVS

after getting really interested in a late Google project, i spent few hours today with Google’s Skipfish v1.25b , which is a Google project for a web application security scanner , or as some times referred in the professional arena – a WVS ( web vulnerabilities scanner ) and is completely open source as i like it.

as i mentioned, i am playing with version v.1.25b ( although 1.26b is available at time of writing the article ) against a vulnerable demo web application that i wrote a few months back… and got some impressions on the current version.

first of all, i have to admit , its blazing fast … once given a destination to scan, the scan is fast , and the results are displayed in a very elegant way ( although a bit too hardcore ) moreover the depth and methods of detecting problems are quite impressive.

that being said .. the security checks themselves missed lots of the application vulnerabilities , including some quite basic SQL Injections which were there especially for security demonstrations. but i will give the credit and wait until this tool matures a little more before i try it again , and i am sure it will be much better.

the report is excellent , very insightful and shows track of the trace of the stream until the vulnerability has been detected , which is always good, nevertheless – i would like to see in future versions some different export mechanisms of reports, such as XML and PDF, to make it more usable in the IT security ecosystem environment.

there is a point to remember that at current time it is being written and managed by one person at Google , as compared to enterprise tools such as IBM’s Rational AppScan or Qualys etc, so you have to give credit here :)

for ease of use , it is easy , but i do expect a UI , since most people that will run this scanner will require some interaction with it that does not require any CLI / Linux skills, since it is not in their job requirements , they just need to run a tool and test for baseline ( unfortunately that also includes lots of “consultants” ).

if i am to rate this tool , i would rate it at its current version (1.25b) with 6.5 of 10 for now , since i really like the speed and the overall architecture of it , but i do see the need for some more maturity and some more robust security tests.

it detected 9 of 14 SQLi and 4 of 8 XSS , and none of the 4 persistent XSS vulnerabilities ( although it claims to detect it ) .. and yes , i have fed it some credentials as needed..

its a descent alternative to lots of the tools out there even in its current stage , and i would definitely go back to it when some holes are put to its belt.

 

Finally, just a quick install HOW-TO for it.
if you want to install it under CentOS ( i used 5.2 ) then do the following :

1. download and extract the tgz file anywhere ( example : tar zxpfv skipfish*.tgz )
2. install some neccesary packages for the install

- yum instll gcc
- yum install openssl-devel
- yum install libidn-devel

3. step into the folder extracted and run – make
4. there you go. :)

Labels: , , , , ,

Friday, August 28, 2009

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

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

 

ביום חמישי הקרוב – 3 לספטמבר 2009 , במשרדי מיקרוסופט ישראל שברעננה , אעביר הרצאה בנושא TOP 10 DB Threats.

הרשמה לאירוע :

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032422463&culture=he-IL

 

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

Labels: , , , , ,

Tuesday, December 16, 2008

Security Assets Interoperability

שלום לכולם,

אתם מוזמנים לקרוא את הפוסט האחרון שלי בבלוג ImperViews בקישור הבא :

http://blog.imperva.com/2008/12/the-interoperability-of-your-s.html

Labels: , , ,

Monday, August 11, 2008

הגנת IPS כנגד SQL Injection , לא ממש...

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

אחד הדברים שתמיד הפתיעו אותי הוא התפיסה הרווחת ( והמוטעית ) אשר אומרת שניתן לחסום SQL Injection במערכות IPS או מערכות FW מתקדמות עם מנגנוני חתימות. ואני כמובן מוחה.

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

משפט SQL הוא משפט אשר עובר Parsing מסויים ולבסוף מעובד על ידי מנגנוני קלט אשר בודקים את תקינותו מבחינת Syntax וקישורו לאובייקטים קיימים בDB , על אותה רגל - משפט SQL Injection יהיה לעולם משפט אשר מנסה לקיים תנאי TRUE. על ידי כך במידה ויש התאמה לתנאי , השאילתה אשר מפיק משפט הSQL תרוץ על השרת...

ואם מדובר במשפטי TRUE ... אז משפט כמו 1=1 הוא נכון , וגם a=a הוא נכון , וגם 100<999 הוא נכון וכן הלאה ... כלומר במילים אחרות --> לא ניתן לייצר חתימה אשר תתפוס כל SQL Injection אלא את הבסיסיים בלבד.

או אולי , לפי הקונספט של לחפש את תווי הגרש ( ' ) בתוך מחרוזת ... והאם השמות "ג'ק" או "ג'ון" אינם שמות הגיוניים ? מובן שכן, ומתוך תפיסה חתימתית - לא יהיה ניתן להזין שמות כאלו לדף מאחורי IPS חתימתי שכזה ...

Labels: , , , , ,

Saturday, April 05, 2008

סוס טרויאני באתר Zap.co.il

במהלך היממה האחרונה קיבלתי התראות שונות כאשר השתמשתי באתר zap.co.il לחיפושים שונים. בכל פעם שאני מחפש משו באתר , אני מקבל התראה ממערכות הESET שלי ומערכת הFORTIGATE שלי על ניסיון חדירה של TROJAN בווקטור התקפה - IFrame.

אגב , אחת התוצאות היא שכאשר אתם מנסים ללחוץ על תוצאות חיפוש מסויימות - יש גרבלינג ללינק , והוא מפנה אתכם למקור חיצוני !

שלחתי מייל למפעילי ZAP בנושא.

zap-trojan

בדיקה :

נבדק באמצעות 4 מנועי הגנה שונים , על 4 מחשבים שונים ( בסביבות VMWARE סטריליות )

 

עדכון [ שעה 17:13 ] :

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

Labels: , , , ,

Saturday, March 22, 2008

לקום וליפול על שירות.

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

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

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

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

שירות.

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

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

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

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

ותחשבו על זה ...  

Labels: , , ,

Thursday, March 13, 2008

פרסום BGP ( או כתובות אחוריות ) לא גורם סיכון לנתב !

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

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

אבל, BGP ... אוי BGP ... ולאו דווקא בגלל שהוא BGP ...

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

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

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

אני רוצה להציג בפניכם שרטוטון :

BGPATTACK

עכשיו :

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

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

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

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

בכל אופן , הכתוב פה הוא דעתי.

Labels: , ,

Saturday, March 08, 2008

כיצד מתמודדים עם וירוסים וDLP בFaceBook ?

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

בוקר טוב בארי,

קראתי את הפוסט שלך לגבי הוירוס שהתגלה בפייסבוק ויש לי שאלה בנושא.

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

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

האם תוכל להפנות אותי למידע רלוונטי בנושא?

תודה מראש על העזרה ועל הזמן שלך,

יעקב

לשאלת אותם מנהלי IT , אכן יש צורך להגדיר "הגנות מיוחדות" שכאלו. את רובן ניתן ליישם באמצעות מערכות IPS ומערכות Network AV אשר יחסמו את ההתקפה לפני שהיא מגיעה לתחנה , וזו גם הדרך הנכונה ביותר לתקוף את הבעיה הזו כרגע ( למרות שלדעתי , יש צורך לחסום את השירות באופן מלא בארגון כי אין שום סיבה להשתמש בFB מתוך רשת ארגונית - פרט לבזבוז משאבים וזמן ).

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

1. משתמשים שמוציאים מידע החוצה.

2. אפליקציות זדוניות שמושכות מידע.

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

לגבי 1, לא תהיה ברירה - יש צורך להטמיע מערכת DLP , שכמובן הדרך המומלצת היא ההטמעה הרשתית של פתרון ( כגון PortAuthority ) ולארגונים עם פחות משאבים - Onigma שכעת הינו חלק מMcAfee. למיטב הבנתי יש אפילו פתרון לSymantec אבל אני לא מכיר אותו , ולכן לא יכול להעיד לגבי טיבו.

חשוב לי לציין , שאת הוירוס הראשון בFacebook תפס מרכז הFortiGuard של חברת Fortinet.

Labels: , , ,

Monday, February 11, 2008

הגבלה במקום חסימה ,P2P ברשת הארגונית.

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

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

דעתי הכנה בנושא היא - לא לבצע חסימה , אלא לבצע Shaping לתעבורה זו לניצולת בלתי אפשרית של עד 2K במערכות בקרת הגישה והניתוב.

הסיבה היא טכנית גרידה -

כאשר אפליקצית תקשורת כגון SKYPE מנסה ליצור קשר החוצה עם העולם , היא פונה לאחד ממאות הכתובות שיש בחוץ ופונה אליו בפורטים מסוכמים מראש על מנת לבצע גישה החוצה לשיחה. אך אם אין גישה שכזו בשל PORT חסום או IPS אשר מנסה לשבור את הבניה של התקשורת - התוכנה מתחילה להשתולל ולחפש דרך אחרת לצאת החוצה כדי לתת שירות ( וספציפית Skype מתמחים בCovert Channeling ) למשל על ידי יציאה דרך HTTP וכדומה. ולכן , בעצם ברגע שחסמנו SKYPE - ייתכן ולא באמת חסמנו , אך מה שכן , בטוח גרמנו לרעש ברשת , כי כל מחשב שינסה לגשת יעמיס לנו על הציוד ללא סיבה נראית לעין.

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

Dont Block It , Shape It.

Labels: , , ,

Sunday, February 10, 2008

מחשבות לגבי OpenID

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

אחת הדרכים המרתקות יותר שתופסות יותר ויותר כותרות לאחרונה היא OpenID.

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

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

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

אני אישית , רואה פה בעיה חמורה.

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

אני מחפש את האלמנט הנוסף . האם ייתכן שיחול מהפך של Full Disclosure על מידע פרטי ?

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

הקלות של הפעלת התקפות Phishing היא בלתי נסבלת בהקשר זה, האם ייתכן שברגע שאני נכנס לארגון אשר מחליט ( שימו לב : נבואה ... ) ליישם OpenID במערכות המידע הפנימיות , האם גם מערכות הERP ומערכות הCRM הופכות להיות נגישות ?

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

יותר מידי שאלות...

Labels: , , ,

Thursday, November 29, 2007

מיקומו של שרת הCA בטופולוגיה הארגונית

למי שלא מכיר - מערכת הCA ( ר"ת Certificate Authority ) , היא אותה מערכת אשר מנהלת ומחוללת סרטיפיקטים עבור הארגון , לכל מטרה שהיא - ובעיקר לשם אימות ועבודה מוצפנת מול מערכות שונות. לדוגמא - אחת הדרכים המקובלות כיום לעבוד בתשתית PKI , או להתחבר בVPN , הם באמצעות סרטיפיקט המופק על ידי מערכות הארגון.

בין המערכות שמרכיבות את הCA , תמיד קיים הCRL ( ר"ת Certificate Revocation List ) אשר מולו בעצם מתבצעת הבדיקה - האם הסרטיפיקט קיים וValid , או האם הוא Revoked או פג תוקף מסיבה כלשהי. כמובן שמערכת זו צריכה להיות זמינה לכל הגורמים הרלוונטיים.

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

אחד הדברים החשובים ביותר בארגון שלנו מבחינת תשתית PKI , הוא הPrivate Key שלנו. אותו מפתח מנוהל על גבי שרת הCA. מסיבה זו בדיוק - הופך שרת הCA לאחד הגורמים החשובים ביותר ברשת שלנו ודורש הגנה מקסימלית. שכן ברגע שנגנב הPRIVATE KEY שלנו , אפשר ללכת הביתה ...

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

ראשית , יש ליצור Subordinate CA , בעצם שרת CA משני אשר נגיש מבחינת המערכות השונות , ואז יש לבצע העברה של שרת הMaster CA לסגמנט משל עצמו ! לא VLAN ולא שום אמצעי לוגי -אלא רגל בFW. לאחר מכן יש למקם אכן את הCRL באיזור DMZ , אך אם הסרטיפיקטים הם לשימוש פנימי ארגוני - למקם אותו באיזור הSDMZ ( ר"ת Secured DMZ ) שמשמעותו שזהו חיץ שאינו נגיש מהאינטרנט או לספקים חיצוניים - אך נגיש לכל המשאבים בארגון. בשלב האחרון , יש לכבות את שרת הCA. אין שום סיבה שהוא יהיה נגיש , שכן המפתח הפרטי המוחזק על ידו לא צריך להיות זמין , ותפקודו של הSCA יהיה פונקציונלי לחלוטין , תוך סיכון פחות של משאבי הרשת.

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

אחת הבעיות בתפיסות של ארגונים שונים לגבי PKI היא שמבחינתם הכל צריך לעבוד מהקופסא , תכנון על פי הStarting Guide של אותו יצרן , ופעמים רבות - לא מעורב יועץ הנדסה בתהליך , מה שגורם למשאבים להיות חשופים, כי מה זה בעצם משנה אם בניתי תשתית מצויינת , ושמתי מערכות PKI והצפנתי את התווך בין השרתים ואת העבודה מול ציודי התקשורת - אבל את המפתח שמתי על השולחן ואומר "אף אחד לא יראה" ...

Labels: , , , ,

Friday, November 09, 2007

קורס הצגה אפקטיבית

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

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

מעבר לטיפים עיצוביים , ופסיכולוגיים לגבי יכולת העברת מצגת , מעביר צביקה בקורס - מספר מצגות אשר הוצגו בכנס TED בארה"ב . ועל ידי כך הפך אותי למעריץ בין-לילה של אל גור, מסתבר שאל גור הוא מרצה במועדון ה100K ( מאה אלף דולר להרצאה ) ואני לא חושב שראיתי מישהו שהצליח לקשור אותי כל כך חזק להקשבה אליו בצורה וירטואוזית כלכך ( פרט אולי לסטיב ג'ובס , שהוא גורו בתחום זה ).

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

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

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

בתור אחד שלא מאמין בשלמות , ומאמין שתמיד יש לאן להשתפר - אני חושב שמצאתי תחביב חדש.

Labels: , , , ,

Tuesday, October 16, 2007

מערכות אבטחת מידע בלי לוגים

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

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

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

מה שקורה בעצם , הוא שחברות כמו סיסקו בחרו לבסס את הפתרון שלהן על חומרה. ככזה - ניתן להגיע לביצועים גבוהים פי כמה , ובעלות נמוכה יותר , והTRADEOFF הוא תמיד לוותר על דיסק קשיח לטובת FLASH מאחר וזמני התגובה אחרים בתכלית. אך מוצרים אלו שומרים בד"כ עד 100 רשומות LOG ( זיכרון נדיף ) ומנקות אותו במקרה של RESTART וכדומה , כך כמובן לא ניתן לעקוב אחר אירוע שקרה לפני X זמן.

אני ארחיב ואוסיף שאני מאמין גדול גם בניתור של סביבות הנתבים והמתגים , וזאת על מנת לקבל ערך מוסף של ניתוח אירועים ובעיות ברשת ( בד"כ מוצרי הלוגים תומכים בסטנדרטים כמו SNMP TRAPS וכמו SYSLOG ) . יש לציין שיש לא מעט פתרונות כאלו אשר אינם עולים כסף נוסף - כגון הגרסאות הפשוטות של KIWI SYSLOG וההשקעה החומרתית היא פחות או יותר מחשב מיושן ורשיון לWINDOWS.

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

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

אני לא מדבר על הטמעה של מערכות SIM\SOC למיניהן , אבל מערכות לוגים בסיסיות - כמו SYSLOG או כמו פתרונות חליפיים , eIQ , FortiAnalyzer , Juniper NSM נדרשים כMandatory כאשר מתכננים כל מערכת אבטחת מידע כלשהי אשר אינה מכילה אלמנט אגירת נתונים פנימי.

Labels: , , ,

Thursday, September 27, 2007

מאמר מצויין בנושא פגיעות אתרי אינטרנט

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

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

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

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

תהנו.

[ פוסט תוקן ב27.9.07 ]

Labels: , , ,

Tuesday, April 17, 2007

אבטחת מידע למנהלים - לפני המכונות

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

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

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

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

מודעות.

Labels: , ,

Thursday, March 01, 2007

אבטחת מידע SMB

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

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

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

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

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

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