תוכנית עבודה לשנה הבאה, מפת איומים – בקשה ממכם

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

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

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

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

אשמח לשמוע מכם.

המדריך השלם לאבטחת סייבר לעסקים קטנים ובינוניים

שלום לכולם,

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

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

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

אז הנה אני מפרגן להם בלינק הבא.

 

 

אבטחת מידע במוסד רפואי נוסח שנת 2017

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

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

 

קמפיין לקוחות בשירות חיצוני

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

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

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

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

מה עושים? כנראה שאין הרבה מה לעשות. אפשר לנסות את ההצעות הבאות:

1. להגדיר חוקים במערכת DLP לזיהוי זליגת נתונים רגישים (שיוצאים בתור דוגמא למשרד הפרסום).
2. לנסות לזהות ולחסום גישה לקמפיינים כאלה ע"י מערכת Web Filtering – מאוד קשה לעלות על זה.
3. לחנך את השיווק (לא ממש יעזור).
4. לבנות עם מערכות מידע תשתית מוכנה מראש לקמפיינים – אחלה הצעה אבל בד"כ לא ממוממשת עקב חוסר משאבים.
5. להעביר החלטה בהנהלה/דירקטוריון נגד הפקרות בנתוני לקוחות – מאוד יעיל אבל קשה למימוש.

 

התמודדות עם תוכנות כופר Ransomware

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

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

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

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

 

המלצה נוספת מתייחסת לאתר חדש שעלה לאחרונה לאוויר המאפשר לחפש מפתחות הצפנה לפענוח תוכנות כופר מוכרות. האתר הוקם ע"י מספר חברות מובילות וע"י היורופול (ארגון האכיפה של ה – EU). האתר נקרא No More Ransom בכתובת: https://www.nomoreransom.org/

תגבו!

דרוש תקציב לאבטחת המידע

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

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

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

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

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

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

להלן מספר כלים עבור מנהל אבטחת מידע לקבלת תקציב עבור אבטחת המידע בארגון:
1. מענה לרגולציה: הרגולציה שאליה כפוף הארגון משפיעה רבות על אבטחת המידע. ישנן רגולציות עולמיות ומקומיות שאי עמידה בהן עלולה להעמיד את הארגון בפני קנסות ו/או פקיעת רישיון עסקי. לרוב, ההנהלה מאשרת פרויקטים הקשורים לרגולציה.
2. ניהול סיכונים: אבטחת מידע מבוססת בעיקר על מדע איכותי (בניגוד לכמותי) של סיכונים. הרי לא ניתן להעריך נזק כספי מדויק מפריצה למערכת נתונים וגניבת מידע או מפגיעה במוניטין של הארגון. עם זאת, על סמך שווי נכס איכותי או אירועי אבטחת מידע קודמים ניתן להעריך סיכונים של ליקויים שונים. על בסיס רמת הסיכון, ניתן להצדיק תקציב לאבטחת המידע .
3. החזר השקעה (ROI): למרות שאין תשואה ריאלית על השקעת ביטחון אלה יש רק ניהול סיכונים, ניתן לכמת עלות של נזק צפוי כגון:
עלות הנכס (Asset Value) X אחוז הפגיעה בנכס (Exposure Factor) = עלות בודדת (Single Loss Expectancy).
עלות בודדת (Single Loss Expectancy) X הסבירות השנתית שיקרה הנזק (Annualized Rate of Occurrence) = עלות הנזק השנתית (Annualized Loss Expectancy).
על עלויות לנזק או נזק שכבר קרה, ניתן להצדיק תקציב לאבטחת המידע .
4. תוכנית עבודה לאבטחת מידע: תוכנית אבטחת מידע צריכה להיגזר מהבנת הסביבה העסקית התואמת את האסטרטגיה העסקית של הארגון. חשוב מאוד לתכנן פרויקטים לטווח ארוך, להכניס אותם לתוכנית עבודה ולאשרה בהנהלה. אם משלבים בתוכנית העבודה את שלוש הנקודות הראשונות, הסיכוי שהמשימות השונות והתקציבים הנדרשים, יאושרו.
5. שילוב אבטחת מידע בפרויקטים: תמחור של פרויקטים באגף מערכות מידע חייבים לכלול גם אספקטים של אבטחת מידע (כגון: סקר אבטחת מידע, מערכות אבטחה, וכד'). שילוב ואישור אבטחת מידע בצמתים קריטיים ובקרה של הפרויקטים בוודאות יסייעו בקבלת תקציבים לאבטחת מידע.
6. הצגת אירועי אבטחת מידע: מנהל אבטחת מידע חייב לקחת חלק פעיל בישיבות הנהלה בחברה, ולהציג את תמונת אבטחת המידע בארגון ואירועי אבטחת מידע כחלק מאסטרטגיית סיוע לפיתוח העסקי בארגון הכוללת לו"ז ותקציב.
7. שיווק פעילות אבטחה: הצגת אבטחת מידע כ- Business Enabler Securely (מאפשר את העסקים המאובטחים) החצנת פעולות אבטחת מידע בארגון והאופן שבו רואים בארגון את מנהל אבטחת מידע קובעת את ההתייחסות שהוא יקבל בכול פורום או דרישת תקציב שהוא יעלה.

המידע שלך חָשוּב לך: חְשוֹב איך להגן עליו.

 

על כותב המאמר:

ליאור מזור, מהנדס תוכנה. בעל תואר ראשון B.sc למדעי המחשב ומתמטיקה, ניסיון של למעלה מ- 9 שנים באבטחת מידע ביישום והטמעה של מערכות אבטחת מידע וניסיון בניהול פרויקטים בארץ ובחו"ל. מוסמך מת"י כ Leading Auditor לתקן ISO 270001, מוסמך CISSP. וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

 

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

 

התקני IoT והסיכונים הנובעים מהם

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

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

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

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

האיומים הנובעים מהם הם אותם איומים הנובעים ממערכות אחרות, אך במספר הבדלים:

• הרכיבים האלה עשויים להיות מחוברים ישירות לאינטרנט באופן העוקף את ה – Firewall
• לא בטוח ש – Firewall יודע לתת מענה אבטחתי לרכיבים אלה
• הרכיבים האלה נבנו ללא תשתית אבטחה מספקת

נציין כאן מספר איומים הנובעים מהתקני IoT:

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

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

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

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

• להגדיר מדיניות הכנסת רכיבי IoT לארגון (שתאפשר כניסה מאוד מבוקרת ושתחסום כניסה של רוב ההתקנים האלה).
• בדיקה קפדנית של רמת האבטחה של כל התקן חדש (או דגם חדש של מוצר שכבר קיים ברשת).
• התקנת רכיבים כאלה מחוץ לרשת הארגונית, או בסגמנט רשת מבודד. למשל, מצלמות IP שממוקמות פיזית מחוץ למשרד ונגישות לקהל לא מבוקר, או מצלמות אלחוטיות.
• בדיקה שהיצרן משחרר טלאי אבטחה באופן מסודר. זה יעיד בין השאר על שימוש ברכיבים רגישים פנימיים בתוך המוצר, כגון רכיב הצפנה ושרת Web, המבוססים על סטנדרטים בשוק.
• הגדרות ACL קפדניות לממשק הניהול של התקנים אלה. להגביל את כתובות ה – IP היכולות לתקשר עם ההתקנים ואת השירותים (פורטים) הפתוחים.
• במידה וניתן, להגביל גישה של התקנים אלה עם מערכת NAC מתקדמת (לא על בסיס כתובת MAC).
• לבדוק אילו הגדרות פנימיות בהתקן ניתן להפעיל במטרה לצמצם את הסיכון.

 

אפליקציות מובייל לא מאובטחות

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

שנת 2014 הייתה שנת המפנה עבור אפליקציות מובייל שבה עקפו את כול התוכנות האחרות שניגשו לאינטרנט מהמחשב האישי או מהדפדפן הקונבנציונלי. לצד זאת גם עלו בצורה משמעותית מספר הפגיעויות באפליקציות, שגרמו לעלייה חדה במספר התקיפות ובפעילות הפלילית באפליקציות השונות.  לפי פרסומי חברת האבטחה FireEye הייתה עלייה חדה של כ- 188% אחוזים בפגיעויות באפליקציות במכשירי אנדרואיד בהשוואה לשנת 2011 ועד 262% במכשירי IOS.

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

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

1. (TTM (TIME TO MARKET קצר: שימוש במתודולוגיות פיתוח כגון Agile Development, גורם לכך שבממוצע TTM לאפליקציות מובייל מקוריים הוא בין 14-20 שבועות, נתון שתלוי גם במורכבות וגורמים אחרים של היישום. פיתוח מהיר שכזה מקשה על שילוב אלמנטים של אבטחת מידע.
2. Code Reuse: מפתחי אפליקציות במובייל נוטים להשתמש באותם מנגנונים (קטעי קוד) המכונים reuse לקוד עצמו, דבר שאוטומטית מממש את קיומה של בעיית אבטחת המידע במגוון רחב של מוצרים (שימוש במנגנון פגיע שוב ושוב), דבר הגורר פגיעות רוחביות.
3. שימוש בקוד פתוח: בקרב מפתחי אפליקציות מובייל, רווחת הדעה כי מנגנוני קוד פתוח הינם אוטומטית "בטוחים לשימוש ומאובטחים", דעה שכמובן אינה בהכרח נכונה ועלולה לגרור פגיעויות אבטחה מרובות ורוחביות באפליקציות שונות. שכן לעיתים קרובות מודולים של קוד פתוח מתוחזקים ע"י מפתחים בודדים אשר לא תמיד מודעים לעקרונות פיתוח מאובטח.

אז כיצד ניתן לשלב אבטחת מידע בפיתוח אפליקציות למובייל:

1. בשלב התכנון מתן הנחיות אבטחת מידע עבור ארכיטקטורה מאובטחת של המערכת וכן תכנון מנגנוני הגנה שיתנו מענה לפרצות שעלו בשלב הניתוח.
2. פיתוח בצורה מאובטחת לפי עקרונות ידועים (כגון: OWASP) והטמעת ליווי בפיתוח מאובטח (SDL- Security development lifecycle) כחלק משלבי הפיתוח והבדיקות.
3. ביצוע מבדקי חדירה (Penetration Test) לקבלת תמונה של מצב אבטחת המידע באופן שבאמצעותה ניתן להעריך את רמת האבטחה של האפליקציה. על ידי הדמיה של התקפה מכוונת, ניתוח וחקירת מערכות, בדיקת תגובה של מערכות הגנה ועוד.
4. ביצוע בדיקות אבטחת קוד אוטומטיות (Automated Code Analysis) לקבלת תמונה של מצב אבטחת המידע בתוך קוד האפליקציה והימנעות משגיאות אבטחה נפוצות ברמת התוכנה. המערכת סורקת בצורה אוטומטית את הקוד ומאתרת חורי אבטחה, על מנת לאתרם לפני התממשות הפריצה.
5. שילוב בדיקות אבטחת קוד אוטומטיות כחלק מתהליך הפיתוח (Secure Development Life (Cycle – יש לשלב מערכות בדיקת קוד אוטומטיות כחלק אינטגרלי מתהליך הפיתוח (כחלק מתהליך ה-Build) ואף מומלץ לשלבם במערכת מעקב הבאגים כדי למנוע "זניחה/התעלמות" מפתחים מליקויי אבטחת מידע שאותרו.
6. הגנה על תשתית האפליקציה ע"י תשתית (WAF (Web Application Firewall כחיץ בין האפליקציה לשרתי המערכת. מוצרי WAF נועדו להתמודד עם פרצות אפליקטיביות וכוללים מנגנון לזיהוי התקפות על המבוסס על למידת האפליקציה ועל חתימות.
7. עדכון אפליקציות למובייל על מנת לתקן חולשות אבטחת מידע שמתגלות בשפות הפיתוח ובמכשירי המובייל בכדי להגן על האפליקציה והמובייל.

 

על כותב המאמר:
ליאור מזור, מהנדס תוכנה. בעל תואר ראשון B.sc למדעי המחשב ומתמטיקה, ניסיון של למעלה מ 9 שנים באבטחת מידע ביישום והטמעה של מערכות אבטחת מידע וניסיון בניהול פרויקטים בארץ ובחו"ל. מוסמך מת"י כ Leading Auditor לתקן ISO 27001, מוסמך CISSP . וכן בעל ניסיון מקצועי בפיתוח, ביצוע מבדקי חדירה אפליקטיביים, בדיקות קוד, תקיפות והגנת סייבר.

סיווג ותיוג מידע

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

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

לאחרונה נתקלתי בפרוטוקול שנקרא TLP שפורסם ע"י ה – CERT האמריקאי (חלק מארגון ה – DHS, ארגון בטחון הפנים שלהם). הפרוטוקול, שהינו ראשי תיבות של Traffic Light Protocol, מציע דרך הרבה יותר ידידותית למשתמש לסיווג מידע. צבע הסיווג מגדיר את רמת רגישות המסמך.

• סיווג (רמזור) אדום: רגיש מאוד – תפוצה פנימית הקשורה לנושא הנדון בלבד (לא לכל העובדים בחברה)
• סיווג (רמזור) כתום: רגיש – תפוצת חברה
• סיווג ירוק: ניתן להפצה בין שותפים חיצוניים הקשורים לנושא (אבל לא בלמ"ס)
• סיווג לבן: בלמ"ס

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

 

באג/תיקון Leap Second

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

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

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