שאלות בענייני רשת ממוקדת המשכיות עסקית

שולחים בצירוף שם ומספר טלפון

לדואר אלקטרוני oz@support.co.il

תוכנה בטוחה

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

חוקרים בינלאומיים רבים חיפשו אלמנטים משותפים שינחו את המתכנתים באסטרטגיות ועקרונות שיפחיתו את הבעיות הפוטנציאליות הקשורות לפיתוח התוכנה. להלן מספר קווים מנחים שנמצאו:
זכויות מזעריות – עקרון זה קובע כי יש להעניק הרשאות מוגבלות לצרכים הנובעים מתפקיד ייעודי.
חסכון ופישוט מנגנוני אבטחה –על מנגנוני ההגנה שיקבעו להיות פשוטים ככל האפשר.
קונפיגורציות בטוחות כברירת מחדל. כלומר, כל מה שלא קיבל הרשאה מיוחדת, פשוט אסור.
אשרור מושלם – כל הגישות לאובייקט יאשרו כדי להבטיח כי הן אכן חוקיות.
עיצוב פתוח – קובע כי אבטחת מנגנון כלשהו אינה תלויה בסודיות העיצוב או האימפלמנטציה.זכויות מותנות – עקרון זה אומר כי יש לשמור על הזכויות הדרושות ברגעים שונים, ברוטינות או בתוכניות שונות. כלומר, אין לקבע את הזכויות לתוכנות, או לרוטינות, בזמן ובהפעלה.
 צמצום מספר המנגנונים המשותפים -  כדאי שיהיו כמה שפחות מנגנונים משותפים בין אובייקטים ובין בעלי תפקידים.
קבלה פסיכולוגית – מנגנון האבטחה שיקבע לאובייקט מסוים לא צריך להציג קושי גדול מזה שהיה קיים אילו המנגנון היה נעדר. בקיצור, על מנגנון האבטחה להיות קל לשימוש.
העקרונות הנ"ל בעצם מזכירים לנו – יותר מאשר גורמים חדישים בפיתוח יישומים – את הנהלים הכלליים שאנו בוחרים בדרך אינטואיטיבית, אך בדרך כלל שוכחים בעת בניית יישומים. אי לכך, העקרונות לעיצוב מאובטח הינם קוים מנחים שיש לממש בנהלי תכנות אשר יהיו חלק מפיתוח התוכנה עצמה.
 
מקורות נקודות התורפה בתוכנות
חשוב לקחת בחשבון ולזהות אלמנטים פרקטיים בחיפוש אחר נקודות תורפה או ליקויי אבטחה בתוכנה. להלן מספר אלמנטים המצביעים על פיתוח בהיעדר תקנים ונהלי פיתוח מתאימים, אשר קשורים באופן ישיר לסצנריו הדרוש לאימות הבטיחות והאמינות של התוכנה.
 
1. שינויים בסביבת העבודה
ה-PATCHES, שינויים בקונפיגורציה, והמשתנים של הסביבה סביב היישומים הינם גורמים קריטיים לשמירה על הפעלה מתאימה ומבוקרת של הרוטינות והפעולות הצפויות בתוכנה. אם מזניחים היבט זה, יתכן ויילקחו בחשבון תוצאות גבוליות או תנאים יוצאי דופן בלתי צפויים אשר לא רק יסכנו את היישום בלבד, אלא את כל מערכת המידע.
 
2. גלישות ובדיקות תחביר הן שני גורמים חשובים בבדיקה והערכת תוכנה. מצד אחד הערכת הגלישות – הן של זיכרון והן של משתנים ספציפיים בתוכנה - ומצד שני האישור לשימוש הנכון של הפקודות או מילים שמורות בשפת התכנות, אשר תאפשרנה למשתמש שימוש יעיל של המבנים. מי שמזניח נושא זה מסכן את שלמות סביבת ההפעלה של היישום.
 
3. תכונות רצויות אך מסוכנות בעיצוב התוכנה. מקור זה של פגיעות מציג מאפיינים רצויים בתוכנה שמגבירים את הגמישות בשימוש היישומים. ביניהם, כלי ניקוי או DEBUG, חיבורים מרוחקים בפורטים מיוחדים, למשל, חשובים למשתמשים אבל אשר פותחים את האפשרות של כניסות בלתי מורשות שמסכנות את שלמות המערכות, ומכרסמות את רגש הביטחון של המשתמש מול היישום.

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

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

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

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

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

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