פחד ותיעוב מ-DevSecOps

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

מקור. יוצרי דמות: ג'סטין רוילנד ודן הרמון.

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

על הדובר: יורי שבאלין - אדריכל אבטחה ראשי בחברה אבטחת דג חרב. אחראי על הטמעת SSDL, על השילוב הכולל של כלי ניתוח יישומים לאקוסיסטם מאוחדים של פיתוח ובדיקות. ניסיון של 7 שנים באבטחת מידע. עבד באלפא-בנק, סברבנק ו-Positive Technologies, המפתחת תוכנה ומספקת שירותים. דובר בכנסים בינלאומיים ZerONights, PHDays, RISSPA, OWASP.

אבטחת יישומים: במה מדובר?

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

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

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

ה-SDLC הקנוני מפורט מאוד במתודולוגיות שונות - OpenSAMM, BSIMM, OWASP. המתודולוגיות שונות, אך בדרך כלל דומות.

בניית אבטחה במודל בגרות

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

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

למה DevSecOps

DevOps הוא תהליך כללי וגדול שבו יש לקחת בחשבון אבטחה.

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

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

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

מעבר ל-DevSecOps

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

פשוט שילוב כלים בתהליך DevOps אינו מספיק - תקשורת והבנה בין משתתפי התהליך חשובות.

אנשים חשובים יותר, לא כלים.

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

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

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

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

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

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

- עכשיו, איפשהו בפתקים היה נתיב שבו נמצא המסמך הזה.

כתוצאה מכך, קיבלנו את המסמך כעבור שבוע.

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

קל יותר לפרמט מחדש את מה שכבר יש לך ולהשתמש בו כדי להתחיל.

השתמש ב-Security Champions

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

אלופי אבטחה הם אנשים בתוך צוות הפיתוח שמתעניינים באבטחת המוצר שלך.

אלוף האבטחה הוא נקודת כניסה לצוות הפיתוח ואוונגליסט אבטחה התגלגל לאחד.

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

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

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

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

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

שלבי בדיקה

פרדיגמה 20 עד 80 אומר ש-20% מהמאמץ מייצר 80% מהתוצאות. 20% אלה הם שיטות ניתוח יישומים שניתן וצריכות להיות אוטומטיות. דוגמאות לפעילויות כאלה הן ניתוח סטטי - SAST, ניתוח דינמי - DAST и בקרת קוד פתוח. אספר לכם בפירוט רב יותר על הפעילויות, כמו גם על הכלים, באילו תכונות אנו נתקלים בדרך כלל בעת הכנסתם לתהליך, וכיצד לעשות זאת נכון.

בעיות עיקריות של כלים

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

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

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

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

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

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

תכונות תהליך

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

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

"יש לך פגיעות כאן, אתה לא תלך לשום מקום יותר!"

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

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

- חבר'ה, יש לכם בעיות, בבקשה שימו לב אליהם.

בשלב UAT אנו מציגים שוב אזהרות לגבי נקודות תורפה, ובשלב השחרור אנו אומרים:

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

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

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

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

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

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

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

ניתוח סטטי - SAST

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

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

חסרונות - זהו חוסר התמיכה בשפות הדרושות.

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

• כלי אינטגרציה: Jenkins, TeamCity ו-Gitlab CI.
• סביבת פיתוח: Intellij IDEA, Visual Studio. למפתח נוח יותר לא לנווט בממשק לא מובן שעדיין צריך לשנן, אלא לראות את כל האינטגרציות והחולשות הנדרשות שמצא ממש במקום העבודה בסביבת הפיתוח שלו.
• סקירת קוד: SonarQube וסקירה ידנית.
• עוקבי פגמים: ג'ירה ובוגזילה.

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

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

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

איך אפשר לשלב את זה אם אתה בתחילת דרכך ואין לך כלום: אין CI, אין Jenkins, אין TeamCity? בואו נשקול את ההשתלבות בתהליך.

אינטגרציה ברמת CVS

אם יש לך Bitbucket או GitLab, אתה יכול להשתלב ברמה מערכת גרסאות במקביל.

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

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

אינטגרציה עם מערכת סקירת הקוד

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

אינטגרציה עם SonarQube

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

אינטגרציה ברמת CI

הכל כאן גם די פשוט:

• בדומה לבדיקות אוטומטיות, בדיקות יחידה.
• חלוקה לפי שלבי פיתוח: dev, test, prod. מערכות שונות של כללים או תנאי כשל שונים עשויים להיכלל: עצור את ההרכבה, אל תפסיק את ההרכבה.
• השקה סינכרונית/אסינכרונית. אנחנו מחכים לסיום בדיקות האבטחה או לא. כלומר, פשוט השקנו אותם וממשיכים הלאה, ואז אנחנו מקבלים את הסטטוס שהכל טוב או רע.

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

למשל, לקחנו פרויקט גדול והחלטנו שעכשיו נסרוק אותו עם SAST - OK. דחפנו את הפרויקט הזה ל-SAST, הוא נתן לנו 20 נקודות תורפה ובהחלטה חזקה החלטנו שהכל בסדר. 000 נקודות תורפה הן החוב הטכני שלנו. נכניס את החוב לקופסה, לאט לאט נפנה אותו ונוסיף באגים לעוקבים פגומים. בואו נשכור חברה, נעשה הכל בעצמנו, או ש-Security Champions יעזרו לנו - והחוב הטכני יקטן.

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

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

אנחנו משתלבים עם SonarQube - התוסף מותקן, הכל מאוד נוח ומגניב.

אינטגרציה עם סביבת פיתוח

אפשרויות אינטגרציה:

• הפעלת סריקה מסביבת הפיתוח לפני commit.
• צפה בתוצאות.
• ניתוח התוצאות.
• סנכרון עם השרת.

כך זה נראה לקבל תוצאות מהשרת.

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

קוד פתוח

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

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

ניתוח קוד פתוח - OSA

הכלי כולל שלושה שלבים גדולים.

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

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

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

מאפיינים:

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

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

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

שילוב תהליכים

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

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

אינטגרציה עם חפצים: Nexus ו-JFrog.

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

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

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

• בעת הבנייה, אנו בודקים שאף אחד לא החליק משהו רע, שכל הרכיבים בטוחים ואף אחד לא הביא שום דבר מסוכן על כונן ההבזק.
• יש לנו רק רכיבים מהימנים במאגר.
• בעת הפריסה, אנו בודקים שוב את החבילה עצמה: war, jar, DL או Docker image כדי לוודא שהיא תואמת למדיניות.
• בכניסה לענף אנו עוקבים אחר הנעשה בסביבה התעשייתית: נקודות תורפה קריטיות מופיעות או אינן מופיעות.

ניתוח דינמי - DAST

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

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

- כן, יש כאן בעיית דה-סריאליזציה, אבל לא כאן.

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

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

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

- חבר'ה, אתם צוחקים עלי?! נתנו לכם חשבונות, והקמתם דוכן!

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

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

כמה משאבים שאנו משתמשים בהם בדרך כלל.

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

שילוב תהליכים

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

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

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

תהליך

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

כל תהליך זקוק לשליטה.

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

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

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

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

המנות העיקריות

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

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

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

יש סימן שוויון בין ליקויי אבטחת מידע לליקויים תפקודיים.

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

אם גודלו של צוות IS קטן - השתמש ב-Security Champions.

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

דרישות לכלים.

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

הדו"ח של יורי נבחר לאחד הטובים ב-DevOpsConf 2018. כדי להכיר רעיונות ומקרים מעשיים מעניינים עוד יותר, בוא לסקולקובו ב-27 וב-28 במאי DevOpsConf בְּתוֹך פסטיבל RIT++. יותר טוב, אם אתה מוכן לחלוק את החוויה שלך, אז להגיש מועמדות לדוח עד 21 באפריל.

מקור: www.habr.com