בקרות אבטחת מידע בתוכנות ויישומים

 

• בקרת אבטחת מידע ביישומים ובתוכנות, תהיה יעילה יותר אם יישום הבקרה יתאפיין בתכנון מקדים ומקיף, וכן אם אופן יישומו יהיה מחזורי (אין "זבנג וגמרנו").
• המטרה: להבטיח כי נתוני המידע עומדים בשלוש העקרונות המנחים את התחום – שלמות (Integrity), סודיות (Confidentiality) ו-זמינות (Availability).
• כיום, תוכנות ומערכות הפעלה חשופות לפגיעויות מסיבה פשוטה אחת – אי יישום בקרות אבטחת מידע באופן הולם\נכון\מתאים.

אבטחת מידע בתהליך פיתוח תוכנות (מערכות אפליקטיביות)

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

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

 סוגיות אבטחת מידע בעת הפיתוח

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

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

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

בקרות אפליקטיביות

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

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

  

בקרות קלט

בקרות הקלט עוסקות באימות ושלמות של המידע. סוג בקרה זה מכיל את הסוגיות הבאות:

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

בקרות פלט

• בקרות הפלט מאפשרות לזהות את אופן הדיוק של שלמות המידע (Integrity). בקטגוריה זו יכללו:
• הסכמה (Reconciliation) – הפעולה שמאשרת כי 2 אובייקטים מתאימים זה לזה.
• נהלי פעולה פיזיים: לדוגמא, מהי האבטחה הפיזית בעת הדפסת מסמכים מסווגים?
• בקרות הרשאה: לדוגמא, מי הסמכות לאישור עסקה כזו או אחרת?

בקרות עיבוד

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

אחרי הכל: יצירת תוכנית המשכיות עסקית

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

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

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

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

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

מידע תומך ונספחים

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

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

שלב ההתראה ונהלי פעולה

שלב זה מגדיר מתי יש להתריא על אירוע. אילו אירועים מצריכים נקיטת צעדים ויישום התוכנית. בקצרה – מתי ואיך יש להתריא?

נהלי התראה

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

כמובן, יש לצרף מידע על אופן ההתראה לצוות ההיענות:

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

 הערכת נזקים

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

כניסה לפעולה – יישום תוכנית ההמשכיות

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

התאוששות

שלב ההתאוששות מורכב מ-3 פעולות עיקריות:

1. ביצוע פעולות שהוגדרו בעת קביעת אסטרטגיית התאוששות.
2. תיקון או החלפה.
3. חזרה לשגרה.

 נהלי וסדר פעולות ההתאוששות

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

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

יש לצרף מידע אודות הצעדים שיש לנקוט ע"מ לחזור לשגרה. הדרך היעילה ביותר לעשות כך היא באמצעות רשימות בדיקה ( Checklist ).

חזל"ש (חזרה לשגרה)

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

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

 

נספחים

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

• פרטים ליצירת קשר.
• פרטי יצירת קשר של ספקים ונותני שירות העובדים עם הארגון.
• נהלים לאופן תפעול בסיסי.
• רשימות בדיקה לצעדי התאוששות בעת אירוע מערכתי או תהליכי.
• פרטי הציוד והמערכות ודרישת משאבים נחוצים לפעילותם.
• הסכמי רמת השירות ( Service level agreements ).
• הסכמים נוספים (הדדיות וכו. ).
• מידע על האתר החלופי.

תוכנית התאוששות מאסון – Disaster Recovery Plan, DRP

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

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

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

מבנה תוכנית התאוששות מאסון יכיל את האלמנטים הבאים:

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

 

אין גיבוי - אין שחזור

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

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

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