ISO 27001 – נספח A.12: אבטחת תפעול

מהי המטרה של נספח A.12.1?

נספח A.12.1 עוסק בנהלים ואחריות תפעוליים. מטרת אזור נספח א' זה היא להבטיח פעולות נכונות ומאובטחות של מתקני עיבוד מידע. זהו חלק חשוב ממערכת ניהול אבטחת המידע (ISMS) במיוחד אם ברצונך להשיג אישור ISO 27001. בואו נבין את הדרישות האלה ואת המשמעות שלהן קצת יותר לעומק עכשיו.

A.12.1.1 נהלי הפעלה מתועדים

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

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

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

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

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

A.12.1.2 ניהול שינויים

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

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

A.12.1.3 ניהול קיבולת

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

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

A.12.1.4 הפרדה בין סביבות פיתוח, בדיקות ותפעול

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

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

מהי המטרה של נספח A.12.2?

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

A.12.2.1 בקרות נגד תוכנות זדוניות

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

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

מהי המטרה של נספח A.12.3?

נספח A.12.3 עוסק בגיבוי. המטרה היא להגן מפני אובדן נתונים.

A.12.3.1 גיבוי מידע

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

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

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

מהי המטרה של נספח A.12.4?

נספח A.12.4 עוסק ברישום וניטור. המטרה באזור נספח א' זה היא לתעד אירועים ולהפיק ראיות.

A.12.4.1 רישום אירועים

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

A.12.4.2 הגנה על מידע יומן

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

A.12.4.3 יומני מנהל ומפעילים

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

A.12.4.4 סנכרון שעון

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

מהי המטרה של נספח A.12.5?

נספח A.12.5 עוסק בשליטה בתוכנה תפעולית. המטרה באזור נספח א' זה היא להבטיח את תקינותן של מערכות תפעוליות.

A.12.5.1 התקנת תוכנה על מערכות תפעוליות

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

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

מהי המטרה של נספח A.12.6?

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

A.12.6.1 ניהול נקודות תורפה טכניות

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

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

A.12.6.2 הגבלות על התקנת תוכנה

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

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

מהי המטרה של נספח A.12.7?

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

A.12.7.1 בקרות ביקורת מערכות מידע

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