IT-Project Management

IT-PM: Персональный блог об управлении IT-проектами

Archive for Апрель 2008

Разбираемся с терминами: уязвимость, угроза, риск

leave a comment »

Да. Именно в таком порядке: уязвимость, угроза, риск.

Пишу политику безопасности по ГОСТ 17799-2005. Она просто изобилует этими и другими терминами. По отдельности  значения этих терминов просты и понятны. Но когда в одном абзаце встречаются все три, поневоле запутаешься. Итак… что с чем едят?

Уязвимость (vulnerability) информационной системы — это недостаток, чаще ошибка в реализации, которая делает возможным непредусмотренное воздействие на систему, влекущее сбои в работе системы. Уязвимости классифицируются по множеству признаков. Один из самых важных признаков — вред, который можно нанести системе, используя уязвимость. Чаще всего под уязвимостью понимают конкретную ошибку, допущенную при проектировании или кодировании системы.

Угроза (threat) безопасности — это возможность нарушения безопасности. Термин «угроза» редко применяют в отношении информационных систем, и очень часто употребляют применительно к информации. Видимо, это связано с самой распространенной таксономией угроз: угрозы конфиденциальности информации, угрозы целостности информации и угрозы доступности информации. Почему-то разработка модели угроз всегда начинается именно с такой таксономии. Видимо потому, что она универсальна. На этом, пожалуй, ее достоинства заканчиваются. Увлекся. Это все к делу не относится.

Риск (risk) — это вероятность или возможность наступления того или иного события. Применительно к информационной безопасности или управлению проектами под событиями понимают всевозможные негативные события. Рисками управляют. Задача управления рисками (если кратко) состоит в идентификации, оценке и минимизации рисков.

Со значениями терминов разобрались. Переходим к их взаимосвязи.

1. Каждая ли уязвимость ведет к возникновению угрозы?
В 99% случаев да. Почему не в 100% случаев? Для реализации уязвимости необходимы определенные условия. Если нарушитель гарантированно не может выполнить эти условия, то уязвимость не может быть использована. Но не стоит забывать, что нарушители бывают разные. Если сегодня мы защищаемся только от удаленных атак и локальные уязвимости в расчет не берем, то завтра к информационной системе может получить доступ инсайдер.
Некоторые уязвимости относятся к одним и тем же угрозам.

2.  Для каждой ли угрозы существует уязвимость?
Нет. Во-первых, угрозы существуют отдельно от уязвимостей. Угроза нарушения конфиденциальности информации существует в любой системе, ограничивающей доступ к информации. Точно также как и угроза нарушения доступности характерна для любого сайта.
Во-вторых, не всегда для осуществления угрозы необходимо использовать уязвимость. Вспомним про того же инсайдера, который обладает полномочиями на доступ к конфиденциальной информации, и может передать ее третьим лицам.
В-третьих, уязвимость может просто быть не известна на данный момент.

3. Для каждой ли угрозы существует риск?
Безусловно. Если существует угроза, значит, существует и риск ее осуществления. Наличие нескольких уязвимостей, используя которые можно осуществить данную угрозу, повышает риск ее осуществления. Как все оказывается просто! Намного сложнее оценить этот самый риск. Но это уже другая опера.

4. Каждый ли риск относится к конкретной угрозе?
Смотря какие риски имеются ввиду. Если речь идет о рисках информационной безопасности данной информационной системы, то (при условии, что модель угроз достаточно полно описывает все возможные угрозы данной системы) можно построить точное соответствие. Если же речь идет о рисках информационной безопасности для организации, использующей данную систему, то реестр рисков будет включать риски реализации угроз.

Реклама

Written by Артур К.

Апрель 17, 2008 at 23:03

Крэг Ларман. Применение UML и шаблонов проектирования

leave a comment »

Обложка книгиФундаментальный труд, охватывающий сразу несколько аспектов разработки ПО. Я читал эту книгу довольно давно, перечитывал некоторые части много раз. Сразу оговорюсь, я читал 2-ое издание, но сейчас в продаже уже 3-е.

Первое, что я вынес для себя из этой книги — это представление о том, как должен выглядеть итеративный процесс разработки. В книге описывается UP. Причем описываются различные аспекты и виды работ: начиная от формирования первоначального видения проекта и описания use-case`ов, и заканчивая тестированием продукта.

В книге приведены наиболее распространенные шаблоны проектирования. Подробные описания и разъяснения, а также примеры применения шаблонов. И конечно же это отличный учебник по UML.

Способ подачи материала не рассчитан на профессионала. Это, скорее всего, учебник, который дает представление обо всех аспектах объектно-ориентированного подхода к созданию ПО и об итеративном процессе разработки. Простой и понятный язык.

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

Безусловно, есть и пара минусов: не очень хорошо переведены некоторые термины, книгой неудобно пользоваться как справочником. 

Written by Артур К.

Апрель 7, 2008 at 8:29

Рубрика «Книги»

leave a comment »

Книги — это очень интересная тема для обсуждения. Тем более, что есть пара произведений про которые хотелось бы рассказать. С сегодняшнего для открываем одноименную рубрику.

Written by Артур К.

Апрель 6, 2008 at 23:23

Опубликовано в IT-PM

Tagged with