Проектирование информационной системы поддержки мероприятий защиты информации банка

 

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

 

Рисунок 3.1 – Диаграмма активности

 

 

4. Проблемы  предметной области и концепция  информационной системы

1. Проблемы предметной области

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

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

2. Концепция информационно системы

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

  4.2.2 - Функциональные требования

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

Основные требования

К информационной системе предъявляются следующие  основные требования:

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

 

4.2.2 - Нефункциональные требования

• современное программное обеспечение, позволяющее максимально упростить процедуры подачи и обработки информации и обеспечивающее надлежащую безопасность передаваемых данных ;
• современное аппаратное обеспечение;
• навыки пользователей системы работы на компьютере в операционных системах семейства Windows (Windows XP, Windows Vista,  Windows Server и т.д.);
• наглядный пользовательский интерфейс для простоты и удобства работы пользователя, а так же высокой скорости освоения;
• возможность хранения большого объема электронных документов;
• возможность работы в сетевом режиме;
• средства, обеспечивающие конфиденциальность информации и защиту от несанкционированного доступа (например, пароль, электронная подпись, сканирования отпечатков пальцев или сетчатки глаза);
• стоимость;
• с учетом возможности роста сети должна присутствовать возможность расширения системы;
• наличие принтера.

 

5. Концептуальная модель информационной системы

Для разработки архитектуры ИС, целесообразно использовать шаблон трехслойной архитектуры.

Основные  высказывания:

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

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

Выполняет обращение  к БД, обмен сообщениями, мониторинг транзакций.

Результаты  разработки представлены в виде диаграммы  классов на рисунке 6, описание назначения классов по слоям – в таблице 1.

 

Таблица 1 – Назначение классов концептуальной модели

 

№	Наименование класса	Назначение класса
Слой представления
1.	E-UI-НачальникСБ	Граничный класс, отвечающий за отображение формы, содержащей список выполняемых мероприятий,  возможность добавление новых, списка полученных данных в результате выполнения мероприятий, возможность поиска, удаления и фильтрации проделанных мероприятий и их результатов.
2.	E-UI-СотрРежИОхр	Граничный класс, отвечающий за отображение  формы со списком мероприятий которые необходимо выполнить, и возможностью внесения списка полученных данных в результате выполнения мероприятий.
3.	E-UI-СотрСпец	Граничный класс, отвечающий за отображение  формы со списком мероприятий которые необходимо выполнить, и возможностью внесения списка полученных данных в результате выполнения мероприятий.
4.	E-UI-СотрИнжИТех	Граничный класс, отвечающий за отображение  формы со списком мероприятий которые необходимо выполнить, и возможностью внесения списка полученных данных в результате выполнения мероприятий.
5.	E-UI-СотрГрВнБез	Граничный класс, отвечающий за отображение  формы со списком мероприятий которые необходимо выполнить, и возможностью внесения списка полученных данных в результате выполнения мероприятий.
6.	Контроллер	Управляющий класс, методы которого отвечают за управление приложением в целом
7.	Правила	Класс хранения, содержащий данные бизнес-правил
Слой предметной области
8.	Обсл. вызовов	Граничный класс, отвечающий за взаимодействие с классами слоя предметной области
9.	Е-История	Класс хранения, содержащий данные о различных уязвимостях
10.	Е-Отчет	Класс хранения, содержащий данные о пройденных мероприятиях, о результатах проведения.
11.	Е-Мероприятия	Класс хранения, содержащий сведения о мероприятия (Такие как -  кто, где, когда, что и как делал).
12.	Е-Сотрудник	Класс хранения, содержащий данные сотрудников, являющихся пользователями информационной системы
13.	Права	Класс хранения, прав доступа пользователей информационной системы
Слой источника данных
13.	Дата	Граничный класс для взаимодействия с базой данных

 

 

Рисунок 5 – Диаграмма классов, моделирующая структуру ИС на концептуальном уровне

 

 

6. Логическая  модель информационной системы

1. Модель  поведения

Модель поведения (модель взаимодействия объектов), разрабатывается посредством UML диаграмм последовательности. Модель поведения разрабатывается для каждой ключевой функции ИС (варианта использования), определяемой в концепции ИС

 

Рисунок 6.1- Диаграмма последовательности, моделирующая процесс создания и редактирования плана мероприятий

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

Так как взаимодействие всех отделов СБ с разрабатываемой  ИС одинаково, то для удобства представления  приведем диаграммы последовательности только для отдела режима и охраны.

Рисунок 6.2- Диаграмма последовательности, моделирующая поддержку процесса выполнения мероприятий и создания по ним отчетов сотрудниками СБ

2. Модель  структуры

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

 

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

Рисунок 6.3 – Диаграмма классов, моделирующая структуру ПО ИС на логическом уровне

 

7. Реализация  модели в среде CASE-средства

В качестве примера  реализации модели в среде Case-средства опишем процесс моделирования диаграмм логической модели ПО ИС.

1. Начало  работы над проектом

В качестве среды разработки ИС было выбрано CASE-средство фирмы Rational Software Corporation – Rational Rose Enterprise Edition.

Запустить программу Rational Rose Enterprise Edition. Создать новый проект: FiIe->New. После того, как проект будет создан и работа с ним будет завершена, необходимо сохранить полученные диаграммы. Для этого в меню File выбрать пункт Save или Save As, дать имя проекту и сохранить его в файл с расширением *.mdl. В нашем случае проект имеет название КП.mdl.

2. Разработка  модели поведения

Для создания диаграммы последовательности действий в программе Rational Rose необходимо добавить в список браузера новую  диаграмму. Для этого нужно щелкнуть правой кнопкой мыши по папке Logical View (Логическое представление) и в появившемся  контекстно-зависимом меню выбрать  команду New -> Sequence Diagram (Создать -> Диаграмма  последовательности действий). Для  создания объектов и сообщений на диаграмме последовательности действий, прежде всего, нужно ее открыть, затем  выбрать на панели инструментов сообщение  или объект и перетащить его на диаграмму. Пример разработки модели поведения представлен на рисунке 6.1.

Рисунок 7.1- Пример разработки модели поведения в среде CASE-средства фирмы Rational Software Corporation – Rational Rose Enterprise Edition.

7.3 Разработка модели структуры

Для создания диаграммы классов  в программе Rational Rose необходимо добавить в список браузера новую диаграмму. Для этого нужно щелкнуть правой кнопкой мыши по папке Logical View (Логическое представление) и в появившемся  контекстно-зависимом меню выбрать  команду New -> Class Diagram (Создать -> Диаграмма классов). Пример разработки модели структуры в виде диаграммы классов представлен на рисунке 6.2.

Рисунок 6.2 - Пример разработки модели структуры в среде CASE-средства фирмы Rational Software Corporation – Rational Rose Enterprise Edition.

 

8. Заключение

В процессе выполнения курсового проекта была разработана  ИС поддержки мероприятий защиты информации банка. Основой для создания информационной системы послужили проблемы предметной области. В качестве среды разработки ИС было выбрано CASE-средство фирмы Rational Software Corporation – Rational Rose Enterprise Edition, с помощью которого были построены концептуальная и логическая модели ПО ИС.

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

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

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