קפוץ לנושא
מהי המטרה של נספח A.14.1?
נספח A.14.1 עוסק בדרישות אבטחה של מערכות מידע. המטרה באזור נספח א' זה היא להבטיח שאבטחת מידע היא חלק בלתי נפרד ממערכות מידע לאורך כל מחזור החיים. זה כולל גם את הדרישות למערכות מידע המספקות שירותים ברשתות ציבוריות.
ISO 27001:2013 מתייחס למחזור החיים דרך A.14.1.1 עד A.14.1.3 וזה חלק חשוב ממערכת ניהול אבטחת המידע (ISMS) במיוחד אם ברצונך להשיג אישור ISO 27001.
A.14.1.1 ניתוח דרישות אבטחת מידע ומפרט
דרישות הקשורות לאבטחת מידע צריכות להיכלל בכל דרישות למערכות מידע חדשות או שיפורים למערכות מידע קיימות. זה יכול לקרות לצד A.6.1.5 כחלק מאבטחת המידע בפרויקטים וצריך לקחת בחשבון את ערך המידע בסיכון שיכול להתאים לתכנית סיווג המידע ב-A.8.2.1.
בכל פיתוח מערכת חדשה או שינוי במערכות קיימות, חשוב להבין מהן הדרישות העסקיות לבקרות אבטחה על ידי ביצוע הערכת סיכונים. זה צריך להיעשות לפני בחירת הפתרון או תחילתו של פיתוחו. שיקולי אבטחה צריכים להתרחש מההזדמנות המוקדמת ביותר האפשרית כדי להבטיח שהדרישות הנכונות מזוהות לפני תחילת בחירת הפתרונות.
יש לתעד ולהסכים על דרישות האבטחה, כך שניתן יהיה להתייחס אליהן בעת רכישת הפתרון או פיתוחו. זה לא נוהג טוב לבחור או לפתח פתרון ואז להעריך את רמת יכולת האבטחה לאחר מכן. זה מוביל לעתים קרובות לסיכונים ולעלויות גבוהות יותר, ועלול לגרום לבעיות בחקיקה החלה כגון GDPR המעודדת פילוסופיה מאובטחת לפי עיצוב וטכניקות כגון הערכות הגנת הפרטיות של מידע (DPIA). ישנם גם אתרי אינטרנט רבים הדוגלים בשיטות פיתוח מאובטחות ובעקרונות מרכזיים שיש לקחת בחשבון, כמו אלה שדגל בהם המרכז הלאומי לאבטחת סייבר (NCSC). ISO 27002 כולל גם הנחיית יישום. יש לתעד כל אחד מהעקרונות לפיהם.
המבקר יחפש לראות שנשקלת אבטחה בכל שלבי מחזור החיים של הפרויקט, עבור מערכת חדשה או שינויים במערכת קיימת. הם גם יצפו לראות בחשבון את הסודיות, היושרה והזמינות לכל הפחות לפני תחילת תהליך הבחירה או הפיתוח.
A.14.1.2 אבטחת שירותי יישומים ברשתות ציבוריות
המידע הכרוך בשירותי יישומים העוברים ברשתות ציבוריות צריך להיות מוגן מפני פעילות הונאה, מחלוקת חוזים וחשיפה ושינוי לא מורשים. עבור שירותים הניתנים דרך רשת ציבורית, כמו האינטרנט, חשוב להבין את רמות הסיכון הכרוכות בכך ואת הדרישות העסקיות להגנה על מידע. שוב, חשוב לקחת בחשבון סודיות, יושרה וזמינות.
כאשר עסקאות פיננסיות או מידע אישי רגיש מהווים חלק מהשירות, חשוב במיוחד לשקול אבטחה כדי למזער את הסיכון לפעילות הונאה כאשר דרישות GDPR להצפנה ואמצעי הגנה אחרים צריכות להיות דרישות המינימום. לאחר הפעלתם, חשוב לוודא ששירותים כאלה יהיו במעקב מתמיד אחר תקיפה או פעילות לא רצויה. המבקר יצפה לראות את השיקול לגבי "כמה מאובטח" צריכים להיות שירותי יישומים ברשתות ציבוריות, עם החלטות המבוססות על הערכת סיכונים ודרישות משפטיות, רגולטוריות וחוזיות אחרות.
A.14.1.3 הגנה על עסקאות שירותי יישומים
מידע המעורב בעסקאות שירות יישומים חייב להיות מוגן כדי למנוע שידור לא שלם, ניתוב שגוי, שינוי הודעות לא מורשה, חשיפה לא מורשית, שכפול הודעות לא מורשה או השמעה חוזרת. הגנה נוספת עשויה לאבטח עסקאות בשירותי יישומים (לא בהכרח רק עסקאות פיננסיות). אלה עשויים לכלול; שימוש בחתימות אלקטרוניות, שימוש בהצפנה; ושימוש בפרוטוקולים מאובטחים. סביר להניח שגם יידרש ניטור שוטף של עסקאות כאלה באופן קרוב לזמן אמת.
מהי המטרה של נספח A.14.2?
נספח A.14.2 עוסק באבטחה בתהליכי פיתוח ותמיכה. המטרה באזור נספח א' זה היא להבטיח שאבטחת מידע מתוכננת ומיושמת בתוך מחזור החיים של מערכות מידע.
A.14.2.1 מדיניות פיתוח מאובטח
יש לקבוע כללים לפיתוח תוכנות ומערכות ולהחיל אותם על התפתחויות בתוך הארגון. מדיניות פיתוח מאובטחת משמשת כדי להבטיח שסביבות הפיתוח עצמן מאובטחות ושהתהליכים לפיתוח והטמעה של מערכות ושינויי מערכות מעודדים שימוש בשיטות קידוד ופיתוח מאובטחות.
מדיניות כזו תכלול מראה כיצד יש להתייחס לאבטחה בכל שלבי מחזור החיים של הפיתוח מהתכנון ועד ליישום החי. לשפות קידוד ולכלי פיתוח ספציפיים יש פגיעויות שונות ודורשות טכניקות "הקשחה" שונות בהתאם וחשוב שאלו יזוהו ויסוכמו והמפתחים יהיו מודעים לאחריותם לפעול לפיהן.
מדיניות תואמת תתייחס לנקודות ביקורת אבטחה במהלך הפיתוח; מאגרים מאובטחים; אבטחה בבקרת גרסאות; ידע באבטחת יישומים; והיכולת של מפתחים להימנע מפגיעות, ואז למצוא ולתקן אותן כשהן מתרחשות. המבקר יסתכל כאן כדי לראות ששיקולי אבטחה מתאימים לרמת הסיכון של המערכות המפותחות או משתנות וכי העוסקים בפיתוח מבינים את הצורך לכלול שיקולי אבטחה לאורך כל מחזור חיי הפיתוח. סינון ראשוני חזק בגיוס מיומנויות אלו, ניהול בחיים והדרכה של משאבים הוא חיוני ופרקטיקות כמו תכנות זוגיות, ביקורות עמיתים והבטחת איכות עצמאית, סקירות קוד ובדיקות הן כולם תכונות חיוביות.
A.14.2.2 נהלי בקרת שינויי מערכת
שינויים במערכות בתוך מחזור החיים של הפיתוח חייבים להיות מבוקרים על ידי שימוש בהליכי בקרת שינויים פורמליים. נהלי בקרת שינויים במערכת צריכים להשתלב, להיות מיושרים ולתמוך בבקרת שינויים תפעוליים. נהלי ניהול שינויים פורמליים נועדו להפחית את הסיכון להתפתחות מקרית או מכוונת של פגיעויות שעלולות לאפשר פגיעה במערכות ברגע שהשינויים יופעלו. עבור בקרת שינויים במערכת, חשוב שבעל המערכת יבין אילו שינויים מתבצעים במערכת שלו, מדוע ועל ידי מי. באחריותם להבטיח שהמערכות שלהם לא ייפגעו באמצעות פיתוח לקוי או זדוני.
לכן הם צריכים להיות מעורבים בקביעת הכללים להרשאה ובדיקות ובדיקה לפני חיים. יומני ביקורת נדרשים כדי לספק ראיות לשימוש נכון בהליכי השינוי. תקן ISO 27002 מתעד היבטים רבים של בקרת שינויים שיש לכלול, החל בתיעוד פשוט של השינויים ועד לבחינת זמן הפריסה כדי למנוע השפעה עסקית שלילית. בקרה זו כמו אחרים ב-A.14 מתיישרת גם עם נהלים מתועדים ב-A.12.1.2.
A.14.2.3 סקירה טכנית של יישומים לאחר שינויים בפלטפורמה ההפעלה
כאשר פלטפורמות הפעלה משתנות, יש לבדוק ולבדוק יישומים קריטיים לעסקים כדי לוודא שאין השפעה שלילית על הפעילות הארגונית או האבטחה. כאשר משנים פלטפורמות של מערכת הפעלה, זה נפוץ שלאפליקציות מסוימות עשויות להיות בעיות תאימות. לכן חשוב לבדוק שינויים במערכת ההפעלה בסביבת פיתוח או בדיקה שבה ניתן לבדוק תאימות של יישומים עסקיים קריטיים למערכת ההפעלה שהשתנתה. נהלי בקרה ובדיקה של שינויים במערכת ההפעלה צריכים לפעול לפי בקרת ניהול שינויים סטנדרטית.
A.14.2.4 הגבלות על שינויים בחבילות תוכנה
יש להמנע משינויים בחבילות תוכנה, להגביל אותם לשינויים הדרושים ויש לשלוט בקפדנות על כל השינויים. חבילות תוכנה שסופקו על ידי הספק מיועדות לשוק ההמוני ואינן מיועדות באמת לארגונים שמבצעים בהן שינויים משלהם. למעשה רוב הזמן היכולת לבצע שינויים כאלה ננעלת על ידי הספק והתאמה אישית מוגבלת לחבילה. כאשר נעשה שימוש בתוכנת קוד פתוח, סביר הרבה יותר שהארגון יכול לבצע שינויים, עם זאת, יש להגביל ולבוקר זאת כדי להבטיח שלשינויים שבוצעו אין השפעה שלילית על השלמות הפנימית או האבטחה של הארגון. תוֹכנָה.
A.14.2.5 עקרונות הנדסת מערכת מאובטחת
יש לבסס, לתעד, לתחזק וליישם עקרונות להנדסת מערכות מאובטחות בכל מאמצי הטמעת מערכות מידע. עקרונות הנדסת תוכנה מאובטחת קיימים הן ברמות הכלליות והן ספציפיות לפלטפורמות פיתוח ושפות קידוד. בכל מקום שבו מבוצע פיתוח, יש לשקול, להעריך, לתעד רשמית ולחייב את הבחירה והיישום של עקרונות כאלה. המבקר ירצה לראות שכמו בקרות רבות, השימוש בעקרונות הנדסת מערכת נשקל מול רמות הסיכון שזוהו ויחפש ראיות התומכות בבחירות שנעשו.
A.14.2.6 סביבת פיתוח מאובטחת
ארגונים צריכים להקים ולהגן כראוי על סביבות פיתוח מאובטחות עבור מאמצי פיתוח ואינטגרציה של מערכת המכסים את כל מחזור החיים של פיתוח המערכת. יש להגן על סביבות פיתוח כדי להבטיח פיתוח זדוני או מקרי ועדכון של קוד שעלול ליצור נקודות תורפה או לסכן את הסודיות, השלמות והזמינות. דרישות ההגנה צריכות להיקבע מהערכת סיכונים, דרישות עסקיות ודרישות פנימיות וחיצוניות אחרות כולל חקיקה, רגולציה, הסכם חוזי או מדיניות. בפרט, אם נעשה שימוש בכל צורה של נתונים חיים בסביבות פיתוח, הוא צריך להיות מוגן ומבוקר במיוחד.
קבל headstart של 81%.
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה.
כל שעליכם לעשות הוא להשלים את החסר.
A.14.2.7 פיתוח במיקור חוץ
על הארגון לפקח ולפקח על פעילות פיתוח מערכות במיקור חוץ. כאשר פיתוח מערכות ותוכנה מועבר במלואו או בחלקו לגורמים חיצוניים, יש לציין את דרישות האבטחה בחוזה או בהסכם מצורף. זה המקום שבו נספח A 15.1 חשוב שיהיה נכון וכן A.13.2.4 לאי חשיפה וסודיות.
חשוב גם לפקח ולפקח על הפיתוח כדי להשיג ביטחון שהסטנדרטים הארגוניים ודרישות האבטחה בתוך המערכות מושגות. בהתאם לאופן שבו שותפי מיקור חוץ משובצים בתוך הארגון, במיוחד אם הצוות ממוקם בחצרים ארגוניים, חשוב לכלול את הצוות שלהם בהדרכה ותוכניות מודעות ותקשורת למודעות אבטחה. זה קריטי להבטיח ששיטות האבטחה הפנימיות של השותף למיקור חוץ, למשל בדיקת צוות, עומדות לפחות בדרישות הבטחה הרלוונטיות לרמות הסיכון הקשורות לפיתוחים עליהם יעבדו.
המבקר יחפש לראות כי במקום בו נעשה שימוש במיקור חוץ, קיימות ראיות לבדיקת נאותות לפני, במהלך ולאחר ביצוע ההתקשרות של שותף המיקור חוץ וכוללת התחשבות בהוראות אבטחת מידע.
A.14.2.8 בדיקת אבטחת מערכת
בדיקת פונקציונליות האבטחה צריכה להתבצע במהלך הפיתוח. בדיקה ספציפית של פונקציונליות האבטחה עבור כל פיתוח חייבת להתבצע ולחתום על ידי רשות מתאימה עם כשירות ואחריות אבטחה. יש לתעד את התוצאות הצפויות של בדיקות אבטחה לפני תחילת הבדיקה ויש להתבסס על דרישות עסקיות לאבטחה. המבקר ירצה לראות שיש ראיות לכך שבוצעו בדיקות ספציפיות לאבטחה בכל פיתוח שרלוונטי לאבטחה.
A.14.2.9 בדיקת קבלת מערכת
יש לקבוע תוכניות בדיקות קבלה וקריטריונים קשורים למערכות מידע חדשות, שדרוגים וגרסאות חדשות. לצורך בדיקת קבלה, יש לתכנן ולפתח את המבחנים והקריטריונים להוכחת מבחן מוצלח בהתאם לדרישות העסקיות לפני ביצוע הבדיקות. בדיקות קבלה צריכות לכלול גם בדיקות אבטחה. המבקר יחפש ראיות המראות שקריטריונים ושיטות לבדיקות קבלה תוכננו בהתאם לדרישות העסקיות וכוללות הוראות לבדיקת קבלה ביטחונית.
מהי המטרה של נספח A.14.3?
נספח A.14.3 עוסק בנתוני בדיקה. המטרה באזור נספח א' זה היא להבטיח הגנה על נתונים המשמשים לבדיקה.
A.14.3.1 הגנה על נתוני בדיקה
יש לבחור את נתוני הבדיקה בקפידה, להגן ולבוקר. נתוני בדיקה צריכים להיווצר בצורה אידיאלית בצורה גנרית ללא קשר לנתוני מערכת חיים. עם זאת, ידוע שלעתים קרובות יש להשתמש בנתונים חיים כדי לבצע בדיקות מדויקות. היכן שמשתמשים בנתונים חיים לבדיקה הם צריכים להיות; אנונימי ככל האפשר; נבחר בקפידה ומאובטח לתקופת הבדיקה; נמחק בצורה מאובטחת בסיום הבדיקה. השימוש בנתונים חיים חייב להיות מאושר מראש, מתועד ומפוקח. המבקר יצפה לראות נהלים חזקים כדי להגן על נתונים בשימוש בסביבות בדיקה, במיוחד אם מדובר בנתונים חיים במלואם או בחלקם.
עזרה נוספת לגבי דרישות ISO 27001 ובקרות נספח A ניתן למצוא ב-ISMS.online Virtual Coach המשלים את המסגרות, הכלים ותוכן המדיניות שלנו.
קבל headstart של 81%.
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה.
כל שעליכם לעשות הוא להשלים את החסר.
