Оновити чи не оновити?

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

Я, звичайно, повністю погоджуюся, що будь-яке оновлення (будь то вбудована програма, ОС або додаток) не повинно застосовуватися недбало, як тільки воно з'явиться, але я також твердо вірю, що якщо постачальник його випустив, має бути хоча б якась причина; і найпоширеніша причина - це зазвичай виправлення помилок ... яких, можливо, ви не відчуваєте зараз, але ви можете відчути незабаром, якщо не будете йти в ногу.

Особливо це стосується виправлень безпеки; Як іспит, якби хтось просто застосував пластир, який уже був доступний місяцями , сумнозвісний SQL Slammerчерв’як був би нешкідливим.

Я все для тестування та оцінки оновлень, перш ніж їх розгортати; але я категорично не погоджуюся з підходом до управління системою "якщо це не порушено, то не чіпай цього", і це мені справді шкодить , коли я знаходжу системи Windows 2003 SP1 або ESX 3.5 Update 2, і єдину відповідь, яку я можу отримати, це "це працює, ми не хочемо його ламати".

Що ти думаєш про це?
Яка ваша політика?
І яка ваша політика компанії , якщо вона не відповідає вашій?

Що з оновленнями мікропрограмного забезпечення (BIOS, зберігання тощо)?
Що з основними оновленнями ОС (пакетами обслуговування)?
А що з незначними оновленнями ОС?
Що з оновленнями додатків?

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

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

Протягом довгострокового менталітету "не зламався, не оновлюй" ви повинні чітко зазначити, що:

• Міграція незавершеної застарілої системи, яка відстала від сучасної системи, набагато дорожчий і болючий процес, ніж поступове оновлення цієї системи з часом.
• Досвідчений та кваліфікований ІТ-персонал активно шукає нові технології та компанії, які постійно розвиваються у своїх ІТ-системах. Є дуже реальна вартість долара в обороті, втрачені можливості та втрата знань, коли компанії втрачають сильно зайнятих, креативних ІТ-співробітників через їхні системи, що застоюються та стають непривабливими для роботи. Тоді все, що тобі залишається, - це "життєзабезпечення".

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

Це нескінченна дискусія, і розумні люди не погоджуються. Якщо ви говорите про ПК користувачів, я погоджуюся, що їх потрібно оновити. Якщо ви говорите про сервери, розгляньте окрему політику щодо серверів, які стикаються з Інтернетом, і тих, які цього не роблять. Я не знаю про ваші сервери, але в моєму середовищі, можливо, 10% наших серверів мають порти, відкриті для Інтернету. Ці сервери, що стоять перед Інтернетом, отримують найвищий пріоритет, коли мова йде про патчі безпеки. Сервери, які не стикаються з Інтернетом, мають нижчий пріоритет.

Гуру безпеки будуть стверджувати, що такий підхід є проблематичним, тому що якщо хакер коли-небудь потрапить у вашу мережу, незапатковані сервери дозволять експлуатувати по мережах подвиги, як wildfire, і це розумний аргумент. Однак, якщо ви тримаєте ті сервери, що стоять перед Інтернетом, щільно зафіксованими і правильно налаштовують брандмауер лише для відкриття тих портів, які абсолютно необхідні, я думаю, що цей підхід працює і часто може бути використаний для заспокоєння менеджерів, які бояться патчів.

Якщо ви покладаєтесь лише на оновлення Windows для виправлень (ви не згадали, яку ОС ви використовуєте, але я здебільшого хлопець Windows, тому це моя довідка), подивіться на фактичні виправлення, які виходять щомісяця . У мене є деякі сервери, що якщо я запускаю оновлення Windows, мені скажуть, що мені потрібно 50+ патчів, але якщо я прокручую ці патчі і досліджую кожен з них, я виявлю, що 90% елементів, які є патчами, не є безпекою пов'язані, але виправляйте помилки, які впливають на послуги, які я не запускаю на цьому полі У великих середовищах, де ви використовуєте систему управління патчами, звичайно переглядати все, що випускається, і турбуватись лише з тим, що абсолютно необхідно, а це зазвичай становить приблизно 10% від того, що випускає Microsoft.

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

Я можу говорити лише про сервери, але у нас є режим "Щоквартального оновлення", на чотири заздалегідь визначені та оголошені дати на рік ми збираємо запити на оновлення, застосовуємо їх до нашого референтного середовища, запускаємо їх протягом місяця, щоб перевірити стабільність і якщо добре розгорнути протягом наступних n днів / тижнів. На додаток до цього ми застосовуємо політику екстреного оновлення, де ми маємо можливість впроваджувати посилання, тестувати та виконувати термінові оновлення протягом дня або двох, якщо серйозність така - хоча це було використано лише 2/3 рази за останній 4 роки або близько того.

Цей подвійний підхід гарантує, що наші сервери обґрунтовано, але не дурно, оновлюють, що оновлення управляються спеціалістами з питань тематики (тобто мікропрограмним забезпеченням, драйверами, ОС, персоналом додатків), а не постачальниками, але також дозволяє швидко виправити, якщо вимагається. Ну, звичайно, нам пощастило, що в усьому бізнесі є дуже мало різних апаратних моделей (<10 варіантів сервера), і значні та сучасні референтні платформи для перевірки.

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

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

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

Модернізація заради цього, що саме ви пропонуєте ("але ви можете відчути незабаром"), навіть якщо ви заявляєте, що це не так, - це абсурдна і небезпечна дорога. Якщо ви не можете представити фактичну причину, на відміну від якоїсь теоретично можливої ​​причини, ви ніколи не збираєтесь переконувати інших, якщо вони проти оновлення.

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

Редагувати

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

Оновлення безпеки надсилаються на сервісний сервер, а потім виробництво після того, як вони виявлять, що вони не підірвали речі. Якщо немає реального біп ІНГ надзвичайної ситуації (що я вдарив кілька разів :(), в цьому випадку PRODUCTION зараз. Інші поновлення тільки по мірі необхідності, після того, як проводити час в постановці.

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