Источники:

1.Пресс-релиз ОАО «Связьинвест» от 31.07.2003 г. (http://www.svyazinvest.ru/news/archiv/?id=1299); интервью генерального директора ОАО «Связьинвест» Валерия Яшина информационному агентству «Рейтер» от 31.05.2004 г. (http://www.svyazinvest.ru/press/archiv/?id=2656).

2. Plitch P. A piece of the action // The Wall Street Journal. 27.10.2003 (http://webreprints.djreprints.com/866680686146.html).

3. Подробнее см. Койн К., Субраманиам С. Дисциплина стратегии // Вестник McKinsey. — 2002. — № 1. — С. 33—45 (http://www.vestnikmckinsey.ru).

4. Удалов Д.А. «Методические рекомендации по количественной оценке состояния корпоративного управления». //«Журнал Финансы и кредит». - 27(411) - 2010г.

5. Бухвалов А. В. Корпоративное управление как объект научных исследований // «Российский журнал менеджмента». — 2005. — Т. 3, № 3. — С. 81−96.

6. Shleifer A., Vishny R. A Survey of Corporate Governance // Journal of Finance. — 1997. — Vol. 52, No. 2, — Pp. 737−783.

7. Tirole J. Corporate Governance // Econometrica. — 2001. — Vol. 69, No. 1. — Pp. 1−35.

8. Критерии, методология, определения анализа и оценки корпоративного управления GAMMA Standard & Poor's

______________

Материалы предлагаются для использования внедрением в различных учебно-творческих лабораториях отдела Технического творчества МГДД(Ю)Т в качестве ознакомительных в составе дополнительных развивающих материалов ОМК соответствующих образовательных программ с целью ознакомления всех участников и активистов системы НТТМ с существующими подходами и методологией корпоративного менеджмента на основе рейтингования (что весьма эффективно также в постановке и развитии системы НТТМ).

Метрики информационной безопасности в проектах нттм

В.В. Голубев, В.В. Шепелев, практиканты, магистранты каф. КП РЭС

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

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

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

Риски - это один из ярких примеров, такой проблемы. Термин “риск информационной безопасности” часто встречается, но в редких случаях имеет количественную (оценку) характеристику. В качестве примера рассмотрим риски в двух системах. Риски в “Системе 1” составляют 100 баллов, а риски в “Системе 2” 400 баллов, таким образом, понятно, то, что последняя, нуждается в пристальном внимании и принятии соответствующих мер по уменьшению рисков или минимизация связанных с ними негативных последствий.

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

Сложность заключается в выборе метрик, что именно надо отслеживать и как их формулировать. Кроме этого метрики должны быть воспроизводимыми. Это значит, что при одном и том же наборе исходных данных и, используя одни и те же средства, разные люди должны получить одинаковый результат. По возможности, метрики не должны зависеть от субъективных решений экспертов. Более того, надо помнить, что метрики надо высчитывать и поэтому не нужно без особой необходимости усложнять для них формулы, особенно в тех случаях, когда часто происходит их оценка. Для получения лучшего результата надо избегать качественных значений метрик, и стараться перейти к количественному выражению – объективно отражает ситуацию. Не стоит забывать, что правильно сформулированные метрики должны выражаться в единицах измерений, связанных с их применением, например: денежные единицы – рубли, доллары, количественные – штуках и.т.д. Применение дополнительного параметра измерения, в таких случаях часто использует время, что позволит получить более информативную и наглядную оценку. Например “количество корректирующих действий за месяц” или “ количество рекламаций за квартал”.

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

Так сложилось, что для метрик в ИТ, не достаточно часто используют статистику. Обычно все описывается выражением вида “в прошлом квартале было меньше сбоев в работе, чем в текущем”, что, конечно же, не очень продуктивно.

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

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

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

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

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

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

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