כללי התיכנותיקה - 19 כללים של הנדסת תוכנה שלא ניתן להתחמק מהם

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

מכיוון שאין להם שם מוכר, נתתי להם שם: "כללי התיכנותיקה" (הלחם לשוני של "תכנות" ו"פיסיקה").

מקור: http://potluckcomics.com/links-laws-of-physics

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

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

הנה הם לפניכם:



Conway’s Law ארגוני ארכיטקטורה
"מבנה התוכנה והקשרים בין חלקיה, סופם שיהיו שיקוף של המבנה הארגוני של הארגון בה היא מפותחת" (רפרנס)
הסבר: המבנה הארגוני הוא כוח חזק מאין כמוהו, שלא ניתן להתעלם ממנו. למשל: אם אתם מתכננים קומפיילר בין 4 שלבים, אך יש לכם 3 צוותי פיתוח - סביר שבסופו של דבר אחד השלבים יהיה אנמי, ובפועל יהיה לכם קומפיילר עם 3 שלבים. הפתרון - להכיר במציאות: או שתתכננו קומפיילר בין 3 שלבים, או שתארגנו את האנשים ב 4 צוותים.


עיקרון פארטו כללי
"במקרים רבים, 80% מההשלכות (effects) נובעות מ 20% מהגורמים הפעילים (causes)"
רקע: ידוע גם בשם "כלל 80-20", והוא כלל שנוסח על ידי הכלכלן האיטלקי וילפרדו פארטו, לאחר שראה את פיזור העושר באיטליה במאה ה-19 (כיום, פיזור העושר הוא קיצוני הרבה יותר, ואולי לא משקף כבר "התפלגות טבעית של סיבה ותוצאה").
וריאציה א: מוצר
"80% המערך של מוצר, ניתן להשיג ב 20% מההשקעה"
וריאציה ב: קוד
"80% מהבאגים המשמעותיים, נובעים מ 20% מאזורי הקוד"
וריאציה ג: ארגוני
"כ 66% מהעשייה המשמעותית, נעשית על ידי כ 33% מהמתכנתים", מה שמתבטא גם ב:

כלל הכישרון ארגוני טכנולוגיה
"האלמנט שמנבא בצורה הטובה ביותר הצלחה או כישלון של תוכנה הוא לא הטכנולוגיה, שפת התכנות, או ה Framework - אלא המתכנתים שכותבים את התוכנה"

עקרון הדורות המקוצרים (short generations) כללי
"כל עשור יהיה על איש התוכנה ללמוד 50% מהמקצוע מחדש"
וריאציה: "כל עשור, 100% מהטכנולוגיות שבשימוש - יתחלפו".
מי שלא מוכן / מבין את ההשקעה הנדרשת בכדי להישאר במקצוע - ייפלט מהתחום במשבר הראשון לאחר מעבר של "דור".


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


עקרון ה Not Invented Here (בקיצור: NIH) קוד הטיה אנושית
"הדשא של השכן ירוק יותר, אך הקוד של השכן הוא גרוע, לא מובן, ולעתים פשוט מטופש"

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

העיקרון הביולוגי של הקוד (הדוד בוב) קוד

"Code Rots"
כלומר: קוד שלא עובר חידוש (refactoring) - הולך ו"נרקב" ואיכותו פוחתת. השקעה רק בפיצ'רים, ללא השקעה בחידוש הקוד תביא את הקוד למצב שאיננו ניתן יותר לתחזוקה, ויש לכתוב אותו מחדש. Guideline מקובל לאורך החיים של תוכנה עד לשלב בו יש לכתוב אותה מחדש (אם לא בוצעו פעולות refactoring, "הזרמת חמצן") הוא 3 עד 5 שנים.
היבט נוסף הוא העיקרון ש"קוד שלא נקרא כחצי שנה - הופך לקוד זר ולא מוכר" (ידוע כ Eagleson's Law). רמת הקריאות של הקוד, ועוצמת המסרים והעקרונות המשתקפים מהקוד - משפיעים רבות על קצב ה"ריקבון" של הקוד.


Lubarsky's law of Cybernetic Entomology קוד
"תמיד יש עוד באג אחד במערכת"
למשל: לאחר 11 שנה של שימוש המוני, נתגלה באג באלגוריתם החיפוש הבינארי של ספריית Java הסטנדרטית. (באג מאוד פינתי, כמובן).


לחלופין: Linus’s Law - הופרך כמיתוס
"Given enough eyeballs, all bugs are shallow".
כלומר: בהינתן מספיק עיניים בוחנות - כל הבאגים יימצאו.
הכלל נקרא על שם לינוס טורבאלדס, יוצר הלינוקס, מכיוון שהוא מבטא סוג של הנחה סמויה של קהילת הקוד הפתוח. הכלל לא הוגדר ע"י לינוס, אלא על ידי אדם אחר, אריק ריימונד.

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



ללא שם (Michael Nygard) פרודשיין
"משתמשים מגבירים בצורה בלתי-מוגבלת את אי-יציבות המערכת"
בנוסח אחר: "לעולם לא ניתן ליצור סביבת stating/testing שתחווה את כל הבעיות של סביבת production".
זו גם סוג של עקיצה למי שכותב תוכנה ללא משתמשים, ונמצא ב"אשליה" שהקוד שלו יציב, scalable, וכו'.
הכלל הוזכר לראשונה בספר (המצוין!) "!Release It"

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


Sturgeon’s Revelation כללי
"90% מכל דבר זה שטויות"

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

The Hype Cycle טכנולוגיה

הסבר: טכנולוגיות חדשות נוטות לחזור אחר אותו מחזור של Hype שטכנולוגיות עבר עברו:

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

הנה דוגמה למיפוי של טכנולוגיות עכשוויות, והמיקום שלהן ב Hype Cycle:

לחצו להגדלה. מקור: Gartner.

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


כלל ההקשר השגוי מתודולוגיה
"אין רעיון טוב שלא ניתן להשתמש בו בצורה שגויה לחלוטין" (ידוע גם כ Flon’s Axiom)



חוק ה 90-90 ניהול זמנים / פרויקטים
"90% מהקוד - ייכתב ב 90% מהזמן. יתר עשרת האחוזים מהקוד - ייכתבו ב 90% נוספים מהזמן." (רפרנס)
יש כמה כללים דומים שמבטאים רעיון דומה:

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

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

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


Brook’s Law ניהול זמנים / פרויקטים
"הוספת אנשים לפרויקט מאחר ובשלב מתקדם - רק תגרום לפרויקט לאחר יותר" (רפרנס)
הסיבות:

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

צורה אחרת: "The bearing of a child takes nine months, no matter how many women are assigned"


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

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

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



שיהיה בהצלחה!

מבוא לאבטחת מידע ("סייבר" ושטויות שכאלו) - חלק ב'

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

לא עניתי אבל על השאלה המתבקשת: "מה עושים?" כיצד מתגוננים ו/או מתכננים מערכות תוכנה מאובטחות יותר[א]?

- על שאלות אלו אנסה לענות בפוסט הנוכחי.

מודל ה-CIA

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

• Confidentiality (סודיות) - מניעת חשיפה לא מורשית של מידע.
• אבני יסוד בהגנה: Authentication (אימות זהות), Authorization (ניהול הרשאות), והצפנה.
• Integrity (שלמות הנתונים) - מניעת שינוי לא רצוי של נתונים, זיוף נתונים, או השחתת נתונים. הידיעה שנתונים שמשתמשים ניגשים אליהם הם אותנטיים ולא שונו ע"י גורם עויין.
• אבני יסוד בהגנה: חתימה דיגיטלית, Authentication, ו Audit (רישום הגישות לנתונים)
• Availability (זמינות) - ווידוא שניתן לגשת לנתונים בכל זמן.
• אבני יסוד בהגנה: יתירות, וגיבויים / Disaster Recovery.

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

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

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

4 עקרונות יסוד נוספים

מודל ה CIA הוא שימושי - אך כנראה הוא המודל הבסיסי ביותר שניתן לחשוב עליו. להלן קבוצה של עקרונות יסוד חשובים שליקטתי. העקרונות הללו הם ה Design Principles היסודיים, בחשיבה על תכנון מערכת כמערכת מאובטחת.


Non-Repudiation (אי-התכחשות)

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

הידע מי ביצע את הפעולה מאפשר לנו להגביל פעולות מסוימות (Access Control => Confidentiality), יכולת ניטור הפעולות (Monitoring => Anomaly Detection) ויכולת לבוא "בחשבון" עם מי שביצע פעולה לא ראויה (Forensics => התרעה).

את אי-ההתכחשות משיגים ע"י:

• Authentication (אימות זהות) - ארחיב עליה בהמשך.
• Audit או לוגים - רישום מה קרה ומי עשה את זה ומתי.

דרכים מצוינות "למסמס" אי-התכחשות הן:

• לחלק את אותו username והססמה לקבוצת אנשים - ואז לא ניתן לדעת מי מהם ביצע את הפעולה, או האם הקבוצה בעצם התרחבה ללא "כוונת המשורר".
• להשתמש במערכת ב"משתמשים טכניים" (technical users) להם יש הרשאות עדיפות ואיתם מבצעים את הפעולות הרגישות - תוך כדי שממסכים מי המשתמש האמיתי שיזם את הפעולה.
• דוגמה: הפקודה "sudo bash" בלינוקס.
• דוגמה נוספת: משתמש הפעיל חישוב של דו"ח / תהליך במערכת, והמערכת מעבירה SQL Query למשתמש טכני (שלו יש גישה מלאה לבסיס הנתונים - כי למשתמש לא נתן כזו גישה! חס ושלום). כשנגלה שמשהו לא טוב קרה בבסיס הנתונים ע"י המשתמש הטכני - לא נדע לקשר זאת לגורם אנושי.

כמה מלים על ססמאות כאמצעי אימות-זיהוי (Authentication)

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

אבל:

• לבני האדם יש דברים חשובים יותר בחיים משינון ססמאות מורכבות. רובנו "נופלים" לאותן ססמאות חוזרות (12345, password, querty, וכו') - מה שמקל על תוקף פוטנציאלי "לנחש" את הססמה שלנו. בעזרת "מילון" / סטטיסטיקה של הססמאות הנפוצות ביותר, ואולי ע"י כמה פרטי רקע שניתן למצוא עלינו ברשת. פעמים רבות יהיה ניתן "למצוא" את הססמה שלנו גם בלי להכיר אותנו באופן אישי.
  מכירים את המסכים עליהם מודבק פתק PostIt עם הססמה למערכת?
• בעזרת תוכנת מחשב פשוטה ניתן לנסות ולנחש את הססמה שלנו ב Brute force: פשוט לנסות שוב ושוב עוד קומבינציות. אולי מילון של 8000 ססמאות נפוצות (יש כאלו לשפות דיבור שונות), ואולי לנסות את כל האפשרויות לאורך זמן. עדיין קיימות מערכות רבות שלא ינסו לחסום את המשתמש, גם כאשר הוא מנסה להיכנס למערכת עם אלפי ססמאות שונות בכל שעה, ובמשך ימים רבים.
• ה Password Strength Meter של My1Login יעריך את חוזק הססמה כנגד Brute Force וייתן כמה טיפים. למשל: מדוע הססמה "MyPasswordIsStrong" היא חלשה למדי.
• חלק מהחלשות שלנו כבני אנוש הן חולשות חברתיות, אותן תוקפים יודעים לנצל - מה שנקרא Social Engineering.
• אם מישהו ממש נחמד יבקש מכם עזרה - לא תעזרו לו?
• נניח שלא. אם הוא יעשה משהו טוב עבורכם ואז יבקש עזרה בחזרה - לא סביר יותר שתעזרו לו בחזרה? לא תתנו לו "רק לדקה" את הגישה שלכם למערכת כדי לעזור לו "במצוקה"?
• יש סיפור על בחור אירופאי שחדר ל CIA אי שם בשנות ה-90 עם אפס אמצעים. הוא ראה בספר הטלפונים את מרחב מספרי הטלפונים של ה CIA (כולם מתחילים ב....) והתקשר באופן אקראי למשתמשים. הוא הציג את עצמו כאיש IT ואמר שהוא ממש מתנצל, אבל בשל בעיה הוא חייב לנתק אותם לכמה שעות מהמערכת.
  "אבל זה לא אפשרי! אני חייב לעבוד!" - רטן עובד ה CIA האקראי בצד השני.
  "אתה יודע מה..." גילה אמפתיה חברית איש ה-IT מדומה "תן לי את הססמה שלך ואני אסדר לך משהו. אבל אל תגלה לאף אחד!". כמה עובדים נידבו את שם המשתמש והססמה שלהם לקול בטלפון (שבכלל מקורו באירופה) - הכל מרצון טוב להמשיך לעבוד ולא להתבטל...
  התוקף, חדר למערכת, כמשתמש לגיטימי - מתחת לרדאר של כל אמצעי ההגנה (שהיו מקובלים אז).

מה אפשר לעשות?

עולם האבטחה נוטה לחלק את סגנונות אימות זהות המשתמש לשלושה Authentication Factors:

• Something you Know - כמו ססמה או שם חיית המחמד הראשונה שלכם.
• Something you Have - למשל כרטיס עובד, קוד שנשלח למכשיר הטלפון (הטלפון = something you have), או Certificate שמותקן על המחשב האישי (עדיף נייד).
• Something you Are - למשל מדדים ביומטריים כמו: טביעת אצבע, חתימה, קול, צילום רשתית (זה כבר לא מדע בדיוני), צורת הליכה (שמסתבר שהיא דיי ייחודית - כמו טביעת אצבע), וכו'.

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

דרך מקובלת יותר היא לבצע Multi-Factor Authentication (בקיצור: MFA), כלומר לאמת את המשתמש ע"פ 2 Factors שונים של אימות זהות: ססמה וגם קוד שנשלח לטלפון. השילוב הזה (נניח לגישה מהבית / בעשות לא אופייניות) הוא לא מטריד כ"כ, אך הוא מקשה מאוד על תוקף פוטנציאלי להתחזות אליכם.
דוגמה נפוצה אחרת ל MFA הן מכשיר כספומט שדורש גם כרטיס אשראי וגם קוד PIN.

MFA הוא סוג של Defense-In-Depth - עקרון שעליו נדבר בהמשך.

Implicit Deny (בסלנג: "נופל סגור")

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

• כי לא לאפשר גישה - אומר שלא ניתן לגנוב מידע.
• כי אם נרשה גישה גם במצבי קצה - האקרים יכולים ללמוד עליהם ואז דרכם נעשית קלה יותר: עליהם "להביא" את עצמם למצב קצה - ואז הם "בפנים".

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

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

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




Defense In Depth (הגנה לעומק)

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

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

מקור: nytimes

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

• קיר בטון חלק בגובה 4 מ' - הקשה מאוד לטיפוס.
• שדה של ברזנטים מחודדים (spike mats, נקרא "הדשא של סטאלין") שמקשה מאוד על ריצה והופך נפילה למסוכנת.
• גדר חשמלית. 
• מחסומי טנקים - שנועדו לחסום מעבר של רכבים.
• 302 מגדלי שמירה עם שומרים חמושים שלא יהססו לירות בדמות לא ברורה.
• פטרול של שומרים מלווים בכלבי תקיפה + שביל גישוש (שביל עם חול מיושר) ברוחב 6 עד 15 מ' שאדם שיעבור דרכו ישאיר עקבות - וכך ידעו על הימצאותו.
• שביל הגישוש הוא יתיר לגדר החשמלית - לזיהוי חדירה של גורם לא מורשה למרחב.
• מרחב גדול שהושטח על מנת להסיר מקומות מחבוא אפשריים - בו דמות שעוברת תהיה בולטת. נקרא "רצועת המוות".
• תעלה למניעת מעבר כלי רכב.
• זוהי הגנה יתירה למחסומי הטנקים, שהזכרנו קודם לכן.
• קיר בטון חלק בגובה 4 מטר עם גדר תיל בראשו - החומה שגבלה עם גרמניה המערבית.

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

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

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

בעולם התוכנה, Defense In Depth נראה יותר כמו התרשים הבא: ריבוי כלים ותהליכים, עם מידה מסוימת יש יתירות ביניהם (redundancy) - כך שכישלון של כל רכיב במערכת, לא יותיר את המערכת חשופה:

Layered Security (נקרא גם "Castle Approach")

האם אתם יודעים כיצד נראו טירות בימי-הביניים?
אם אתם חובבי היסטוריה ולחימה - בוודאי שאתם יודעים!

בדרך כלל היו לטירות 2 או 3 חומות, בהם שערים.
כל חומה, סיפקה רמה אחרת של אבטחה - שהתאימה לה.

למשל:

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

ניתן היה לבנות את העיר כשלושה רבעים בלתי-תלויים, כשלכל רובע יש שער עם כללי כניסה משלו.

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

דוגמה מהעולם האמיתי

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

האינטרנט

מחוץ ל Data Center שורר האינטרנט - מלא באיומים ופורעי חוק.

כדרך קבע bots עוינים (יש גם bots ידידותיים. למשל: מנוע חיפוש, או כל אלו שעשיו מפתחים לפייסבוק) שפועלים באינטרנט ומנסים לגשת ל Data Center שלנו:

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

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

ה Firewall בוחן את כל ההודעות ברמת ה (Internet Protocol (IP (+ התייחסות ל port של tcp) ומסנן תעבורה שמזוהה כעוינת ע"פ חוקים שהוגדרו לו. למשל:

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

ה DMZ (קיצור של demilitarized zone = "איזור מפורז")

ה DMZ הוא שכבת הגנה ראשונה שמסננת את ה Traffic מהאינטרנט. ב Data Center בענן, יהיו ב DMZ מעט מאוד שרתים - שתפקידם הוא בעיקר בקרה והגנה (ומכאן השם).

ה DMZ נוגע ב 2 Firewalls:

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

על אילו שרתים מדובר:

Reverse Proxy - שרת שמעביר תקשורת פנימה ובחזרה (התשובות של השרתים שלנו), אך מסתיר את הכתובות האמיתיות של השרתים הפנימיים (Network Address Translation). מדוע להסתיר את מבנה הרשת הפנימית שלנו? כדי להקשות על תוקף לנהל התקפה. למשל: תוקף החדיר Malware לשרת הפנימית אך הוא לא יודע מה לפקוד עליו כי הוא לא מכיר את השמות האמיתיים של השרתים.

זה התפקיד הראשון של ה Reverse Proxy אבל התפקיד החשוב שלו הוא להיות איתן.

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

ה Reverse Proxy הוא שרת פשוט למדי שמתוחזק בחשיבה על Security ומעצם כך כמות הפגיעויות שלו נמוכה משמעותית. יש לעדכן אותו ואת מערכת ההפעלה עליו הוא רץ בצורה תדירה.
אנו מעדיפים שה Traffic העוין מהאינטרנט קודם כל ייתקל בשרת מעודכן שכזה - ועליו וינסה עליו את "הטריקים שלו" ( - ולא יצליח) מאשר שייתקל בתוכנה שלנו שאותה יותר קשה להחזיק עמידה ומעודכנת.

Web Application Firewall (בקיצור WAF) - היא הגרסה המודרנית יותר של Reverse Proxy, שכוללת גם את סט היכולות הקלאסי של Reverse Proxy. בדומה ל Firewall, ש"מבין" תעבורה של פרוטוקול IP (פרוטוקול האינטרנט) ויודע לסנן ע"פ חוקים תעבורה בעייתית, ה WAF "מבין" HTTP ויודע לסנן תעבורה בעייתית: תעבורה שמנסה להגיע ל URLs לא תקינים, שמנסה לסרוק רנדומלית URLs עם HTTP Method חשוד (למשל: קריאה ל DELETE על כל ה URLs הידועים של המערכת).

התעבורה הנ"ל יכולה להיות תקינה לחלוטין מבחינת ה Firewall (פרוטוקול IP), אך דיי ברור שהיא עוינת ברגע שמתבוננים בה ברמת ה HTTP. על מנת "לסנן" HTTP יש "להרכיב" את ה packets של IP לכדי הודעת HTTP request, מה שנעדיף לעשות על תוכן שכבר עבר סינון ראשוני של Firewall.

הערה: עבור מערכות שאינן בענן (on-premises) תפקיד ה DMZ הוא מעט שונה (למשל: מכיל שרתי אינטרנט ציבוריים), לא אכנס להבדלים אלו ברמת הפוסט.

רשת אמצעית

ברשת הפנימית הראשונית - אנו מציבים את שרתי הווב שלנו. אלו שמתקשרים עם המשתמשים (דרך ווב או דרך APIs). התעבורה שמגיעה עליהם עברה כבר סינון של ה Firewall החיצוני וה Reverse Proxy (או WAF), וה Firewall שבכניסה לרשת מאפשר רק לתעבורה כזו להיכנס (ע"י חסימת כל כתובות ה IP מלבד אלו של ה Reverse Proxy / WAF).

ברשת הפנימית נמצא באופן טיפוסי את הרכיבים הבאים:

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

היבט האבטחה של ה Proxy הוא שניתן להגדיר עליו כללים: להיכן אסור לצאת / לשלוח הודעות. ההגדרות יכולות להיות הן ברמת ה IP (כתובת IP) או ברמת ה HTTP (כלומר: URL Pattern).

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

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

Identity Detection / Prevention System (בקיצור IDS/IPS)

רכיבים אלו מאזינים לתעבורת הרשת לרשת הפנימית (זו שעברה סינון ראשוני ע"פ חוקי Firewall / WAF) ולזהות דפוסים חריגים או כאלו שנראים כמו התקפה פוטנציאלית. ההבדל המהותי בין IDS ל IPS הוא ש IDS, ברגע שזיהה משהו שנראה לו כמו התקפה יעלה Alert - לאנשי ה DevOps / Security. ה IPS יכול לקחת גם החלטה לחסום את תעבורת הרשת ולעצור את ההתקפה (במידה של זיהוי שגוי - הוא יעצור תעבורה לגיטימית).

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

יש חפיפה מסוימת בין WAF או Firewall חכמים ובין IDS/IPS, אבל כפי שציינו קודם לכן בפוסט - יש ייתרון ביתירות הזו בדמות Defense In Depth. כלי אחד שכשל - לא יגרום למערכת שלנו להיות חשופה.

Physical Security - זה גם חלק מהעניין. מקור: onthetech.com

רשת פנימית

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

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

סביר יותר שכאן נמצא כלי monitoring (למשל, אבל לא רק HIDS או Agents שונים) שמותקנים על שרתי ה DB עצמם ומנטרים את ההתנהגות על המערכת.

מה הצעד הבא?

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

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

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

לשם כך נוצרו מודלים ("Frameworks") שעוזרים למי שמשתמש בהם לתכנן מקצה לקצה - כיצד להקים ולתחזק מערך הגנה.

למשל, מודל ה NIST Cybersecurity Framework מגדיר את היסודות (cores) הבאים:

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

למשל: אתם רוצים לאבטח את גישת ה SSH לשרתי הפרודקשיין שלכם? אפשר לחפש בקטלוג המדריכים של NIST ולמצוא את NIST.IR.7966 - מדריך בן 50 עמודים שממצה את הנושא עד תום!  

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

• ניהול חשבונות
• אכיפת גישה
• צמצום גישה (Least Privilege principle)
• Audit וניטור
• ניהול סיכונים (בהיבט ה SSH)
• זיהוי ואימות משתמשים.

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

הרעיון של רוב ה Frameworks הוא לא להציע רשימה שטוחה של אמצי-אבטחה (Controls) - בנוסח "חייבים את הכל!".

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

מקור: https://rofori.wordpress.com

חוץ מ NIST CSF (קיצור של Cyber Security Framework) - אלו עוד Framework פופולריים קיימים?

לרוב מחלקים אותם ל-3 קטגוריות:

• Frameworks רגלוטוריים - אותם המדינה מחייבת על ארגונים מסויימים.
• למשל: HIPAA לארגונים המחזיקים מידע רפואי, SOX - לחברות בורסאיות בארה"ב, NERC CIP - לחברות החשמל בצפון אמריקה, וכו'
• Frameworks רגלוטוריים למחצה - אשר ארגון מקבל על עצמו כחלק מחוזה / הסדר מסחרי.
• הדוגמה הכי נפוצה: PCI-DSS של חברות האשראי. אם אתם מנהלים מידע על כרטיסי אשראי ואתם לא עומדים ברמת ההגנה של ה Framework / או בסטנדרטים שלו (למשל: לא יותר מ 1% מהעסקאות שאתם סולקים הם לא-לגיטימיות) - חברות האשראי עלולות להפסיק לעבוד אתכם. עבור ארגונים רבים - זהו עניין קיומי.
• יש Frameworks קצת פחות ידועים בעולם עריכת הדין, חשבנאות, וכו'.
• Voluntary Frameworks - שהארגון בוחר לאמץ ביוזמתו בגלל צרכים כאלו או אחרים.
• ISO/IEC 27001 - הוא ה Framework הנפוץ בתחום, ובד"כ אימוץ שלו כולל הסמכה ע"י גוף שהוסמך לכך (חברות ייעוץ שונות).
• הוא נחשב בסיסי, נדרש לעתים על מנת להיות ספק של ארגונים גדולים. דיי "מרובע" בתפיסות שלו, בעיקר מסביב לתהליכים.
• יש לו 2 גרסאות תקפות: 2005 - גרסה מאוד ממוקדת תהליכים ("Plan-Do-Check-Act") והתיעוד שלהם (למי שמכיר ISO 9000), וגרסאת 2013 - שנחשבת יותר גמישה ומעשית.
• NIST SP800-53 (נקרא גם NIST 800 series) - הוא תקן אבטחה לו נדרשים גופים ממשלתיים בארה"ב (ועוד כמה מדינות שאמצו אותו כתקן) - אבל גם זמין לכל דורש.
• (ISC)2 Common Body of Knowledge (CBK) - זה בעצם ה Framework ה"פנימי" של הסמכות ה CISSP - ההסמכה ה"נחשבת" בעולם אבטחת המידע. 
• (DHS Cyber Resilience Review (CRR - עוד Framework אמריקאי (יש רבים כאלו), הפעם של הארגון לבטחון המולדת (DHS).
• CIS Critical Security Controls (כרגע בגרסה 6.0) - תקן "פתוח", שנוצר ע"י קבוצה של מומחי-אבטחה בלתי תלויים, וללא מטרות רווח, ש"מחוייבים לחופשיות האינטרנט".
• לעתים מזוהה עם חברת SANS - שמסייעת להפיץ אותו.
• OWASP TOP 10 - זהו לא Framework, אלא ניתוח תלת-שנתי של 10 ההתקפות הנפוצות ביותר על שרתי ווב, מידע פרטי, מובייל, וכו' (יש מספר גרסאות של הדו"ח). אם אתם רוצים להתחיל עם הבסיס של הבסיס - זה המקום.
• וכו' וכו'

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

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


אם אתם פשוט כותבים תוכנה ומנסים לאבטח אותה, ולא לאבטח ארגון שלם - כנראה ש OWASP זה השלב הראשון, ו ISC^2 / CIS / NIST - הם המקומות להמשיך וללמוד מהם /לקבל מהם מושג וכיוון.

סיכום

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

אני מקווה שהפוסט הזה עשה מעט סדר. עולם אבטחת המידע ("סייבר") הוא גדול ומורכב. יש תחומי מומחיות של Penetration Testing, איתור וניתוח Malware, מודיעין, Reverse Engineering, ועוד.

אני? אני ניסיתי רק לתת את הבסיס.


שיהיה בהצלחה!



-----


[א] לא קיימת מערכת מוגנת ב 100%, וגם אם תיאורטית היה ניתן ליצור אותה - היא לא הייתה משתלמת עסקית. מחירי האבטחה עולים בצורה מעריכית - ככל שאנו הולכים ומתקרבים ל"אבטחה מושלמת".

מבוא לאבטחת מידע ("סייבר" ושטויות כאלו...)

אבטחת מידע (Information Security) או בקיצור InfoSec היא הפרקטיקה של הגנה על מידע במערכות, בעיקר מערכות ממוחשבות - אך לא רק.
ממש בשנים האחרונות, הפכו אנשי האבטחה ("גננים") למשהו אחר לגמרי: אנשי סייבר ("מהנדסי נוף"). Fancy Name שהוא בעצם אותו הדבר.


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

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

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

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

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

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

אני ממליץ לכם להשקיע שלוש דקות לצפות בסרטון הקצבי הבא: https://vimeo.com/55183725

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

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

אני רוצה להתייחס לכמה אמירות מהסרטון:

"10,000,000 (עשר מיליון) התקפות מתבצעות ביום על מחלקת האנרגיה בארה''ב"

ההגדרה של התקפה כאן היא נכונה "משפטית", אך סביר שתעתע בצופה שאינו מומחה אבטחה.
התקפה שמתייחסים אליה כאן - היא קריאה בודדת ברשת (פרוטוקולי HTTP, ICMP, TCP, וכו') שכוונתה לגרום נזק. זו יכולה להיות קריאת Scanning (אין בעיה ל Scanner לשבת 24/7 ולשלוח קריאות בכדי ללמוד את הרשת והמערכת שלנו. לרוב הוא יעשה אותן בקצב "מנומס" בכדי שלא יבחינו בו), או ניסיון אקראי לפנות ל API עם פרמטרים שגויים ולראות מה התוצאה.

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

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

זה לא משחק מחשב!
בקרו ב http://map.norsecorp.com על מנת לראות מדגם מזערי, אך עדני בזמן אמת - של traffic עויין שעובר באינטרנט.
הטראפיק הזה לא עוצר, ולא פוחת, 24/7.

"59% מעובדים שעוזבים את החברה גונבים נתונים בדרכם החוצה"

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

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

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

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

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


"385 חברות בארה''ב חוו פריצה משמעותית למערכות שלהם ב 2010"

המספר הזה דווקא לא נשמע כ"כ מרשים. יש לכך 2 סיבות:

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

"בתי חולים בקליפורניה נקנסו ב $675K על כך שנכשלו בעקביות להגן על מידע של מטופלים"

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


"80% מהבנקים לא מצליחים לעצור הונאות לפני שהכסף מועבר"

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

חשוב לי להזכיר שהנטייה הטבעית לחשוב על אבטחת מידע כ Prevention - חסימת התוקף מבעוד מועד, אבל קשת הפעולה של אבטחת המידע היא רחבה הרבה יותר:

• מודיעין - להאזין לתוקפים וללמוד מה הם מתכננים מבעוד מועד. יש חברות שסורקות פורומים של תוקפים ותמורת תשלום - יעדכנו אתכם במגמות העדכניות אצל התוקפים ו/או כל שביב מידע שהם נתקלו בו שקשור לחברה שלכם.
• Prevention - בניית קווי הגנה נגד תוקפים פוטנציאלים. שם מושקע רוב המאמץ.
• Reaction - היכולת להגיב בזמן שהתקפה מתבצעת, ולצמצם את נזקיה. אם ע"י מערכות Alerts ותגובה ידנית, ואם ע"י סקריפטים של תגובה אוטומטית.
• Forensics ("זיהוי פלילי") - איסוף ראיות על התוקפים (ע"י audits ולוגים, למשל) בכדי לפעול נגדם בחזרה. אלו יכולים להיות צעדים משפטיים, או התקפת-נגד.
  חשבו על מערכת המשפט: היא לא מונעת שום פשע, אך עדיין יש לה תרומה חשובה מאוד בצמצם הפשע בכך שהיא מענישה פושעים לאחר שהעברה כבר בוצעה.

לסיכום ביניים:

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

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

מחירון לפרטי כרטיסי אשראי גנובים. מקור: http://cybersolace.co.uk/2016/04/06/hacking-underground-market

מושגים בסיסיים

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

• פגיעות / חולשה (vulnerability) היא תכונה של המערכת (מערכת תוכנה או מערכת אנושית) שתוקף יכול לנצל לרעה. פגיעויות ניתן "לחסום"- אך יש לכך מחיר. לעתים קרובות לא משתלם מבחינה עסקית או מבחינת "איכות החיים" לנטרל את הפגיעות - ולכן מקבלים אותה גם כאשר היא ידועה.
• למשל: למטוסים יש פגיעות שניתן לחטוף אותם ולרסק אותם. ניתן "לבטל" את הפגיעות הזו ע"י הפסקת שימוש במטוסים ע"י האנושות - מה שכנראה לא יקרה. אלטרנטיבה נוספת: ע"י בניית מטוסים מצופים בחומר חסין-התרסקות שייקר את עלות הטיסה פי 2000 - מה שגם כנראה לא יקרה.
• מה שכן עושים הוא למתן (mitigate) את הפגיעות ע"י אמצעים כלכליים יותר: אבטחה בשדות תעופה, הגנה פיסית טובה יותר על תא הטייס, נהלי אבטחה מחמירים יותר במהלך הטיסה, וכו'.
• איום (threat) הוא סוג מסוים של התקפה אפשרית. פעולה שתוקף יכול לנקוט.
• סיכון (risk) הוא הסבירות שאיום מסוים יתממש. בכדי שאיום יתממש יש גם צורך בתוקף שיממש אותו - וגם פגיעות שתאפשר את ההיתכנות שלו.
• למשל: תוקף יכול לבצע "חטיפה והתרסקות של מקרר ביתי", אך מכיוון שלמקרר ביתי אין את הפגיעות של "התרסקות" - האיום לא יכול להתממש. למקרר ביתי כן יש את הפגיעות של "חטיפה", אבל המוטיבציה לכזו תקיפה היא כ"כ קטנה כך שאנו יכולים בקלות לקבל עלינו את הסיכון הזה.

מקור: pickywallpapers

2016

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

בלי מאמץ מיוחד, קפצתי לאתר Hackmageddon שמבצע סיכום דו-שבועי של התקפות שהתפרסמו באותה התקופה. הנה כמה highlights ממה שמצאתי במהלך חודש (שבועיים מפברואר + שבועיים ממרץ), ויחסית ל Highlights של 2010:

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

הנה כמה דוגמאות שצצות מהזיכרון:

• הניתוח של אולה ביני כיצד עובד תור (כלי לאנונימיות באינטרנט)
• המאמר The Basics of Web Application Security שנכתב בצורה מתגלגלת בימים אלו בבלוג של מרטין פאוולר. מאמר פרקטי.
• רן בר-זיק ("אינטרנט ישראל") שכתב בעקביות מאמר בשנה על אבטחת-מידע בבלוג - אך מתחילת 2016 הספיק כבר לכתוב ארבעה מאמרים בנושא

שוב: המאמרים הללו נכתבו ע"י אנשי תוכנה - לא אנשי אבטחה. 

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

לחצו להגדלה

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

סוגי תוקפים

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

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

גם את מידת המומחיות התוקפים ניתן לאפיין ולסווג:

• Casual Person - אנשים ללא מומחיות טכנית עדיין יכולים לבצע התקפות. דוגמה קלאסית: Insiders.
• Script Kiddies - אנשי בעלי יכולות טכניות בסיסיות, המשתמשים (הורידו באינטרנט) בכלים אוטומטיים שמישהו אחר הכין על מנת להפעיל התקפות. הם לרוב לא יודעים כיצד הכלים הללו עובדים אך משמשים כמכפיל כח למי שבנה את הכלי.
• תוקפים ברמת מומחיות בינונית - אנשים בעלי יכולת לכתוב סקריפטים / קוד והבנה בסיסית בעולם התוכנה, היכולים להמציא התקפות משלהם - לרוב לא כ"כ מתוחכמות או פשוט וריאציה משופרת של התקפה קיימת.
• "האקר" - זהו במקור תואר כבוד למקצועני תוכנה ברמה הגבוהה ביותר, בעלי הבנה עמוקה בכתיבת קוד, מערכות הפעלה, רשתות נתונים, בסיסי נתונים וכו' אשר ממציאים ומיישמים התקפות מורכבות ומתוחכמות. את הכלים שלהם הם לעתים מפיצים לכל דורש - וכך מאפשרים את הקטגוריה של ה Script Kiddies.
  המונח "האקר" כבר איננו באמת אקסלוסיבי ומשמש סבים רבים לתאר את הנכנדים שלהם שיודעים להשתמש בגוגל "הוא מצא לבד את האתר של ביטוח לאומי! הוא ממש האקר!!".

מחירון לשירותי "האקינג" כלליים. מקור: http://cybersolace.co.uk/2016/04/06/hacking-underground-market

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

• איומים פוטנציאלים מאדם ללא מומחיות טכנית:
• גניבת רוחב פס - שכן או עובר אורח ש"זולל" לנו חלק מגלישת האינטרנט.
• SPAM - שליחת מיילים ללא הסכמת המקבל ובכמויות גדולות.
• גניבת זהות נקודתית - פרסום פוסטים באתרים / רשתות חברתיות בשם אדם אחר וללא ידיעתו / הסכמתו.
• איומים מצד משתמש טכני פשוט שמשתמש בכלים שניתן להוריד באינטרנט (מה שנקרא Scipt Kiddie):
• האזנה לתקשורת אלחוטית של משתמשים אחרים ברשת Wi-Fi או בתא סלולרי זהה.
• גילוי ססמה של משתמש אחר ע"י keylogger (רכיב שניתן לקנות באינטרנט ומחברים בין המקלדת למחשב על מנת להקליט את ססמת החיבור למחשב)
• ניחוש ססמה של משתמשים לאתרים ע"י שימוש ב Dictionary Attack (ניסוי כמה אלפי הססמאות הנפוצות ביותר).
• איומים מצד "פושע אינטרנט" (cyber criminal) - אדם בעל נכונות לקחת סיכונים ובעל רמת מומחיות בינונית:
• Rogue security software - היכולת לספר לאדם שהמחשב שלו נמצא בסיכון אבטחה (זה יכול להיות סתם פופ-אפ מעוצב באתר) ולדרוש ממנו תשלום על מנת לטפל בה. מסתבר שזה שוק לא קטן...
• טרנד חם חם היום הוא ה"כופרה" (ransomware) שעשתה לאחרונה עליה משמעותית לקהל דוברי העברית. תוכנה שמצפינה למשתמש את הקבצים במחשב - ודורשת תשלום תמונת מפתח ההצפנה.
• אפשר לקרוא עוד (בעברית) בכלכליסט, גיקטיים, ועוד לינק בגיקטיים.
• הפצת תוכנות זדוניות (malware - "נוזקה") למשתמשי קצה. למשל: העלאת משחק או תוכנה נגועה לאתר שיתוף קבצים. התוכנה הזדונית, ברגע שהופעלה יכולה לשלוח לתוקף מידע שנמצא על המחשב (למשל: תיקיית "My Documents" בחלונות) - בתקווה "לדוג" משהו שימושי, או לשמש כבסיס להתקפת Denial of Service ואז בקשת כופר.
• Phishing - התחזות לאתר לגיטימי, שלעתים נראה 1:1 כמו האתר אליו הם מתחזים על מנת לגנוב מהמשתמשים את הססמאות שלהם (או מקבילה אחרת). אל האתר המזויף ניתן להגיע ע"י קישור בפורום או במייל (קל לביצוע) או ע"י רישום של כתובת דומה מאוד לאתר המקורי שמשתמשים אקראיים יכולים להתבלבל.
• בווריאציה אחרת: מספיק ה click של המשתמש על מנת לגנוב session של המשתמש לאתר - וביצוע פעולות באתר "בשם המשתמש" (להלן CSRF, Clickjacking)
• איומים מצד "האקרים":
• גניבת זהות מלאה: גניבת ושינוי ססמאות לאתרים המרכזיים של האדם (Gmail, פייסבוק, וכו'). מכאן יש קשת רחבה של אפשרויות: שליטה על המייל מאפשר בד"כ אתחול ססמה וקבלת סיסמה חדשה לאתרים רבים. ניתן לגנוב כסף ושירותים, ניתן לדרוש כופר להחזרת הזהות, או לבצע פעולות לפגוע במוניטין (reputation) של האדם שהותקף - כאשר אותו האדם יתקשה להוכיח שלא הוא העומד מאחרי המעשים.
• גניבת כמויות של נתונים פרטיים של משתמשים מאתרים עסקיים - ופגיעה במוניטין שלהם, עד פגיעה חמורה ביכולת שלהם להמשיך ולעשות עסקים.
• בעצם... כל מה שתוכנה יכולה לעשות. בהינתן ההשקעה מצד התוקף, פגיעויות קיימות מצד המותקף, וקצת מזל לטובתו של התוקף.

כדאי לזכור שלאינטרנט יש שלוש תכונות שהופכות אותו לסביבה פורה כ"כ להתקפות:

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

סיכום

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

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

שיהיה בהצלחה!

מצגת על מיקרו-שירותים ב DevConTLV בפורים

בפורים, ממש לפני כמה שבועות הופעתי בכנס DevConTLV שהיה בסינמטק.

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

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

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

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

מקווה שתמצאו את החומר מעניין ושימושי!

ליאור