Курсовая "Оценка компонентов мониторинга событий безопасности на примере устройств Arduino"

Содержание
Введение ....................................................................................................................... 2
1
АНАЛИЗ СИСТЕМ СБОРА И АНАЛИЗА СОБЫТИЙ БЕЗОПАСНОСТИ ... 3
1.1
Мониторинг событий информационной безопасности ................. 3
1.2
Критерии
событий
1.3
2
оценки
интегрированной
системы
мониторинга
5
Выводы по разделу ............................................................................ 9
РАЗРАБОТКА И ОЦЕНКА СИСТЕМЫ ОХРАНЫ ПЕРИМЕТРА С
ИСПОЛЬЗОВАНИЕМ ARDUINO ........................................................................... 10
2.1
периметра
Требования к разрабатываемому прототипу системы охраны
10
2.2
Выбор компонентов прототипа системы охраны периметра ...... 13
2.3
Описание и оценка компонентов прототипа спроектированной
системы охраны периметра ...................................................................................... 15
2.4
Оценка системы безопасности........................................................ 19
2.5
Выводы по разделу .......................................................................... 20
Заключение ............................................................................................................... 21
Список используемых источников ...................................................................... 22
Введение
Стремительное развитие технологий и микропроцессоров предполагает
появление на рынке более компактных и производительных устройств.
Одной из главных проблем в области систем мониторинга событий
является отсутствие децентрализации, из-за чего при потере связи с главным
сервером отдельные сегменты системы не могут эффективно функционировать.
Объектом курсовой работы является система мониторинга событий
безопасности, предметом – возможности реализации автономных систем или
сегментов системы.
Целью курсовой работы является разработка и оценка системы
мониторинга событий с использованием Adrduino и возможностью автономной
работы.
При этом решаются следующие задачи:
 провести анализ систем сбора и анализа событий безопасности и выявить
критерии оценки интегрированной системы мониторинга событий
 разработать и произвести оценку системы мониторинга событий с
использованием Arduino
Актуальность данной работы обусловлена тем, что в обозримом будущем
используя новые технологии, в частности одноплатные компьютеры Arduino и
Raspberry Pi существующие системы мониторинга станут мало эффективными
или потеряют свою актульность.
2
1
АНАЛИЗ СИСТЕМ СБОРА И АНАЛИЗА СОБЫТИЙ
БЕЗОПАСНОСТИ
1.1 Мониторинг событий информационной безопасности
1.1.1 Определение
Мониторинг событий информационной безопасности — это процесс
проверки всех событий безопасности, получаемых от различных источников.
Источниками
событий
могут
быть
антивирусные
системы,
журналы
операционных систем, сканеры анализа защищенности инфраструктуры, сетевое
оборудование
и
другие
источники,
расположенные
в
инфраструктуре
организации.
1.1.2 Категории
Системы мониторинга событий можно разделить на следующие категории:
SIEM — системы для управления событиями, полученными из различных
источников, позволяющие анализировать события в режиме реального времени.
UBA — системы, осуществляющие сбор и анализ действий пользователей
для поиска возможных внутренних угроз и атак.
UEBA — системы с функцией поиска аномалий в поведении сотрудников
и различных систем.
Системы
контроля
эффективности
сотрудников,
позволяющие
анализировать действия пользователей на рабочем месте и контролировать их
действия при работе с конфиденциальной информацией.
Системы поиска и обнаружения атак, которые направлены на повышение
уровня защищенности инфраструктуры организации.
1.1.3 Компоненты системы
Системы мониторинга событий, как правило, состоят из четырех
компонентов:
3
Программные агенты. Такие агенты необходимы для обеспечения сбора
информации, которая поступает от источников (программное обеспечение,
средства защиты информации, аппаратные компоненты инфраструктуры).
Сервер.
Этот
модуль
позволяет
выполнять
обработку
событий
безопасности централизованно. Сервер аккумулирует информацию, которая
поступает от программных агентов, и обрабатывает поступающие события на
основе политик и правил, которые были настроены администраторами
безопасности компании.
Хранилище данных. Все события безопасности, которые поступают от
агентов, передаются на хранение в хранилище данных. У администратора
безопасности всегда есть возможность обратиться к событиям, которые были
зарегистрированы в последние несколько недель, месяцев (в зависимости от
размеров хранилища данных).
Консоль управления. Для того чтобы настраивать параметры обработки
поступающих
предоставляется
событий
безопасности,
инструмент
настройки
администратору
—
консоль
безопасности
централизованного
управления. В ней же он может просматривать события информационной
безопасности и обращаться к хранилищу данных.
1.1.4 Области применения
Системы мониторинга событий позволяют проводить инвентаризацию
ресурсов
автоматизированными
средствами,
анализировать
сетевые
приложения, оборудование и веб-сервисы, сокращать затраты на проведение
аудита, автоматизировать процесс управления уязвимостями и обеспечивать
контроль соответствия политикам информационной безопасности, принятым в
организации.
4
1.2 Критерии
оценки
интегрированной
системы
мониторинга
событий
1.2.1 Комплектность ИСБ
Классическая ИСБ объединяет четыре основные системы безопасности
объекта: систему пожарной сигнализации, систему охранной сигнализации,
систему контроля и управления доступом, систему видеонаблюдения.
Комплектная ИСБ объединяет не менее четырех основных систем
безопасности.
Некомплектная
ИСБ объединяет
менее
четырех
основных
систем
безопасности.
1.2.2 Функциональность ИСБ
Под функциональностью понимается набор основных функциональных
характеристик ИСБ по обмену информацией и управлению системами,
входящими в ИСБ.
Малофункциональная ИСБ: передача информации между системами
происходит только при возникновении тревоги в какой-либо одной системе. При
этом отсутствует возможность управления всеми системами, входящими в ИСБ,
с одного или нескольких рабочих мест. Базы данных отдельных систем не
синхронизованы.
Среднефункциональная ИСБ: передача информации между системами
происходит только при возникновении тревоги в какой-либо одной системе. ИСБ
предоставляет возможность управления всеми системами, входящими в ИСБ, с
одного или нескольких рабочих мест, имеющих общую программную оболочку.
Базы данных отдельных систем не синхронизованы.
Высокофункциональная ИСБ: передача информации между системами
происходит не только при возникновении тревоги в одной из систем, но и при
выполнении системой своих штатных функций - постановка области на охрану,
считывание карты доступа и т.п. ИСБ предоставляет возможность управления
всеми системами, входящими в ИСБ, с одного или нескольких рабочих мест,
5
имеющих общую программную оболочку с широким набором функций,
например, управление ресурсами систем по поэтажным планам объекта. Базы
данных систем синхронизованы, т.е. ИСБ по событию, произошедшему в одной
системе (тревожному и штатному), автоматически находит и предоставляет
оператору соответствующее событие в другой системе. Например, по факту
постановки области на охрану, найденному в журнале событий системы
охранной сигнализации, ИСБ автоматически находит в архиве видеосистемы
соответствующие этому процессу кадры; по факту считывания карты доступа
ИСБ
автоматически
находит
и
предоставляет
оператору
видеокадры,
зафиксировавшие данное событие.
1.2.3 Размер ИСБ
Под размером ИСБ понимается максимальный размер, определяемый
фирмой-изготовителем для данной модели ИСБ. Так как ИСБ объединяет четыре
системы безопасности, а размер каждой, как правило, сильно различается
(например, различие в количестве адресных точек в адресно-аналоговой
пожарной сигнализации и считывателей системы доступа), то при определении
максимального размера ИСБ указывается также и максимальный размер каждой
входящей в ИСБ системы.
Малая ИСБ: состоит из систем, в каждой из которых до 50 точек (под
точкой понимается адресный элемент в системе пожарной сигнализации,
адресный датчик или шлейф в системе охранной сигнализации, считыватель в
системе доступа, видеоканал в системе видеонаблюдения).
Средняя ИСБ: состоит из систем, в каждой из которых от 50 до 500 точек.
Крупная ИСБ: состоит из систем, в каждой из которых больше 500 точек.
Уточнение: Количество точек в системе определяется из расчета
максимального аппаратного размера системы. Например, общее количество
датчиков пожарной и/или охранной сигнализации при объединении панелей в
аппаратную сеть без объединяющего компьютера. Размер СКУД определяется
по количеству подключенных к одному компьютеру управления считывателей;
6
увеличение размера СКУД за счет объединения компьютеров управления в сеть
не допускается.
1.2.4 Масштабируемость
Это способность ИСБ и входящих в нее систем к увеличению своего
размера в процессе эксплуатации.
Фиксированная ИСБ не может сколько-нибудь существенно увеличивать
свой размер.
Масштабируемая ИСБ может значительно увеличивать существующий
размер за счет добавления функционально законченных модулей или новых
отдельных систем. Например, увеличение адресно-аналоговой пожарной
сигнализации добавлением еще одной пожарной панели и включение ее в общую
станционную сеть. Или увеличение системы контроля доступа посредством
нового компьютера управления с подключенными к нему считывателями и
объединение его с существующим сервером.
1.2.5 Быстродействие ИСБ
Данный параметр определяет промежуток времени между событием в
одной системе безопасности и соответствующей реакцией в другой/других
системах безопасности, входящих в ИСБ.
Высокое быстродействие: время реакции между системами составляет
менее 1 секунды.
Среднее быстродействие: время реакции находится в пределах от 1 до 2
секунд.
Низкое быстродействие: время реакции превышает 2 секунды.
7
Уточнение: ИСБ должна работать в режиме реального времени. С этой
точки зрения 2 с -практически верхний предел задержки, так как за это время
подготовленный человек может преодолеть до 10 м и выйти, например, из поля
зрения камеры. Тогда вся интеграция становится малоэффективна. Однако для
большинства крупных и многих средних ИСБ задержка в 1 с вряд ли будет
достижима. Увеличение же задержки свыше 2 с приведет к потере
целесообразности применения целого ряда функций ИСБ - автоматическое
включение камеры, в поле зрения которой произошла тревога в системе
охранной сигнализации или контроля доступа, видеоидентификация человека на
проходной с помощью систем доступа и видеонаблюдения (человек просто
успеет выйти из поля зрения камеры), запись видеосистемой человека,
использующего карту доступа и т.д.
1.2.6 Отказоустойчивость/живучесть
Низкая живучесть: ИСБ имеет один нерезервированный сервер управления
или нерезервированный процессорный модуль (как правило, для малых ИСБ).
Линии связи в такой системе также не резервированы. Сбой в работе сервера,
процессора или обрыв линии связи сразу приводят к нарушению обмена
информации в ИСБ и в лучшем случае рассыпанию ее на отдельные системы
безопасности.
Средняя живучесть: ИСБ имеет резервный сервер или процессор,
работающие в "горячем" режиме. Линии связи резервированы. В такой ИСБ
однократные сбой в работе сервера или обрыв линии связи не приводят к
нарушению работы ИСБ.
Высокая живучесть: ИСБ имеет резервный сервер или процессор,
работающие в "горячем" режиме. Линии связи резервированы. Интегра¬ция
между системами выполнена не только на программном, но и на аппаратном
уровне.
8
В системе данного типа даже полное нарушение работоспособности
серверов или сбой в работе программного обеспечения не приводят к
разрушению ИСБ. Благодаря аппаратной интеграции систем безопасности ИСБ
сохраняет передачу основных сообщений между всеми системами (тревожные
сообщения), а также сохраняет прежний объем обмена информацией между
частью систем безопасности.
1.2.7 Расширяемость
Расширяемая ИСБ позволяет добавлять в существующий состав ИСБ
системы новых производителей.
Нерасширяемая ИСБ включает в свой состав только жесткий перечень
оборудования уже определенных производителей. Добавить оборудование
других производителей невозможно.
1.3 Выводы по разделу
В данном разделе были рассмотрены различные аспекты систем
мониторинга событий и выявлены основные критерии их оценки.
Определены основные компоненты системы, что позволяет представить их
работу и выявить основные недостатки такой системы – вся информация
обрабатывается в одном месте на сервере и при его сбоях вся система теряет
возможность функционирования.
9
2
РАЗРАБОТКА И ОЦЕНКА СИСТЕМЫ ОХРАНЫ ПЕРИМЕТРА С
ИСПОЛЬЗОВАНИЕМ ARDUINO
2.1 Требования к разрабатываемому прототипу системы охраны
периметра
Данная система должна осуществлять управление физическим доступом в
определенном здании, включая ограничение доступа в заданное помещение и
идентификацию лица, имеющего доступ в заданное помещение. Кроме того,
система
должна
контролировать
информационный
доступ.
Каждый
пользователь, контролируемый системой, может находиться в четырех
состояниях:
 S1 — пользователь вошел в помещение;
 S2 — пользователь авторизовался на рабочем месте (начало сеанса
работы с операционной системой);
 S3 — пользователь завершил сеанс работы с операционной системой; S4
— пользователь покинул помещение.
Вход пользователя в помещение или выход пользователя из помещения
идентифицируется приложением бесконтактной карты к считывателю, который
подсоединен к подсистеме контроля доступа в помещении. В ситуациях, когда
пользователь не приложил карту, открытие двери идентифицируется переходом
кнопки из нажатого состояния в свободное и/или инфракрасным датчиком
движения. Как только установлено, что человек вошел в помещение (или вышел
из него), запускается обратный отсчет — время, за которое пользователю
необходимо авторизоваться в системе при помощи карты. На основе уникальных
данных карты формируется специальный запрос к центральному серверу
управления доступом для получения информации о наличии или отсутствии
доступа к помещению у пользователя карты. Подсистема контроля доступа в
помещение, получив ответ от центрального сервера управления доступом,
начинает обработку полученной информации. Результат проверки карты
10
пользователя сопровождается открытием замка, выводом текстовой информации
на экран, световым и звуковым сигналом. Результаты проверки карт вместе с
информацией о состоянии сеансов работы пользователей с операционной
системой направляются на сервер журналирования.
Таким образом, для реализации защищенной системы охраны периметра в
целом необходимо реализовать надежную и защищенную подсистему контроля
доступа в помещение. Данная подсистема представляет собой встроенное
устройство (ВУ), расположенное в дверях между помещениями и подключенное
к механизму управления замком.
Рассмотрим основные функциональные требования к данному устройству
более подробно.
ВУ должно осуществлять работу в локальной сети системы по
беспроводному каналу передачи данных. Это необходимо для защиты от
физического воздействия на канал передачи данных между микроконтроллером
и центральным сервером управления (например, повреждение Ethernet-кабеля),
а также для существенного снижения стоимости установки системы. ВУ должно
поддерживать
интерфейс
для
взаимодействия
с
удаленным
сервером
приложений для удобства интеграции в общую систему контроля и управления
доступом. Взаимодействие с сервером приложений может осуществляется по
HTTP, HTTPS, SOAP. Данные, передаваемые по HTTP и SOAP, должны быть
предварительно зашифрованы.
Для взаимодействия с центральным сервером управления доступом ВУ
должно поддерживать запуск приложений, разработанных на одном из
высокоуровневых языков программирования.
Разрабатываемое ВУ должно поддерживать аварийный режим работы в
случае, если обмен данными между ВУ и центральным сервером управления
доступом перестает быть возможным (отсутствие соединения с сервером, отказ
в обслуживании на стороне сервера и т.п.). В аварийном режиме работы решение
о предоставлении пользователю доступа в помещение принимается на основе
локальной базы данных, расположенной на ВУ. Локальная база данных
11
представляет собой резервную копию сетевой базы данных доступа и содержит
информацию об администраторах системы. Таким образом, при аварийном
режиме работы, доступ в помещение может получить только сотрудник с
правами администратора. При этом разрабатываемое ВУ должно обладать
объемом памяти, достаточным для хранения и поддержки локальной базы
данных.
ВУ должно предоставлять веб-интерфейс для управления ВУ при
локальном Ethernet подключении. Данный веб-интерфейс должен содержать
внутренний журнал ВУ и обеспечить инициализацию ре зервного копирования
сетевой базы данных доступа. Таким образом, функциональные требования
могут быть сведены в общее представление (таблица 1).
Таблица 1. Функциональные требования к разрабатываемому ВУ
Функциональные № Описание
требования
К аппаратному
обеспечению
К программному
обеспечению
1
Обеспечение взаимодействия с внешними электронными
компонентами: механическими замками, сканерами
бесконтактных RFID-карт, инфракрасными датчиками
движения, устройствами вывода текстовой и звуковой
информации, звуковых и световых сигналов.
2
Обеспечение беспроводного канала передачи данных.
3
Обеспечение передачи данных через Ethernet.
4
Обеспечение обмена данными по HTTP, HTTPS, SOAP.
5
Обеспечение запуска приложений, написанных на JAVA, Python,
C++.
6
Обеспечение хранения локальной резервной копии базы данных
7
Обеспечение шифрования данных, передаваемых по каналам
передачи данных.
8
Обеспечение управления ВУ через веб-интерфейс при
локальном Ethernet подключении.
В случае выхода из строя электрической цепи, к которой подсоединено ВУ,
обеспечение энергией выполняет источник резервного питания. В подобной
ситуации функционирование ВУ не нарушается, но максимально возможное
12
время работы ВУ зависит от ёмкости источника и количества потребляемой им
энергии.
Стоимость
ВУ
рассчитывается
комплексно,
учитывается
микроконтроллер со всем множеством компонент. Таким образом, предпочтение
следует
отдавать
ВУ,
которое
удовлетворяет
всем
функциональным
требованиям и при этом оптимально по соотношению итоговая стоимость /
энергоэффективность. Предполагается, что устройство будет располагаться в
непосредственной близости от входа в помещение. ВУ должно обладать
соответствующими размерами, позволяющими разместить его на малой
площади. Наименьшей поверхностью в данной ситуации обладает дверь. Таким
образом, при встраивании в дверь ВУ должно быть не толще трех сантиметров,
при условии, что наиболее распространенная толщина двери четыре сантиметра.
Отметим, что толщиной менее трех сантиметров обладает большая часть
популярных микроконтроллеров.
Таким образом, нефункциональные требования могут быть сведены в
единую таблицу (таблица 2).
Таблица 2. Нефункциональные требования к разрабатываемому ВУ
Нефункциональные
требования
Описание
К
энергоэффективности
Обеспечение функционирования ВУ в условиях
выхода из строя электрической цепи, к которой
подсоединено ВУ, за счет энергии резервного
источника питания.
К стоимости
Минимизация стоимости микроконтроллера,
расширений микроконтроллера, сенсоров и
периферии, необходимых для соответствия
функциональным требованиям.
К занимаемому
пространству
Минимизация размеров микроконтроллера,
расширений микроконтроллера, сенсоров и
периферии, таким образом, чтобы толщина ВУ не
превышала толщины двери.
2.2 Выбор компонентов прототипа системы охраны периметра
13
В соответствии с функциональными требованиями (таблица 1), каждая из
рассматриваемых
альтернатив
должна
поддерживать
взаимодействие
с
внешними электронными компонентами: механическими замками, сканерами
бесконтактных карт технологии RFID, инфракрасными датчиками движения,
устройствами вывода текстовой, звуковой информации, звуковых и световых
сигналов. Набор внешних электронных компонент с их показателями по цене и
потреблению электроэнергии сведен в единую таблицу (таблица 3).
Таблица 3. Набор внешних электронных компонентов
Выбранное
физическое
устройство
Механический
замок
TowerPro SG90
Сканер
бесконтактных карт
технологии RFID
Grove 125KHz RFID
Reader
50 [16]
1296
Инфракрасный
датчик движения
PIR Motion Sensor
HC-SR501
0,05 [17]
216
Устройство вывода DC 5V Character
текстовой LCD 16x2
информации
100 [18] (при
поднесении
бесконтактной
карты к сканеру)
1080
Устройство вывода
звуковых сигналов
DC 12mA 5V
12mm Piezo Alarm
Buzzer
12 [17] (в момент
подачи сигнала)
216
Устройство вывода
световых сигналов
RGB Lightemitting
Diode
20 [19]
7.2
70,05 –
732,05 (среднее –
200)
2880
Итого
Потребление
(мАм/час)
Стоимость (руб.)
Внешний
электронный
компонент
550 [15] (в момент
открытия двери)
792
Таблица 4. Набор компонентов защиты
14
Описание
Набор
компонентов
защиты
Потребление Стоимость Размер
(₽)
(мм)
энергии
(мАч)
Arduino Yun, Внутренняя память Arduino Yun 500
microSD 512 ограничена 8 MB, чего
MB
недостаточно для соответствия
функциональным требованиям к
программному обеспечению.
Внутреннюю память Arduino
Yun можно расширить с
помощью microSD.
6768
73*53*8
В качестве источников резервного питания рассматриваются power bank,
так как их размер соответствует нефункциональным требованиям. Стоимость
power bank зависит от ёмкости и количества поддерживаемых циклов
перезарядки и равна 1280 руб. и 2560 руб. для ёмкостей в 12000 mAh и 30000
mAh.
Итоговый набор компонент защиты: Arduino Yun, microSD 512 MB,
TowerPro SG90, Grove 125KHz RFID Reader, PIR Motion Sensor HC-SR501, DC
5V Character LCD 16x2, DC 12mA 5V 12mm Piezo Alarm Buzzer, RGB Lightemitting Diode, power bank 12000 mAh
2.3 Описание и оценка компонентов прототипа спроектированной
системы охраны периметра
Архитектура системы представлена на рисунке 1:
1) микроконтроллер Arduino Yun состоит из двух частей:
− процессор ATmega 32U4 (выполняет требования 2, 3 из табл. II),
управляющий через sketch [28] сервоприводом, сканнером бесконтактных карт
технологии RFID, текстовым экраном, инфракрасным датчиком движения,
компонентами вывода световых и звуковых сигналов;
− процессор AR9331 под управлением Linux (выполняет требования 5, 6
из табл. II), содержащий Arduino_Client (выполняет требования 4, 7 из табл. II),
15
который выполняет роль посредника между ATmega 32U4 и Access_App_Server,
а также журналирует вход и выход пользователей из помещения;
2) Access_App_Server
предоставляет
удаленный
доступ
к
Access_DB_Server для Arduino_Client и для Admin_Client, а также
журналирует действия Admin_Client;
3) база данных Access_DB_Server содержит информацию о пользователях
системы, бесконтактных картах, ролях пользователей, устройствах и
правах доступа к помещениям для каждой из ролей;
4) Admin_Client осуществляет управление информацией, хранящейся в
базе данных Access_DB_Server, а также журналирование действий
администратора;
5) User_Client журналирует начало и завершение сеанса пользователя с
операционной системой;
6) Syslog_App_Server
предоставляет
удаленный
доступ
к
Syslog_DB_Server, а также осуществляет генерацию инцидентов
безопасности на основе корреляции журналов;
7) база данных Syslog_DB_Server содержит информацию о событиях и
инцидентах безопасности, происходящих в системе.
Рис. 1. Архитектура системы
16
В процессор ATmega 32U4 (1) загружается код, который называется sketch
. Любой sketch можно условно разделить на три части: блок инициализации, блок
прошивки,
блок
необходимые
исполнения.
для
работы
В
блоке
инициализации
sketchбиблиотеки,
подключаются
объявляются
глобальные
переменные, задаются специальные обозначения для цифровых или аналоговых
PIN. В блоке прошивки (setup(){}) осуществляется настройка Arduino, ее
подготовка для выполнения функционала, необходимого в блоке исполнения.
Блок исполнения (loop(){}) циклически выполняет записанный в нем код,
представляя собой алгоритмическое ядро sketch.
Взаимосвязь между ATmega 32U4 и AR9331 Linuxпроцессорами Arduino
Yun осуществляется при помощи библиотек Bridge.h и FileIO.h. Библиотека
Bridge.h позволяет запускать shellкоманды прямо из sketch, а FileIO.h дает
возможность считывать и записывать файлы, принадлежащие файловой системе
Linux.
Запуск Arduino_Client осуществляется из sketch благодаря библиотеке
Bridge.h посредством выполнения асинхронной (без ожидания завершения) shellкоманды. Дальнейшее взаимодействие между sketch и Arduino_Client строится
на обработке (чтение/запись) специальных текстовых (.txt) файлов. Это
происходит относительно быстро благодаря использованию библиотеки
FileIO.h. Запись осуществляется в специальном формате, напоминающем HTTP.
Arduino_Client представлен jar-приложением. Работу jarприложения
клиента можно разделить на два этапа: инициализация и функционирование. При
инициализации происходит проверка доступности сервера (2), настройка
параметров взаимодействия между AR9331 и ATmega, а также репликация
данных администраторов из Access_DB_Server в локальную базу данных и из нее
в
кэш.
Локальная
база
данных
хранит
реплицированные
данные
администраторов. Она необходима на случай, если Access_App_Server станет
недоступен. На этапе функционирования предусмотрено разбиение главного
потока на прикладные. Каждый поток обрабатывает запросы, приходящие от
Arduino, с некоторой периодичностью. В данный момент реализовано четыре
17
потока: первый обрабатывает запросы на получение доступа в помещение,
второй проверяет соединение с сервером, третий обеспечивает журналирование,
четвертый обновляет локальную БД с некоторой периодичностью или по запросу
от ATmega.
При помощи sketch также реализована Arduino_Web_Pannel вебстраница,
позволяющая просматривать локальные журналы устройства и инициировать
обновления локальной базы данных. Для получения доступа к веб-странице
необходимо прямое подключение к микроконтроллеру через Ethernet-кабель, а
также прохождение процедуры аутентификации.
Серверная часть (2) и (6) представлена каталогом сервлетов Tomcat [30],
на котором развернуто war-приложение. War-приложение разрабатывается в
рамках фреймворка Spring [31], который уже имеет готовые решения в области
доступа к базе данных (пакет DAOSupport) и реализации базовых требований к
безопасности (пакет Spring Security).
Посредником между war-приложением и базами данных (3) и (7) является
пул соединений C3P0, который основан на JDBC. C3P0 обеспечивает большую
гибкость соединения: он позволяет распределять подключения к базе данных для
разных пользователей с разными правами, а также реализует механизмы
управления нагрузкой.
База данных Access_DB_Server (3) содержит информацию о пользователях
системы, бесконтактных картах, ролях пользователей, устройствах и правах
доступа на эти устройства для каждой из ролей.
Клиентская часть администратора (4) представлена jarприложением,
запуск
которого
осуществляет
администратор,
предварительно
пройдя
процедуру аутентификации путем ввода логина и пароля.
Клиентская часть, расположенная на пользовательском компьютере (5),
представлена jar-приложением, запуск которого осуществляет операционная
система при успешной попытке входа/выхода в/из системы. При запуске клиент
(5) отправляет сообщение на Syslog_App_Server (6) с информацией о параметрах
входа в систему. При отсутствии сети (как правило, сеть появляется через
18
несколько секунд после входа в систему) клиент пытается отправить сообщение
с определенным интервалом вплоть до успешной отправки или выхода из
системы.
База данных Syslog_DB_Server (7) содержит информацию о событиях и
инцидентах безопасности, происходящих в системе.
Взаимодействие компонентов системы осуществляется в рамках сетевого
соединения при помощи HTTP-сообщений, так как сообщения обладают
большей надежностью, легко поддаются регулированию, поддерживают
асинхронное взаимодействие и обеспечивают легкую интеграцию. Сообщения
формируются по принципу построения GETзапросов, так как подобная
структура устойчива к ошибкам и обеспечивает легкость интеграции
компонентов.
Скорость отклика системы контроля доступа в помещение зависит от
скорости работы отдельных компонент ВУ. Так, скорость работы ATmega 32U4
зависит от скорости чтения бесконтактных карт технологии RFID и скорости
вывода текстовой информации, составляя 30,1 мс. Скорость взаимодействия
между ATmega 32U4 и AR9331 зависит от скорости чтения текстовых файлов и
записи в них, составляя в среднем 316,2 мс. Скорость обработки запросов и
ответов Access_App_Server составляет 47,1 мс и также может варьироваться в
зависимости от степени загруженности сервера или канала связи. Таким образом,
среднее время между моментом считывания RFID карты и выводом устройством
информации составляет 393,4 мс.
2.4 Оценка системы безопасности
2.4.1 Комплектность ИСБ
Система является некомплектной, так как объединяет менее четырех
основных систем безопасности.
2.4.2 Функциональность ИСБ
19
Система является высокофункциональной, так как передача информации
между системами происходит при выполнении системой своих штатных
функций.
2.4.3 Размер ИСБ
Система классифицируется как малая.
2.4.4 Масштабируемость
Система – масштабируемая и ограничена в возможности расширения.
2.4.5 Быстродействие ИСБ
Характеризуется высоким быстродействием, время отклика около 393,4
мс.
2.4.6 Отказоустойчивость/живучесть
Средняя живучесть, система имеет резервный источник питания, а также
возможность автономной работы.
2.4.7 Расширяемость
Система
расширяемая,
но
при
интеграции
слабо
совместимого
оборудования могут потребоваться дополнительные модули, которые понизят
быстродействие и отказоустойчивость.
2.5 Выводы по разделу
В данном разделы были разработаны требования для системы мониторинга
с учетом стандартов, предъявляемым к подобным системам и подсистемам.
Разработана система мониторинга с учетом ранее сформированных требований,
так же оценена с помощью критериев полученных в первой главе.
Описанное устройство может использоваться в любом охраняемом
помещении с ограниченным доступом как самостоятельная система или как
интегрируемая подсистема.
20
Заключение
В результате курсовой работы была разработана и оценена автономная
система мониторинга событий безопасности на базе одноплатного компьютера
Arduino
В ходе работы были обозначены и решены следующие задачи:
 провести анализ систем сбора и анализа событий безопасности и выявить
 разработать и произвести оценку системы мониторинга событий с
использованием Arduino
В результате решения данных задач были сделаны следующие выводы.
При определении основных категорий и компонентов, выяснено, основные
недостатки такой системы – отсутствие децентрализации и автономных
подсистем.
Исследованы и возможности использования одноплатных компьютеров в
системах мониторинга событий безопасности. Также, разработана система для
пропускного пункта на охраняемую территорию.
В результате оценки разработанной системы, она не только не уступает
существующим аналогам в эффективности, но и превосходит их в возможности
масштабируемости, взаимодействия с внешними системами, а также живучести.
21
Список используемых источников
1.
Системы мониторинга событий безопасности // anti-malware URL:
https://www.anti-malware.ru/security/security-monitoring
(дата
обращения:
15.04.2021).
2.
Критерии оценки интегрированной системы безопасности // secuteck
URL:
http://secuteck.ru/articles2/pronsol/kriterii_ocenki_integrirovannoi_sistemi_bezopasn
osti_isb_page171 (дата обращения: 15.04.2021).
3.
Arduino Yun Rev 2 // amperka URL: https://amperka.ru/product/arduino-
yun-rev-2 (дата обращения: 15.04.2021).
4.
Vasilevskaya M. Designing Security-enhanced Embedded Systems:
Bridging Two Islands of Expertise // PhD thesis. Linkoping Studies in Science and
Technology. Sweden. 2013.
5.
Desnitsky V., Kotenko I., Chechulin A. Configuration-based approach to
embedded device security // Springer-Verlag. 2012. LNCS. 7531.
6.
Desnitsky V., Kotenko I. Expert Knowledge based Design and
Verification of Secure Systems with Embedded Devices // Springer-Verlag. 2014.
LNCS 8708.
7.
Henzinger T., Sifakis J. The Embedded Systems Design Challenge //
Springer-Verlag. LNCS 4085. 2006.
8.
Object Management Group. The UML Profile for MARTE: Modeling and
Analysis of Real-Time and Embedded Systems. version 1.1. 2011.
9.
Hwang D., Schaumont P., Tiri K., Verbauwhede I. Securing Embedded
Systems // IEEE Security and Privacy. 2006.
10.
Knezevic M., Rozic V., Verbauwhede I. Design Methods for Embedded
Security // Telfor Journal. 2009.
11.
Moyers B., Dunning J., Marchany R., Tron J. Effects of Wi-Fi and
Bluetooth Battery Exhaustion Attacks on Mobile Devices // Proceedings of the 43rd
22
Hawaii International Conference on System Sciences (HICSS'10). IEEE Computer
Society. 2010.
12.
Gogniat G., Wolf T., Burleson W. Reconfigurable Security Primitive for
Embedded Systems // Proceedings of International Symposium on In System-on-Chip.
2005.
13.
Nojmol I. How can Access Control Systems Improve Security and Reduce
Costs? //
14.
Public Sector Estates Management, September. 2014. 8 p. URL:
http://www.assaabloy.co.uk/Other/ASSA/ASSA%20ABLOY/
White%20Papers/ASSA_Smartair_Whitepaper%20V3.pdf
(дата
обращения
15.04.2021).
15.
Ruiz J., Harjani R., Maña A., Desnitsky V., Kotenko I., Chechulin A. A
Methodology for the Analysis and Modeling of Security Threats and Attacks for
Systems of Embedded Components // Proceedings of the 20th Euromicro International
Conference on Parallel, Distributed and Network-Based Computing (PDP2012).
Munich. Germany. 2012.
16.
Rae A., Wildman L. A Taxonomy of Attacks on Secure Devices //
Australian Information Warfare and IT Security. 2003.
17.
Abraham D., Dolan G., Double G., Stevens J. Transaction security system
// IBM Systems Journal. 1991.
18.
Intel
Galileo
distributor shop.
URL:
http://newegg.com/
(дата
обращения: 15.04.2021).
19.
Electronic shop. URL: http://nettigo.pl/ (дата обращения: 15.04.2021).
23