דגם פיתוח אבטחה של AXIS מדריך למשתמש לתוכנה

תוכנת מודל פיתוח אבטחה של AXIS

מָבוֹא

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

היעדים העיקריים המניעים את מאמצי ASDM הם

• הפוך את אבטחת התוכנה לחלק משולב מפעילויות פיתוח התוכנה של Axis.
• צמצום סיכונים עסקיים הקשורים לאבטחה עבור לקוחות Axis.
• Meet increasing awareness of security considerations by customers and partners.
• יצירת פוטנציאל להפחתת עלויות בגלל זיהוי מוקדם ופתרון בעיות
  ASDM scope היא תוכנת Axis הכלולה במוצרים ובפתרונות Axis. קבוצת אבטחת התוכנה (SSG) היא הבעלים והמתחזק של ה-ASDM.

אַגְרוֹן

ASDM נגמרview

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

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

Software Security Group (SSG)

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

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

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

השקת פעילות ASDM
השקת פעילות ASDM לצוות פיתוח היא כמוtagתהליך ed:

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

   

הגדרת SSG של "בוצע" עבור מסירה היא:

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

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

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

ממשל ASDM

מערכת הממשל כוללת את החלקים הבאים:

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

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

מבנה סטטוס ASDM

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

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

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

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

מצב הרכיב

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

אנו קוראים לזה כיסוי נכס והגדרנו את רמות הכיסוי הבאות:

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

מצב פתרון

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

פעילויות ASDM

הערכת סיכונים
המטרה העיקרית של הערכת סיכונים היא לסנן אילו פעילויות פיתוח ידרשו גם עבודת אבטחה בתוך הצוות.
הערכת סיכונים נעשית על ידי שיפוט אם מוצר חדש או תכונה נוספת/שונה במוצרים קיימים מגדילה את החשיפה לסיכון. שימו לב שזה כולל גם היבטי פרטיות נתונים ודרישות תאימות. לְשֶׁעָבַרampחלק מהשינויים שיש להם השפעה על סיכון הם ממשקי API חדשים, שינויים בדרישות ההרשאה, תוכנת ביניים חדשה וכו'.

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

• מילוי חובות משפטיות
• מילוי התחייבויות חוזיות
• עזרו ללקוחות לעמוד בהתחייבויותיהם

אנו מחלקים את פעילות פרטיות הנתונים לשתי פעילויות משנה:

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

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

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

  

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

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

   

ניתוח קוד סטטי
ב-ASDM, צוותים יכולים להשתמש בניתוח קוד סטטי בשלוש דרכים:

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

  

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

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

ניהול פגיעות
Axis היא, מאז 2021, רשות שמות CVE רשומה (CNA) ולכן מסוגלת לפרסם דוחות CVE סטנדרטיים למסד הנתונים של MITER לצריכה על ידי סורקי פגיעות של צד שלישי וכלים אחרים. לוח הפגיעות (VB) הוא נקודת המגע הפנימית של הציר לפגיעויות שהתגלו על ידי חוקרים חיצוניים. דיווח של
נקודות תורפה שהתגלו ותוכניות תיקון עוקבות מועברות באמצעות ה- product-security@axis.com כתובת אימייל.
האחריות העיקרית של מועצת הפגיעות היא לנתח ולתעדף פרצות מדווחות מנקודת מבט עסקית, בהתבסס על

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

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

Axis Security Model Development © Axis Communications AB, 2022