ISO 27001 A.5.36: הוכחת תאימות למדיניות פיתוח, תפעול ומסחר בסביבות צמיחה מהירה

מדוע "תאימות נייר" משתבשת בפיתוח, תפעול ומסחר

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

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

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

מדיניות חשובה רק כשהיא משנה את מה שקורה בזמן אמת.

פער המציאות בין מסמכים לעבודה היומיומית

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

כאשר מדיניות מרגישה מרוחקת מכלים והחלטות יומיומיות, בסופו של דבר יש "תאימות לנייר": אישורים שנתיים, הכשרות חובה וביקורות פנימיות מזדמנות שאומרות את הדברים הנכונים, בעוד שפרקטיקות בעולם האמיתי מתרחקות אט אט מהכוונה. תקן ISO 27001 A.5.36 עודכן כדי לדחוף ארגונים מעבר לדפוס זה לעבר בדיקות קבועות ומובנות, כדי לוודא שמה שקורה בפועל עדיין תואם את הכללים שכתבתם.

מדוע צוותים במהירות גבוהה חשופים במיוחד

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

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

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

הזמן הדגמה

מה באמת מבקש ממך לעשות בתקן ISO 27001 A.5.36

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

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

תצוגה פשוטה של הבקרה

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

לניסוח הפשוט הזה יש כמה השלכות:

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

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

מה המשמעות של זה עבור צוותי פיתוח, תפעול ומסחר

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

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

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

השוואה פשוטה מקלה על הראייה.

תְחוּם	מוקד עיקרי A.5.36	אותות ראיות אופייניים
dev	קידוד מאובטח ופריסה מבוקרת	יומני צינור, סקירות קוד, תוצאות סריקה
Ops	שינוי, גישה ותצורה	שינוי רשומות, ביקורות גישה, התראות סחיפה
מסחר	מערכות מורשות וטיפול במידע	דוחות מעקב, אישורי שולחן

ISMS.online מעניק לך יתרון של 81% מרגע הכניסה

ISO 27001 בקלות

עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.

התחל כאן

שינוי מסגור A.5.36 כמערכת בקרה ידידותית לזרימה

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

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

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

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

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

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

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

הקצאת בעלות, טריגרים ולולאות משוב

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

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

תכנון מדיניות לפיתוח, תפעול ומסחר בפועל

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

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

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

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

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

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

שלב חריגים ואישורים בתכנון

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

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

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

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

הזמן את ההדגמה שלך

הטמעת A.5.36 לתוך Dev ו-CI/CD מבלי להרוס את המהירות

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

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

מדיניות כקוד ב-SDLC וב-pipelines שלך

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

דוגמאות כוללות:

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

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

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

תכנון מעקות בטיחות המגנים על מהירות

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

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

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

יישום A.5.36 בתפעול ייצור ותשתיות

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

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

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

מיפוי ציפיות בקרה על זרימות עבודה מרכזיות של התפעול

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

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

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

מדדים וראיות מהייצור

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

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

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

ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.

הזמן את ההדגמה שלך

יישום A.5.36 על רצפת המסחר מבלי להאט את הביצוע

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

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

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

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

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

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

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

בקרות שמכבדות את מהירות המסחר

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

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

לדוגמה, ייתכן שתעשה זאת:

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

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

הזמן הדגמה עם ISMS.online עוד היום

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

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

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

ראה את תנוחת A.5.36 שלך במקום אחד

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

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

צעד ראשון בסיכון נמוך

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

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

הזמן הדגמה

שאלות נפוצות

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

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

כיצד תקן ISO 27001 A.5.36 באמת חל על צוותי פיתוח, תפעול ומסחר ביום-יום?

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

איך נראה A.5.36 עבור צוותי פיתוח?

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

כללים: קידוד מאובטח, כלים ושירותים מאושרים, הפרדת סביבות, נתיבי שינוי ושחרור רשומים, בבעלותם ומתעדכנים.
יישום: כללים אלה מופיעים בצינורות, במדיניות ענפים, ברשימות תיוג לסקירת קוד ובסטנדרטים של אדריכלות שמפתחים רואים מדי יום.
עֵדוּת: ניתן להצביע על בקשות משיכה (pull requests), ריצות צינור (pill directions) ויומני חריגים אחרונים שמראים שהכללים מועברים רוב הזמן, ושמגיבים כאשר לא.

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

כיצד מתבטא A.5.36 בתפעול ובמסחר?

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

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

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

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

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

כיצד ניתן להטמיע את A.5.36 בפיתוח וב-CI/CD מבלי להאט את המסירה?

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

איך הופכים מדיניות לכללי צינור?

התייחסו לתקן הפיתוח המאובטח שלכם כאל "מדיניות כקוד":

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

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

כיצד עליך להתמודד עם שינויים דחופים מבלי להפר את A.5.36?

סעיף A.5.36 אינו אוסר על דחיפות; הוא מצפה ממך לנהל אותה בשקיפות:

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

אם בקרת A.5.36 שלך ב-ISMS.online מקשרת למאגרים, צינורות ורשומות עקיפה ספציפיים, תוכל להראות למבקרים שפיתוח מאובטח משולב ב-CI/CD ושגם פעילות חירום גלויה, אחראית ומוגבלת בזמן.

כיצד צוותי תפעול צריכים להדגים עמידה בתקן A.5.36 בייצור?

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

כיצד מחברים זרימות עבודה של ITSM ל-A.5.36?

התחל על ידי מיפוי כל תהליך תפעולי לבקרה:

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

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

אילו ראיות הפקה בדרך כלל יבקשו רואי חשבון לראות?

רואי חשבון בדרך כלל דוגמים:

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

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

כיצד דסקי מסחר יכולים לעמוד בתקן A.5.36 מבלי לפגוע במהירות הביצוע?

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

איך הופכים אבטחה לחלק מהתנהגות מסחר רגילה?

התחל עם נהלים ברמת השולחן שסוחרים משתמשים בהם בפועל:

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

יישרו את ההליכים הללו עם:

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

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

כיצד נראות ראיות מסחר שימושיות עבור A.5.36?

ראיות שימושיות כוללות בדרך כלל:

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

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

איזה סוג של ראיות תומכות בצורה הטובה ביותר ב-A.5.36 בפיתוח, בתפעול ובמסחר?

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

כיצד ניתן לבנות ראיות כך שיהיו משכנעות ויעילות?

מבנה פשוט עובד היטב:

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

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

כיצד שומרים על ראיות מסוג A.5.36 מאורגנות וניתנות לשימוש חוזר?

במקום להמציא את הגלגל מחדש בכל ביקורת, תוכלו:

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

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

כיצד ISMS.online יכול לפשט את התאימות לתקן A.5.36 בפיתוח, תפעול ומסחר?

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

מה מאפשרת הרצת A.5.36 דרך פלטפורמה אחת?

עם ISMS.online אתה יכול:

להגדיר ולשמור מדיניות וסטנדרטים של אבטחת מידע שחלים על פיתוח, תפעול ומסחר, ולאחר מכן ממפים אותם ישירות ל-A.5.36 ולבקרות קשורות
לִיצוֹר פקדים מקושרים עבור כל קבוצה, תוך תיעוד האופן שבו היא מפרשת ומיישמת את הכללים בשפה הגיונית עבורה
לצרף ראיות חיות ממערכות CI/CD, כלי ITSM ופלטפורמות מסחר מול הבקרות הנכונות, כאשר התאריכים והבעלים גלויים במבט חטוף
לתכנן ולעקוב ביקורות, חריגים ושיפורים באמצעות סקירות הנהלה, ביקורות פנימיות ותהליכי עבודה של פעולות מתקנות
השתמשו בלוחות מחוונים כדי לראות היכן הציות חזק, היכן הוא נסחף והיכן ביקורות או ביקורים רגולטוריים עתידיים דורשים תשומת לב רבה יותר

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

היכן מומלץ להתחיל אם עדיין לא ביצעתם רשמי של A.5.36?

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

לבחור שירות או דסק מסחר אחד בסיכון גבוה היכן שלקוחות, רגולטורים או הדירקטוריון אכפת להם ביותר מהתנהגות אבטחת מידע
למפות את המדיניות, הסטנדרטים, הפניות, היומנים והסקירות שלה לתוך קבוצה קטנה של בקרות A.5.36 ב-ISMS.online
להריץ את המודל הזה לתקופה קצרה, ולבחון כמה קל לאסוף ראיות, היכן מופיעים פערים ועד כמה מנהלים ומבקרים יכולים לעקוב אחר השלבים.
שכלל את הגישה שלך בהתבסס על מה שאתה לומד, ולאחר מכן הרחב את התבנית לשירותים, צוותים ומסגרות עבודה אחרות כגון SOC 2, ISO 27701 או NIS 2

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

אם תרצה, אני יכול עכשיו: