בגרסאות ישנות יותר של Windows, ה-Services במערכת ההפעלה בד"כ לא רצו עם הרשאות מינימליות. אם זה לא מספיק, רוב ה-Services אפילו רצו עם Local System Account, חשבון המאפשר להם הרשאות אף יותר מרחיקות לכת מאשר Administrator מקומי. מעבר לכך, רוב המשתמשים לא היו מודעים לכך ש-Services אשר קיימים אצלהם במחשב ניתנים לביטול (Disable).
לסיכום הכל, ה-Services והמשתמשים רצו תחת אותו מרחב מחייה, דבר שהיה יכול לגרום לגישה בלתי מורשה ושימוש לא מורשה ב-Services.
במערכת ההפעלה החדשה (Vista), מיקרוסופט מאפשרת למשתמשים להתמודד עם הסכנות הללו באמצעות ארבעה תכונות חדשות שנוספו לכל נושא ניהול ה-Services על המחשב האישי:
1. Service Isloation - זוהי שיטה המאפשרת להריץ Services בלי להרוג את מנהל הרשת מעומס יתר (של ניהול חשבונות ל-Services) ובלי הצורך להשתמש ב-LocalSystem. שיטה זאת עובדת ע"י הקשחת אובייקט מסויים (דוגמת Registry Key) עם ACL שמכיל Security ID. זהו בעצם ה-Service Identiry או ה-Per-Service SID (לא לבלבל עם SID שאנחנו מכירים מהרשאות סטנדרטיות שנקרא Security Identifier).ה-SID הזה הוא חד-ערכי ל-Service ונגזר משמו של ה-Service. לאחר שיצרנו את ה-SID והגדרנו אותו לשימוש ע"י Service כזה או אחר, אנו יכולים להגדיר עבור כל אובייקט מסויים (דוגמת RegKey) הדורש גישה, הרשאות עבור אותו ה-Service ובכך לאפשר לו גישה ספציפית לאובייקט מסויים ללא שימוש ב"הרשאות-על".
2. Least Privilge - כדי להגן על המערכת, אנו נרצה כי כל ה-Services ירוצו עם ההרשאות המינימליות שהם צריכים כדי לבצע את עבודתם. למרות זאת, עדיין קיימים מספר לא קטן של Services אשר צריכים את ה-LocalSystem בשביל לרוץ כמו שצריך. במערכות Windows ישנות יותר, כל Service שהשתמש ב-LocalSystem היה יכול לבצע הכל על המערכת עליה הוא רץ. ב-Vista, כל Service שדורש הרשאות שניתנות אך ורק ל-LocalSystem, יכול לרוץ עדיין על LocalSystem, אך להיות מקונפג כך שיהיו לו הרשאות לבצע רק את אותן פעולות שאותן הוא צריך לבצע בשביל לעבוד.כמו כן, אל-מנת לשמור על תאימות לאחור, ניתן עדיין להפעיל Services שאינם תומכים בתכונה זו בצורה הרגילה. עקב כך, חשוב לציין כי תכונה זו אינה מגינה על המשתמש מפני תוקף שינסה לנצל פגם כלשהו שקיים ב-Services, אך הוא יספק הגנה טובה הרבה יותר נגד תוקף שינסה לחדור בארגון ולעשות שימוש בתשתיות Services קיימות על-מנת לנצל את ההרשאות הקיימות להן ולקבל גישה מלאה למערכת.
3. Restricted Network Access - במשך השנים, יותר ויותר שירותים הפכו להיות תלויים ברשת ובגישה למשאבים ברשת. כמו כן, לא מעט שירותים יושבים מאזינים לרשת במטרה לקבל התקשרויות חדשות. דבר זה הופך אותם לפגיעים אף יותר מאשר Services רגילים. תחת Vista, מתכנת יכול להגביל את ה-Service לגישה בפרוטוקול מסויים, ב-TCP או ב-UDP ואפילו בכיוון התנועה (מהמחשב המקומי, ממחשבים ברשת המקומית או ממחשבים ברשתות אחרות). כשהגבלות מסוג זה מוכלות, הדבר מקטין את משטח התקיפה (Attack Surface) של ה-Service משמעותית. ההגבלות על הגישה לרשת מבוצעות בצורה דומה מאוד לצורה שבה מבוצע ה-Service Isolation באמצעות ה-SID.
4. Session 0 Isolation - כאשר משתמש ב-Windows XP מתחבר פיזית למחשב, הוא בעצם מתחבר ל-Session 0 (ה-Session הראשון שנפתח על המחשב). כאשר אנו משתמשים ב-Fast User Switching (או ב-TS לצורך העניין) ויש לנו יותר ממשתמש אחד על מחשב פיזי אחד, המשתמשים הבאים שמתחברים מקבלים את Session 1, Session 2 וכן הלאה. הבעייה נוצרת כאשר כל ה-Services במערכת רצים תחת Session 0 יחד עם כל היישומים של המתשמש הראשון שהתחבר למערכת. הערבוב של ה-Services אשר רצים עם הרשאות גבוהות יחסית לעומת אפליקציות של משתמש יוצרים סיכון אבטחה גבוה. במידה וקיימת אפליקציה שלא נכתבה כמו שצריך, נופלת קורבן ל-Exploit כלשהו, או אם האפליקציה רצה באותו ה-Session יחד עם השירותים, אותם Services יהיו פגיעים במיוחד מאשר אם הם היו רצים על מכונה נפרדת או Session נפרד לחלוטין. ב-Vista, כל תוכניות המשתמש רצות החל מ-Session 1 ו-Session 0 מוקדש ל-Services בלבד, דבר המקטין משמעותית את שטח התקיפה של אותם ה-Services.
לסיכום, חשוב להסביר שלמרות שחלק מהתכונות החדשות מקטינות את משטח התקיפה המיועד עבור ה-Services, רובם מתרכזים בעיקר במניעה או מינימזציה של נזק שניתן לבצע במידע והצליחו אכן להשתלט על אותם ה-Services. השימוש ב-Service Hardening יחד עם תכונות ה-FW החדשות ב-VISTA ויכולות אבטחה נוספות, יכול להציג מערך אבטחה לתחנת קצה שלא היה מבייש שום מוצר צד שלישי....