2.1.1 Общая концептуальная модель

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

При использовании данной методологии можно определить влияние стандартов и нормативных документов; на каких этапах проектирования требуются программно-инструментальные комплексы; осуществление контроля за ходом проектирования.

Как можно видеть из диаграммы A-0, мы поставили перед собой цель разработать систему защиты камер хранения банка (Рис. 8).

Рис 8.Общая концептуальная модель IDEF0.

2.1.2 Диаграмма уровня А0

Построение системы защиты сводится к 4 этапам:

1. Оценка уровня защищенности

2. Создание системы защиты

3. Управление системой защиты

4. Сопровождение системы

Мы руководствовались мнениями специалистов при выборе такого пути моделирования. На диаграмме А0 можно увидеть эти этапы. В процессе моделирования приходилось учитывать ограничения по ГОСТам. Также немало важно было решить, использовать или нет мнения специалистов в том или ином вопросе (Рис. 9).

Рис 9. Диаграмма уровня А0.

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

Далее, после соответствующего мониторинга, необходимо перейти к непосредственному созданию системы на основе ГОСТов и проектов.

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

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

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

2.1.3 «Сопровождение системы»

Подробнее рассмотрим блок «Сопровождение системы», который состоит из следующих компонентов:

Рис 10. Контроль учёта доступа к системе.

1. Контроль учёта доступа к системе (Рис. 10)

· Планирование системы доступа

· Контроль за доступом к системе персонала

· Контроль за доступом к системе клиентов

· Создание отчётной документации доступа

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

2. Организационная поддержка системы (Рис. 11)

· Обзор документации о системе

· Техническая поддержка

· Кадровая поддержка

· Анализ состояния системы на данный момент

Рис 11. Организационная поддержка системы.

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

3. Тестирование системы к уязвимостям (Рис. 12)

· Определение тестируемого компонента системы

· Идентификация возможных угроз

· Измерение рисков

· Анализ имеющихся средств защиты системы

Рис 12. Тестирование системы к уязвимостям.

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

4. Адаптация системы к изменениям во внешней среде (Рис. 13)

· Исследование необходимых изменений системы

· Выбор усовершенствованных технологий

· Внедрение изменений

· Результаты адаптации

Рис 13. Адаптация системы к изменениям во внешней среде.

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

2.2 Анализ информационных потоков