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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рубрика “Книги”

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

Мозговой штурм

В нашем дружном коллективе разработчиков сложилась такая традиция: при проектировании наиболее сложных частей системы собирать группу из 2-5 разработчиков и устраивать мозговой штурм. На мой проект эта традиция распространилась в немного измененном виде. Поскольку разработка итеративная, проектирование новых модулей проводится раз в 2 недели (длинна итерации). На днях мне как раз предстоит очередной такой мозговой штурм. Все свои мысли по поводу стратегии (!) проведения этого мероприятия попытаюсь изложить ниже. А заодно и для себя все разложу, что называется, ”по полочкам”.

Итак, начать нужно вот с чего:

• Четко обозначить границы проектирования.
• Обозначить все интерфейсы с другими частями системы.
• Просмотреть список требований на предмет того, что планируется учесть при проектировании. 
• Обдумать и расписать обязанности проектируемых компонент.

Далее, в процессе обсуждения:

• Не пытаться решить все проблемы одновременно: примерно через 10-30 минут можно составить список проблем, порожденных архитектурой, свойством системы, конкретным проектным решением и.т.д. Далее нужно брать по одному пункту из этого списка и решать только его. Все сразу продумать не получится. А если “штурмующие” начнут увлекаться, нужно сводить спор именно на ту проблему, которая решается в данный момент.
• По каждой проблеме нужно рассмотреть как минимум 2 варианта решений. Лучше больше. Для каждого варианта обдумывать его преимущества и недостатки. А не порождает ли это решение новые проблемы? А не противоречит ли оно уже принятым решениям?
• Если не получается принять решение в течение часа, то лучше сделать перерыв и переходить к следующему пункту. Можно будет вернуться к этой проблеме позже.
• Скорее всего, часть проблем решить так и не получится. Причина в недостатке информации о проблеме. В таком случае решение по данному вопросу целесообразно отложить на следующую итерацию. В плане необходимо предусмотреть проведение исследований по данной проблеме.
  (Это кстати очень распространенная ситуация когда из-за недостатка знаний о предметной области принимается неверное решение, или ни одно из предложенных решений не кажется правильным. Мы с группой как-то потратили 3 часа, но так и не смогли придумать что-то стоящее. Про это я уже недавно писал тут.)
• По поводу принятия решения… вопрос сложный. Тут могут быть варианты: либо решение принимается единогласно, либо принимается решение от наиболее компетентного в данной области проектировщика, либо в команде есть профессиональный архитектор, которые одобряет или отклоняет решения, либо какой-то другой вариант.

В завершении мозгового штурма:

• Еще раз вернутся к списку проблем, и оценить все принятые/непринятые решения.
• Самое время дать еще раз высказаться тем, кто категорически не согласен с тем или иным решением. (возможно, штурм будет продолжен)
• Определить, кто задокументирует все принятые решения.
• Отметить, какие требования будут реализованы каким компонентом.

Вроде все. Если что забыл, допишу позже.

Phishing

На днях делал доклад по этой теме (см. тему поста) для всех желающих в родном институте (СПбГПУ). Выкладываю презентацию, по которой делал доклад.

Ничего принципиально нового, но содержит интересные моменты. Выделяются типовые сценарии атак, рассматриваются приемы достижения целей, есть различные статистические данные, примеры phishing-сообщений и рекомендации по организации защиты.

Вот ссылка на сам доклад: Phishing_By_ArturK.

Переход от концепции к проектированию

Любой проект начинается со стадии выработки концепции, когда определяются основные цели и требования проекта. Здесь же обычно проводится куча исследований предметной области. Чем лучше на стадии выработки концепции будет разобрана предметная область, тем легче пройдет проектирование.

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

Приведу пример. Предположим, речь идет о построении распределенной системы контроля коммутации, которая встраивается между узлами сети и в зависимости от определенных условий разешает или запрещает коммутацию этих узлов. Условия меняются динамически. Система узнает об изменении условий посредством анализа трафика.

А теперь проблема. Исследования протоколов коммутации проводились неоднократно. Они начались, как только стало понятно, что придется анализировать трафик. Были выделены и разобраны конкретные протоколы, порты, типы сообщений и т.д. (все вплоть до конкретных пакетов). А когда дело дошло до проектирования, мы застопорились на одной простой вещи, которая имела принципиальное значение для контроля коммутации: ни кто не смог ответить на вопрос: “Может ли вот этот конкретный тип устройств инициировать новый сеанс обмена данными?”. Выяснилось, что ни в одном RFC или каком либо другом стандарте ответа на этот вопрос нет. Необходимо либо проконсультироваться с производителями этого типа устройств, либо взять это устройство и поэкспериментировать с ним два-три дня.

Может быть это мой промах. Возможно, я не так хорошо сформулировал задачи исследований для исследователей, может быть схалтурили исследователи. В обоих случаях есть стопроцентное оправдание. Когда проводились исследования, эта проблема была не очевидна.

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

О пользе итеративной разработки

Такое ёмкое понятие как “процесс разработки” охватывает очень много различных аспектов. Популярный сегодня UP (унифицированный процесс) и все его модификации оперируют понятием “итерация”. Не собираюсь описывать здесь итеративный процесс как таковой. По этой теме пишутся и с успехом продаются целые книги. Всего лишь выскажу свое мнение о полезности его применения в плане управления разработкой.

Планирование 

Два аспекта процесса итеративной разработки, которые в разы облегчают составление календарного плана или любого другого графика работ:

1. Каждая итерация подразумевает законченный и протестированный прототип разрабатываемой системы.
2. Длительность итерации – это константа.

Если оба этих правила выполняются, то к завершению фазы проектирования можно составить довольно точный календарный план, который будет подробно описывать весь процесс реализации проекта вплоть до этапа сдачи. Конечно, все зависит от объемов работ и самого проекта, но, по крайней мере, точные сроки разработки спроектированных частей системы (+/- 2 итерации) можно высчитать без гадания на кофейной гуще.

Назначение заданий

Планировать задания привязываясь к итерациям опять же намного проще. На совещании вначале итерации обсуждается текущее состояние проекта и цели итерации. Исходя из этих целей, составляется список задач.

Оценка результатов

Длительность итерации выбирается, как правило, небольшой – от нескольких дней до двух недель (редко месяц). За это время каждый член команды успевает выполнить ряд небольших, вполне конкретных задач. В конце каждой итерации мы имеем законченный “state”. Вот и все, что нужно для оценки текущих результатов проекта. Обсуждая новый билд, новые функции и баги, результаты исследований и разработанные документы можно легко оценивать продуктивность работ, сверятся с планом или графиком, составлять отчеты и т.д.

Итого

У себя на работе я активно продвигаю идею итеративной разработки. Конечно, до UP еще пока далеко, но уже то, что есть на данный момент приносит свои плоды. Все описанные плюсы были мне далеко не очевидны, поскольку раньше я занимался разработкой и не думал о “всяких там планах и графиках”. А вот, как выяснилось, итеративный процесс удобен не только с точки зрения development`а, но и с точки зрения management`а.

Баг с публикацией поста. 408 Request Time-out

Наткнулся на баг wordpress, пока писал предыдущий пост. Точнее с написанием все прошло гладко, а вот публиковаться пост ну ин как не хотел. На неделе было некогда разбираться, а сегодня вот занялся и получил дельный совет от службы поддержки.

В чем заключается проблема: при попытке публикации поста, сервер возвращает ошибку:

408 Request Time-out.This request takes too long to process, it is timed out by the server. If it should not be timed out, please contact administrator of this web site to increase 'Connection Timeout'.

Причина возникновения ошибки – знаки пунктуации в заголовке или слишком длинный заголовок. К конкретному языку это не относится и в службе поддержки про эту ошибку знают, но пока не исправили.

Поборол я эту ошибку следующим образом. Открыл черновик поста, переименовал пост, озаглавив одним словом без знаков препинания. Затем, сохранил как черновик и потом опубликовал. После публикации вернул старое название.

Теперь все работает. Можно приступать к следующим статьям!

Требования – это главное и основное. Часть 2: Документирование

Продолжаем тему менеджмента требований. После того, как требования собраны (а еще лучше в процессе сбора), они должны быть задокументированы.

Все требования желательно хранить централизовано. Если требования разбросаны по множеству документов, папок, сайтов и т.д., одно из них (или целая группа) будут неучтены. Желательно строго определить формат изложения требований и придерживаться этого формата. Посоветуйтесь со всей командой. Каждый ее участник может привнести в разрабатываемый шаблон требований что-то действительно нужное.

Чтобы не записывать все требования сплошным списком, нужно выделить группы требований. Здесь каждый решает сам, какая таксономия будет удобнее. Можно взять одну из уже существующих систем классификации, можно придумать свою, «заточенную» под конкретные нужды и цели. Лично я, предпочитаю широко известную модель FURPS+. Пару слов об этой модели.

Модель FURPS+ достаточно универсальна, и вместе с тем достаточно удобна. Путаница с распределением требований по группам возникает редко. Выделяются следующие группы требований:

• Функциональные требования – функциональность, свойства, возможности, безопасность, и т.д.
• Требования надежности – частота сбоев, возможность восстановления, предсказуемость поведения.
• Требования производительности – время отклика, точность, доступность, использование ресурсов.
• Возможность поддержки и конфигурирования – адаптивность, соответствие стандартам, возможность конфигурирования.
• Требования к реализации – требования к ресурсам, языки и средства разработки, аппаратное обеспечение.
• Требования к интерфейсам – ограничения, накладываемые необходимостью взаимодействия с внешними системами.
• Управление системой – требования к инструментам управления системой, к интерфейсам управления и пользовательскому интерфейсу.
• Требования удобства и эргономики – человеческий фактор, справочная система, документация.
• Юридические вопросы – авторское право, использование компонентов сторонних разработчиков и пр.

Также полезно снабдить требования некоторыми атрибутами. Например:

• Уникальный идентификатор, состоящий из первой буквы названия класса требований (Ф – функциональные, Н – надежность) и целого числа. Нумерация списков в Word может сместиться в случае перемещения требования или добавлении нового, а такой идентификатор (записанный простым текстом) никуда не денется. При ссылке на требование из другого документа достаточно указать этот идентификатор.
• Актуальность (”Действительно”, “Снято”, “Под вопросом”) – часть требований в процессе разработки снимается, но не следует сразу удалять их. Возможно, кто-то ссылался на них из других документов.
• Источник требования – документ, либо лицо, выдвинувшее данное требование. Если требование сформулирован плохо, или непонятно откуда взялось, можно будет уточнить, обратившись к источнику.
• Дата введения требования.
• Проектирование – когда и кем требование было учтено при проектировании, и в каком проектном документе можно найти решение, подтверждающее, что требование учтено.
• Реализация – когда и кем требование было реализовано, и в каком модуле/файле/документе можно найти реализацию этого требования.
• Тестирование – когда и кем была проверена и подтверждена корректность реализации требования. Также может быть указан использовавшийся при проверке Test-Case.

Требования – это главное и основное. Часть 1: Сбор требований

О том какую роль играют требования в процессе разработки написано очень много. Но раз уж я решил затронуть эту тему, придется и мне присоединится и добавить кое-что от себя.

В любом проекте, если речь не идет о чем-нибудь очень простом, фигурируют такие документы как техническое задание (ТЗ), технические условия (ТУ), требования к изделию и т.д. От названия документа и формата изложения смысл содержимого не меняется – все эти документы содержат требования к разрабатываемому продукту. Невыполнение этих требований может привести к самым разным последствиям. Самый удачный вариант – заказчик просто не заметит отсутствие тех или иных свойств изделия. Самый скверный – откажется платить деньги на основании невыполнения того же пресловутого ТЗ. Это было вступление. Теперь по делу…

В зависимости от масштаба предприятия и состава команды разработки, обязанности по менеджменту требований могут возлагаться на аналитика (насколько я знаю, в некоторых компаниях даже есть такая должность «аналитик по требованиям»), на руководителя или не возлагаться вообще ни на кого. Последний вариант самый печальный и грозит вышеописанными сложностями сдачи продукта заказчику. Задача менеджмента требований состоит в сборе, уточнении и формализации требований, документировании требований, актуализации требований, и самая главная задача – контроль реализации требований.

Источники требований

1. Требования могут быть сформулированы четко и ясно в каком-то документе (те же ТЗ и ТУ). С такими требованиями работать проще всего. Они, как правило, конкретны, четки и исключительно по делу. Иногда такие требования нуждаются в уточнении. К примеру, из требования «Передаваемые по сети данные должны шифроваться» непонятно, шифровать только значимые данные, или и служебные тоже.

2. Требования могут быть высказаны заказчиком в ходе обсуждения проекта. Искусство понять, что конкретно хочет получить заказчик – это тема отдельной статьи. Заказчик в большинстве случаев сам не знает, что конкретно ему нужно. Часто высказывает противоречивые или плохо сформулированные требования. Самое важное, на мой взгляд, стараться говорить с заказчиком на «его языке». Если он не программист не надо пытаться читать ему лекцию на тему «Managed code vs. native code». Может ему вообще неважно, на каком языке будет написан продукт. Углубляться в эту тему здесь я не буду. Замечу лишь, что у заказчика, еще на самых начальных этапах разработки полезно бывает поинтересоваться, насколько критично то, или иное требование. Это поможет спланировать реализацию функций разрабатываемого продукта от важных к менее важным.

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

В общем случае невозможно определить все требования с самого начала. Перечисленные источники – это лишь то, к чему можно обратиться на начальных стадиях разработки. Источником новых требований может стать любой документ (не говоря уже о переменчивых желаниях заказчика). По завершении некоторых задач, полезно просматривать результаты работ на предмет новых требований. К примеру, в том проекте, на котором я сейчас занят, требования собирались из следующих источников: ТЗ, модель доступа, предполагаемая архитектура, обсуждения проекта с заказчиком, use-case`ы, некоторые стандарты и ГОСТы. Больше чем уверен, что позже, с появлением новых результатов, этот список расширится.