Федеральное агентство по образованию Российской Федерации

Новосибирский государственный университет экономики и управления

Кафедра прикладных информационных технологий

Теоретическая часть курсовой работы

Дисциплина: «Управление эффективностью информационных систем»

Тема: «Бюджетирование процессов информационной безопасности на предприятии»

Выполнил: студент 5 курса гр. 5095

Мочалов В.Ю.

Проверил: Пашков П.М.

Новосибирск 2009

СОДЕРЖАНИЕ

Теоритическая часть

СОДЕРЖАНИЕ.. 2

ВВЕДЕНИЕ.. 4

1. ЦЕЛИ БЮДЖЕТИРОВАНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ НА ПРЕДПРИЯТИИ. 5

1.1 Выбор инструмента для реализации системы бюджетирования . 5

1.2 Создание или оптимизация системы финансового планирования и бюджетирования 12

2. ЗАДАЧИ БЮДЖЕТИРОВАНИЯ.. 17

2.1 Проведение аудита ИБ .. 17

2.2 Оценка текущего уровня ТСО Информационных систем и систем защиты .. 19

2.3 Формирование целевой модели предприятия . 26

2.4 Бюджетирование . 27

2.5 Расчет ROI . 29

3. ФАКТОРЫ, ВЛИЯЮЩИЕ НА БЮДЖЕТИРОВАНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ НА ПРЕДПРИЯТИИИ.. 31

3.1. Экономические факторы .. 31

3.2. Не экономические факторы .. 33

ЗАКЛЮЧЕНИЕ.. 35

Расчетная часть

1. ПОСТАНОВКА ЗАДАЧИ.. 36

1.1. Характеристика предприятия и описание бизнес-проблемы.. 36

1.2. Цели и задачи информационной системы.. 36

1.3. Описание компонентов информационной системы.. 37

2. ОЦЕНКА ПРЯМЫХ ТРУДОЗАТРАТ НА РАЗРАБОТКУ ИС.. 42

2.1. Оценка размера программной системы с помощью функционально-ориентированных метрик 42

2.2. Оценка трудозатраты на основе конструктивной модели стоимости COCOMO II для этапа «композиция приложений». 43

2.3. Оценка трудозатраты на основе конструктивной модели стоимости COCOMO II для этапа «Раннего проектирование». 46

3. ОЦЕНКА ЭФФЕКТА ОТ ВНЕДРЕНИЯ ИС.. 49

3.1. Определение центров затрат в модели бизнес-процессе. 49

3.2. Модели бизнес-процесса (AS-IS) и (TO-BE) 51

3.3. Функционально-стоимостной анализ моделей бизнес-процесса (AS-IS) и (TO-BE) 58

4. ОЦЕНКА ЭФФЕКТИВНОСТИ ПРОЕКТА.. 62

4.1. Ввод финансовых параметров проекта. 62

4.2. Ввод ресурсов и сформирование календарного плана. 63

4.3. Определение источников финансирования. 64

4.4. Формирование поступлений от проекта (эффект) 65

4.5. Ввод затрат на управление и производство. 65

4.6. Расчёт финансовых отчётов и показателей эффективности. 67

4.7. Заключение о выгодности проекта. 69

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ... 72

ПРИЛОЖЕНИЕ 1. 74

ПРИЛОЖЕНИЕ 2. 82

ВВЕДЕНИЕ

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

Курсовая работа была начата с поиска соответствующей литературы по теме и создания списка литературы. После этого была составлена таблица понятий и терминов (ПРИЛОЖЕНИЕ 1), использующихся в найденной литературе. Закончив с таблицей понятий и терминов, была составлена ментальная карта (ПРИЛОЖЕНИЕ 2) и подобраны иллюстрации, после чего написан текст реферата и подготовлена презентация и доклад. В процессе работы над данной курсовой работой каждый из артефактов приходилось уточнять и дополнять практически на каждой стадии работы.

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

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

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

1. ЦЕЛИ БЮДЖЕТИРОВАНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ НА ПРЕДПРИЯТИИ.

1.1 Выбор инструмента для реализации системы бюджетирования

Под инструментом понимается тот или иной программный продукт, который будет использоваться для бюджетирования[3]. С точки зрения функциональности, на сегодняшний день программные продукты, которые используются для бюджетирования, можно разделить на три класса.

1-й класс - это условно "жесткие" системы, в которых уже запрограммирован основной алгоритм бюджетирования[3]. Для начала работы с системой требуется только ввести исходные данные. Преимущество таких систем заключается в том, что вам не надо задумываться о том как реализуется система планирования. Все алгоритмы уже заложены, и их тяжело изменить. Одновременно это является и недостатком, если у вас возникнет изменение в учетной политике и окажется, что система не позволяет внести изменения, то вам придется обратиться к разработчику.

2-й класс - "гибкие" системы[3]. Это относительно новые для российского рынка системы, однако их популярность растет очень быстро. Основные преимущества "гибких" систем:

· такие системы позволяют работать большому количеству пользователей одновременно в режиме реального времени;

· совместная работа по планированию деятельности удаленных территориально подразделений облегчается за счет использования современных интернет-технологий;

· системы обладают возможностью хранения и обработки больших объемов данных;

· система конструктора позволяет настроить программный продукт под нужды практически любого предприятия;

· использование технологии OLAP позволяет получать отчеты любой формы и содержания;

· системы позволяют делать импорт и экспорт данных из различных баз данных, электронных таблиц, учетных программ и т.д.;

· системы позволяют добавлять и удалять записи (продукты, отделы, виды сырья и пр.), что достаточно тяжело реализуется в электронных таблицах;

· системы обладают большим набором встроенных функций, специально настроенных для решения задач планирования;

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

3-й класс - это абсолютно гибкие программные продукты[3], целью которых не является решение задач бюджетирования, но которые для этого очень часто используются. К таким программным продуктам относятся MS Excel, MS Access. К числу достинств использования для бюджетного планирования этих приложений MS Оffice можно отнести разве что их доступность и относительную простоту для подготовленного пользователя. На начальных этапах становления системы бюджетирования на предприятии как правило, этого оказывается вполне достаточно. Существенные недостатки использования для целей планирования офисных приложений:

· Отсутствует возможность совместной работы большого количества пользователей

· Для MS Excel - отсутствует возможность хранения больших объемов данных (до 250 знаков в одной ячейке)

· Существует вероятность случайного изменения формул и связей между ячейками и листами (массивами данных)

· Возможно создание только двухмерных массивов данных

· Количество встроенных финансовых функций весьма ограничено.

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

Перейдем непосредственно к выбору. На рисунке 1 представлено процентное соотношение внедренных систем бюджетирования[3] и опишем некоторые из них.

Рис.1.[3] Процентное соотношение кол-ва внедрений систем бюджетирования по состоянию на конец 2005 года

Программные продукты для систем бюджетирования:

· Cognos Planning 7.1 (Cognos)

· Active Planner (Epicor Software)

· Hyperion (Hyperion)

· Corporate Planner (Corporate Planning)

· Comshare MPC (Comshare)

· PlanDesigner (Softprom)

· МАСТЕР ФИНАНСОВ: Бюджет предприятия (КГ "Воронов и Максимов")

Cognos Planning 7.1 . Разработчик: Cognos

Продукт является одним из наиболее известных в мире. В данный момент он активно внедряется в Европе, в том числе и в России. Решение Cognos Planning 7.1 позволяет компании устранить информационные пробелы и обеспечивает всех участников процесса планирования возможностями для эффективного сотрудничества, используя соответствующие технологию и терминологию.

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

Cognos Planning 7.1 состоит из модулей, каждый из которых выполняет свою задачу:
1. Analyst - главный вычислительный блок программы. В нем строится модель бюджетирования и осуществляется планирование деятельности. Используя модуль Analyst, пользователи могут с лёгкостью произвести оценку финансовых моделей, изменить и протестировать имеющиеся предположения, и полностью осмыслить запланированные показатели. Основными элементами модуля являются следующие: D-List (одномерный список), D-Cube (образуется путем объединения листов и представляет собой многомерный куб, более всего он напоминает кубик Рубика с большим количеством измерений) и D-Link (связывает кубы между собой). Особое преимущество данного блока - это простота в работе и наличие большого количества встроенных финансовых функций. Кроме этого в нем существуют специальные инструменты, которые позволяют делать прогнозирование по различным принципам, осуществлять поиск ошибки, распределять данные с учетом сезонности и т.д.

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

Active Planner . Разработчик: Epicor Software

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

Hyperion . Разработчик: Hyperion

В общих чертах, схема работы выглядит так: Менеджер центра учета (планировщик) заполняет предлагаемые ему формы, прогнозируя поступления и перечисляя запланированные затраты. Описание начинается от каждого отдельного элемента, с указанием физических объемов, взаимосвязей между различными типами поступлений и издержек, далее данные объединяются программой в бюджет центра и в таком виде становятся доступны менеджеру верхнего уровня (консолидатору). Тот собирает бюджет на своем уровне уже не из отдельных затрат или поступлений, а из бюджетов нижестоящих центров и т.д. В результате получается не просто фиксированный, пусть даже и в разных вариантах, прогноз, а динамическая модель компании, в которой за каждый уровень модели отвечают руководители соответствующих подразделений и выстроена строгая технология внесения изменений. Положительные результаты очевидны - динамическая модель даст многократную экономию времени и снижение числа ошибок при корректировке бюджета, а это и является основной задачей внедрения подобных систем. Проблема только в том, что внедрение таких решений обязательно требует существенно большей аккуратности при реализации и использовании, а значит понадобится не только дополнительное обучение персонала, но и усилия по поддержанию определенного уровня дисциплины в вопросах подготовки бюджетов. Интерфейс на уровне работы с бюджетом хорош. Красиво и не слишком путано. На уровне ввода данных по отдельным пунктам немного хуже, - к сожалению, не предусмотрено ничего, что помогло бы работать эффективнее (групповое заполнение данных и т.д.), хотя это логично следовало бы из структуры программы. При задании связей между элементами бюджета приходится работать с немного перегруженными информацией диалогами, но это все же лучше, чем задавать формулы, как приходится поступать в решениях, собранных на электронных таблицах. Вообще есть такое ощущение, что интерфейс стабилизировался несколько лет назад и с тех пор не слишком менялся. Система тесно интегрирована с другими продуктами Hyperion: Enterprise и Essbase OLAP Server, Reporting. О других системах ничего не говорится, судя по всему, интеграция с ними возможна, но только через Essbase OLAP Server. При работе без Essbase информация хранятся в файлах и базы данных не используются, т.е. при внедрении крупных проектов с распределенной работой использование Essbase очень желательно.

Corporate Planner . Разработчик: Corporate Planning

Весь бюджет в системе строится на дереве, описывающем структуру затрат компании. Каждому узлу на этом дереве соответствует табличка из трех строк: плановые значения, фактические и их рассогласование. Между узлами дерева могут задаваться связи (с помощью формул, похожих на формулы в электронных таблицах). Судя по функционалу, Corporate Planner ориентирован на средние предприятия. Это же подтвердили и представители компании, которые, сравнивая свою программу с Hyperion Pillar, сказали, что наиболее крупные пользователи Corporate Planner примерно соответствуют наиболее мелким пользователям Pillar'а. Интерфейс продуман хорошо, начиная от работы дерева издержек и до графического отображения результатов. В этом, собственно, основной плюс системы - все очень красиво и аккуратно, создается ощущение цельности решения. Возможности интеграции довольно бедные - можно только импортировать файлы через ODBC. Другое ограничение, не позволяющее использовать Corporate Planner в крупных компаниях - отсутствие средств разделения доступа и распределенной работы. Этот продукт ориентирован на рабочее место финансового менеджера, а не на создание единого процесса бюджетирования.

Comshare MPC . Разработчик: Comshare

Если рассматривать весь набор компонент, то Comshare MPC охватывает задачи бюджетирования, организации групповой работы и поддержки принятия решений, а также генерацию управленческой отчетности. В основе функциональных возможностей этого комплекса лежит OLAP-система, все функциональные элементы являются расширениями этой системы. В результате, с одной стороны, Comshare MPC предлагает достаточно высокий уровень гибкости и масштабируемости, с другой стороны, возможности построения пользовательского интерфейса и хранения данных ограничены принципами, заложенными в OLAP. Общий объем функционала слишком велик для того, чтобы задерживаться на отдельных функциях. Как и у других лидеров рынка, в системе реализованы, с теми или иными особенностями, все основные операции, связанные с поддержкой бюджетного управления. Хотя система имеет облегченные варианты, рассчитанные на быстрое внедрение в небольших компаниях, основным считается именно "корпоративный" вариант, причем российский представитель Comshare предлагает только его, т.е. система ориентирована на средние и крупные предприятия. Система имеет веб-интерфейс, построенный на основе приложений Java. Это несколько утяжеляет ее (повышаются требования к сети, клиентским компьютерам), но помогает частично избавиться от крайне бедного оформления, присущего веб-интерфейсам. Графические представления весьма разнообразны, используются нестандартные средства отображения данных. Из наиболее существенных моментов, связанных с технологиями, можно отметить то, что Comshare MPC интегрирована со многими ведущими корпоративными системами. Средним компаниям может быть также интересна интеграция с такими легкими системами как 1С:Бухгалтерия - это уже также предлагается внедренцами в России. Очевидно, что клиент-серверная система, с OLAP, мощными средствами настройки и т.п. не может быть быстро установлена своими силами, она предполагает внедрение, по масштабам почти не отличающееся от внедрения небольших ERP-систем (стандартная методология разработчика предполагает внедрение за 2 месяца).

PlanDesigner .

PlanDesigner - российский аналог широко распространённых в Европе систем бюджетного планирования. В данный момент он активно внедряется в России. В Петербурге PlanDesigner предлагает КГ "Воронов и Максимов". PlanDesigner обеспечивает полную автоматизацию важнейших этапов бюджетного процесса: Планирования , Контроля и Анализа отклонений , Регулирования и создания самых разнообразных, в том числе экзотических моделей прогнозирования и планирования. Основными элементами программы являются измерения, кубы и связи. Измерение - аналитический срез, в рамках значений которого происходит реальное изменение целевого бюджетного факторах[3]. Технически это список простых и вычисляемых значений объединенных семантическим содержанием. Существует ряд "стандартных" бизнес-измерений для процессов бюджетирования, таких как Время , Накладные расходы, Прибыли и Убытки, Статьи Баланса, Подразделения и т.д. Однако при создании конкретных бюджетных моделей, как правило, существует необходимость создания специфических измерений. Куб - многомерная матричная форма, которая создается путем объединения измерений. Может использоваться в любых сочетаниях в качестве формы ввода, области расчетов и отчетной формы. Связь - механизм передачи данных между измерениями как внутри куба, так и между кубами в рамках Бюджетной модели.

Основные возможности PlanDesigner:

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

2. Cистема поддерживает многопользовательский интерфейс внутри локальной сети. Количество пользователей практически неограниченно.

3. Система предусматривает динамическое управление правами доступа к редактированию и просмотру информации самими участниками бюджетного планирования без привлечения Администратора. Для этого используются так называемые семафоры , которые позволяют заранее определённому пользователю переводить процесс управления правами доступа на следующий уровень путём простого нажатия кнопки.

4. Продукт предусматривает возможность контроля выполняемых пользователями действий через "аудит" - систему мониторинга действий пользователей в системе.

5. Встроенная функция Drill Down позволяет легко определить источник возникновения того или иного значения.

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

7. PlanDesigner позволяет производить так называемые обратные расчёты, которые разбивают итоговую сумму по слагаемым в соответствии с заранее заданными пропорциями и функциями. Это позволяет легко проводить многомерный анализ воздействия изменений параметров на целевую функцию. Задавая желаемый уровень целевой функции, можно получить план производства с разбивкой по всем подразделениям, видам платежа и другим параметрам в соответствии с заданными ограничениями.

1.2 Создание или оптимизация системы финансового планирования и бюджетирования

В общем случае решение задачи бюджетирования и финансового планирования на предприятии можно разделить на две части:

1. Построение или оптимизация системы финансового планирования и бюджетирования;.
2. Выбор инструмента для реализации построенной системы.

Между построением и оптимизацией чаще выбирают построение системы, что видно из статистики на рисунке 2.

Рис.2.[3] Построение и оптимизация системы бюджетирования.

Построение или оптимизация системы финансового планирования и бюджетирования - это достаточно трудоемкий процесс, который можно разбить на несколько этапов[3]:

· Составление стратегического плана(цели на долгосрочный период).

· Описание системы "как есть"(описание системы бюджетирования, которая уже существует на предприятии[3]).

· Выявление недостатков(этап, на котором выявляются все недостатки существующей системы и определить то, что в ней нужно улучшить[3])

· Определение необходимых изменений и их обоснование(На данном этапе определяется, что необходимо для осуществления изменений, определенных на этапе "Выявление недостатков"[3]).

· Построение системы "как надо"(формирование новой системы, которая будет лишена всех недостатков предшественницы[3]).

· Внедрение системы(Внедрение системы включает в себя комплекс работ по реализации задуманной системы в жизнь[3]).

· Эксплуатация(На этом этапе начинается непосредственно эксплуатация новой системы, выявление ее ошибок и их устранение[3]).

- Составление стратегического плана

"Кто не знает, в какую бухту он плывет, для того нет попутного ветра"
Сенека

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

- Описание системы "как есть"

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

- Выявление недостатков

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

- Определение необходимых изменений и их обоснование

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

- Построение системы "как надо"

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

- Внедрение системы

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

- Эксплуатация

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

2. ЗАДАЧИ БЮДЖЕТИРОВАНИЯ

2.1 Проведение аудита ИБ

Одной из задач бюджетирования является проведение аудита информационной безопасности. Основная цель проведения комплексного аудита информационной безопасности являются получение реальной и независимой оценки текущего состояния уровня информационной безопасности Заказчика[6]. Кроме этого, материалы аудита являются информационно-аналитической базой для разработки Концепции и политик информационной безопасности.

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

Проведение аудита разделяется не следующие этапы работ:

· Сбор исходных данных об информационной системе предприятия, функций и особенностей, об используемых технологиях автоматизированной обработки и передачи данных (с учетом ближайших перспектив развития);

· Сбор информации об имеющихся организационно-распорядительных документах по обеспечению информационной безопасности и их анализ;

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

· Формирование перечня подсистем ИС каждого подразделения предприятия - заказчика с категорированием критичной информации и схемами информационных потоков;

· Подготовка предложений по совершенствованию системы обеспечения информационной безопасности.

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

Аудит информационной безопасности

Аудит информационной безопасности представляет собой ряд мероприятий, которые включают исследование всех аспектов обеспечения информационной безопасности в компании, а также проводимый независимыми экспертами по согласованному с Заказчиком плану аудит, основывая данные работы на выбранных методиках и критериях[6].

Аудит информационной безопасности позволяет установить, соответствует ли уровень безопасности ИТ-инфраструктуры предприятия указанным требованиям, обеспечивается ли необходимый уровень конфиденциальности, целостности и доступности ресурсов информационной системы. В общем виде комплексный аудит представлен схемой на рисунке 3.

Рис.3.[6] Комплексный аудит Информационной безопасности.

2.2 Оценка текущего уровня ТСО Информационных систем и систем защиты

TCO (Total Cost of Ownership - совокупная стоимость владения) - методика определения наилучшего соотношения цена/качество[2], разработанная компанией Gartner. Критериями оценки являются стоимость приобретения, администрирования, установки, перемещения и модернизации, технической поддержки и сопровождения, вынужденных простоев и других скрытых затрат. Методика позволяет учитывать внепроизводственные затраты, такие как внеслужебное использование оборудования и ПО. Однако, с другой стороны, TCO не учитывает риски и не позволяет соотнести технологию со стратегическими целями бизнеса.

Общая стоимость владения компьютерной техникой (Total Cost of Ownership)

· Основные проблемы ИТ

· Составляющие ТСО

· Составляющие ТСО

Общая стоимость владения складывается из прямых затрат на покупку оборудования и косвенных затрат, связанных с его обслуживанием[2].

Основные проблемы ИТ:

· Непонимание роли ИТ в структуре организации

· Принятие решений о закупке некомпетентными сотрудниками

· Короткий горизонт планирования развития ИТ

· Желание сэкономить на ИТ

Как использовать ТСО

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

Существуют два наиболее наглядных варианта оценки подобного проекта. Первый – сравнение ТСО уже реализованных аналогичных решений[2]. Второй основан на сравнении ТСО решений, предлагаемых разными исполнителями или созданными на базе разных продуктов. Выбор конкретного способа оценки TCO всегда остается за ИТ-руководителем или менеджером проекта. Заметим, что в обоих случаях следует по возможности сравнивать те решения, что развернуты на предприятиях той же отрасли, в которой работает заказчик проекта.

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

Кроме того, статистический материал нуждается в постоянном обновлении. Даже при наличии необходимых данных может оказаться, что для расчета показателей ТСО использовались различные методики, учитывающие затраты в разном объеме (единой-то методики пока нет!), данные будут несопоставимы между собой, а следовательно, ни о каком объективном сравнении не может быть и речи.

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

Как считать

Методика определения ТСО изначально была выдвинута исследовательской компанией Gartner Group в конце 80-х годов. После введения данного термина компания Interpose совместно с Microsoft предложили новую основанную на ТСО модель анализа использования ИТ, которая подразумевает разбиение затрат на прямые (бюджетные) и косвенные:

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

Соотношение прямых и косвенных расходов показаны на рисунке 4.

Рис.4.[2] Соотношение прямых и косвенных затрат.

Для сравнения возможных вариантов реализации проекта имеет смысл ввести показатель «точки безразличия»[2], определяющий, через сколько лет ТСО одного и того же проекта для двух различных вариантов его реализации станут равны. В дальнейшем этот срок сравнивается со сроком функционирования проекта. Косвенные расходы, хотя и могут играть весьма существенную роль при выборе варианта реализации проекта (особенно при проектировании информационных систем и организации технической поддержки), часто находятся за рамками бюджетов на информационные технологии. Причина этого кроется в трудности их подсчета.

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

Вторая группа – расходы, зависящие от восприятия нововведений персоналом компании.[2] Так, из-за ненадлежащей поддержки со стороны штатных сотрудников ИТ-подразделений, пользователи внутри компании могут быть вынуждены заниматься вопросами восстановления работоспособности системы, самообучением и т. д., что также уменьшит производительное время их работы.

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

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

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

Крупный проект и модернизация

Внедрение крупных проектов обычно происходит поэтапно. Достаточно часто на этапе принятия решения рассматривается несколько вариантов реализации проекта. Такое случается, когда бюджет проекта ограничен, или когда клиент хочет оценить масштабы и целесообразность реализации проекта «на практике». При внедрении крупных проектов варианты реализации могут становиться этапами проекта.

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

При модернизации системы также возникает ряд вопросов, ответы на которые могут повлиять на ТСО. Необходимо понять, позволит ли старое оборудование в случае обновления системы частично компенсировать затраты на модернизацию; как сложно и как долго будет происходить демонтаж оборудования, замена программных средств и установка новых, и какие дополнительные средства на демонтаж потребуются; а также вся ли система должна быть подвергнута обновлению, то есть позволит ли, например, старое оборудование осуществить установку нового программного обеспечения[8].

Кроме того, в затратах на модернизацию необходимо учитывать и расходы на реконструкцию либо ликвидацию старого оборудования. Модернизация системы – дополнительный фактор, влияющий на выбор исполнителя.[2]

Что нужно учитывать помимо ТСО

При принятии решения о реализации проекта, помимо оценки ТСО, необходимо учесть многие другие качественные и количественные показатели: технологические, управленческие, кадровые и финансовые. Минимальное значение ТСО не всегда пойдет на пользу как конкретному проекту в частности, так и бизнесу в целом. Определение ТСО является лишь экономической оценкой, то есть одним из этапов комплексной оценки проекта по принципу «цена – качество»[2]. Некоторые параметры, прямо или косвенно влияющие на ТСО, придется оценивать экспертным путем.

Прямые расходы

Статьи прямых расходов можно разделить на следующие группы:

Единовременные расходы [2]:

Расходы на консультационные услуги со стороны поставщиков и интеграторов. К сожалению, они зачастую не учитываются при оценке ТСО решения, несмотря на то, что стоимость и важность проведения консультационных услуг растут год от года. Кроме того, от результатов работы консультантов напрямую будет зависеть выбор средств автоматизации, а значит, и затраты на их приобретение. Капитальные расходы: покупка необходимого оборудования, приобретение (покупка или разработка) программного обеспечения, расходы на их доставку и установку. Расходы на управление внедряемой системой: расходы на проектирование (разработка схем устройств, политики функционирования системы); на администрирование или сопровождение (изменение локальных политик функционирования системы, обновление аппаратных платформ и т. д.); на расширение системы. Расходы на интеграцию нового решения в уже существующую корпоративную систему - очень важная статья расходов, которая также обычно не учитывается. Расходы на обучение обслуживающего персонала. Командировочные и прочие расходы, совершаемые для запуска проекта.

Ежегодные расходы [2]:

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

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

Следует учесть

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

Чем больше планируемый срок функционирования проекта, тем важнее оценка ежегодных затрат по сравнению с единовременными, и наоборот (со временем доля ежегодных затрат в общем показателе ТСО увеличивается, и для долгосрочных проектов именно размер ежегодных затрат играет решающую роль). Следует помнить о возможной модернизации. При проведении начальной оценки ТСО можно предположить, что общий срок функционирования системы будет совпадать со сроком ее функционирования до первой модернизации.
В предложенном методе расчета ТСО не учитывается такой экономический показатель, как коэффициент дисконтирования[6], смысл которого сводится к тому, что "расходы, совершенные сегодня, дороже расходов, совершенных завтра". При более детальном расчете ТСО в долгосрочной перспективе стоит вспомнить и об этом коэффициенте.
Учет косвенных издержек возможен как "вторая итерация" или "второй фильтр" при выборе поставщика. Определение косвенных расходов, скорее всего, потребует экспертной оценки. Экспертом может выступать как сотрудник организации заказчика, имеющий соответствующую квалификацию, так и привлеченный со стороны исполнитель.
Полученное значение показателя ТСО может подвигнуть к пересмотру состава решения и проведению дополнительной оценки функциональности используемого аппаратного и программного обеспечения.
Таким образом, чтобы оптимизировать процесс выбора исполнителя проекта вместо широкого спектра параметров можно использовать оценку проекта с технической точки зрения (функциональность), ТСО проекта (в разрезе прямых единовременных и ежегодных затрат); возможные косвенные затраты по проекту и затраты на модернизацию системы.

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

2.3 Формирование целевой модели предприятия

Руководство предприятия должно сформулировать свои цели на долгосрочный период. Причем должно быть четко зафиксировано, каких целей и когда желает достичь предприятие[13]. Это первый необходимый этап, который воплощает в себе стратегию предприятия. После него можно переходить на более низкие уровни.

В построении целевой модели может помочь анкетирование или опрос лиц, работающих на предприятии и дальнейшее объединение целей т.е. формирование общей направленности деятельности предприятия[10]. Целевая модель может формироваться и другими способами, на рис.5 приведена примерная схема, которая может помочь в построении модели.

Рис.5.[13] Построение целевой модели предприятия.

2.4 Бюджетирование

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

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

· разработку ключевых показателей деятельности предприятия в соответствии с его стратегическими целями;

· разработку (корректировку) финансовой структуры;

· определение видов и форм бюджетов, их взаимосвязей, принципов консолидации (разработка регламента бюджетирования[11]);

· разработку основного бюджета - Финансовое, количественно определенное выражение маркетинговых и производственных планов, необходимых для достижения поставленных целей;

· Разработку Финансового бюджета(Инвестиционный, кассовый и балансовый бюджет);

· Формирование модели бюджетного управления[13] - кросс-функционального процесса, задействующего все службы предприятия, изменяющего ментальные модели сотрудников;

· Контроль за расходами и доходами(денежными средствами, поступающие в безвозмездном и безвозвратном порядке) ;

· определение схем внутреннего документооборота;

· Контроль за исполнением бюджета[11] - получения доходов и осуществления расходов, предусмотренных в утвержденном бюджете. В ходе исполнения бюджета могут наблюдаться отклонения от принятого варианта, в связи с чем необходимо контролировать и регулировать процесс исполнения.

Для выполнения многих задач можно использовать специализированное ПО(рис.6).

Рис.6.[14] ПО для прогнозирования бюджета.

2.5 Расчет ROI

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

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

ROI - отношение среднего увеличения прибыли к объёму инвестиций[1]. Срок окупаемости инвестиций - метод оценки инвестиционных проектов, когда важнейшим критерием выступает продолжительность срока (период окупаемости), в течение которого возвращаются первоначальные затраты[4]. При этом предполагается, что все последующие доходы представляют собой чистую прибыль.

ROI = ((чистая прибыль за 1 год + чистая прибыль за 2 год + чистая прибыль за 3 год) / 3 / капитальные затраты) × 100.[1]
Для расчетов ROI используются данные о стоимости:
- программного обеспечения и поддержание его в рабочем состоянии;
- аппаратного обеспечения, с учетом амортизации и обслуживания;
- персонала;
- консалтинга, при условии использования внешних консультантов;
- обучения персонала;
- других связанных с проектом мероприятий.
На рис.6 показан рост ROI в зависимости от длительности существования предприятия.

Рис.6.[1] Рост ROI в зависимости от длительности существования предприятия.

3. ФАКТОРЫ, ВЛИЯЮЩИЕ НА БЮДЖЕТИРОВАНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ НА ПРЕДПРИЯТИИИ

3.1. Экономические факторы

Информационная Безопасность, как и её Бюджетирование зависит от многих факторов и многие компании пренебрегают финансированием(рис.8), тратя на защиту информации менее 5% бюджета ИТ. Кроме того, все предприятия выбирают различные способы защиты, поэтому у каждой компании разное кол-во затрат(рис.7).

Рис.7.[3] Популярные средства ИТ-Безопасности.

Совокупная стоимость[3] владения для системы ИБ, в общем случае, складывается из стоимости:
- Проектных работ;
- Закупки и настройки программно-технических средств защиты, включающих следующие основные группы: межсетевые экраны, средства криптографии, антивирусы и AAA (средства аутентификации, авторизации и администрирования);
- Затрат на обеспечение физической безопасности;
- Обучения персонала;
- Управления и поддержки системы (администрирование безопасности);
- Аудита ИБ;
- Периодической модернизации системы ИБ;

Рис.8.[2] Процент расходов на защиту информации в ИТ.

3.2. Не экономические факторы

При применении экономических методов анализа эффективности инвестиций в ИБ для аргументации принятия тех или иных решений, необходимо помнить, что существуют и другие «неэкономические» факторы, в частности:

- Структура организации и особенности системы управления;
- Осведомленность и вовлеченность руководства в вопросы развития ИТ. От этого зависит и количество бюджетных ассигнований. Статистика ассигнований на ИТ от ассигнований на ИБ показана на рисунке 9;

Рис.9.[2] Бюджетные ассигнования на ИТ, млрд. долларов.

- Особенности стратегии и автоматизации организации. Большинство предприятий мало автоматизированы(рис.10);
- Позиции руководства отделов ИТ и ИБ в компании;
- Роль ИТ в производственном процессе;
- Случившиеся инциденты в области ИБ с тяжелыми последствиями.

Рис.10.[4] Автоматизация предприятий в процентном соотношении.

ЗАКЛЮЧЕНИЕ

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

1. ПОСТАНОВКА ЗАДАЧИ

1.1. Характеристика предприятия и описание бизнес-проблемы

В качестве объекта автоматизации рассматривается провайдер «Большие Сети» .

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

· доступ в интернет

· хостинг

· E-mail

· Корпоративный доступ в интернет

· Доступ в интернет по выделенным высокоскоростным линиям связи

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

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

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

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

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

1.2. Цели и задачи информационной системы

Цель - создание автоматизированного комплекса работ по управлению систем обработки информации в области информационной безопасности провайдера для более эффективной его работы.

Задачи:

· Отслеживание изменений в составе активов;

· Выявление и обработка угроз и уязвимостей;

· Оценка и обработка рисков;

· Формирование конкретных методов и средств защиты;

· Формирование критериев оценки безопасности;

Данная информационная система должна:

1. Поддерживать ведение справочников активов, уязвимостей, угроз, рисков, критериев оценки безопасности (КОБ), методов/средств, сотрудников, отделов.

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

1.3. Описание компонентов информационной системы

Справочники:

Для реализации данной задачи необходимо вести следующие справочники:

1. Справочник «Актив» - предназначен для фиксирования информации обо всех имеющихся активах организации. Ведется специалистом по управлению рисками после появления новых или изменения информации об уже сущетсвующих. Уровень сложности – низкий.

Актив (ИД_Актива, ИД_Сотрудника, ИД_Отдела, Наименование, Описание)

2. Справочник «Метод/средство» - предназначен для фиксирования информации обо всех методах и средствах, применяемых для защиты активов организации от выявленных угроз и уязвимостей. Ведется системным аналитиком после выявления новых или изменения информации об уже сущетсвующих. Уровень сложности – низкий.

Метод/средство (ИД_Метода/средства, ИД_Актива, ИД_Риска, ИД_Сотрудника, ИД_Отдела, Наименование, Описание)

3. Справочник «Отдел» - предназначен для фиксирования информации обо всех отделах организации. Ведется руководством после появления нового отдела или изменения информации о существующем. Уровень сложности – низкий.

Отдел (ИД_Отдела, Наименование, Деятельность, Количество сотрудников)

4. Справочник «Сотрудник» - предназначен для фиксирования информации обо всех сотрудниках организации. Ведется отделом кадров после появления новых сотрудников или изменения личной информации о существующих. Уровень сложности – низкий.

Сотрудник (ИД_Сотрудника, ИД_Отдела, Фамилия, Имя, Отчество, Паспортные данные, Телефон, Должность, Руководитль)

5. Справочник «Угроза» - предназначен для фиксирования информации обо всех угрозах, воздействующих на активы организации. Ведется специалистом по управлению рисками после появления новых или изменения информации о существующих. Уровень сложности – низкий.

Угроза (ИД_Угрозы, ИД_Актива, ИД_Сотрудника, ИД_Отдела, Наименование, Описание)

6. Справочник «Уязвимость» - предназначен для фиксирования информации обо всех уязвимостях, воздействующих на активы. Ведется специалистом по управлению рисками после появления новых или изменения информации о существующих. Уровень сложности – низкий.

Уязвимость (ИД_Уязвимости, ИД_Актива, ИД_Сотрудника, ИД_Отдела, Категория, Наименование, Описание)

7. Справочник «Риск» - предназначен для фиксирования информации обо всех рисках, выявленных на основе анализа угроз и уязвимостей, действующих на активы. Ведется специалистом по управлению рисками фирмы после их оценки и обработки. Уровень сложности – низкий.

Риск (ИД_Риска, ИД_Угрозы, ИД_Уязвимости, Наименование, Описание)

8. Справочник «КОБ» - предназначен для фиксирования информации обо всех критериях оценки безопасности организации, сформированных разработчиком ПУИБ после оценки рисков. Уровень сложности – низкий.

КОБ (ИД_ КОБ , ИД_Уязвимости, Наименование, Описание)

Отчеты:

В данном приложении должны формироваться следующие отчеты:

1. Отчет «Об оценке уязвимостей» (список уязвимостей, определяемых на основе анализа ИС). Уровень сложность – низкий.

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

3. Отчет «Об оценке риска» (список рисков, определяемый на основе анализа выявленных угроз и уязвимостей). Уровень сложность – средний.

4. Отчет «Об обработке риска» (список рисков с определенным приемлимым уровнем). Уровень сложность – средний.

5. Отчет «Об изменениях» (список изменений, выявленных в ходе внедрения методов и средств защиты). Уровень сложность – низкий.

6. Отчет «Состояние активов на конкретную дату». Уровень сложность – средний.

7. Отчет «Наличие рисков на конкретную дату». Уровень сложность – средний.

8. Отчет «Выявленные угрозы за конкретный период». Уровень сложность – средний.

9. Отчет «Внедренные методы/средства для защиты активов за конкретный период». Уровень сложность – средний.

Операции:

Операции, которые будут выполняться системой:

1. Поддержка ведения всех справочников;

2. Учет новых активов организации;

3. Учет выявленных уязвимостей

4. Обработка информации о рисках.

5. Учет методов и средств защиты активов;

Формы:

Для реализации выше перечисленных операций необходимо создать следующие формы:

1. Форма для ввода/удаления/изменения данных об активах. Здесь можно добавить новый актив или изменить данные об уже имеющемся в базе данных. Уровень сложность – низкий.

2. Форма для ввода/удаления/изменения данных о методах/средствах. Здесь можно добавить новый метод или средство защиты или изменить данные об уже имеющемся базе данных. Уровень сложность – низкий.

3. Форма для ввода/удаления/изменения данных об отделах. Здесь можно добавить новый отдел или изменить данные об уже имеющемся в базе данных. Уровень сложность – низкий.

4. Форма для ввода/удаления/изменения данных о сотрудниках. Здесь можно добавить нового сотрудника или изменить данные об уже имеющемся в базе данных. Уровень сложность – низкий.

5. Форма для ввода/удаления/изменения данных об угрозах. Здесь можно добавить новую угрозу или изменить данные об уже имеющейся в базе данных. Уровень сложность – низкий.

6. Форма для ввода/удаления/изменения данных об уязвимостях. Здесь можно добавить новую уязвимость или изменить данные об уже имеющейся в базе данных. Уровень сложность – низкий.

7. Форма для ввода/удаления/изменения данных о рисках. Здесь можно добавить новый риск или изменить данные об уже имеющемся в базе данных. Уровень сложность – низкий.

8. Форма для ввода/удаления/изменения данных о критериях оценки безопасности. Здесь можно добавить новый КОБ или изменить данные об уже имеющемся в базе данных. Уровень сложность – низкий.

9. Форма для ввода/удаления/изменения данных об изменениях. Здесь можно добавить новые изменения или изменить данные об уже имеющихся в базе данных. Уровень сложность – низкий.

10. Форма для ввода/удаления/изменения информации об оценке рисков. Здесь можно добавить новую оценку риска или изменить уже имеющуюся в базе данных. Уровень сложность – средний.

11. Форма для ввода/удаления/изменения информации об обработке рисков. Здесь можно добавить новую информацию по обработке риска уже имеющуюся в базе данных. Уровень сложность – средний.

12. Форма для выбора метода/средства. Здесь можно выбрать необходимый метод из базы данных и просмотреть его описание. Уровень сложность – средний.

Запросы:

1. Запрос на количество активов имеющихся в конкретном отделе. Система сопоставляет ИД_Отдела, указанного пользователем, и тот же атрибут в таблице «Актив», и если эти значения совпадают, то количество таких совпадений суммируется. Уровень сложности – низкий.

2. Запрос на количество выявленных угроз влияющих на конкретный актив. Система сопоставляет ИД_Актива, указанного пользователем, и тот же атрибут в таблице «Угроза», и если эти значения совпадают, то количество таких совпадений суммируется. Уровень сложности – низкий.

3. Запрос на количество угроз выявленных в конкретном отделе. Система сопоставляет ИД_Отдел, указанного пользователем, и тот же атрибут в таблице «Угроза», и если эти значения совпадают, то количество таких совпадений суммируется. Уровень сложности – низкий.

4. Запрос на количество методов и средств принимаемых для защиты от конкретного риска. Система сопоставляет ИД_Риска, указанного пользователем, и тот же атрибут в таблице «Метод/средство», и если эти значения совпадают, то количество таких совпадений суммируется. Уровень сложности – низкий.

5. Запрос на поиск изменений по внедрению конкретных методов и средств защиты . Система ищет все изменения, созданные для координирования работ по формированию методов и средств защиты. Уровень сложности – средний.

6. Запрос на пописк активов, для которых зарегестрировано максимальное количество угроз. Система ищет все активы с количеством угроз, которые установил пользователь как максимальное. Уровень сложности – средний.

7. Запрос на поиск информации о методах/средствах защиты от конкретной угрозы . Система ищет все методы и средства, созданные для предотвращения конкретной угрозы влияющей на активы организации. Уровень сложности – средний.

8. Запрос на поиск информации об угрозах конкретным активам. Система ищет все угрозы, оказывающие отрицательное воздействие на конкретный актив организации. Уровень сложности – средний.

2. ОЦЕНКА ПРЯМЫХ ТРУДОЗАТРАТ НА РАЗРАБОТКУ ИС

2.1. Оценка размера программной системы с помощью функционально-ориентированных метрик

Исходные данные для расчета функционально-ориентированных метрик (FP-метрик) представлены в Таблице 1:

Таблица 1. Количество функциональных указателей

Далее производится обоснование коэффициентов регулировки сложности, которые представлены в Таблице 2. Коэффициент регулировки сложности может принимать следующие значения:

0 – нет влияния , 1 – случайное , 2 – небольшое , 3 – среднее , 4 – важное , 5 – основное .

Для разрабатываемой системы:

Таблица 2. Определение системных параметров приложения

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

14

FP = Общее_количество * (0,65 + 0,01 * Σ F_i ),

i=1

FP = 165 * (0,65 + 0,01 * 38),

FP = 169,95

Данный показатель отражает размер программной системы и позволяет вычислить размер программного кода, т. е. предполагаемое количество строк. Он будет использоваться в дальнейшем, при расчете трудовых затрат по COCOMO II.

2.2. Оценка трудозатраты на основе конструктивной модели стоимости COCOMO II для этапа «композиция приложений»

Для предварительной оценки трудозатрат (этапа «композиция приложений») по модели COCOMO II необходимо оценить сложность экранов и отчётов. Оценка сложности экранов представлена в Таблице 3.

Таблица 3. Оценка сложности экранов

Оценка сложности отчётов представлена в Таблице 4.

Таблица 4. Оценка сложности отчетов

В Таблице 5 приводится расчёт объектных указателей (NOP).

Таблица 5. Расчёт числа объектных указателей (NOP)

Повторно-используемые компоненты отсутствуют. Следовательно, NOP = 51.

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

Таблица 6. Оценка скорости разработки

Возможность разработчика - номинальная, т.к. разработчик не имеет большого опыта работы в данной предметной области, а также не развиты навыки разработки приложений, следовательно, PROD =13.

Возможность среды – высокая, следовательно, PROD = 25.

Общий коэффициент продуктивности продукта:

PROD = (13+25)/2=19.

Зная значение объектного показателя и коэффициента продуктивности можно оценить затраты на проект в чел/мес.

NOP/PROD = 51/19 = 2,68 чел/мес.

2.3. Оценка трудозатраты на основе конструктивной модели стоимости COCOMO II для этапа «Раннего проектирование»

Для уточнения оценки трудозатрат (этапа «композиция приложений») по модели COCOMO II на этапе раннего проектирования необходимо использовать следующую формулу:

Затраты = А*Размер^В *М_е +Затраты_auto [чел./мес]

где:

· параметр А - коэффициент масштабности, равен 2,5;

· Размер - количество строк кода (выражается в тысячах LOC);

· параметр В - отражает линейную зависимость затрат от размера проекта;

· множитель поправки М_е зависит от 7 формирователей затрат, характеризующих продукт, процесс и персонал;

· слагаемое Затраты _auto отражает затраты на автоматически генерируемый программный код.

Рассчитаем необходимые показатели для вычисления трудозатрат.

Программа будет разрабатываться на С#. Учитывая количество функциональных указателей (169,95) и коэффициент перевода строчек кода (29), получим размер программного кода равный 169,95*29 = 4928,55 строк кода, примерно 4,9 тыс. строк.

В - параметр, отражающий линейную зависимость затрат от размера проекта. Он рассчитывается по формуле:

где - масштабные факторы, которые оцениваются в диапазоне от очень низкой – 0, до очень высокой -5.

Оценка масштабных факторов для разрабатываемой ИС представлена в Таблице 7.

Таблица 7. Оценка масштабных факторов

Коэффициент, отражающий линейную зависимость затрат от размера проекта, равен: B=1,01+0,01*11=1,12.

M_e - множитель поправки рассчитывается по следующей формуле:

,

где:

· E - табличный коэффициент,

· M_i - формирователей затрат (оцениваются в диапазоне от 1 до 6 : 1 - очень низкий уровень, 6 - сверх высокий уровень).

Оценка формирователей затрат представлена M_i в Таблице 8.

Таблица 8. Оценка формирователей затрат

Множитель поправки, который определяется на основе формирователей затрат, равен:

=0,958.

При разработке не используется автоматическая генерация кода, соответственно, Затраты _auto =0.

Отсюда, оценка трудозатрат равна:

Затраты = А*Размер^В *М_е +Затраты_auto [чел./мес]

Затраты =2,5*4,9^1,12 *0,958+0 = 14,2012 (чел./дней).

3. ОЦЕНКА ЭФФЕКТА ОТ ВНЕДРЕНИЯ ИС

3.1. Определение центров затрат в модели бизнес-процессе

Функционально-стоимостной анализ моделей бизнес-процессов производится по следующим центрам затрат:

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

· оборудование;

· информационные технологии.

Смета затрат на заработную плату работникам модели «AS-IS» представлена в Таблице 9.

Таблица 9. Смета затрат на заработную плату в модели «AS-IS»

Смета затрат на заработную плату работникам модели «TO-BE» представлена в Таблице 10.

Таблица 10. Смета затрат на заработную плату в модели «TO-BE»

Центр затрат «Оборудование» включает в себя амортизацию использования компьютерной аппаратуры. Данные затраты применимы только на тех этапах бизнес-процесса, где выполнение той или иной задачи возможно с использованием ПК.

Центр затрат «Информационные технологии» включает в себя стоимость использования применяемых информационных технологий. Данные затраты применимы только на тех этапах бизнес-процесса, где выполнение той или иной задачи возможно с использованием ИТ.

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

3.2. Модели бизнес-процесса (AS-IS) и ( TO-BE)

Модель бизнес-процесса (AS IS) представлена на рис. 1 - 6.

Рис. 1. Контекстная диаграмма бизнес-процесса «Управление безопасностью средств обработки информации»

Рис. 2. Декомпозиция контекстной диаграммы бизнес-процесса «Управление безопасностью средств обработки информации»

Рис. 3. Декомпозиция блока «Выявление рисков»

Рис. 4. Декомпозиция блока «Выбор методов и средств защиты»

Модель бизнес-процесса (TO BE) представлена на рис. 7 - 12.

Рис. 5. Контекстная диаграмма бизнес-процесса «Управление безопасностью средств обработки информации»

Рис. 6. Декомпозиция контекстной диаграммы бизнес-процесса «Управление безопасностью средств обработки информации»

Рис. 7. Декомпозиция блока «Выявление рисков»

Рис. 8. Декомпозиция блока «Выбор методов и средств защиты»

3.3. Функционально-стоимостной анализ моделей бизнес-процесса (AS-IS) и (TO-BE)

В Таблице 11 представлен функционально-стоимостной анализ модели «AS-IS».

Таблица 11. Функционально-стоимостной анализ модели «AS-IS»

В Таблице 12. представлен функционально-стоимостной анализ модели «TO-BE».

Таблица 12. Функционально-стоимостной анализ модели «TO-BE»

На основе проведенного функционально-стоимостного анализа можно сделать вывод, что использование новой информационной системы позволит экономить 14150 руб. (20,36%) в месяц. Снижение стоимости бизнес-процесса возможно за счет снижения затрат на оплату труда, вследствие автоматизации рабочего процесса, то есть уменьшения работы с бумажными ностителями, что приведет к увеличению скорости потоков информации и, следовательно, более эффективной работы по управлению безопасностью средств обработки информации.

4. ОЦЕНКА ЭФФЕКТИВНОСТИ ПРОЕКТА

4.1. Ввод финансовых параметров проекта

На рис. 9. представлена форма для ввода сведений о проекте:

Рис. 9. Ввод сведений о проекте

В качестве продукта автоматизации будет выступать обновленная база уязвимостей, автоматизированное формирование и управление которой и будет приносить эффект в виде снижения затрат. Началом «продаж», будем считать 30.04.2010 – дату полного внедрения АИС (рис. 10).

Рис. 10. Ввод сведений о поступлениях (экономическом эффекте)

Далее необходимо учесть влияние налогов. В нашем случае применим только ЕСН (26% с заработной платы персонала, занятого непосредственным созданием ИС). Иные виды налогов при расчете сметы затрат не учитываются, т.к. банк разрабатывает ИС собственными силами (рис. 11).

Рис. 11. Ввод сведений о налоге

4.2. Ввод ресурсов и сформирование календарного плана

Для календарного плана проекта необходимо учесть ресурсы, участвующие в смете затрат на создание ИС (рис. 12).

Рис. 12. Ввод сведений о ресурсах

На рис. 13. представлен календарный план проектной части. Стоимость всех ресурсов, указанных выше, не столь значима, поэтому их можно закрепить за «корневым» этапом – «Создание АИС» в объеме, необходимом для всего периода разработки.

Рис. 13. Календарный план проектной части

4.3. Определение источников финансирования

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

Рис. 14. Формирование источников финансирования

4.4. Формирование поступлений от проекта (эффект)

На основании результатов функционально-стоимостного анализа, имеем: эффект (экономия) от использования аналитической информационной системы составляет 24 910 руб. в месяц. Зная, что данный положительный эффект будет наблюдаться ежемесячно на протяжении всего периода использования системы после полного внедрения АИС (с 5-го месяца), введем эту информацию (рис. 15).

Рис. 15. Ввод информации о поступлениях от проекта

4.5. Ввод затрат на управление и производство

В проекте отсутствуют маркетинговые издержки, в виду ненадобности данной статьи расходов при создании и внедрении информационной системы.

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

Рис. 16. Ввод затрат на управление

В процессе создания данной АИС необходимо участие аналитика на этапе проектирования. Данный этап длится почти 1 месяц (01.01.2010-.29.01.2010).

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

Также в проекте предусмотрена роль специалиста по тестированию, который участвует на завершающем этапе разработки ИС (внедрение). Этот специалист задействован на 4-м месяце разработки системы (31.03.2010-30.04.2010).

Аналитик, программист и специалист по тестированию являются производственным персоналом в проекте. Затраты на производственный персонал вводятся в форму на рис. 17.

Рис. 17. Ввод затрат на производственный персонал

4.6. Расчёт финансовых отчётов и показателей эффективности

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

Рис. 18. Ввод ставки дисконтирования

На рис. 19. представлен отчёт «Прибыли-убытки».

Рис. 19. Отчёт о прибылях и убытках

На рис. 20. представлен отчет «Кэш-фло».

Рис. 20. Отчёт «Кэш-фло»

На рис. 21. представлен отчёт «Баланс».

Рис. 21. Баланс

На рис. 22. представлены показатели эффективности инвестиций в проект.

Рис. 22. Показатели эффективности

4.7. Заключение о выгодности проекта

Проанализируем полученные показатели эффективности:

1. Период окупаемости (PB) равен 16 мес., следовательно, через 12 месяцев после внедрения новой ИС (с учетом первых 4-х месяцев разработок) предполагается оправдать вложенные средства.

2. Средняя норма рентабельности показывает, что среднегодовой доход (экономия от использования ИС) составляет 105,60% от суммы инвестиций (вложений в создание новой системы).

3. Чистый приведенный доход представляет разность между дисконтированными затратами и поступлениями (эффекта) от создания и использования ИС. Следовательно, руководители страховой компании могут рассчитывать на 526808,00 руб. в случае использования новой ИС в течение 5 лет.

4. Индекс прибыльности демонстрирует, что за 5 лет эффект (экономия) от использования АИС в 4,57 раза больше вложенных в нее средств.

5. Из ниже приведенного графика (рис. 23) видим, что в первую половину 2010 г. (период разработки) организация имеет только убытки, связанные с затратами на создание ИС и отсутствием каких-либо доходов от ее использования. Однако, начиная ссередины второго квартала 2010 года до конца первого квартала 2011 года, наблюдается период окупаемости. С конца первого квартала 2011 года банк будет иметь постоянную чистую прибыль от использования ИС. Положительный эффект от использования ИС представлен линейным графиком. Это объясняется тем, что ежемесячная стоимость данного бизнес-процесса снижена на постоянную величину (14 150 руб.) Наличие положительного эффекта объясняет целесообразность создания новой информационной системы.

Рис. 23. График окупаемости

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

Рис. 5.25. Накопленные инвестиции

Таким образом, можно считать доказанным тот факт, что провайдеру «Большие сети» целесообразно автоматизировать процесс управления безопасностью средств обработки информации, нежели продолжать вести ее разработку без использования базы данных и формировать отчеты в ручную.

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Якущенко А.Н. «Обеспечение бюджета информационной безопасности информационной системы» URL: http://ev.nuos.edu.ua/content/obespechenie-byudzheta-informatsionnoi-bezopasnosti-informatsionnoi-sistemy (дата обращения 31.11.2009)

2. С.А. Петренко "Оценка затрат на информационную безопасность".

3. Материалы консультационной группы "Воронов и Максимов" 1996-2008

«Построение или оптимизация системы бюджетирования на предприятии», «Выбор инструмента для реализации построенной системы бюджетирования».

4. «Аудит информационной безопасности», "Алатус Информационные Технологии"

2006 — 2009

5. ГОСТ Р ИСО/МЭК 15408-3-2002 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий»

6. Е.Добровольский, Б.Карабанов, П.Боровков, Е.Глухов, Е.Бреслав "Бюджетирование шаг за шагом" Издательство "Питер", 2005г.

7. «Доктрина информационной безопасности Российской Федерации». 2000г. URL: http://www.rg.ru/oficial/doc/min_and_vedom/mim_bezop/doctr.shtm (дата обращения 2.12.209)

8. Корпорация КАРАНА / USAID «Бюджетирование» 2006г.

9. Сергей Костяков, Станислав Гераськин, Андрей Коптелов «Как правильно спланировать ИТ-бюджет» 30.10.2009 URL:http://www.iemag.ru/analitics/detail.php?ID=1967(дата обращения 25.11.2009г)

10. С. А. Петренко «Возможная методика построения системы информационной безопасности предприятия.» URL: http://www.bre.ru/security/13985.html (дата обращения 2.12.2009)

11. Перепанова Т.С., Балтахинова «Основы бюджетной системы и бюджетного учёта».

Системные требования:winRar, pdf-просмотрщик. http://www.gaudeamus.omskcity.com/lib-pdf/econom/Perepanova-Baltahinova_-_OsnovyBudzhetnojSistemyBudzhetnogoUcheta_-_2004_128_PDF.zip

12. Ольга Шава «Бюджетное планирование как способ управления предприятием». URL:http://www.gaap.ru/biblio/corpfin/guide/053.asp(дата обращения 25.11.2009г)

13. Репин В.В. «Применение процессного подхода при бюджетировании» URL:http://www.smartcat.ru/FinancialManagement/expensesA.shtml(дата обращения 26.11.2009г)

14. Родин В.Д. Вестник Удмуртского Университета, «Инструмент Финансового Менеджмента - Бюджетирование».

ПРИЛОЖЕНИЕ 1 .

Глоссарий:

ПРИЛОЖЕНИЕ 2 .

Ментальная карта: