Лекции для подготовки к экзамену по дисциплине «Методы и средства защиты компьютерной информации» (стр. 6 )

Организационно-управленческие секреты - системы организации произ­водства, маркетинга, управления качеством, персоналом, финансами.

6.2. Экономическая оценка объектов интеллектуальной

собственности

В современной хозяйственной деятельности предприятий важное значение играет оперативная оценка и переоценка объектов интеллектуальной собствен­ности (ОИС), и, следовательно, определение экономической целесообразности их защиты.

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

В общем случае оценка рыночной стоимости (Ци) ОИС может произво­диться по формуле:

Сп - затраты на обеспечение правовой охраны объекта;

См - затраты на маркетинговые исследования и мероприятия по продви­жению объекта на рынок;

р - среднестатистическая ставка лицензионных выплат;

Аr - база для расчета лицензионных выплат (экономическая выгода от ис­пользования оцениваемого объекта);

Т - срок полезного использования объекта интеллектуальной собственно­сти;

К1 - коэффициент технико-экономической значимости объекта правовой значимости (для товарных знаков - коэффициент эстетического восприятия);

К2 - коэффициент промышленной (производственной) готовности объекта правовой охраны;

К3 - коэффициент надежности правовой охраны оцениваемого объекта;

К4 - коэффициент морального старения оцениваемого объекта;

К5 - коэффициент амортизации оцениваемого объекта на момент расчета;

К6 - коэффициент правовой значимости оцениваемого объекта интеллекту­альной собственности.

Данная формула может быть использована для расчета рыночной цены ОИС, например, для целей продажи лицензии, внесения долевого пая в устав­ной капитал предприятия.

Итоговая стоимостная оценка ОИС при расчете его рыночной цены может быть скорректирована с учетом конкретной ситуации. В этом случае надбавка к стоимостной оценке объекта не должна превышать 30% его расчетной рыноч­ной стоимости.

Основаниями для бонификации (независимого от срока действия охранно­го документа на момент его оценки) могут служить критерии: конкурентоспо­собности объекта, экономической эффективности использования объекта, объ­ема и надежности правовой охраны объекта, степени новизны объекта, а также ряд других факторов.

Рассмотренная концепция оценки ОИС в целом соответствует Междуна­родным стандартам оценки, разработанным МКСОИ (TIAVSC - The Interna­tional Assets Valuation Standards Committee), и может быть предложена для ис­пользования в практике оценке имущества предприятий.

Уровень защиты ОИС на предприятии можно оценить с помощью частно­го функционального критерия защиты ОИС, который рассчитывается по фор­муле:

где

Упр - суммарный предотвращенный ущерб от реализации комплекса мер по защите ОИС;

3 - общая сумма затрат, понесенных предприятием при реализации ука­занного комплекса мер;

Упо - суммарный понесенный предприятием ущерб в результате неправо­мерного использования ОИС.

Очевидно, что чем выше значение данного ЧФК, тем выше уровень защи­ты ОИС предприятия.

Экспертные методы в задачах оценки рисков информационной безопасности

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

ОЦЕНКА РИСКОВ ИБ МЕТОДОМ ДЕЛЬФИ

Метод «Дельфи» используют для усовершенствования группового подхода к решению задач оценки путем взаимной критики субъективных взглядов, высказываемых отдельными специалистами, без непосредственных контактов между ними и при сохранении анонимности мнений или аргументации в защиту этих мнений. Это позволяет исключить влияние авторитетных и «напористых» участников на суждение остальных, а также уменьшить или исключить явление «сдвига Риска».

Суть метода Дельфи

Пусть в опросе участвует m экспертов. Метод «Дельфи» предусматривает проведение экспертного опроса в несколько туров.

1. Во время каждого тура эксперты со­общают свое мнение и дают оценку исследуемым явлениям. При обработке информации, полученной от экспертов, все оценки располагают в порядке их убывания N1, …, Nm, затем определя­ют медиану (М) и квартили (Q1, Q2), которые разбивают все оценки на четыре примерно равных интервала, как показано на рис.

Медиана служит характеристикой группового ответа, размер квартилей — показателем разброса индивидуальных оценок. За медиану M принимается член ряда, по отношению к которому число экспертных оценок с начала и с конца ряда будет одинаковым. Затем определяются верхний и нижний квартили, представляющие собой интервалы, в каждый из которых попадает примерно по 25% значений ряда. Средние квартили, расположенные слева и справа от медианы, считаются предпочтительными.

2. Экспертов, чьи оценки попадают в крайние интервалы (не лежат внутри диапазона Q1 — Q2), просят обосновать свое мне­ние по поводу этих оценок. С их обоснованием и выводами (не указывая, от кого именно они получены) знакомят остальных экс­пертов. Подобная процедура позволяет специалистам изменять в слу­чае необходимости свою оценку, принимая в расчет обстоя­тельства, которые они могли случайно упустить или которыми пренебрегли в первом туре опроса. Благодаря этому, результаты второго и последующих туров опроса дают, как правило, мень­ший разброс оценок.

3. После получения оценок второго тура снова рассчитываются медиана и квартили.

4. Этот процесс продолжается до тех пор, пока продвижение к сближению точек зрения не становится незначительным. После этого рассчитывается медиана. Она и есть – оценка.

Как правило, производят не более 3-4 итераций. Если за это время разброс не стал приемлемым, то необходимо либо переформулировать вопрос, либо переформировать группу экспертов.

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

Пример

Рассмотрим задачу оценки рисков ИБ методов Дельфи на следующем множестве угроз (двухфакторный метод). Угрозы взяты из каталога BSI ITPM при использовании 5 экспертов:

1.  Угрозы в связи с форс-мажорными обстоятельствами – пожар (Т 1.4);

2.  Угрозы на организационном уровне – ненадлежащая организация изменения пользователей (Т 2.21);

3.  Угрозы на организационном уровне – несоответствие помещений требованиям в области безопасности (Т 2.6);

4.  Угрозы на организационном уровне – неподходящая обработка инцидентов в области безопасности (Т 2.62);

5.  Угрозы, связанные с ошибками людей – небрежность при стирании (уничтожении) информации (Т 3.25);

6.  Угрозы, связанные с ошибками людей – повреждение кабелей из-за небрежности (Т 3.5);

7.  Угрозы, связанные с техникой – отказы внутренних сетей электроснабжения (Т 4.2);

8.  Угрозы, связанные с техникой – потери данных из-за старения (ухудшения качества) носителя данных (Т 4.20);

9.  Угрозы, связанные с техникой – потери данных в базе данных (Т 4.28);

10.  Угрозы, возникающие на предпроектном этапе – подбор паролей (Т 5.18);

11.  Угрозы, возникающие на предпроектном этапе – враждебные апплеты и вирусы (Т 5.23);

12.  Угрозы, возникающие на предпроектном этапе – воровство (Т 5.4)..

В результате проведенной экспертизы методом Дельфи получены следующие оценки рисков:

Угроза	T.1.4	T.2.21	T.2.6	T.2.62	T.3.25	T.3.5	T.4.2	T.4.20	T.2.38	T.5.18	T.5.23	T.5.4
Риск	0,18	0,36	0,15	0,28	0,30	0,24	0,21	0,45	0,30	0,24	0,42	0,24

Ранжируем угрозы по возрастанию риска.

T.2.6	T.1.4	T.4.2	T.3.5	T.5.18	T.5.4	T.2.62	T.3.25	T.4.28	T.2.21	T.5.23	T.4.20
0,15	0,18	0,21	0,24	0,24	0,24	0,28	0,30	0,30	0,36	0,42	0,45

Таким образом, наименьший риск имеет угроза «Несоответствие помещений требованиям в области безопасности» (0,15), а наибольший риск у угрозы «Потери данных из-за старения (ухудшения качества) носителя данных» (0,45).

Анализируя достоинства и недостатки количественных методов можно сказать следующее

Достоинства

1.  Результат формируется в количественной форме, более естественной для последующей аналитической обработки (например, для расчета ROI, эффективности СЗИ). Качественные оценки не позволяют это сделать.

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

Недостатки

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

2.  Трудно обеспечить релевантность и согласованность оценок. Она обеспечивается путем принудительного введения большой избыточности в получаемую от экспертов информацию, использования специализированных методик, в методы экспертного опроса.

3.  Эксперту достаточно сложно формировать и работать с подобными оценками. Для него более удобно работать с качественными категориями. В особенности, если сами критерии являются качественными.

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

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

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

Оценка рисков ИБ с помощью метода анализа иерархий

Метод был предложен Т. Саати в 70х – 80х гг. XX века и нашел очень мощное применение при принятии управленческих решений и прогнозировании возможных результатов развития ситуации в сложной системе взаимосвязанных компонент, где участвуют ресурсы, желаемые исходы или цели, заинтересованные лица или группа лиц (например, разрешение военных конфликтов). Он позволяет включить в процесс оценки рисков различные факторы, в том числе и качественные, а также модели злоумышленников со своими целями, мотивами.

Идея метода заключается в построении многоуровневой иерархии – системы наслаиваемых друг на друга уровней, каждый из которых состоит из многих элементов или факторов.

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

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

Метод состоит в декомпозиции проблемы на все более простые составляющие части, а затем, путем проведения парных сравнений ЛПР - в выражении относительной степени интенсивности элементов в иерархии.

В данном методе, вместо того, чтобы задавать эксперту, например, вопросы вида: «Какова вероятность реализации некоторой угрозы с номером i?», ему задают вопросы следующего вида: «В какой степени первая угроза более вероятна, чем вторая? Первая чем третья? Первая чем четвертая? Вторая, чем третья?». Полученная матрица парных сравнений затем обрабатывается, по результатам чего формируются веса предпочтительности объектов (например, веса, определяющие вероятность реализации угроз).

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

Международные стандарты в области управления ИТ-инфраструктурой и ИБ

Информационные технологии (ИТ) являются неотъемлемой частью деятельности любой организации, информация и поддерживающие ее технологии представляют собой зачастую самые ценные ее активы. Эффективное управление ИТ в организации является важнейшим фактором ее выживания и успеха, достижения ее бизнес-целей, которые все больше привязываются к ИТ. Отсутствие в организации процессов управления ИТ может привести к неэффективному достижению бизнес-целей организации, и даже к срыву в их достижении. В связи с этим многими организациями все больше уделяется внимание вопросу управления своими ИТ-процессами, вопросу стандартизации данного управления. Многие ИТ-процессы напрямую влияют также на безопасность информационных ресурсов, поэтому вопросы информационной безопасности организации должны быть неразрывно связаны с управлением ее ИТ-процессами.

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

В настоящее время наиболее известными стандартами и подходами в области управления ИТ-процессами и ИТ-инфраструктурой являются:

1. CobiT – «Цели контроля для информации и связанных с ней технологий».

2. ISO 17799:2005 - «Информационная технология. Методы обеспечения безопасности. Руководство по управлению безопасности информации».

3. ISO 27001:2005 – «Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Требования».

4. Microsoft Operational Framework – «Подход к эксплуатации ИТ-сервисов Майкрософт».

5. ITSM – «Управление ИТ-сервисами».

6. ITIL – IT Infrastructure Library.

Рассмотрим основные подходы и модели, используемые в них для управления ИТ-процессами.

Управление конфигурациями

По терминологии процесса Управления Конфигурациями ИТ-компоненты и предоставляемые на их основе услуги называются Конфигурационными Единицами (CI). Каждый ИТ-компонент, чье наличие и версия зарегистрированы, является Конфигурационной Единицей.

В каждой ИТ-организации имеется информация об ИТ-инфраструктуре. Она чаще всего появляется после реализации крупных проектов, которые обычно завершаются проведением аудита и анализом результатов. Главным в работе с такой информацией является поддержание ее в актуальном состоянии. Процесс Управления Конфигурациями помогает получать достоверную и актуальную информацию об ИТ-инфраструктуре. Важным в этой информации является то, что в нее входят данные не только о конкретных единицах конфигурации (Конфигурационных Единицах или CI), но и о том, как они связаны друг с другом. Взаимоотношения и взаимосвязи между Конфигурационными Единицами составляют основу для анализа степени воздействия инцидентов, проблем, изменений и т. д. на ИТ-инфраструктуру. Процесс Управления Конфигурациями проверяет, правильно ли регистрируются изменения в ИТ-инфраструктуре, включая взаимоотношения между Конфигурационными Единицами (CI), и ведет мониторинг статуса ИТ-компонентов чтобы гарантировать наличие точной информации о версиях существующих Конфигурационных Единиц (CIs).

В случае если Управление Конфигурациями реализовано эффективно, то этот процесс может дать информацию о следующем:

§  Финансовая информация и политика компании в отношении продуктов

-  Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на протяжении какого времени?

-  Какие тенденции существуют в разных группах продуктов?

-  Какова текущая и остаточная стоимость ИТ-компонентов?

-  Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?

-  Сколько будет стоить замена определенных компонентов?

-  Какие имеются лицензии и достаточно ли их?

-  Какие контракты на сопровождение следует пересмотреть?

-  Какова степень стандартизации инфраструктуры?

§  Выявление неисправностей и оценка результатов

-  Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвычайной ситуации?

-  Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была изменена Конфигурация Инфраструктуры?

-  Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?

-  Как оборудование подключено к сети?

-  Какие программные модули входят в каждый из комплектов программного обеспечения?

-  Какие ИТ-компоненты затрагиваются изменениями?

-  Какие Запросы на Изменения (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?

-  Какие ИТ-компоненты вызывают известные ошибки?

-  Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого периода?

§  Предоставление услуг и выставление счетов

-  Какие Конфигурации ИТ-компонентов являются существенными для определенных услуг?

-  Какие ИТ-компоненты используются в том или ином месте и кем?

-  Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддерживаются (каталог продуктов)?

Если Управление Конфигурациями применено к информационным системам, а не только к информационным технологиям, то Конфигурационная База Данных (CMDB) может хранить и управлять детальной информацией о пользователях, персонале ИТ-организации и бизнес-структурах. Эти Конфигурационные Единицы также попадают под действие процесса Управления Изменениями, например, при найме и увольнении работников.

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

Разработчики часто используют нечто подобное Конфигурационной Базе Данных для контроля версий всех программных модулей. Некоторые платформы предоставляют такой вид контроля. Конфигурационная База Данных может состоять из нескольких физически раздельных баз данных, которые вместе составляют единое логическое целое. Рекомендуется оптимально интегрировать различные источники Конфигурационных Данных.

He следует путать Конфигурационную Базу Данных со складскими или инвентаризационными базами данных. Такие программы предоставляют только ограниченную информацию о действующем аппаратном и программном обеспечении, сетевых компонентах и компонентах среды. Кроме того, Конфигурационная База Данных (CMDB) демонстрирует, какой должна быть инфраструктура, если все идет по плану (см. также Управление Изменениями), включая документацию. Данные в базе CMDB фактически представляют авторизованную Конфигурацию Инфраструктуры. Список расхождений (дельта) между бухгалтерскими и Конфигурационными Базами Данных является источником ценной информации. Управление Конфигурациями не следует путать с Управлением Активами.

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

§  Управление Конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.

Атрибуты

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

Атрибут	Описание
Номер/метка Конфигурационной Единицы или штриховой код	Уникальный идентификатор Конфигурационной Единицы. Часто это номер, автоматически присваиваемый базой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер
Номер лицензии или серийный номер	Идентификационный номер поставщика в виде серийного номера или номера лицензии
Номер инвентаризационной системы	Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с этой средой
Номер модели/ идентификационный номер Каталога	Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, например, PAT-NL-CT
Наименование модели	Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MHZ
Изготовитель	Изготовитель Конфигурационной Единицы
Категория	Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.)
Тип	Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль
Гарантийный срок	Срок действия гарантии
Номер версии	Номер версии Конфигурационной Единицы
Расположение	Месторасположение Конфигурационной Единицы например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица
Владелец	Имя владельца или лица, ответственного за Конфигурационную Единицу
Дата начала ответственности	Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу
Источник/поставщик	Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика «X» и т. д.
Лицензия	Номер лицензии и ссылка на лицензионное соглашение
Дата поставки	Дата поставки Конфигурационной Единицы в организацию
Дата приемки	Дата приемки Конфигурационной Единицы в операционную среду
Статус (текущий)	Текущее состояние Конфигурационной Единицы, например, «в тестировании», «в работе», «выведено из операционной среды»
Статус (запланированный)	Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий
Стоимость	Стоимость приобретения Конфигурационной Единицы
Остаточная	Текущая стоимость Конфигурационной Единицы с учетом амортизации; амортизационная стоимость
Комментарии	Текстовое поле для комментариев, например, для описания отличий одного варианта от другого

Базисная Конфигурация