NIST Special Publication 800-40 Revision 3

Guide to Enterprise Patch Management Technologies

Executive Summary 

Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware. From a security perspective, patches are most often of interest because they are mitigating software flaw vulnerabilities; applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation. Patches serve other purposes than just fixing software flaws; they can also add new features to software and firmware, including security capabilities. 

There are several challenges that complicate patch management. Organizations that do not overcome these challenges will be unable to patch systems effectively and efficiently, leading to compromises that were easily preventable. Organizations that can minimize the time they spend dealing with patching can use those resources for addressing other security concerns. Already many organizations have largely operationalized their patch management, making it more of a core IT function than a part of security. However, it is still important for all organizations to carefully consider patch management in the context of security because patch management is so important to achieving and maintaining sound security. 

This publication is designed to assist organizations in understanding the basics of enterprise patch management technologies. It explains the importance of patch management and examines the challenges inherent in performing patch management. The publication also provides an overview of enterprise patch management technologies and briefly discusses metrics for measuring the technologies’ effectiveness and for comparing the relative importance of patches. 

Organizations should implement the following recommendations to improve the effectiveness and efficiency of their enterprise patch management technologies. 

Organizations should deploy enterprise patch management tools using a phased approach

This approach allows process and user communication issues to be addressed with a small group before deploying the patch application universally. Most organizations deploy patch management tools first to standardized desktop systems and single-platform server farms of similarly configured servers. Once this has been accomplished, organizations should address the more difficult issue of integrating multiplatform environments, nonstandard desktop systems, legacy computers, and computers with unusual configurations. Manual methods may need to be used for operating systems and applications not supported by automated patching tools, as well as some computers with unusual configurations. 

Organizations should reduce the risks associated with enterprise patch management tools through the application of standard security techniques that should be used when deploying any enterprisewide application

Deploying enterprise patch management tools within an enterprise can create additional security risks for an organization; however, a much greater risk is faced by organizations that do not effectively patch their systems. Such tools usually increase security far more than they decrease security, especially when the tools contain built-in security measures to protect against security risks and threats. Risk associated with these tools include patches being altered, credentials being misused, vulnerabilities in the tools being exploited, and entities monitoring tool communications to identify vulnerabilities. Examples of possible countermeasures to these risks include keeping the patching solution components tightly secured and upto-date, encrypting network communications, verifying the integrity of patches before installing them, and testing patches before deployment. 

Organizations should balance their security needs with their needs for usability and availability

For example, installing a patch may “break” other applications; this can best be addressed by testing patches before deployment. Another example is that forcing application restarts, operating system reboots, and other host state changes is disruptive and could cause loss of data or services. Again, organizations need to balance the need to get patches applied with the need to support operations. A final example, particularly important for mobile devices, is the acquisition of updates over low-bandwidth or metered connections; it may be technically or financially infeasible to download large patches over such connections. Organizations should make provisions for ensuring that their enterprise  patching solution works for mobile hosts and other hosts used on low-bandwidth or metered networks.
......................................................
......................................................
Full text of publication:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r3.pdf

СИСТЕМА ЗА УПРАВЛЕНИЕ НА НЕПРЕКЪСНАТОСТТА НА БИЗНЕСА (СУНБ)

ДОКУМЕНТАЛНА ЧАСТ НА СУНБ, СЪГЛАСНО ИЗИСКВАНИЯТА НА ISO 22301:2012

При изграждането  на СУНБ е необходимо да се разработят следните документи (показани в следващата Таблица 1):

Таблица 1

№	Наименование на документа	Клауза от ISO 22301	Забележка
	ЗАДЪЛЖИТЕЛНИ ДОКУМЕНТИ НА СУНБ
1	Процедура за определяне на законовите / регулаторните изисквания	4.2.2	Определя отговорностите за постигане на съответствие със законовите / регулаторни изисквания
2	Списък на законовите / регулаторни и други, приложими изисквания	4.2.2	Пълен списък на изискванията, които трябва да се изпълняват
3	Обхват на СУНБ и описание на изключенията	4.3	Определя, къде ще бъде внедрена СУНБ
4	Политика за непрекъснатост на бизнеса	5.3	Определя основните отговорности и очакванията на Ръководството.
5	Цели на непрекъснатостта на бизнеса	6.2	Определя измерими цели, които ще се постигнат чрез непрекъснатост на бизнеса
6	Компетентност на персонала	7.2	Определя необходимите знания и умения на персонала
7	Комуникация с трети страни, имащи интерес от непрекъснатостта на бизнеса	7.4	Определя интересуващите се трети страни и как да се комуникира с всяка от тях
8	Процес на анализ на влиянието върху бизнеса и оценка на рисковете	8.2.1	Определя и описва приетата методология за провеждане на анализ на влиянието върху бизнеса и оценката на рисковете
9	Резултати от проведения анализ на влиянието върху бизнеса	8.2.2	Документира резултатите от проведения анализ
10	Резултати от проведения анализ на рисковете	8.2.3	Документира резултатите от проведения анализ ва рисковете
11	Процедури за непрекъснатост на бизнеса	8.4.1	Включват се планове за инциденти, възстановяване и бизнес планове
12	Процедури за реакция при инциденти	8.4.2	Определят първоначалните действия при реакция на различни видове инциденти
13	Решение дали рисковете и влиянието трябва да се комуникират извън организацията	8.4.2	Обикновено се извършва от Менажера (служителя) по кризисните ситуации
14	Комуникации с трети страни, вкл. със системи на национално / регионално ниво	8.4.3	Може да се документира, както е приложимо – електронна поща, бележки от работни срещи и др.
15	Записи на важни данни / информация за инцидентите и съответните мерки и решения	8.4.3	Обикновено записите са на база документираните работни данни / информация  по и след времето на възникване на инцидента
16	Процедури за реакция при разрушителни инциденти	8.4.4	Включват се планове за непрекъснатост на бизнеса и за възстановяване, вкл. и плановете за възстановяване от бедствия
17	Процедури за възстановяване на бизнеса и връщане към нормалните бизнес операции	8.4.5	Тези процедури описват какво се прави, след като бизнес операциите са възстановени.
18	Резултати от действията, предприети спрямо неблагоприятни тенденции или резултати	9.1.1	Това, основно са резултати от проведени превантивни действия
19	Данни и резултати от проведените наблюдения и измервания	9.1.1	Чрез тези данни / резултати се определя, дали СУНБ изпълнява поставените цели към нея.
20	Резултати от проведени наблюдение след приключването на инцидент	9.1.2	Чрез тези резултати се оценява колко ефективна е внедрената СУНБ
21	Резултати от проведени вътрешни одити	9.2	Обикновено, това са доклади от проведени вътрешни одити
22	Резултати от проведени прегледи от Ръководството	9.3	Обикновено, това са протоколи от проведените прегледи от Ръководството и съответните решения в тях
23	Видове несъответствие и предприети действия	10.1	Описание на разкритите несъответствие и съответните случаи, в които са разкрити
24	Резултати от приложени коригиращи действия	10.1	Описание на предприетите действия за премахване на разкритите несъответствия
	ПРЕПОРЪЧИТЕЛНИ ДОКУМЕНТИ НА СУНБ
1	План за внедряване на СУНБ	6.2
2	План за обучение и тренировки	7.2 /7.3
3	Процедура за контрол на документираната информация	7.5
4	Договори / Споразумения зя нива на предоставяните услуги с доставчици и/или подизпълнители	8.1
5	Стратегия за постигане на непрекъснатост на бизнеса	8.3
6	Противодействие на рисковете (описание)	8.3.3
7	Оперативни сценарии за действие при възникване на различни по тип инциденти	8.5
8	Планове за провеждане на тренировки и тестване на процедурите	8.5
9	Доклади за резултатите от предприетите мерки	8.5
10	План за поддръжка и развитие на СУНБ	9.1.1
11	Описание на прилаганите методи за наблюдение, измервания, анализи и оценка	9.1.1
12	Процедура за провеждане на вътрешни одити на СУНБ	9.2
13	Програма за провеждане на вътрешни одити	9.2
14	Процедура за провеждане на корективни действия	10.1