Реализация программной системы для предотвращения внутренних утечек корпоративных данных | Вестник Томского государственного университета. Управление, вычислительная техника и информатика. 2014. № 1(26).

Реализация программной системы для предотвращения внутренних утечек корпоративных данных

Рассматриваются подходы к созданию программных систем для предотвращения внутренних утечек данных. Автор представляет две архитектуры программных систем. Первая архитектура применима для клиент-серверных программных приложений и использует драйвер СУБД промежуточного уровня. Вторая архитектура служит для защиты многоуровневых программных систем и использует агенты по сбору статистики. В качестве метода предотвращения утечек данных оба решения применяют анализ поведения пользователей программных приложений. В статье описаны форматы и способы хранения статистических данных о действиях пользователей и их профилей.

Implementation of Software system for prevention of internal data leaks.pdf Доступные статистические данные свидетельствуют о том, что количество случаев утечек данных ежегодно увеличивается [1]. В качестве средств предотвращения внутренних утечек данных используются аппаратные и программные решения. Аппаратные средства часто реализуются как вычислительное устройство, подключенное к корпоративной сети для исследования трафика с помощью технологии глубокого исследования сетевых пакетов (deep packet inspection) [2]. Распространенными методами в системах предотвращения утечек данных являются статистический анализ и лингвистический анализ. Использование сетевых экранов, своевременное обновление программного обеспечения, установка прав доступа - эффективные меры для снижения рисков внешних утечек данных. Значительно труднее выявить и предотвратить хищения корпоративной информации, совершенные в результате умышленных действий сотрудников предприятия [3]. Информация о случаях внутренней утечки данных несет большие репутационные риски, поэтому значительная ее часть не присутствует в официальной статистике [4]. Сотрудников предприятия можно условно разделить на две категории: универсальные сотрудники (директоры, руководители и другие лица с широкими полномочиями) и сотрудники с фиксированным перечнем обязанностей (специалисты). Именно для второй группы сотрудников могут быть созданы поведенческие профили. Ежедневно в течение рабочего дня такие сотрудники пользуются разными источниками данных, формируют отчеты, обращаются к справочникам, создают новые записи. Поведение пользователя меняется в случае целенаправленной выгрузки данных. Частота обращения к определенным источникам данных, количество просмотров записей определенной категории и другие параметры могут измениться. Архитектуры программной системы, представленные далее, могут уменьшить риски внутренних утечек данных с помощью анализа поведения пользователей программного обеспечения. Решение проблемы Представленные далее архитектуры имеют общий компонент «Обработчик статистики» и отличаются способом сбора информации о действиях пользователей. «Обработчик статистики» хранит статистические данные, получаемые при выполнении каждого значимого действия пользователя или его запроса к источнику данных; на основании собранной ранее статистики определяет безопасность текущего действия пользователя. Первая архитектура ориентирована на защиту клиент-серверных (клиент-СУБД) приложений (рис. 1). Для сбора статистики о поведении пользователей в данной архитектуре используется ODBC-драйвер промежуточного уровня. Данный компонент зависит от платформы и используемой СУБД, является поставщиком статистических данных и ответствен за запрет выполнения подозрительных запросов (рис. 2). Сервер | | ODBC-драйвер | промежуточного -| I уровня -1=_11_ СУБД 1 /\- Клиент IZZI ODBC driver ] ODBC-драйвер -ж- Обработчик статистики |=Ъ |=р Клиент izb / Рис. 1. Базовая архитектура №1 I I I Рис. 2. Схема выполнения запроса через промежуточный ODBC-драйвер Промежуточный ODBC-драйвер позволяет полностью контролировать запросы к источнику данных и прерывать их в случае необходимости. В многоуровневой программной системе авторизацию пользователей проводит сервер приложений. В этом случае с помощью драйвера промежуточного уровня невозможно идентифицировать пользователя ввиду того, что обращение к базе данных происходит от учетной записи сервера приложений. Также современные системы программных приложений обращаются к нескольким источникам данных, в том числе к веб-сервисам. Второе архитектурное решение ориентировано на защиту многоуровневых систем программных приложений (см. рис. 3). В данной архитектуре отслеживаются значимые действия пользователей, а не отдельные запросы к базе данных. Необходимость разработки дополнений к используемым информационным системам на предприятии является недостатком этой архитектуры. На диаграмме компонентов (рис. 3) также присутствует компонент «Инструмент администрирования», являющийся веб-приложением. Данное веб-приложение предоставляет графический интерфейс для управления настройками обработчика статистики, просмотра уведомлений и профилей пользователей. Рис. 3. Базовая архитектура № 2 Обе архитектуры используют два хранилища данных: хранилище статистики действий пользователей и хранилище профилей пользователей. Диаграмма потоков данных приведена на рис. 4. Рис. 4. Диаграмма потоков данных История действий пользователей и сформированные профили пользовалей хранятся в документно-ориентированной БД MongoDB. Также в этом хранилище хранятся настройки обработчика статистики и уведомления. Формат хранения данных - JSON. Данные о действиях пользователей достаточно объемны, но имеют простую схему. Их хранение в документно-ориентированном хранилище может обеспечить большую масштабируемость и производительность в сравнении с реляционной базой данных. Информация о действии пользователя отправляется обработчику статистики асинхронным способом и включает следующие поля: 1. Имя пользователя (логин), роль пользователя. 2. Тип инструмента. Программные приложения предоставляют широкий набор инструментов. Справочники, средства составления отчетов, обработки, специальные графические интерфейсы (интерфейс наблюдения за статистикой продаж, интерфейс сотрудника ca/l-центра, интерфейс "Рабочее место кассира"). Тип инструмента передается в виде строковой константы из заранее определенного перечня. 3. Название программного приложения. 4. Название инструмента в составе программного приложения. Например, если пользователь открывает справочник "Контрагенты", то в качестве названия передается значение "Контрагенты". 5. Список коллекций данных, к которым обратился пользователь. Коллекция - произвольный набор данных одного типа независимо от используемого хранилища. При использовании реляционного хранилища названием коллекции является название таблицы или представления. 6. Тип выполненной операции. Операции условно разделены на пять типов: просмотр коллекции (списка, таблицы), просмотр детальной информации об отдельной записи, создание, удаление, редактирование. Данный параметр также передается в виде строковой константы. 7. Данные или их часть, которые получил или сохранил пользователь в виде JSON-объекта. 8. Категория данных. Следующая JSON-строка является примером статистики о действии пользователя: ("user": "Svetlana", "tool": "prebuild_report", tool_name:"daily sales report", "entities": ["sales", "employees", "shops"], "operation":"view_col", "app": "1C_Retail", "data":{"category": "null", "date": "06-03-2014", search_query: "Иван Федоров" }}. Собранная информация о действиях пользователей является входными данными для процесса построения и обновления профилей пользователей, выполняемого обработчиком статистики по расписанию. Профиль пользователя представляет собой описание ежедневной работы с источниками. Для каждого пользователя создаются поведенческие профили за разные временные промежутки (профиль предыдущего дня, профиль последних 30 дней и др.). Выявление факта утечки данных происходит путем сравнения параметров текущей работы пользователя с его профилями (рис. 5). Несмотря на то, что ложные уведомления о возможных утечках данных неизбежны, использование нескольких профилей для каждого пользователя может уменьшить их количество. Итоговая оценка безопасности действия пользователя формируется в результате сложения независимых оценок с каждым из профилей. Областью использования программной системы, описанной в статье, являются предприятия, работающие с персональной информацией, и предприятия, работающие со сведениями, представля- Рис. 5. Сравнение с профилями Заключение ющими коммерческую или государственную тайну. Предполагается, что использование системы предотвращения утечек данных целесообразно при количестве пользователей, превышающем 100 человек. Статистика о поведении пользователей, собираемая представленным программным решением, может быть использована для анализа производительности труда сотрудника предприятия или для анализа использования рабочего времени сотрудником. Благодаря наличию данных об используемых инструментах также можно выявить, насколько те или иные программные приложения или инструменты программных приложений востребованы и наиболее часто используются сотрудниками предприятия.

Ключевые слова

software system, software users' behavior, data leaks, DBMS, information security, СУБД, программная система для предотвращения утечек данных, внутренние утечки данных, поведение пользователей, утечки данных, информационная безопасность

Авторы

ФИООрганизацияДополнительноE-mail
Банокин Павел ИвановичТомский политехнический университетаспирант, ассистент кафедры автоматики и компьютерных систем Института кибернетикиpavel805@gmail.com
Вичугов Владимир НиколаевичТомский политехнический университеткандидат технических наук, доцент кафедры автоматики и компьютерных систем Института кибернетикиvlad@aics.ru
Всего: 2

Ссылки

Data Leakage Worldwide: The High Cost of Insider Threats // Cisco. URL: http://www.cisco.com/en/US/solutions/ collateral/ns170/ns896/ns895/white_paper_c11-506224.pdf
Data breach investigations report 2012 // Verizon Enterprise Solutions Worldwide Site. URL: http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf
Data Loss Statistics // Data Loss DB. URL: http://datalossdb.org/statistics
Brandel M. Data Loss Prevention Dos and Don'ts. URL: http://www.csoonline.com/article/221272/data-loss-preventiondos-and-don-ts
 Реализация программной системы для предотвращения внутренних утечек корпоративных данных | Вестник Томского государственного университета. Управление, вычислительная техника и информатика. 2014. № 1(26).

Реализация программной системы для предотвращения внутренних утечек корпоративных данных | Вестник Томского государственного университета. Управление, вычислительная техника и информатика. 2014. № 1(26).

Полнотекстовая версия