- •2.1. Забезпечення безпеки конфіденційної інформації за допомогою програмних продуктів компанії InfoWatch 20
- •3.6. Особливості розгортання субд Oracle 102
- •3.7. Вирішення проблем 106 вступ
- •1. Контроль та захист інформації від внутрішніх загроз
- •1.1 Інформація та ризик
- •1.2 Забезпечення безпеки конфіденційної інформації за допомогою програмних продуктів компанії InfoWatch
- •1.2.1 InfoWatch Mail Monitor
- •1.2.2 InfoWatch Web Monitor
- •1.2.3 InfoWatch Device Monitor
- •1.2.3 InfoWatch Mail Storage
- •1.2.4 InfoWatch Net Monitor
- •1.2.5 InfoWatch Enterprise Solution
- •Структура InfoWatch Enterprise Solution наведена на рисунку 6.
- •1.3 Сервіси
- •Розділ 2. Засоби та методи захисту мереж від витоків інформації
- •2.1. Забезпечення безпеки конфіденційної інформації за допомогою програмних продуктів компанії InfoWatch
- •2.1.1. Склад Traffic Monitor
- •2.1.2. Traffic Monitor Server
- •2.1.3. Traffic Monitor isa Server Plugin
- •2.1.4. Traffic Monitor Security Administrator
- •2.1.5. Traffic Monitor Security Officer
- •2.1.6. Traffic Monitor db Administrator
- •2.1.7. Traffic Monitor Analyser
- •2.1.8. Traffic Monitor Eraser
- •2.1.9. Схема роботи Traffic Monitor
- •2.1.10. Розподіл ролей
- •2.2. Принципи фільтрації
- •2.2.1. Загальний аналіз листа
- •2.2.2. Контентний аналіз листа
- •2.2.3. Дії над листами
- •2.3. Фільтрація Web-пошти
- •2.3.1. Цикл обробки Web-пошти
- •2.3.2. Особливості обробки Web-пошти
- •2.3.2.1. Авторизований і неавторизований режими роботи Web-фільтра
- •2.3.2.2. Обробка форм авторизації
- •2.3.2.3. Визначення кодування листа
- •2.4. Профілі фільтрації
- •2.4.1. Спеціальні заголовки
- •InfoWatch-Formal-Categories;
- •InfoWatch-WebMail-Fin.
- •2.4.2. Виявлення ознак порушення
- •2.5. Робота з Traffic Monitor Security Administrator
- •2.5.1. Головне вікно програми
- •2.5.2. Дерево конфігурацій
- •2.5.3. Конфігурація сервера контентної фільтрації
- •2.6. База профілів
- •2.6.1. Правила фільтрації
- •2.6.2. Призначення умов і дій у правилі фільтрації
- •2.7. Списки адрес
- •2.8. Робота з Traffic Monitor Security Officer
- •2.8.1. Головне вікно програми
- •2.8.2. Пошук листів
- •2.8.3. Моніторинг і аналіз листів
- •2.8.4. Перегляд листів
- •2.8.5. Ухвалення рішення
- •2.8.6. Робота з листами
- •2.8.8. Довідник X-InfoWatch-Status
- •2.9. Робота з Traffic Monitor db Administrator
- •2.9.1. Головне вікно програми
- •2.9.2. Керування обліковими записами
- •2.9.3. Сегменти даних
- •2.9.4 Перегляд статистики
- •2.10. Робота з Traffic Monitor Analyser
- •2.10.1. Головне вікно програми
- •2.10.2. Аналіз листів
- •2.10.3. Перегляд листів
- •2.10.4. Робота з листами
- •2.11. Робота з Traffic Monitor Eraser
- •2.11.1. Головне вікно програми
- •2.11.2. Пошук листів
- •2.11.3. Перегляд листів
- •2.12. Утиліта архівування
- •Розділ 3. Встановлення та конфігурування системи traffic monitor
- •3.1. Вимоги до апаратного та програмного забезпечення
- •3.1.1. Traffic Monitor Server
- •3.1.2. Traffic Monitor isa Server Plugin
- •3.1.3. Traffic Monitor Security Administrator, Traffic Monitor Security Officer
- •3.1.4. Traffic Monitor db Administrator, Traffic Monitor Analyser, Traffic Monitor Create Database Wizard, Traffic Monitor Eraser
- •3.2. Traffic Monitor Create Database Wizard
- •3.3. Створення схем баз даних
- •3.4. Traffic Monitor Server
- •3.4.1. Підготовка до встановлення
- •3.4.2. Встановлення Traffic Monitor Server
- •3.4.3. Настроювання Traffic Monitor Server
- •3.4.4. Настроювання з'єднання із сервером субд Oracle
- •3.4.5. Настроювання інтеграції з Postfix
- •3.4.6. Взаємодія із серверами субд Oracle
- •3.5. Traffic Monitor isa Server Plugin
- •3.5.1. Встановлення Traffic Monitor isa Server Plugin
- •3.5.2. Настроювання Traffic Monitor isa Server Plugin
- •3.6. Особливості розгортання субд Oracle
- •3.6.1 Вимоги до обов'язкового набору функціональності субд Oracle
- •3.6.2. Короткий опис процесу установки
- •3.6.3. Вирішення проблеми зв'язку із сервером субд Oracle
- •3.7. Вирішення проблем
- •Перелік використаних джерел
2.1.8. Traffic Monitor Eraser
Після обробки сервером поштової фільтрації всі листи зберігаються в базі даних. Виключення становлять ті листи, для яких за умовами фільтрації виконується дія Не зберігати в базі даних. Таким чином, обсяг бази даних постійно збільшується. Зменшити обсяг і тим самим звільнити місце на жорсткому диску можна шляхом видалення тих листів, подальше зберігання яких у базі даних не потрібно. Для виконання даного завдання призначена програма Traffic Monitor Eraser.
У програмі Traffic Monitor Eraser відображаються тільки ті листи, які вже оброблені сервісом Deferred processor.
Працювати із програмою Traffic Monitor Eraser може користувач, якому призначена роль Чистильника. У процесі роботи Чистильник може переглядати відомості тільки про основні заголовки листа й не має доступу до інформації про зміст тіла листа, наявності й змісту вкладень. Основною функцією Чистильника є видалення листів з бази даних.
2.1.9. Схема роботи Traffic Monitor
Робота системи Traffic Monitor відбувається в такий спосіб:
Потік листів корпоративної електронної пошти направляється в чергу повідомлень (Локальне сховище повідомлень сервера поштової фільтрації), що очікують перевірки сервером контентной фільтрації.
Перехоплення вихідних запитів до сайтів Web-пошти, форумів і т.д. здійснюється модулем фільтрації POST-запитів. З перехоплених POST-запитів формуються SMTP-листи, які обробляються сервером контентной фільтрації.
Сервер контентной фільтрації, що є частиною сервера поштової фільтрації, виконує аналіз листів відповідно до заданих правил фільтрації.
Для складання правил фільтрації листів використовуються:
База профілів, що визначають методи класифікації листів по формальних ознаках.
База контентного аналізу, у якій задаються параметри класифікації листів:
контентні категорії (категорії утворять ієрархічну структуру з довільною кількістю вкладених рівнів);
набір термінів і зразків листів, які задаються в межах кожної контентной категорії.
База профілів і база контентного аналізу утворять конфігурацію сервера контентной фільтрації. Створення й настроювання конфігурації, а також завантаження готової конфігурації на сервер контентной фільтрації виконує Адміністратор інформаційної безпеки за допомогою програми Traffic Monitor Security Administrator.
База профілів і база контентного аналізу являють собою формальну реалізацію корпоративної політики безпеки (або її частини) у термінах Traffic Monitor. При цьому база контентного аналізу використовується для класифікації листів по змісту, а база профілів являє собою набір правил, що реалізують вимоги корпоративної політики безпеки на основі формальних атрибутів листів і класифікації по базі контентного аналізу.
Відповідно до корпоративної політики безпеки приймається рішення про затримку листа або про доставку листа одержувачам.
При відсутності ознак порушення корпоративної політики безпеки виконується доставка листів одержувачам:
Листи корпоративної електронної пошти доставляються на корпоративний поштовий сервер для відправлення зазначеним адресатам.
Листи Web-пошти доставляються фільтруючим Proxy-сервером (ISA-сервер із установленим модулем фільтрації POST-запитів) на зовнішні сервери Web-пошти (або вищестоящий корпоративний Proxy-сервер).
Доставка листів, визнаних такими, що порушують корпоративну політику безпеки, блокується.
За результатами фільтрації листу приписується ряд ознак, фіксованих у додаткових заголовках листа. Далі виробляється запис листів у базу даних:
Копії листів, у яких сервер контентной фільтрації не виявив ознак порушення корпоративної політики безпеки, зберігаються в архіві.
Листи, що зберігаються в архіві, можуть бути експортовані з бази даних у зазначене місце за допомогою утиліти архівування. Працювати з утилітою архівування може користувач, якому призначені права власника схеми бази даних.
Листи, доставка яких блокована сервером контентної фільтрації, перенаправляються в карантин.
У карантині зберігається:
Лист із MIME заголовками, які додаються/модифікуються сервером контентной фільтрації.
Вихідний набір MIME-заголовків листа (на випадок, якщо Офіцер безпеки дозволить доставку листа).
Список одержувачів листа, з SMTP-конверта (атрибутів POST-запиту у випадку Web-листів), або змінений список одержувачів (якщо політика безпеки вимагає зміни списку одержувачів для даного листа). Даний список використовується при ухваленні рішення Офіцером безпеки про доставку затриманого листа.
Атрибути, привласнені листу в результаті перевірки: статус і контентна категорія. Значення даних атрибутів відображаються в програмі Traffic Monitor Security Officer.
Описаний принцип укладання листів у базу даних не поширюється на ті випадки, коли в правилі фільтрації задана дія Не зберігати в базі даних. Листи, що попадають під дію такого правила фільтрації, у базі даних зберігатися не будуть.
У карантині виробляється розбір листа: виділяються заголовки листа, тіло й вкладення, розкриваються архіви. Отримані частини листа індексуються для контентного пошуку.
Листи, що надходять у карантин (тобто листи, у яких виявлені порушення корпоративної політики безпеки), відображаються в програмі Traffic Monitor Security Officer. Офіцер безпеки перевіряє, чи дійсно даний лист порушує корпоративну політику безпеки.
При підтвердженні факту порушення Офіцер безпеки формує висновок по даному листу. Висновок з коментарями із приводу виявлених порушень відправляється особам, відповідальним за ухвалення остаточного рішення про те, які дії варто почати з даним листом.
Офіцер безпеки може за своїм розсудом дозволити доставку листа. Лист буде доставлено визначеним адресатам, або за списком адресатів, сформованому в ході обробки листа сервером поштової фільтрації.
Описана схема відповідає роботі системи Traffic Monitor у режимі затримки листів, що порушують корпоративну політику безпеки. Однак система Traffic Monitor може працювати в режимі прослуховування. Режим прослуховування відрізняється від режиму затримки тим, що вся корпоративна пошта доставляється зазначеним адресатам. У карантин при цьому розміщуються не самі листи, що порушують корпоративну політику безпеки, а копії таких листів. Реалізація режиму прослуховування виконується шляхом настроювання профілів фільтрації.
