Проектування інфраструктури оновлення системи безпеки

Міністерство освіти і науки України Кафедра інформатики та інформаційної безпеки

КУРСОВА РОБОТА

з дисципліни: «Безпека мереж»

на тему:

«Проектування інфраструктури оновлення системи безпеки»

Завдання

Згідно варіанту спроектувати захист мережі в рамках певного аспекту безпеки мереж. Виконати дослідження існуючих способів та методів захисту у вказаній предметній області та їх застосування для описаної мережі.

Проектування інфраструктури оновлення системи безпеки.

Загальні поняття та принципи проектування системи оновлень.

· Вибір оптимальної комбінації методів оновлення

· Розгортання служби SUS

· Захист сервера SUS.

· Застосування SUS при проектуванні системи оновлень.

Проектування клієнтської частини інфраструктури оновлення системи безпеки.

· Настройка SUS за допомогою групової політики

· Настройки SUS специфічні для користувача.

· Настройка за допомогою системного реєстру.

Моніторинг та оптимізація оновлень системи безпеки.

· Застосування MBSA

· Проведення аудиту встановлення виправлень

· Перевірка виправлень за допомогою SUS та клієнськиїх журналів.

· Тестування виправлень

· Моніторинг та оптимізація встановлення виправлень.

Зміст

Вступ

I. Загальні поняття та принципи проектування системи оновлень

1.1 Вибір оптимальної комбінації методів оновлення

1.2 Розгортання служби SUS

1.3 Захист сервера SUS

1.4 Застосування SUS при проектуванні системи оновлень

II. Проектування клієнтської частини інфраструктури оновлення системи безпеки

2.1 Настройка SUS за допомогою групової політики

2.2 Настройки SUS специфічні для користувача

2.3 Настройка за допомогою системного реєстру

III. Моніторинг та оптимізація оновлень системи безпеки

3.1 Застосування MBSA

3.2 Проведення аудиту встановлення виправлень

3.3 Перевірка виправлень за допомогою SUS та клієнтських журналів

3.4 Тестування виправлень

3.5 Моніторинг та оптимізація встановлення виправлень Висновок Література

Вступ

Крім чисто технічних і економічних наслідків у проблем з інформаційною безпекою присутній ще іміджевий аспект — підривається довіра клієнтів, партнерів по бізнесу, інвесторів. За даними Forrester Research, 95% проблем, пов’язаних з безпекою мереж, викликано невірними настройками, 85% опитаних повідомили про випадки проникнення шкідливих програм. Приведені цифри показують, наскільки важливо підтримувати інформаційну безпеку на належному рівні.

Цикл робіт по проектуванню і побудові IT-инфраструктуры, що включає підключення до зовнішніх каналів комунікацій, повинен починатися з етапу ідентифікації можливих погроз. Їх номенклатура залежить від набору сервісів, які компанія припускає використовувати (їх відомих уязвімостей, наявність пакетів виправлень і т. п.). Наступним кроком стає вибір найбільш відповідної для поставлених цілей політики безпеки, супроводжуючої новостворюване рішення на всіх етапах його життєвого циклу. На третьому етапі підбираються відповідні програмні продукти.

Безпека Дані необхідно захищати від неавторизованого знищення і зміни. Часто зовнішні атаки направлені не стільки на крадіжку інформації, скільки на внесення до записів шкідливих змін, що зберігаються. Захистом від цієї риски служить перевірка цілісності, збереження резервних копій і в першу чергу постійне протоколювання доступу до важливих інформаційних об'єктів.

Конфіденційність

Інформація повинна бути захищена від несанкціонованого доступу. Можливість анонімного доступу до даним — перша ознака проблем з безпекою. Крім випадків, коли анонімності не уникнути (наприклад, на публічному веб-вузлі).

Надійність Збої на серверах, оброблювальних дані, не менш небезпечні, чим дії хакерів. Крім того, хоча доступність інформації для зовнішніх користувачів певною мірою залежить від апаратного забезпечення інфраструктури безпечних підключень, цілий клас атак направлений на перевантаження серверів надмірним потоком запитів, що веде до відмови в обслуговуванні звичайних користувачів.

Бізнес-інтеграція Піклуючись про досягнення безпеки інфраструктури, не можна ні на момент забувати, що основним завданням інформаційної системи є підтримка бізнес процесів. Вирішення всіх цих завдань повинне здійснюватися одночасно, інакше одна уразлива ланка, виправлення якої було відкладене «на потім», може привести до втрати всіх позитивних результатів на решті фронтів боротьби за безпеку в рамках всього підприємства. Більш того, Microsoft бачить процес роботи з ризиками як циклічну послідовність заходів, що не дає системі безпеки IT-інфраструктури застаріти.

У загальному випадку цей процес починається з побудови інфраструктури безпечного доступу, адекватній по рівню захищеності поточним вимогам на момент її запуску в експлуатацію. Далі починається етап виявлення потенційних рисок і реальних атак, а також постійного оновлення встановленого програмного забезпечення за допомогою пакетів виправлень і «гарячих латочок» і баз антивірусних програм. Крім того, на цьому етапі повинен проводитися поточний аналіз системних журналів, які можуть містити свідоцтва спроб атак.

I. Загальні поняття та принципи проектування системи оновлень

Оновлення системи безпеки — не просто установка виправлень, хоч це першочергова задача. Грамотно спроектована автоматизована інфраструктура обновлень системи безпеки — необхідний компонент мережі. Служби Software Update Services (SUS) здатні вирішити більшість задач оновлення системи безпеки, в мережі на основі ОС сімейства Windows.

Грамотне проектування інфраструктури оновлення, що використовує SUS, потребує знань способів оновлення системи безпеки, вміння вибирати їх оптимальну комбінацію, а також знання основних принципів проектування інфраструктури обновлень, служб SUS і принципів їх роботи. Без цього неможливо інтегрувати SUS в інфраструктуру оновлення системи безпеки відповідно потребам нашої мережі. Планування інфраструктури оновлення системи безпеки — ключова частина будь-якого проекту захисту мережі. Ми повинні не тільки визначити, що і як оновлювати, але і врахувати наслідки оновлення для різних аспектів роботи мережі. Можливо прийдеться передивитися декілька процедур оновлення.

Проектування інфраструктури оновлення системи безпеки включає наступні етапи:

— Визначити яких змін потребує оновлення системи безпеки

— Вибрати методи оновлення

— Знайти оптимальну комбінацію методів оновлення

— Задіяти SUS як механізм установки виправлень системи безпеки.

Під оновленням системи слід розуміти будь-які зміни необхідність яких обумовлена новими відомостями і досвідом роботи, направлених на зміцнення безпеки. Цим же терміном позначають виправлення системи безпеки, котрі відповідають за виявлення нових вразливостей.

1.1 Вибір оптимальної комбінації методів оновлення

Мало які з методів здатні поодинці забезпечити оновлення всіх аспектів системи безпеки. Швидше за все, нам доведеться використовувати різні методи для настройки параметрів захисту і установки виправлень системи безпеки. У виборі оптимальної комбінації методів оновлення захисту нам допоможуть наступні рекомендації.

Вибір методу залежить від числа обновлюваних систем. Дотримуйтеся наступних правил:

· Сайт Windows Update зручний, тільки якщо оновлюваних систем не більше 50;

· масштабованість ручного оновлення ще менша. Для оновлення вручну доведеться завантажувати виправлення і встановлювати їх на всі комп’ютери окремо. Ця процедура дуже трудомістка для оновлення значної кількості систем;

· служб SUS достатньо для оновлення машинного парку розміром до декількох сотень систем, можливості ієрархії SUS ще ширші;

· можливостей сервера SMS достатньо для оновлення будь-якого числа систем, зазвичай такі сервери використовують у великих мережах із-за складності установки і підтримки інфраструктури SMS

· програмні продукти сторонніх виробників володіють різними можливостями і значно розрізняються за вартістю і складністю;

· параметрами захисту краще всього управляти через групову політику, але в організаціях з невеликим числом комп’ютерів, де немає інфраструктури домену, немає і можливості використання групової політики;

· оснащення Аналіз і настройка безпеки дозволяє оновлювати параметри комп’ютерів тільки окремо, якщо мережа невелика і в ній всього декілька комп’ютерів, цей спосіб цілком підійде;

· утиліту secedii можна задіювати в сценаріях і застосувати для оновлення безліч систем, але це складніше за використання групової політики.

· настройте підключення до Windows Update для автоматичного оновлення на декількох системах, проте кожну з них спочатку доведеться відвідати особисто, щоб зробити необхідні настройки. Оновлення можна встановити або ігнорувати, але у разі одиночної системи це можна зробити, лише прочитавши його опис;

автоматичне оновлення (Automatic Updates) можна настроїти для загрузки негайної установки оновлень. Як і при використанні Windows Lptlates, можна прийняти або відхилити оновлення, але отримати про нього інформацію можна, тільки прочитавши опис;

· SUS, SMS і аналогічні ним служби можна набудувати для автоматичного оновлення безлічі комп’ютерів; завантаженням, тестуванням і аналізом оновлень перед їх розповсюдженням повинні займатися адміністратори;

· самостійно написані сценарії. При їх використанні передбачається, що оновлення вже протестовані; це допускають автоматизацію;

· для розповсюдження протестованих виправлень можна застосовувати групову політику, а всі настройки і виправлення системи безпеки повинні тестуватися перед впровадженням. а може потрібно декілька методів оновлення, підбирайте комбінацію, згідно розміру і потребам вашої організації;

Пошук актуальної інформації про вразливості

Щоб дізнатися, які зміни потрібно внести до системи безпеки, потрібно знати де шукати відповідну інформацію і розуміти призначення тих або інших змін. Відомості, необхідні для забезпечення надійного захисту, можна і потрібно шукати в різних джерелах. Оновлення може потрібно після попередження про небезпеку або ухвалення строгішої політики безпеки. Зміни в системі безпеки включають установку виправлень, пакетів оновлень, відключення невживаних служб, оновлення антивірусного ПО і інші заходи. Для отримання попереджень про небезпеку:

· підпишіться на розсилки Microsoft, присвячені безпеці;

· регулярно відвідуйте Web-сайты, де публікують попередження про небезпеку;

· підпишіться на розсилки виробників антивірусного ПО.

Для пошуку загальної інформації по темі безпеки:

· відвідаєте розділи Security і Technet Security Web-сайта Microsoft і інші джерела інформації з цієї тематики

· виконуйте пошук вразливостей за допомогою Microsoft Security Baseline Analyzer або аналогічних програм;

· відвідуйте сайти по інформаційній безпеці.

Проектування інфраструктури оновлення системи безпеки

Визначивши зміни, необхідні для впровадження оновлення системи безпеки доступні методи оновлення і джерела відомостей про вразливості, можна приступати до проектування інфраструктури оновлення.

Проектування інфраструктури оновлення системи безпеки

· з’ясуєте, які ОС і додатки застосовуються в мережі;

· визначите загальне число систем мережі і оціните їх важливість. Особливу увагу приділіть системам, які оперують критичними даними і повинні бути доступні постійно;

· з’ясуєте, які системи більш не підтримуються, а також системи, не охоплені адмініструванням;

· оціните існуючу інфраструктуру мережі і системи безпеки. Визначите, чи захищені внутрішні комп’ютери від атак ззовні, чи встановлені брандмауери, захисні і охоронні системи; і виявите всі альтернативні способи підключення до корпоративної мережі, такі як бездротові мережі, комп’ютери віддалених співробітників і модеми; оцінить надійність їх захисту; оціните надійність захисту мобільних комп’ютерів, наприклад лептопів — вони можуть стати найуразливішою частиною мережі.

· Оціните поточний рівень уразливості, визначте поточну стратегію оновлень;

· складіть список необхідних оновлень.

· Оціните наявні процедури установки ПО:

· з’ясуєте, чи автоматизована установка ПО;

· визначите, чи придатні ці процедури для установки оновлень.

· Оціните роботу персоналу: з’ясуєте, хто управляє внесенням змін;

· оціните навики персоналу, уповноваженого для внесення змін в систему. Чи достатньо компетентні ці особи?

Рада Microsoft публікує інформацію про серйозність уязвімостей (Security Levelsof Vulnerability) в своєму бюлетені. Інші організації привласнюють попередженням про небезпеку різні ступені серйозності. У Microsoft прийняті наступні рівні серйозності: критичний, важливий, середній і низький. Орієнтуючись на цей рейтинг, встановлюйте перш за все критичні оновлення. Не жалійте часу на аналіз обставин, що змінюють пріоритет оновлень, таких як цінність окремих систем, досвід минулих атак, наявність заходів захисту і так далі Не слідує орієнтуватися на рейтинг серйозності в інших організаціях, краще проаналізувати погрози, що отримали найвищий в декількох організаціях: можливо, виправлення такої уразливості і у вашому списку повинно займати перший рядок. Оновлення повинне охоплювати комп’ютери всіх конфігурацій:

· використовуйте службу віддаленої установки (Remote Installation Service, RIS) та інші технології автоматизованої установки. щоб забезпечити установку на серверах мережі всіх необхідних оновлень;

· вимагайте оновлення систем, підключених за допомогою віддаленого доступу і VPN. Можливості Windows Server 2003, наприклад Network Access Quarantine Control, дозволяють обмежувати доступ до систем, не задовольняючим заданим вимогам безпеки;

· вимагайте оновлення портативних комп’ютерів мандрівних користувачів і перевірки їх безпеки після повернення в мережу.

Оновлення повинне охоплювати всі програми:

· оновлюйте всі програмні продукти. Будь-який з них має свої уразливості

· для зміцнення захисту і запобігання атакам не упускайте при оновленні ніякі з наявних програмних продуктів;

· переконаєтеся, що вибраний метод оновлення охоплює всі системи і програмні продукти;

· використовуйте служби SUS. Windows Update і служби автоматичного оновлення для установки виправлень Windows і її компонентів, включаючи Internet Explorer і Windows Media;

· використовуйте Office Update — службу, аналогічну Windows Update, для оновлення Microsoft Office 2000 і вищих версій.

Розбийте оцінку уразливості на окремі завдання:

· перед оновленням перевірте всі системи на уразливість — це допоможе з’ясувати які системи потребують оновлення, і які виправленні слідує встановити;

· після оновлення перевірте, чи успішно внесені необхідні зміни; і періодично перевіряйте оновлення систем;

· при виникненні нової загрози перевіряйте системи на уразливість до неї;

Сплануйте періодичну перевірку оновлень:

· складіть графік отримання і проглядання відомостей про рекомендовані змінах системи безпеці;

· отримуйте і проглядайте оновлення мінімум раз на тиждень;

· розбийте вивчення рекомендованих змін на етапи: пошук можливих змін, перевірка потреби в цих оновленнях і ступені їх серйозності завантаження виправлень, установка і аналіз в тестовому середовищі.

1.2 Служби SUS

Служби Software Update Services (SUS) дозволяють автоматизувати поширену установку виправлень, вибраних адміністратором. SUS підтримуються Windows Server 2003 і 2000 Server, вони автоматично поширюють виправлення до комп’ютерів під управлінням Windows 2000, Server 2003 і ХР Professional, на котрих запущений клієнт автоматичного оновлення.

По суті, SUS — це аналог сайту Windows Update в локальній мережі, що контролюється її адміністратором. Розгортання SUS дозволяє відмовитися від настройки всіх комп’ютерів для автоматичного завантаження виправлень з Інтернету. Замість цього адміністратор указує виправлення, які будуть доступні для викачування з локального сервера SUS. Так вдається розвантажити канал зв’язку з Інтернетом Служби SUS підтримують додаткові можливості, але все-таки не являються комплексним рішенням для установки оновлень. Нижче описані можливості і обмеження служб SUS, приводяться вимоги до їх розгортання в мережі, а також розповідається про клієнтів і ієрархію SUS.

Служби SUS дозволяють;

· завантажувати на сервер SUS виправлення, перераховані в бюлетенях безпеки Microsoft для Windows ХР, Windows 2000 і Windows Server 2003;

· регулярно синхронізувати БД виправлень SUS з БД виправлень Microsoft автоматично і в ручну;

· вибирати оновлення для розповсюдження в мережі - клієнти отримають тільки дозволені виправлення;

· настроювати комп’ютери під управлінням Windows ХР, 2000 і Server 2003 для автоматичного завантаження і установки виправлень з сервера SUS;

· отримувати повідомлення про оновлення. Якщо ви підписані на розсилку повідомлень, при появі змін в БД виправлень Microsoft вам прийде по електронній пошті повідомлення.

Обмеження SUS

Служби SUS не підтримують:

· настройку параметрів безпеки;

· оновлення Microsoft Office n інше ПО від Microsoft, не вказане вище;

· оновлення ПО сторонніх виробників;

· установку і оновлення драйверів пристроїв;

· установку пакетів оновлень;

· завантаження оновлень від сторонніх виробників;

· індивідуальну настройку оновлення для окремих комп’ютерів. Всі комп’ютери, пов’язані з одним сервером SUS, отримують однакові оновлення, дозволені адміністратором для встановленої на них ОС.

Вимоги для розгортання SUS

процесор Pentium 700 Mru або вище;

12 Мб ОЗУ;

мережева плата;

розділ NTFS з 100 Мб вільного місця для установки SUS і не менше 6 Гб для оновлень у разі їх локального розміщення;

рядовий сервер домена Windows 2000 Server Sp2 і вище або Windows Server 2003 або контроллер домена Windows 2000 або Windows Server 2003, або Small Business Server;

встановлені служби IIS;

|Internet Explorer 5.5 або вище.

Примітку SUS можна отримати з Web-сервера Microsoft за адресою http://wwv/.microsoft.com/downhads/details.aspx?FamilyId=A7AA96E4−6E4]-4F54−972C-AE66A4E4BF6C&displaylang=en.

Клієнти SUS

Клієнтом SUS називається Автоматичне оновлення (Automatic Updates). Окремо клієнт SUS поставлявся в Windows 2000 Service Pack 2, а в Windows 2000 Service P. ick 3 Windows XP і Windows Server 2003 функція автоматичного оновлення стала вбудованою. У настройках клієнта необхідно вказати сервер SUS, з яким він буде працювати, а також поклопотатися про автоматичне перезавантаження, зміну графіка оновлень і інших речах.

Ієрархія SUS

Ієрархією SUS називають впорядкований набір систем SUS. Коренем ієрархії є батьківський сервер SUS, тільки йому дозволено завантажувати оновлення з сайту Microsoft. Дочірні сервери SUS можуть бути настроєні для отримання оновлень від батьківського сервера, щодня синхронізуючи свої БД з БД батьківського сервера. Виправлення, дозволені на батьківському сервері, вважаються дозволеними для всіх клієнтів. На мал. 1 показана ієрархія SUS і вірний спосіб це розміщення в мережі: батьківський сервер SUS підключений до сайту Windows Update через брандмауер, з ним сполучені дочірні сервери SUS і клієнтські системи.

Мал. 1. Ієрархія SUS

Ієрархію SUS можна використовувати і для тестування БД виправлень (мал. 2 і 3). На мал. 2 тестовий сервер SUS підключений до сайту Windows Update безпосередньо забезпечує виправленнями клієнтів в своїй ізольованій мережі. Окрема ієрархія SUS поширює виправлення робочої мережі. Після тестування виправлення що дістали схвалення на батьківському сервері SUS, розташованому в основний мережі, передаються клієнтам. Перевагою такого проекту є повна ізоляція тестовій мережі від робочої.

Мал. 2. Ізольована ієрархія SUS в тестовій мережі

На мал. показано рішення, в якому SUS-сервер тестової мережі є дочірнім сервером і входить в ієрархію робочої мережі. Дочірній сервер тестової мережі автоматично синхронізується з батьківським сервером, а той вимагає ручний синхронізації. Виправлення дістають схвалення на батьківському сервері, і при синхронізації з сервером тестової мережі готуються до розповсюдження в ній. Якщо виправлення протестоване успішно, дочірній сервер SUS робочої мережі вручну синхронізується з батьківським сервером і передає виправлення в робочу мережа, інакше батьківський сервер забороняє його розповсюдження.

сервер оновлення безпека

1.3 Захист сервера SUS

Сервер SUS повинен бути захищений. Зловмисники, швидше за все, не зможуть використовувати його для розповсюдження шкідливих програм замість виправлень Microsoftале цілком здатні перешкодити розповсюдженню виправлень, заблокувати доступ сервера SUS до Інтернету, батьківським серверам або іншим способом перешкодити синхронізації. На додаток до стандартних заходів безпеки серверів, захистите сервер SUS таким чином:

· старайтеся, щоб в локальній групі Адміністратори було якомога менше користувачів, щоб число осіб, уповноважених для управління сервером SUS було мінімальним (тільки локальним адміністраторам дозволено управляти сервером SUS із сторінки hup://umx_cepeepa/sjsadmin);

· обмежте число адміністраторів, для цього: видаліть групу Адміністратори домена (Domain Admins) з локальної групи Адміністратори (Administrators);

· створіть в домені окрему групу для адміністраторів SUS; додайте в цю групу вибраних членів групи Адміністратори домену;

· введіть в створену групу в локальну групу Адміністратори;

· подумайте про застосування протоколу SSL для перевірки достовірності сервера (для настройки SSL на сервері SUS буде потрібно цифровий сертифікат, що діє).

1.4 Застосування SUS при проектуванні системи оновлень

Розгортання сервер SUS в невеликій мережі, зосередженій на одному фізичному ділянці не представляє складності: виправлення завантажуються автоматично, для цього ви їх тестуєте і вирішуєте до розповсюдження, далі вони розповсюджуються серед клієнтів і встановлюються на них. У великих мережах структура складніша. Як оновлювати віддалені системи і лептопи, які чаші всього відключені або підключені через повільні лінії? У яких випадках можна обійтися однією ієрархією, а коли потрібно декілька батьківських серверів? Як оновлювати системи, не підключені до Інтернету? При проектуванні інфраструктури оновлень з використанням служб SUS враховуйте наступні рекомендації.

При проектуванні мережевої інфраструктури SUS:

· визначите джерело виправлень. Сервер SUS може отримувати виправлення сайту Windows Update, від іншого сервера SLJS або від сервера управління контентом — IISсервера. що зберігає копії дозволених виправлень. Такі сервери застосовуються для синхронізації Sus-серперов, розташованих в сегментах, не підключених до Інтернету;

· настроюйте батьківський і дочірні сервери SUS для розповсюдження однакових виправлень. У ієрархії тільки батьківський сервер може завантажувати виправлення безпосередньо з сайту Microsoft;

· розмістіть сервери SUS у всіх важливих центрах обробки даних і представництвах організації;

· продумайте розміщення серверів в мережі. Дочірні сервери рекомендується розміщувати ближче до обслуговуваних ними клієнтів, а розміщення батьківських серверів залежить від підключення до Інтернету; дочернім серверам і клієнтам доступ до Інтернету для оновлення не потрібний;

· SUS-серверы в сегментах, не підключених до Інтернету, слід набудувати для отримання виправлень від сервера управління контентом;

· використовуйте балансування навантаження на мережу (Network Load Balancing, NLB) для серверів SUS. NLB автоматично розподіляє навантаження між серверами SUS якщо один з серверів вийде з ладу, останні продовжать роботу.

Застосування NLB оптимальне, якщо інфраструктура включає безліч серверів SUS які повинні бути постійно доступними. Проте NLB — дороге рішення оскільки вимагає установки декількох серверів, тому NLB краще набудувати для дочірніх серверів, а для завантаження оновлень використовувати батьківський сервер (мал. 4).

При проектуванні розгортання SUS:

· з’ясуєте обмеження ПО і устаткування;

· встановлюйте SUS на захищений сервер, на який встановлені всі необхідні виправлення і пакети оновлень;

Мал. 4. Використання NLB для забезпечення надмірності SUS

· створіть ізольоване середовище для тестування сервера SUS і оновлень;

· спочатку встановіть і перевірте служби SUS в тестовому середовищі. Це дозволить адміністраторам відпрацювати застосування SUS без збитку для робочої мережі;

· на сервері не повинно бути додатків окрім SUS. US здатні забезпечувати роботу різних застосувань, але з SUS сумісні далеко не всі вони. До сумісних відносяться додатки ASP.NET, серверні розширення Frontpage служби Sharepoini. Якщо сервер страждає із-за збоїв додатків, що працюють в US, під загрозою вся інфраструктура SLJS;

· забезпечте антивірусну зашиту сервера, але врахуйте, що при установці SUS антивірусний захист повинен бути відключений;

· використовуйте IIS Lockdown на серверах під управлінням Windows 2000. Утиліти US Lockdown і Urlscan забезпечують додатковий захист служб US. Якщо вони не встановлені з SUS SPI, слід встановити їх пізніше;

· якщо планується зробити сервер SUS контролером домена, зробіть це до установки SUS, інакше видалити SUS буде неможливо;

· становите в мережі US-сервер для розміщення сайту сервера SUS. Не рекомендується використовувати цей сервер для розміщення інших Web-сайтів, оскільки атака відкритого Web-сайту, розташований на одному сервері з SUS поставить під загрозу всю інфраструктура оновлень;

· якщо ви не бажаєте встановлювати SUS поверх Web-сайту за умовчанням,

· відключите або видалите його. SUS завжди встановлюється на Web-сайт за умовчанням якщо той працює, відсутність такого SUS створить новий Web-сайт, встановить його і призначить йому порт 80.

При плануванні роботи SUS:

· досвід вимагає завантажувати виправлення регулярно, бажано щодня. Щоб набудувати графік синхронізації, з сайту адміністрування SUS відкрийте сторінку Synchronize Server (Синхронізація сервера), викличте вікно Schedule Synchronization (Планування синхронізації), див. мал. 5. Можна також виконувати синхронізацію уручну;

· набудуйте періодичність завантаження на дочірніх серверах так. щоб вони як можна швидше отримували виправлення, завантажені батьківським сервером з сервера Microsoft;

· не включайте автоматичне отримання дозволу для отриманих виправлень, оскільки перед розповсюдженням їх слід протестувати;

· сплануйте тестування оновлень. Конфігурація тестових комп’ютерів повинна співпадати з такою робочих серверів і клієнтів. Для розповсюдження виправлення повинне бути схвалене (дозволено до розповсюдження) на сторінці Approve Updates (мал. 6). Дозволені виправлення автоматично стають доступними для клієнтів:

Мал. 5 Синхронізація.

При проектуванні інфраструктури клієнтів:

· врахуйте, що деякі оновлення вступають в силу тільки після перезавантаження. Користувачам, що працюють в цей час, можна не турбуватися, оскільки SUS перезавантажують комп’ютер тільки після виходу з системи всіх користувачів;

· продумайте оновлення віддалених комп’ютерів, користувачі яких не являються адміністраторами. Адміністратори отримують повідомлення про невдале оновленнях і виконують їх уручну Оновлення не відбудеться, якщо комп’ютер не буде підключений до мережі під час розповсюдження оновлень;

II. Проектування клієнтської частини інфраструктури оновлення системи безпеки

Другим етапом проектування інфраструктури оновлення є настройка автоматичного оновлення на комп’ютерах — клієнтах SUS. Хоча оновлення можна виконувати за допомогою локальної політики або системного реєстру, краще всього робити це з використанням консолі групової політики.

Існує чотири способи настройки клієнтів SUS:

· на вкладці Автоматичне оновлення або за допомогою однойменного ярлика Панелі управління групової політики;

· за допомогою GPO;

· за допомогою редагування системного реєстру (на кожному клієнтові).

Віддається перевага управлінню через групову політику за допомогою служби каталогів Active Directory. Крім полегшення адміністратора цей підхід гарантує однакову настройку всіх клієнтів, розташованих в одному контейнері Active Directory.

2.1 Настройка SUS за допомогою групової політики

У контейнері Адміністративні шаблони (Administrative Templates) об'єкту, що містить клієнти SUS, повинен бути шаблон wuau.adm. Якщо цей шаблон відсутній, його можна встановити команді й контекстного меню Додавання і видалення шаблонів (Add/ Remove Templates). Для діставання доступу до настройок клієнтів SUS клацніть Конфігурація комп’ютера | Адміністративні шаблони | Компоненти Windows | Windows Update (Computer Configuration | Administrative Templates [ Windows Components | Windows Update). Доступні чотири політика:

Проектування інфраструктури оновлення системи безпеки Настройка автоматичного оновлення (Configure Automatic Updates) — дозволяє задавати день і час оновлення, а також спосіб його виконання. Після настройки цієї політики клієнти автоматично завантажуватимуть і встановлюватимуть оновлення (мал. 5−9). Можливі наступні варіанти настройки:

· про автоматичне завантаження оновлень з подальшим повідомленням користувачі;

· повідомлення користувача про необхідність оновлення, отримавши його, користувач повинен сам завантажити і встановити оновлення;

· автоматичне завантаження і установка оновлень.

Мал 6 Настойка графіка автоматичного оновлення Вкажіть розташування служби Windows Update в інтрасеті (Specify Intranet Microsoft Update Service Location) — задає сервер SUS і сервер, на який клієнти винні передавати статистику (інформацію про виконане оновлення, включаючи його завантаження і установку). Сервер статистики не зобов’язаний бути SUS-сервером, потрібний лише наявність служб 11s з включеним веденням журналу. Один сервер 1is здатний збирати статистику з декількох серверів SUS (мал.6). Reschedule Automatic Updates Scheduled Installations (Очікування перед установкою запланованих оновлень) — визначає затримку (у хвилинах) між запуском служб SUS і початком установки оновлень (мал. 6), дозволяє оновлювати комп’ютери, відключені від мережі під час розповсюдження оновлення, після відновлення підключення.

Мал 7 Визначення севера SUS

Мал 8 Настойки зміни графіка оновлення

2.2 Настройки SUS специфічні для користувача

Більшість клієнтських настройок SUS впливають на всіх користувачів комп’ютера і містяться в Конфігурація комп’ютера групової політики. Проте, індивідуальна настройки користувача також можлива з допомогою наступних політик.

Видалити доступ до можливостей Windows Update (Remove Access To Use All Windows Update Features) — на системах під управлінням Windows XP дозволить заблокувати установку оновлень для будь-яких користувачів, включаючи локальних адміністраторів. Автоматичне оновлення працюватиме, але користувач не зможе увійти на сайт Windows Update, завантажити і встановити оновлення. Оскільки ця політика діє на користувачів, її застосування можна обмежувати, застосовуючи відповідні GPO до потрібних груп користувачів. Для настройки цієї політики клацніть Конфігурація користувача | Адміністративні шаблони | Компоненти Windows | Windows Update. | Видалити посилання і заборонити використання Windows Update (Remove Links And Access To Windows Update) забороняє користувачеві отримувати з сайту Windows Update оновлення, які не дозволені на сервері SUS. Для настройки цієї політики клацніть Конфігурація користувача | Адміністративні шаблони | Панель завдань і меню «Пуск» (User Configuration — Administrative Templates — Start Menu and Taskbar)

2.3 Настройка за допомогою системного реєстра

Якщо в середовищі не використовується служба каталогів Active Directory, конфігурація автоматичного оновлення може бути визначена за допомогою параметрів реєстру. Для настройки параметрів реєстру використовується один з наступних способів: уручну за допомогою редактора реєстру (Regedit.exe); централізоване розгортання розділів реєстру через системну політику Windows NT 4.0.

За допомогою редактора реєстру.

Натисніть кнопку Пуск, виберіть пункт Виконати і введіть в поле Відкрити команду regedit. Знайдіть і виділіть наступний розділ реєстру:HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU Додайте необхідні параметри.

Параметр: Reschedulewaittime

Значення: у де у — час очікування від запуску компоненту «Автоматичне оновлення» до початку установки оновлень у випадку, якщо запланована установка була пропущена, в хвилинах від 1 до 60.

Тип; Reg_dword

Примітка. Цей параметр набуває чинності лише в тому випадку, якщо встановлений клієнт SUS з пакетом оновлення версії 1 (Sp1) або вище. Параметр: Noautorebootwithloggedonusers

Значення: REGDWORD: Про (брехня) або 1 (істина). Якщо параметр має значення 1, компонент «Автоматичне оновлення» не перезапускає комп’ютер під час сеансу роботи користувача. Тип: REGDWORD

Примітка. Цей параметр набуває чинності лише в тому випадку, якщо встановлений клієнт SUS з пакетом оновлення версії 1 (Sp1) або вище.

Зведення про використання компоненту «Автоматичне оновлення» з сервером, на якому запущені служби SUS, див. в документі «Software Update Services Deployment» (Розгортання служб Software Update Services) на наступній сторінці веб-вузла корпорації майкрософт:

http://www.microsoft.coni/windowsserversystem/sus/susdeployment.mspx (http://go.microsoft.com/fwlink/?linkid=6928)

При настройці параметрів автоматичного оновлення за допомогою реєстру параметри політики мають вищий пріоритет в порівнянні з настройками, заданими локальним адміністратором. Якщо видалити відповідні розділи реєстру, то знову набудуть чинності задані локальним адміністратором параметри.

Щоб призначити сервер із запущеними службами Software Update Services, до якого решта серверів і клієнтських комп’ютерів повинна звертатися за оновленнями, додайте вказані нижче параметри в наступний розділ системного реєстру:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsjWindowsUpdate

Параметр: Wuserver

Тип: Reg_sz

Параметр служить для вказівки HTTP-имени сервера SUS (наприклад, http://intranetsus).

Параметр: Wustatusserver

Тіп:reg_sz

Параметр служить для вказівки HTTP-имени сервера статистики SUS (наприклад, http://intranetsus).

Приклад *.reg файлу

Regedit4

[Hkey_local_machinesoftwarepoliciesmicrosoftwindows]

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]

" Noautoupdate" =dword:0

" Auoptions" =dword:4

" Scheduledinstallday" =dword:0

" Sheduledinstalltime" =dword:11

" Usewuserver" =dword:1

" Reschedulewaittime" =dword:30

" Noautorebootwithloggedonusers" =dword:1

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]

" Wuserver" ="http://xxx12:8530″

" Wustatusserver" ="http://xxx12:8530″

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdate]

" Pingid" =;

" Accountdomainsid" =;

III. Моніторинг та оптимізація оновлень системи безпеки

Мета оновлення системи безпеки — своєчасна установка виправлень. Проте вся робота по проектуванню інфраструктури оновлень пройде даремно якщо після установки виправлень виникають збої, виправлення встановлюються не на всі системи або спізнюються. Завершальним (і дуже важливим) етапом створення інфраструктури оновлень є проектування тестування, моніторингу і оптимізації процесу оновлення.

3.1 Застосування MBSA

Аналізатор безпеки MBSA використовується для визначення наявності на серверах розгортання невідомих вразливостей. Деякі служби повинні бути активні і відкриті для доступу з мережі, наприклад служба загального доступу до файлів. Непотрібні ж уразливості, виявлені аналізатором безпеки MBSA, необхідно усунути.

Дії для запуску аналізатора безпеки MBSA

1.Завантажите аналізатор безпеки MBSA за адресою http://www.microsoft.com/mbsa і встановите його.

2.Запустите аналізатор безпеки MBSA.

3.Виконаєте вказівки майстра, вибравши сканування всієї мережі з відповідними обліковими даними.

4.На сторінці вітання клацніть напис Scan more than one computer (сканувати декілька комп’ютерів).

5.На сторінці Pick Multiple Computers To Scan (вибір декількох комп’ютерів для сканування) введіть діапазон IP-адресов серверів розгортання. Потім клацніть напис Start scan (почати сканування).

Коли сканування завершиться, в переліку результатів не повинно бути нічого, окрім інформаційних попереджень про загальні ресурси. На серверах, на яких розміщується служба каталогів Active Directory, необхідно уважно перевірити всі відкриті загальні теки і встановлені на них дозволи. За умовчанням створюються загальні ресурси Admin$, NETLOGON, SYSVOL, Cap_імя_домена і загальні ресурси кореневих розділів і томів (наприклад C$ і D$). Якщо на комп’ютері встановлена служба SMS, то на нім також будуть створені загальні ресурси Smspkgc$, Sms_hq1, Sms_site і Sms_suiagent. Всі непотрібні загальні ресурси необхідно видалити.

Для серверів Windows DS також виводитиметься інформаційне попередження про загальні ресурси. Необхідно уважно перевірити всі загальні теки і встановлені на них дозволи. Засіб Deployment Workbench при оновленні членом групи розгортання точки розгортання автоматично створює приховану загальну теку з ім'ям «Sharename$». Також створюються стандартний загальний ресурс Admin$ і загальні ресурси кореневих розділів і томів (наприклад C$ іd$). Необхідно обмежити доступ до дистрибутивних загальних ресурсів тільки користувачам, яким потрібний доступ до образів. Подальше обмеження доступу проводиться за допомогою настройки прав файлової системи NTFS, як це описано в додатку Е «Обмеження дозволів для файлів на серверах розгортання». Всі непотрібні загальні ресурси необхідно видалити. Необхідно позбавитися від всіх решті уязвімостей для зведення до мінімуму риски зараження знов встановлених клієнтських комп’ютерів із-за скомпрометованого сервера розгортання. Зокрема, варто звернути увагу на наступні типи вразливостей (у випадку, якщо вони були виявлені).

Облікові записи з порожніми або простими паролями. Компрометація інфраструктури розгортання може дозволити зломщикові скомпрометувати все нові комп’ютери, тому дуже важливо захистити всі облікові записи складними паролями. Додаткову інформацію про складні паролі можна отримати в керівництві Creating, а Strong Password Policy (правила створення надійних паролів) за адресою http://technet2.microsoft.com/WindowsServer/en/library/4 1728b4−5ed9−44a8−99fe-c050333d42451033.mspx?mfr=true.

* Облікові записи з необмеженим терміном дії паролів. Необмежений термін дії пароля є загрозою безпеці з кількох причин.

У зломщиків є більше часу для підбору пароля методом повного перебору.

*У разі компрометації пароля користувача у зломщика є доступ до системи користувача протягом всього часу, поки користувач не поміняє свій пароль.

* Після звільнення у співробітників є доступ до системи до тих пір, поки не буде змінені їх паролі.

* Потрібна установка оновлень безпеки. Часто оновлення безпеки усувають недавно виявлені уразливості.

Встановлені непотрібні служби. Аналізатор безпеки MBSA не попереджає членів групи розгортання про наявність служб, які потрібні для функціонування середовища розгортання. Тому всі непотрібні служби можна видалити або відключити.

* Аудит відключений. За умовчанням включений тільки аудит успіхів входу в систему. Включення аудиту відмов входу в систему дозволить відстежувати спроби неуспіхів аутентифікації на сервер складок. Не дивлячись на те, що ведення журналу аудиту відмов піддає сервер потенційної небезпеки атак типу «відмова в обслуговуванні», вірогідність проведення такого типу атак в середовищі розповсюдження украй мала. Інструкції по зміні параметрів аудиту приведені в керівництві Define or modify auditing policy settings for an event category (визначення або зміна параметрів політики аудиту для категорії події) за адресою http://technet2.microsoft.com/WindowsServer/en/library/d9fea7ea-61e5−43b1−98cd-b02a09f101561033.mspx?mfr=true.

* Наявність непотрібних загальних ресурсів. Як було описано раніше, на сервері збірки повинен бути як мінімум один прихований дистрибутивний загальний ресурс. Всі непотрібні загальні ресурси слід видалити для зменшення погроз безпеці.

Детальні інструкції по використанню аналізатора безпеки MBSA, включаючи навчальні посібники, доступні за адресою http://www.microsoft.com/resources/sam/partnerguide/howto_inv_tool.aspx.

Запуск MBSA з командного рядка

Основна перевага MBSA — можливість запису результатів н текстовий файл для імпорту в електронну таблицю або БД з метою генерації звітів для оцінки ефективності установки виправлень. Для кожного комп’ютера у файфайлі звіту приводиться список відсутніх виправлень, дозволяючий визначити, чи на всіх комп’ютерах успішно проходить завантаження і установка виправлень. Повний синтаксис команди mbsacli. exe див. в статті «Microsoft Baseline Security Analyzer (MBSA) Version 1.1 Is Available» за адресою hltp://suppon.microsoft, com/default.aspx?scid=kb;en-us;320 454. Нижче наводяться приклади команд:

· перевірка комп’ютерів по NetBIOS-именам:

Hbsacli.exe /hfh computer" !, computed, computers, computed

· перевірка комп’ютерів по IP-адресам: Hscacli /hfi xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx

· перевірка комп’ютерів з IP-адресами з файлу mycomputerip. txt: Mbsacli /hffip mycomputerip. txt

· виключення з перевірки виправлень за списком їх номерів в Knowledge Base, що завантажується з файлу notthese. txt: Mbsacli /hf notthese. txt

· вибір домена для перевірки: Hbsacli /hfd tailspintoys

· завдання імені файлу (myscan.txt) для збереження вихідних даних: Hbsacli /hfо tabf myscan. txt

· введення пароля, використовуваного при перевірці. При цьому пароль не передається по мережі в чистому вигляді, використовується шифрування NTLM: Mbsacli /hfi xxx.xxx.xxx.xxxu administratorp password

· |вибір сервера SUS для визначення дозволених виправлень: Hbsacli /hfsus ?http://susserver?

· перевірка домена tailspintoys.com із записом результатів у файлі myscan. txt: Hbsacli /hfd tailspintoys. comо tab f myscan. txt

3.2 Проведення аудиту встановлення виправлень

· для віддаленої перевірки на комп’ютерах, що перевіряються, повинні працювати служби сервер, віддалене управління реєстром і загальний доступ до файлів і принтерів.

Останні дві часто відключають для захисту від атак;

· зважте ризик від цих служб і переваги віддаленої перевірки. Часто цей ризик виправданий, але не завжди: виняток становлять сервери, потребуючі високій безпеці, наприклад, сполучені з Інтернетом безпосередньо;

· замість видаленої перевірки можна виконувати локальну, підключившись до сервера за допомогою служб терміналів (потрібні служби сервер і робоча станція).

mssecure.xml містить актуальні відомості про виправлення від Microsoft.

· можна вказати локальну копію mssecure. xml;

· альтернативний варіант — використання сервера SUS (див. мал. 5−13). У цьому випадку MBSA виконуватиме перевірку на відповідність списку виправлень дозволених на сервері SUS (доступ до Інтернету не потрібний).

Врахуйте відмінності запуску MBSA на контроллері домена і рядовому сервері:

· не рекомендується запускати MBSA на контроллерах домена за виключенням таких в невеликих мережах, особливо за наявності Small Business Server (SBS); з установка пакету оновлень для SBS захистить від збоїв при роботі MBSA наприклад, пов’язаних з обмеженнями анонімного доступу;

· М BSA пропонує відключити деякі служби, такі як Диспетчер підключень видаленого доступу (Remote Access Connection Manager), SMTP і Служба публікації (World Wide Web Publishing Service), але відключати їх нерекомендується, оскільки вони часто використовуються SBS;

· MBSA може повідомляти, що утиліта US Lockdown не використовується. На системі з SBS може також працювати Exchange Server, тому адміністратори

3.3 Перевірка виправлень за допомогою SUS і клієнтських журналів

Інформація про активність клієнтів записується в журнал Система (System), який можна експортувати і проаналізувати; У файлі update. log на системах з Windows XP, що оновлюються через SUS, зустрічається повідомлення про помилку «Еггог 1ueng1ne Querying software update catalog from htlp://servername/autoupdatedrivers/getmanitest.asp*. Його можна ігнорувати, оскільки SUS не підтримує оновлення драйверів.

И сервер SUS перевіряє наявність цифрового підпису у завантажуваних виправлень, при її відсутності або невдалій перевірці до журналу синхронізації вноситься запис «subject is not trusted for the specified action*. Такі помилки виникають із-за пошкодження файлу виправлення або в результаті модифікації пакету зловмисниками;

Примітка Завантажені виправлення зберігаються у файлах з розширенням .tmp, поки їх цифровий підпис не буде перевірений. Якщо перевірка пройшла успішно, початкове розширення відновлюється — це захист від випадкового розповсюдження виправлень з сумнівних джерел.

Вірно настроєне антивірусне ПО перехопить будь-яке інфіковане виправлення. Використовуйте антивірусне ПО, таке, що підтримує ведення журналів і щодня перевіряйте ці журнали; для пошуку виправлень, які не вдалося завантажити клієнтам, перевіряйте журнали подій. Опис повідомлень про помилки шукайте в керівництві по розгортанню SUS (див. www.microsoft.com/windows2000 /windowsupdate/sus/ susdeployment. asp);

Зведення про активність систем, що використовують автоматичне оновлення (Automatic Updates, AU), див. у файлі updalc. log, розташованому в системному каталозі клієнтського комп’ютера;

· перевіряйте системний реєстр клієнтів AU. Якщо значення параметра Austate (див. розділ Н До L М S Про FT WA R Е М i з rosofrwi ndo wsc u rre n tfe rsi onwi n do wsu pd ate Auto Update) рівне 2, клієнт запрошуватиме нове оновлення, у клієнта, нездібного до нових запитів із-за очікування завершення установки, це значення рівне 5; після закінчення оновлення початкове значення відновлюється;

· перевірте для клієнтів настройки Active Directory, що регламентують отримання GPO, що визначає розклад і джерело оновлення. Для цього застосовуються такі засоби, як Gpresult (Windows 2000 Resource Kit), оснащення Результуюча політика (входить в Windows XP і Windows Server 2003), а також консоль управління груповою політикою;

· перевіряйте виконання розкладу, аналізуючи журнал синхронізації, стежите за повідомленнями про збої завантаження у файлі <�каталог Web-сайта SUS> AutoUpdate Administrationhistory-sync.xml;

· перевіряйте журнал дозволених виправлень, стежте, щоб дозвіл на розповсюдження отримували тільки перевірені оновлення, а дозволи призначалися уповноваженими особами. Список дозволених виправлень див. у файлі <�каталог Web-сайта Sus>autoupdateadministrationhistory-approve, xml.

3.4 Тестування виправлень

Тестування виправлень схоже з тестуванням додатків. Нижче пояснюється необхідність тестування і приводяться інструкції для його проведення.

Всі виправлення тестуються перед випуском, але це не означає, при установці на конкретну систему не виникне проблем. Існує безліч ситуацій, в яких можливі неполадки, наприклад із-за несумісних:

· пристроїв;

· драйверів

· виправлень;

· додатку.

Крім того, в самому виправленні також можуть залишитися помилки. Щоб понизити ризик неполадок, перед установкою виправлення необхідно тестувати.

Проведення тестування Тестування виправлень нагадує тестування звичайних програмних продуктів. При тестуванні дотримуйтеся наступних інструкцій:

· проводите тестування на комп’ютерах, ізольованих від основної мережі;

· об'єднаєте ці комп’ютери, а окрему тестову мережу;

· на тестових комп’ютерах повинно бути те ж ПО і настройки, що і на робочих;

· підпишіться на розсилки і відвідуйте телеконференції, присвячені обговоренню проблем з виправленнями, — використовуйте досвід колег;

· повідомите про проблеми в службу підтримки Microsoft. Це дозволить усунути помилки і випустити нову версію виправлення і/або порекомендувати спосіб усунення проблем.

3.5 Моніторинг та оптимізація встановлення виправлень

Якщо процедура установки виправлень відсутня або погано реалізована, будь-яка нова загроза може викликати неспокій, паніку або навіть зупинку роботи. В цьому випадку реагування на загрозу займає багато часу, тим самим підвищуючи шанси успішної атаки. Якщо оновлення системи безпеки грамотно організовано, є час спокійно вивчити загрозу і вчасно усунути відповідну уразливість. Але навіть добре спроектовані процедури установки виправлень деколи не дозволяють вчасно зреагувати на загрозу, тому потрібно постійно підвищувати ефективність і швидкість реагування на погрози.

Регулярне оновлення системи безпеки гарантує віддзеркалення атаки по відомих вразливостях. Від більшості атак можна захиститися, просто приділяючи належну увагу настройці системи безпеки. Установка виправлень і настройка системи безпеки — взаимодоповнюючі заходи.

Щоб підвищити ефективність будь-якої операції, розділіть її на етапи, відкиньте ті, які змінити не можна, і продумайте ті, які можна змінити. Наприклад, ви не прискорите випуск виправлення і не передбачите точний час атаки, але зможете прискорити тестування виправлень і їх установку на всі комп’ютери мережі. Підвищити ефективність проекту оновлення допоможуть наступні рекомендації:

· визначите часовий проміжок між виникненням уразливості і атакою. Зафіксуйте:

1) поява повідомлення про уразливість і час виходу відповідного оновлення;

2) час тестування і отримання дозволу на розповсюдження виправлення; 3) час завершення установки виправлення:

· час, необхідний для дозволу виправлення, — час між появою попередження і випуском виправлення;

· час установки виправлення — час між дозволом виправлення і його установкою по всій мережі;

Своєчасно вирішуйте виникаючі проблеми із завантаженням виправлень; у шукайте способи прискорення установки виправлень. З’ясуєте наявність засобів, необхідних для розгортання виправлень, перевірки успіху їх установки і вирішення виникаючих проблем. Визначите, як встановлюватимуться виправлення на видалених системах і лептопах тих, що відряджаються. Можливо, деякі сервери доведеться оновлювати уручну.

Черв’як Blaster

У липні 2003 року в службі виклику видалених процедур (Remote Procedure Call, RPC) була виявлена уразливість настільки серйозна, що для попередження користувачів Windows були зроблені виняткові заходи. Проти звичаю Mictosfi повідомила про небезпеку не тільки через спеціальні бюлетені, але і звернулася до клієнтів безпосередньо, всім твердили: «встановите виправлення, поки є час». І, не дивлячись на це, коли з’явився черв’як Blaster (він же Msblast і Lovesan), що використовує цю уразливість, безліч комп’ютерів тут же заразилася ним.

Опит мережевих адміністраторів, проведений журналом Microsoft Certified Professional Magazine, показав, що більше 40% постраждалих знали про вірус, їм просто не вистачило часу для установки виправлення на всі системи, не дивлячись на те, що виправлення на три тижні випередило появу червя. Втім, деякі відповіли, що вони навіть не знали про загрозу.