Book review - Threat Modeling

This post is quite long, for sure it came out longer than I intended. The English version is still below, but you might need to scroll down a bit.

לפני כמה חודשים הגיע הזמן לעדכן את מסמך "מודל האיומים" (Threat modeling) של התוכנה שלנו. וכן, באנגלית זה לגמרי נשמע יותר טוב. בשל צירוף נסיבות אקראי למדי, יצא שאני האדם הכי מתאים בצוות לביצוע המשימה (למעט מנהל צוות הפיתוח, אני היחיד בצוות שהשתתף בתהליך בעבר, ובניגוד אליו אני יכולתי למצוא קצת זמן להקדיש לזה). חדור מוטיבציה ועזוז, ניגשתי למשימה רק כדי לגלות שאין לי מושג ירוק איפה להתחיל - גם עם המסמך אותו אני צריך רק לעדכן מול העיניים. אז התחלתי לחפש מידע - קראתי את הפרק הרביעי בספר הזה שהתגלגל אצלנו במשרד, קראתי הנחיות בדף ויקי פנימי שהיה זמין לי, וישבתי לדבר עם מי שכתב את המסמך המקורי אותו רציתי לעדכן, שאמנם עזב את הצוות, אבל נשאר בחברה בתפקיד אחר. הוא הסביר לי המון על התהליך ועל מה צריך לעשות וכך יכולנו לעדכן את המודל בצורה אפקטיבית. כשהתברר לשנינו שאני גם נהנה מתהליך מידול האיומים, הוא השאיל לי ספר Threat Modeling : Designing for Security שכתב אדם שוסטק (Adam Shostack). 

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

אז מה יש בו? הספר מחולק לחמישה חלקים, וכל חלק מכיל כמה פרקים:

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

• החלק השני מתמקד ב"מציאת איומים" ועוסק בהרחבה במודל STRIDE (שכבר הזכרתי), בעצי התקפה ובמאגרי התקפות\חולשות, כשלכל אחת מהשיטות האלה מוקדש פרק שלם. הפרקים שונים מאוד זה מזה מבחינת איכות החומר הכתוב ומבחינת התועלת שהצלחתי למצוא בהם. כך למשל, בעוד שהפרק על STRIDE מאורגן בצורה מופתית - לכל אחת מהקטגוריות מצורף הסבר קצר על מהות הבעיה, יחד עם טבלה שמציגה מגוון אפשרויות למימוש התקפה - הפרק על עצי התקפה משמעותית חלש יותר ולאחר קריאתו נותרתי בתחושה שאני לא יועד הרבה יותר על השימוש בהם מאשר ידעתי קודם. אולי זה קשור לטענה בסוף הפרק: "מאוד קשה ליצור עצי התקפה".  במקרה של ספריות ההתקפה, יש פחות צורך לחשוב - שימוש ברשימות כמו Owasp top 10 (רשימה עם עשר המתקפות הכי נפוצות\מזיקות באינטרנט), או בCAPEC לא דורש הרבה מאוד הסברים, והספר מציין, כמו שכדאי לעשות, שלעבוד עם רשימה מפורטת כזו יכול להתברר כלא מעט עבודה.
   לבסוף, כדי להזכיר לנו שהעולם מסובך יותר משנדמה לנו, הפרק האחרון בחלק הזה מתעסק באיומים על פרטיות ובכלים מחשבתיים שיכולים לעזור לנו לשים לב לפגיעה בפרטיות. בעיקר מצא חן בעיני הרעיון של הנוטריקון  LINDDUN. 
• החלק השלישי עוסק בניהול האיומים - החל בסוגיות כמו "מתי לבצע פעולות של מידול איומים?" או "כמה זמן להשקיע בזה?", דרך נקודות שכדאי לשקול בתיעדוף הטיפול ובדרכיםמקובלות לטיפול באיומים נפוצים.
  חמשת הפרקים שבפרק הזה ממוקדים יחסית, ומעניינים במידה כמעט שווה.
  הפרק הזה ארוך למדי, וסקירה מפורטת של כל הפרקים בו תהיה מתישה. לכן, אני רוצה להתעכב על שתי נקודות קטנות.
  הראשונה היא דוגמה לסיבה בגללה אני מוצא את הספר מאוד נגיש ומאוד קריא לציבור הרחב: בפרק השביעי מזכיר המחבר בדיחה מוכרת על שני אנשים (אליס ובוב, כי אנחנו מתעסקים באבטחת תוכנה) שבורחים מדוב, בוב עוצר לנעול את נעלי הריצה שלו, כי הוא לא צריך לרוץ מהר יותר מהדוב, רק מהר יותר מאליס. הספר מסביר שהאנלוגיה הזו לא טובה במקרה שלנו, או, כפי שהוא מנסח זאת: "... לא זו בלבד שיש דובים רבים ביער, אלא שהם מקיימים כנסים בהם הם מדברים על טכניקות שיאפשרו להם לאכול את אליס וגם את בוב לארוחת צהריים". והנה לכם - תמונה מנטלית שקל לזכור.
  הנקודה השנייה היא הפרק העשירי, בו מצאתי את עצמי מהנהן בראשי שוב ושוב - נושא הפרק הוא "איך לוודא שאיומים מטופלים", או, בתרגום לעברית, "איך מוודאים שעשיתי עבודה טובה?" זה נשמע דומה לבדיקות תוכנה? זה לא במקרה. בתוך הפרק אפשר למצוא את הציטטה שתמיד נתקלים בה - you can't test quality in, והכותב מבהיר שבאותו אופן בדיוק אי אפשר לבדוק אבטחה לתוך המוצר. מה שכנראה מצא חן בעיני הכי הרבה היה כשתחושת הבטן שהייתה איתי לאורך קריאת הספר קיבלה אישור כשהכותב טען שבעת מידול איומים, בודקי התוכנה הם "בעלי ברית טבעיים"בין היתר כי הם כבר מתורגלים בלחפש את המקומות בהם דברים עשויים להשתבש.
• בין הפרקים השונים בחלק הרביעי ניתן למצוא "ספר מתכונים לדרישות", שאמור לעזור בהתמודדות עם כתיבת דרישות אבטחה (או במצב בו דרישות האבטחה לא כתובות היטב, או בכלל), קצת על איומים בענן ובסביבות web, כמה שאלות לא פשוטות שכדאי להיות מודעים אליהן בזמן שמטפלים בזיהוי משתמשים וניהול זהויות, דיון עמוס למדי על שימושיות, ומעבר זריז על עקרונות בסיס בהצפנה והתקפות נפוצות (ההתקפה החביבה עלי היא קריפטואנליזה בעזרת צינור גומי,  שזו דרך אלגנטית לתאר את השיטה בה תופסים את הג'ינג'י עם המפתח ומפרקים לו את הצורה עד שהוא מספר לנו מה שאנחנו רוצים) ובהקשר הזה אנחנו מקבלים גם תזכורת לגבי פרטיות, הפעם - איך הצפנה יכולה לעזור לנו איתה. 
• החלק החמישי הוא סיכום, ומתוך שלושת הפרקים שלו - שני פרקים קצת "נמצאים באוויר" כשהם מדברים על "גישות נסיוניות במידול איומים" (כמו למשל, משחק בשם FlipIT), או ברעיונות כלליים כמו עומס קוגניטיבי או  תיאוריית הזרימה. הפרק השלישי ממוקד במטרה קונקרטית מאוד: איך להכניס מידול איומים לארגון שלך? כאן אפשר למצוא עצות פרקטיות על איך ניתן "למכור" את הרעיון להנהלה או למהנדסים מהם יצפו לעשות את העבודה, כולל תשובות להתנגדויות נפוצות. אם טרם השתכנעתם שיש קשר הדוק בין בדיקות תוכנה למידול איומים והתזכורת שיש בפרק הזה לא משכנעת אתכם, אחת ההתנגדויות שמוזכרות כאן היא "אבל אף אחד אף פעם לא יעשה משהו כזה". 

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

• נספח א' - תשובות נפוצות לשאלה "מה הוא מודל האיומים שלך?"
• נספח ב' - עצי איומים. זו הרחבה של הפרק הרביעי והיא מתישה לקריאה. 
• נספח ג' - רשימות תוקפים. כאן מוצג הרעיון הנחמד של שימוש בפרסונות, יחד עם כמה הצעות לרשימות תוקפים. 
• נספח ד' - חוקים למשחק הקלפים Elevation of Privelege
• נספח ה'  - ארבעה מקרים לדוגמה (case studies). המקרים אינם מקרים אמיתיים, אבל הם מעניינים. 

טוב, זה יצא ארוך יותר ממה שהתכוונתי, אבל זה נתן לי תירוץ לרפרף דרך כל הספר שוב, וזה בפני עצמו הצדיק את המאמץ.
אם אתם רוצים, אפשר לקרוא כמה עמודים (=כל הפרק הראשון והשני, עם עמוד מהפרק השלישי)  בחינם בגוגל ספרים. והכי חשוב, במילותיו של הספר - Go Threat model, and make things more secure.

-------------------------------------------------------

A while ago, just before I started writing this blog, we got to that point in the year where we should update our threat model (one of the cool things in working in a large company is that there are some mandatory procedures, and for some of them there actually is someone who is responsible of verifying they are done). By what seems to me as a sheer coincidence, I was the most suitable person to lead the threat modeling, as I was the only one who participated in the process last year besides our dev team leader who is awfully occupied (so, me being able to muster some free time trumps his superior knowledge and experience). Full of motivation to dive into this new and shiny field, I started out just to find out that I didn't have the slightest clue as to where can I begin - even when all I had to do was to update an existing document with the changes we made in the past year. So I starting looking for information and instructions - I read the fourth chapter of this book that was rolling around in the office, read an internal Wiki page that was supposed to help me, somehow, and then I sat down to talk with the guy that has composed the original document I was updating (who, despite having moved to another team, remained at hands reach and was happy to help). His knowledge and expertise helped me tremendously, and I was able to actually start updating our model and even add some improvements to the document (as this document was the product of his self-education, there were some things there that could have been done better, and unlike him - I had help from the first moment I dove into this matter). Anyway, once we both found out that I was enjoying the process, maybe more than I should, he lent me his copy of Adam Shostack's Threat Modeling:  Designing for Security.

It took me a while to do so, but I read this book front to back (excluding some of the appendices), and in short - that's a great book. It's a must-read for anyone who wished to learn a bit about the world of threat modeling, and it is a good source of knowledge for those who wish to learn about software security. On top of that, it seems to my inexperienced eye to be something useful even for those that are familiar with threat modeling. Finally, even if you believe that your product has nothing to do with software security, I think you'll find reading this book worthwhile. 

So, what's in it? 

• The book has five parts, each containing several chapters, the first of which was the most important for me - being completely inexperienced in that field - is labeled "Getting Started". The first sentence in the book (excluding the thirty odd introductory pages explaining what can the reader expect to gain, who are the intended audience and how to use that book - still it's the first sentence of the first chapter, so there you have it) is "Everyone can learn to threat model, and what's more, everyone should". with such encouragement, how can we not start threat modeling immediately?
  And indeed we do. Very quickly we are drawing a diagram of a software, and discussing a bit how to add information to the diagram without making it unreadable or over detailed. Once we have our diagram (In our case, A Data-Flow Diagram, or a DTD) we go on and start finding threats by playing "Elevation of Privileges" - a card game that was developed along with this book and is freely available to download (you can find it here). Naturally, you can buy a proper deck and save yourself the fuss of printing it. Once we are done playing, the book reminds us that we have four options to deal with a threat we found:
• Mitigate the threat - Add some control mechanisms and defenses that will make exploiting the weakness you found harder, limit the amount of damage an attack can do via this venue, etc. this is done in order to allow us to choose one of the other options comfortably. 
• Eliminate the threat - delete the relevant piece of code, block a vulnerable functionality - do something that will make sure that this vulnerability is simply not out there anymore. 
• Transfer the risk - you can transfer the problem to someone, or something else. For instance, you can decide to leave authentication to the OS, or just notify the user that "The software does not deal with this type of risk (A great example for this is Mailinator, a temporary email service, that have the following privacy policy in their FAQ page - "There is no privacy"). Obviously, such decisions should be business decisions, and you should be careful when deciding to transfer a risk, as you can do that to a limited extent only. 
• Accept the risk - Sometimes, it's acceptable to acknowledge a risk and respond with "I'll take my chances". This should not be your go-to approach, but if the risk is improbable enough (e.g.: The server drowning if the Netherlands dam breaks and the sea floods everything), or if the impact is low enough in comparison to the cost of fixing it (e.g.: protecting your server physically can cost you a small fortune to maintain something like this) , then just living with the risk might be acceptable. 

Done with that? Great. That's all folks, let's go home. The rest of the book is just some elaboration and expansion of what was done up to this point. The book then continues with a question I learned to like - "what's your threat model?". This short question can help learning quite a lot, despite having a short answer as well. Answers can be "a single attacker with a standard laptop", or "a disgruntled employee", "cyber-criminals" or "NSA, Mossad, MI5 and every other intelligence agency". Once you know what is the threat you want to protect yourself against, you can make good choices that will help defending against it. As the book mentions, a common answer to this question is "huh?", and this answer provides us with a lot of information as well. Specifically, it tells us that we need to start thinking and identifying the threats we are concerned about.  At this point, we get into more details and discuss a bit approaches to threat modeling. The book covers some unstructured & structured approaches to threat modeling (with a bit of focus on Data-Flow-Diagrams, or DFDs, which seem to be the author strong recommendation). While reading this, we encounter some useful terminology and concepts such as assets & stepping stones or trust-boundaries. 

• The 2nd section deals extensively with the analysis part, or, as the section is named "Finding threats". It starts by focusing on the STRIDE model (on which I already wrote a bit), and then goes to discuss other methods such as attack trees and attack libraries. Finally, just as a reminder, the section shifts its focus to privacy threats and some tools that may help us noticing those.
  The quality of the different sections vary greatly - while the STRIDE chapter is well organized and very readable, with several examples of how to apply each part of the STRIDE model, the one about attack trees has left me not much better off than where I first began. Perhaps it is simply a proof by example of the claim in the end of the chapter: "It's very hard to create attack trees". The chapter on attack libraries is somewhat in the middle - it's very clear, but a bit boring, since using lists such as OWASP top 10, or CAPEC requires very little explanation. The book reminds us that using attack libraries can be quite a bit of work.
  The chapter about privacy is great - it gave me the feeling that I now have the basic knowledge about some mental tools to address the issue, but also that there is so much more to learn about it by following the hints there (The one i liked best is the LINDDUN acronym). 
• The third part deals with "Managing and addressing threats", with all 5 chapters written in about the same quality. The section deals with a lot of subjects, from managing the threat modeling process, to defense strategies to available tools that can be used while threat modeling.
  In this section I want to delve on a short anecdote that demonstrates why I find this book so readable: When dealing with approaches to threats, the author mentions the story about Alice and Bob who were running from a bear, and Bob stopping to put on his running-shoes, justifying that he does not need to run faster than the bear, only faster than Alice. At this point, the author breaks the metaphor by stating that in the software vulnerabilities world, "not only there are multiple bears, but they have conferences in which they discuss techniques for eating both Alice and Bob for lunch".
  The tenth chapter is the one I found myself nodding the most, as it dealt with the question "How can I make sure my work is complete and that threats are dealt with?". Does it sound a bit like testing to you? it sure did to me. In this chapter we can find the always repeated truth "you can't test quality in" (which leads to "and neither can you test security in"). Perhaps the thing that got me most was when my gut feeling matched what I read in the book that stated that testers are "close allies" in threat modeling, as they are already trained to think of "what might go wrong?"
• The fourth section is dealing with "Threat modeling in technologies and tricky areas". This section is actually a mixture of various subjects that have very little in common, except being significant enough to have a chapter of their own. Among its chapters we can find "requirements cookbook" which contains possible examples of security requirements for us to write, Web & cloud common threats, some tough questions to consider when dealing with identities and accounts, a content-heavy discussion with tons of references about usability, some basic cryptography concepts and common attacks (the one I liked most was rubber-hose cryptanalysis, which is a fancy term to say "beat the cr** out of someone until they tell you what you want to know") and we get another reminder about privacy, this time about how can encryption help with privacy. 
• The fifth and last section is more of a summary. It has three chapters, two of which are somewhat intangible, speaking of ideas such as experimental approaches to threat modeling such a FlipIt, or about stuff like Flow theory and cognitive load. The most concrete chapter in this section is about bringing threat modeling into your organization, with practical advice for "selling" the idea to management or to the engineers who'll be doing it with you, and how to deal with common objections, and if you haven't yet become convinced that threat modeling is very much like software testing, and the reminder in this chapter was not enough, one of the  objections mentioned is "No one would ever do that".
  My impression was that the intangible chapters are meant for experts in threat modeling that are looking for ideas to stimulate their thoughts - For me, most of it went way above my head. 

By the end of the book there are five appendices, some short, some a bit longer:

• "Helpful tools" - This appendix contains some answers to "what is your threat model" and some of the common assets a software project might have. 
• Threat trees - This is an extension of chapter 4 (part of the 2nd section) and is really taxing to read. 
• Lists of potential attackers. Along with several generic lists, we have also the idea of using attacker personas along with some examples. Also, it's fun to read. 
• Rules for the card-game "Elevation of Privileges" that was linked above. 
• Four "case studies". They are not real, but are interesting to read. 

That's about it, and it definitely came out longer than I expected, but writing this post gave me an opportunity to go over the book again, and this by itself was totally worth it. 

Also, if you are interested, or think you might be interested, the first sixty-odd pages of the book are free to read on google-books. 

And most important, as the book states: Go Threat model, and make things more secure.