מהו ISO 27002:2022 בקרה 8.28 על קידוד מאובטח?
שיטות קידוד לקויות כמו אימות קלט לא תקין ויצירת מפתח חלש עלולות לחשוף מערכות מידע לפרצות אבטחה ולגרום להתקפות סייבר ולפגיעה בנכסי מידע רגיש.
למשל, בשמצה תקרית באג עם דימום לב, האקרים ניצלו אימות קלט לא תקין בקוד כדי לקבל גישה ליותר מ 4 מיליון נתונים של חולים.
לכן, ארגונים צריכים להבטיח שעקרונות קידוד מאובטח יבוצעו כך ששיטות קידוד לקויות לא יובילו לפרצות אבטחה.
מטרת הבקרה 8.28
בקרה 8.28 מאפשרת לארגונים למנוע סיכוני אבטחה ופגיעויות שעלולות להיווצר כתוצאה מפרקטיקות לקויות של קידוד תוכנה על ידי תכנון, הטמעה ובחינה של עקרונות קידוד תוכנה מאובטחים מתאימים.
טבלת בקרה של תכונות 8.28
Control 8.28 הוא סוג מניעתי של בקרה שעוזר לארגונים לשמור על אבטחת הרשתות, המערכות והיישומים על ידי ביטול סיכונים שעלולים לנבוע מקוד תוכנה מעוצב בצורה גרועה.
| סוג הבקרה | מאפייני אבטחת מידע | מושגי אבטחת סייבר | יכולות מבצעיות | תחומי אבטחה |
|---|---|---|---|---|
| #מוֹנֵעַ | #סודיות | #לְהַגֵן | #אבטחת יישומים | #הֲגָנָה |
| #יושרה | #אבטחת מערכת ורשת | |||
| #זמינות |
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
בעלות על שליטה 8.28
בהתחשב בעובדה ש-8.28 דורש תכנון ויישום של עקרונות ונהלים של קידוד מאובטח ברחבי הארגון, קצין אבטחת המידע הראשי צריך להיות אחראי לנקוט בצעדים מתאימים לציות.
הנחיות כלליות בנושא ציות
בקרה 8.28 מחייבת ארגונים להקים וליישם תהליכים כלל-ארגוניים לקידוד מאובטח החל הן על מוצרי תוכנה המתקבלים מגורמים חיצוניים והן על רכיבי תוכנה בקוד פתוח.
יתר על כן, ארגונים צריכים להתעדכן באיומי אבטחה מתפתחים בעולם האמיתי ובמידע העדכני ביותר על פרצות אבטחת תוכנה ידועות או פוטנציאליות. זה יאפשר לארגונים לשפר וליישם עקרונות קידוד תוכנה מאובטחים חזקים, יעילים נגד איומי סייבר מתפתחים.
הנחיות משלימות לתכנון
יש להקפיד על עקרונות קידוד תוכנה מאובטח הן עבור פרויקטי קידוד חדשים והן עבור פעולות שימוש חוזר בתוכנה.
יש להקפיד על עקרונות אלו הן עבור פעילויות פיתוח תוכנה פנימיות והן עבור העברת מוצרי התוכנה או השירותים של הארגון לצדדים שלישיים.
בעת הקמת תוכנית לעקרונות קידוד מאובטח וקביעת התנאים המוקדמים לקידוד מאובטח, ארגונים צריכים לעמוד בדרישות הבאות:
- ארגונים צריכים לקבוע את ציפיות האבטחה המותאמות לצרכיהם ולקבוע עקרונות מאושרים לקידוד תוכנה מאובטח שיחולו הן על פיתוח תוכנה פנימי והן על רכיבי תוכנה במיקור חוץ.
- ארגונים צריכים לזהות ולתעד את הפרקטיקות השכיחות וההיסטוריות הדלות ביותר של עיצוב קידוד וטעויות שגורמות לפגיעה באבטחת המידע.
- ארגונים צריכים להקים ולהגדיר כלי פיתוח תוכנה כדי להבטיח את האבטחה של כל הקוד שנוצר. דוגמה אחת לכלים כאלה היא סביבות פיתוח משולבות (IDE).
- ארגונים צריכים להשיג ציות להנחיה ולהנחיות המסופקות על ידי כלי פיתוח תוכנה.
- ארגונים צריכים לסקור, לתחזק ולהשתמש בצורה מאובטחת בכלי פיתוח כגון מהדרים.
הנחיות משלימות בנושא אבטחה במהלך קידוד
שיטות ונהלי קידוד מאובטחים צריכים לקחת בחשבון את הדברים הבאים לתהליך הקידוד:
- עקרונות קידוד תוכנה מאובטח צריכים להיות מותאמים לכל שפת תכנות וטכניקות בשימוש.
- פריסת טכניקות ושיטות תכנות מאובטחות כגון פיתוח מונחה מבחן ותכנות זוגיות.
- שימוש בשיטות תכנות מובנות.
- תיעוד קוד נכון והסרת פגמי קוד.
- איסור על שימוש בשיטות קידוד תוכנה לא מאובטחות כגון דוגמאות קוד לא מאושרות או סיסמאות מקודדות קשיחות.
ההנחיה המשלימה מציינת גם כי יש לבצע בדיקות אבטחה הן במהלך הפיתוח והן לאחריו בהתאם לבקרה 8.29.
לפני כניסת התוכנה לשימוש ממשי בסביבת היישומים החיים, ארגונים צריכים לשקול את הדברים הבאים:
- מהו משטח ההתקפה?
- האם מקיימים את עקרון הזכות הקטנה ביותר?
- ביצוע ניתוח של טעויות התכנות הנפוצות ביותר ותיעוד שהסיכונים הללו בוטלו.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
הנחיות משלימות על תהליך סקירה
לאחר כניסת הקוד לשימוש בסביבת הייצור
- יש להחיל עדכונים בצורה מאובטחת.
- יש לטפל בפרצות אבטחה שדווחו בהתאם ל-Control 8.8.
- יש לרשום חשד להתקפות על מערכות מידע ושגיאות ולבדוק את הרשומות הללו במרווחי זמן קבועים כדי שניתן יהיה לבצע שינויים מתאימים בקוד.
- יש למנוע גישה לא מורשית לקוד המקור, שימוש בו או שינויים בו באמצעות מנגנונים כגון כלי ניהול.
כאשר ארגונים משתמשים בכלים חיצוניים, עליהם לקחת בחשבון את הדברים הבאים
- יש לנטר ולעדכן ספריות חיצוניות במרווחי זמן קבועים על סמך מחזורי השחרור שלהן.
- רכיבי תוכנה צריכים להיבדק בקפידה, לבחור ולהיות מאושרים, במיוחד רכיבי קריפטוגרפיה ואימות.
- רישוי רכיבים חיצוניים והבטחת אבטחתם.
- יש לעקוב ולתחזק תוכנה. יתר על כן, יש לוודא שהוא מגיע ממקור אמין.
- משאבי פיתוח צריכים להיות זמינים לטווח ארוך.
בעת ביצוע שינויים בחבילת תוכנה, יש לשקול את הדברים הבאים
- סיכונים שעלולים להיווצר עקב בקרות מובנות או פגיעה בתהליכי יושרה.
- האם הספק נותן הסכמה לשינויים.
- האם ניתן לקבל הסכמה מספק התוכנה לעדכונים שוטפים.
- ההשפעה הסבירה של ביצוע תחזוקה של התוכנה הנובעת משינויים.
- האם השינויים יהיו תואמים לרכיבי תוכנה אחרים המשמשים את הארגון.
הנחיות נוספות בנושא בקרה 8.28
ארגונים צריכים להבטיח כי נעשה שימוש בקוד הרלוונטי לאבטחה כאשר הדבר נחוץ ועמיד בפני שיבוש.
Control 8.28 מפרטת גם את ההמלצות הבאות עבור קוד רלוונטי לאבטחה:
- בעוד שתוכניות המותקנות באמצעות קוד בינארי כוללות קוד רלוונטי לאבטחה, הדבר מוגבל לנתונים המאוחסנים באפליקציה עצמה.
- מושג הקוד הרלוונטי לאבטחה שימושי רק כאשר הקוד מופעל על שרת שאינו נגיש למשתמש והוא מופרד מהתהליכים המשתמשים בו והנתונים שלו נשמרים בצורה מאובטחת במסד נתונים אחר. לדוגמה, אתה יכול להפעיל קוד מפורש בשירות ענן וניתן להגביל את הגישה לקוד למנהלי מערכת מורשים. מומלץ להגן על זכויות הגישה הללו באמצעות שיטות כגון הרשאות מנהל בדיוק בזמן ומנגנוני אימות חזקים.
- יש ליישם תצורות מתאימות בשרתי אינטרנט כדי למנוע גישה בלתי מורשית לספרייה ולגלישה בה.
- בעת תכנון קוד אפליקציה, עליך להתחיל בהנחה שהקוד חשוף להתקפות עקב שגיאות קידוד ופעולות של גורמים זדוניים. עליך לעצב יישומים קריטיים באופן שהם אינם חשופים לתקלות פנימיות. לדוגמה, ניתן לבדוק את הפלט המופק על ידי אלגוריתם כדי לוודא שהוא עומד בדרישות האבטחה לפני שניתן יהיה להשתמש בו ביישומים קריטיים כגון יישומים הקשורים לפיננסים.
- יישומי אינטרנט מסוימים פגיעים מאוד לאיומי אבטחה עקב שיטות קידוד לקויות כגון הזרקת מסד נתונים והתקפות סקריפטים בין-אתרים.
- ארגונים צריכים לעיין בסדרת ISO/IEC 15408 למידע נוסף על הערכת אבטחת IT.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
שינויים והבדלים מ-ISO 27002:2013
27002:2022/8.28 הוא סוג חדש של בקרה.
בקרות חדשות ISO 27002
| מזהה בקרה ISO/IEC 27002:2022 | מזהה בקרה ISO/IEC 27002:2013 | שם בקרה |
|---|---|---|
| 5.7 | NEW | אינטליגנציה מאיימת |
| 5.23 | NEW | אבטחת מידע לשימוש בשירותי ענן |
| 5.30 | NEW | מוכנות ICT להמשכיות עסקית |
| 7.4 | NEW | ניטור אבטחה פיזית |
| 8.9 | NEW | ניהול תצורה |
| 8.10 | NEW | מחיקת מידע |
| 8.11 | NEW | מיסוך נתונים |
| 8.12 | NEW | מניעת דליפת נתונים |
| 8.16 | NEW | פעילויות ניטור |
| 8.23 | NEW | סינון אינטרנט |
| 8.28 | NEW | קידוד מאובטח |
| מזהה בקרה ISO/IEC 27002:2022 | מזהה בקרה ISO/IEC 27002:2013 | שם בקרה |
|---|---|---|
| 6.1 | 07.1.1 | סריקה |
| 6.2 | 07.1.2 | תנאי העסקה |
| 6.3 | 07.2.2 | מודעות, חינוך והדרכה לאבטחת מידע |
| 6.4 | 07.2.3 | תהליך משמעתי |
| 6.5 | 07.3.1 | אחריות לאחר סיום או שינוי עבודה |
| 6.6 | 13.2.4 | הסכמי סודיות או סודיות |
| 6.7 | 06.2.2 | עבודה מרחוק |
| 6.8 | 16.1.2, 16.1.3 | דיווח על אירועי אבטחת מידע |
| מזהה בקרה ISO/IEC 27002:2022 | מזהה בקרה ISO/IEC 27002:2013 | שם בקרה |
|---|---|---|
| 7.1 | 11.1.1 | היקפי אבטחה פיזית |
| 7.2 | 11.1.2, 11.1.6 | כניסה פיזית |
| 7.3 | 11.1.3 | אבטחת משרדים, חדרים ומתקנים |
| 7.4 | NEW | ניטור אבטחה פיזית |
| 7.5 | 11.1.4 | הגנה מפני איומים פיזיים וסביבתיים |
| 7.6 | 11.1.5 | עבודה באזורים מאובטחים |
| 7.7 | 11.2.9 | שולחן כתיבה ברור ומסך ברור |
| 7.8 | 11.2.1 | מיקום ומיגון ציוד |
| 7.9 | 11.2.6 | אבטחת נכסים מחוץ לשטח |
| 7.10 | 08.3.1, 08.3.2, 08.3.3, 11.2.5 | אחסון מדיה |
| 7.11 | 11.2.2 | כלי עזר תומכים |
| 7.12 | 11.2.3 | אבטחת כבלים |
| 7.13 | 11.2.4 | תחזוקת ציוד |
| 7.14 | 11.2.7 | סילוק מאובטח או שימוש חוזר בציוד |
כיצד ISMS.online עוזר
הפלטפורמה שלנו פותחה במיוחד עבור אלה שחדשים באבטחת מידע או זקוקים לדרך קלה ללמוד על ISO 27002 מבלי להקדיש זמן ללמידה מאפס או לקרוא מסמכים ארוכים.
ISMS.Online מגיע מצויד בכל הכלים הדרושים להשגת תאימות לרבות תבניות מסמכים, רשימות ביקורת ומדיניות שניתן להתאים אישית בהתאם לצרכים שלך.
רוצים לראות איך זה עובד?
צור קשר עוד היום כדי הזמן הדגמה.
