Як технології ABBYY допомагають поліпшити роботу систем виявлення витоків даних

Незважаючи на прогнози про швидке настання світлого безпаперового майбутнього, обсяг паперових документів все ще величезний. Частина з них сканується і продовжує свою «життя» вже в електронному варіанті – але тільки у вигляді зображень. В середньому в організаціях обсяг сканованих копій становить 30% від всіх документів, які зберігаються в електронному вигляді. В держсекторі він досягає 41,5%, в ритейлі – 17%, у сфері послуг – 23%, в банках і телеком-галузі наближається до 45%. Коли скани документів лежать собі в потрібній папці або роблять роботу, для якої вони призначені, – це добре. Погано, коли хтось намагається використовувати дані з цих сканів у шахрайських схемах або якось інакше зловживати ними. Щоб конфіденційна інформація не «витекла», інформаційні системи компаній встановлюють DLP – системи запобігання витокам.

Сьогодні ми розповімо, як в одну з таких програм – Контур інформаційної безпеки SearchInform був інтегрований SDK-продукт ABBYY FineReader Engine і що з цього вийшло.

Ми вважаємо, що не всі читачі блогу ABBYY добре розбираються в інформаційній безпеці, тому спочатку коротко опишемо, як взагалі працює Контур інформаційної безпеки. Якщо ви – завсідник хаба «ІБ» і знайомі з принципами роботи DLP-систем, можна пропустити цей розділ.

Як працює DLPКонтур інформаційної безпеки SearchInform призначений для контролю інформаційних потоків в рамках локальної обчислювальної мережі. Контроль можливий двома способами, в залежності від використовуваного серверного компонента: в мережі, або на робочих станціях користувачів. Серверні компоненти являють собою платформи, на яких працюють модулі перехоплення даних. Кожен модуль перехоплення виступає в ролі аналізатора трафіку і контролює свій канал передачі даних.

Перший модуль перехоплює і при необхідності блокує інформаційні потоки на рівні мережі. Він дозволяє працювати з зеркалируемым трафіком, проксі-серверами, поштовими серверами та іншим корпоративним ЗА, наприклад, Lynс. Мережевий трафік перехоплюється на рівні мережевих протоколів (пошта, інтернет, месенджери, FTP, хмарні сховища). Другий – перехоплює і блокує інформацію за допомогою агентів, які встановлюються на комп'ютери співробітників. При цьому контролюються: інтернет, корпоративна і особиста електронна пошта, всі популярні месенджери (Viber, ICQ, тощо), Skype, хмарні сховища, FTP, Sharepoint, висновок документів на принтери, використання зовнішніх пристроїв зберігання. Контролюється файлова система, активність процесів і сайтів, інформація, що відображається на моніторах ПК і вловлюється мікрофонами, натиснуті клавіші, доступно віддалене онлайн-спостереження за ПК.

Система також дозволяє індексувати документи «в спокої» — на робочих станціях користувачів або мережевих пристроях – і може індексувати будь-яку текстову інформацію з будь-яких джерел, які мають API або можливість підключення через ODBC.

Конфіденційну інформацію, яка не повинна «витекти» система шукає різними способами: за ключовими словами з урахуванням морфології і синонімів, по фразах з урахуванням порядку слів і відстані між ними, за атрибутами або за ознаками документів (форматом, імені відправника або одержувача та ін). Алгоритми аналізу настільки чутливі, що здатні знайти навіть серйозно змінений документ, якщо він близький за змістом або змістом з «еталоном»

У системі можна задавати політики безпеки і стежити за їх виконанням. DLP вміє збирати статистику і створює звіти за випадками порушення політики безпеки.

Архітектура системи – для цікавляться – добре описана у цьому огляді, не будемо повторюватися.

Більшу частину завдань у DLP вирішує аналіз тексту. Але, як ми пам'ятаємо, у багатьох компаніях зберігається і передається різними каналами велика кількість сканів (зображень) документів. Якщо залишити картинку «як є» – картинкою, DLP-система не зможе з нею працювати. Щоб система зрозуміла, яка інформація міститься на зображенні і чи можна її зберігати/передавати тим або іншим способом, картинку потрібно розпізнати і отримати текст. При цьому на вхід подаються різні зображення, і якість їх може бути абсолютно різним. Якщо у перехоплення потрапляє нечітка картинка, доводиться працювати з тим, що є, не просити ж користувача відправити її знову, в більш високій якості.

DLP-система SearchInform і раніше була оснащена технологією OCR. Але цей двигун мав серйозні недоліки як в якості розпізнавання, так і в швидкості. Розробка власного движка для SearchInform сенсу не мала, тому почали шукати готові технології. Зараз у модулі SearchServer в якості движка повнотекстового розпізнавання можна використовувати технології ABBYY.

Як відбувалася інтеграція FineReader Engine в систему
Розробка поділилася на два напрямки. По-перше, потрібно було легко інтегрувати технології ABBYY і створити зручний для користувачів DLP модуль розпізнавання. По-друге, адаптувати технології розпізнавання та класифікації документів ABBYY під прикладні задачі.

Перша задача була вирішена швидко: вона була реалізована через власний преднастроенный інсталятор в DLP-системи. Розгортання модуля OCR на базі технології ABBYY зводиться до встановлення додаткового компонента в стилі «далі – далі», і активації потрібної «галочки» у DLP. Компонент встановлюється на сервер DLP, тому ніяка налаштування для «з'єднання» DLP і OCR не потрібно в принципі, більше користувачеві нічого не потрібно робити.



Включення FineReader Engine реалізовано через інтерфейс DLP, включається в один клік шляхом вибору відповідного пункту з випадаючого списку. Тут же доступні більш детальні налаштування (при бажанні).



Більш того, користувачу не потрібно взаємодіяти з ABBYY, ліцензування FineReader Engine здійснюється SearchInform на рівні ліцензії до DLP. Реалізація вийшла справді дружня користувачу і сподобалася клієнтам SearchInform.

З другим завданням – адаптацією технології ABBYY під прикладні завдання – роботи було значно більше.

Коли програмісти SearchInform почали вивчати технології, то виявили масу можливостей, потенційно корисних для вирішення ІБ-завдань. Всі звикли, що ABBYY – це, насамперед, OCR. Але FineReader Engine вміє ще й класифікувати документи по зовнішнім виглядом і змістом. Щоб налаштувати процес класифікації, на першому етапі треба визначити категорію, за якою будуть розподілятися документи (наприклад, «Паспорт», «Договір», «Чек»). Після цього програму потрібно навчити: «показати» документи, відповідні кожному класу у всіх можливих варіантах оформлення.

Як працює класифікатор у FineReader EngineДля того щоб така машинка запрацювала, класифікатор спочатку потрібно навчити. Ви підбираєте невелику базу документів, що представляють кожну категорію, яку ви ходите визначати. За допомогою цієї бази ви навчаєте класифікатор. Потім берете іншу базу, перевіряєте роботу класифікатора на ній, і якщо результати вас влаштовують, можна пускати класифікатор «в бій».

При роботі та навчанні класифікатор використовує набір ознак, що допомагають відокремити документи одного типу документів від іншого типу. Всі ознаки можна умовно розділити на графічні та текстові.

Графічні ознаки добре розділяють групи документів, сильно зовні відрізняються один від одного. Умовно кажучи, якщо ви дивитеся видали документ так, що не можете прочитати текст на ньому, але можете зрозуміти, який у нього тип, то графічні ознаки тут будуть добре працювати.

Так, графічні ознаки можуть добре відокремлювати злитий і неслитный текст, наприклад, листи і платіжні квитанції. Вони дивляться на розмір зображення, щільність кольорів в різних його частинах, різні інші характерні елементи на зразок вертикальних і горизонтальних ліній.

А якщо зовні документи схожі, або одну групу, не читаючи текст, не можна відокремити від іншої групи, то допомагають текстові ознаки. Вони дуже схожі на ті, що використовуються в спам-фільтрах і дозволяють по характерним словами визначати належність документа до того чи іншого типу. Відокремлювати листи від договорів, чеки від візитних карток зручно саме з допомогою текстових ознак.

Також текстові ознаки допомагають відокремлювати документи схожого вигляду, але що відрізняються значенням одного або декількох полів. Наприклад, чеки з Макдональдса і Теремка зовні дуже схожі, але якщо розглядати їх як текст, то відмінності будуть дуже помітні.

У підсумку класифікатор для кожної навчальної вибірки дає більшу вагу тим текстовим або графічним ознаками, які дозволяють найкращим чином розділяти документи з цієї вибірки за типами.

Як реалізована класифікація в зв'язці DLP + ABBYY
Розробники SearchInform поставили в програмі кілька категорій документів, які могли знадобитися користувачам у першу чергу – різні типи паспортів та банківські картки.
Категоризація паспортів і кредиток починає працювати у користувача без навчання системи, фактично відразу після розгортання FineReader Engine. Користувачеві досить включити в налаштуваннях класифікатор – і всі нові документи будуть розбиратися по категоріях, для класифікації документів з архіву потрібно просто перезапустити по них перевірку.

Разом з тим, користувачеві залишена можливість створювати додаткові категорії. Він сам може задавати будь-які класи (категорії), або додавати свої документи наявні (паспорта і кредитки). Для цього йому потрібно створити в спеціальній папці з назвами класів, покласти туди еталони документів і запустити процес навчання. Ця процедура зазвичай виконується спільно з інженерами SearchInform, які все наочно демонструють і розповідають про вимоги до зображень, спільно з замовником формують базу еталонів, радять, які документи краще підійдуть як еталони тієї чи іншої категорії. Відразу після установки йде перевірка на реальних даних, часто після перевірки потрібна перенастроювання, невелика коректування налаштувань або еталонів. Зазвичай ця процедура займає півгодини-годину.

Точність класифікації залежить від того, наскільки система зможе «побачити» різницю між документами в різних категоріях. Якщо на навчання у двох різних категоріях подати документи, подібні за зовнішнім виглядом і містять багато однакових ключових слів, технологія почне плутатися і точність класифікації знизиться.

Так, при детектуванні сканів тільки головної сторінки паспортів інженери SearchInform зіткнулися з великою кількістю помилкових спрацьовувань. Алгоритм ABBYY знаходив в архіві з 10 000 зображень 300 малюнків, схожих на паспорти, в той час як паспортів там було всього кілька штук.

Якщо для довільних категорій це допустимий відсоток релевантності, то для ключових об'єктів, наприклад, кредиток, це дуже велика похибка. Аби покращити рівень релевантності інженери SearchInform розробили ще і власні алгоритми перевірки, які застосовуються вже до результатів класифікації ABBYY. Для кожної категорії даних був створений індивідуальний валідатор, який працює тільки зі своєю групою.

Як система DLP + ABBYY працює з зображеннями
Обробкою даних у DLP займається спеціальний компонент – SearchServer. Коли цей компонент знаходить у перехоплених даних зображення (причому не важливо, це частина документа або окрема картинка), він передає його в модуль FineReader Engine, який виконує оптичне розпізнавання і класифікує зображення за певних категорій. Причому разом з категорією FineReader Engine віддає і «відсоток схожості» зображення на відповідний клас, наприклад, зображення №1 схоже на паспорт на 83%, зображення №2 схоже на водійське посвідчення на 35%. Результат передається в SearchServer. У SearchServer задано спеціальний параметр, для простоти розуміння назвемо його «мінімально можливий відсоток» за замовчуванням він дорівнює 40%. Якщо FineReader Engine привласнив відсоток менше цього значення – клас видаляється, і в DLP цей документ йде без класу. Якщо відсоток вище, буде наступне:

1. Для паспортів і кредитних карт працює валідатор SearchInform, він перевіряє документ як за розпізнаної тексту, так і графічну складову (наприклад, для паспортів з'ясовується, чи є на зображенні обличчя, в якому місці воно розташовується, скільки місця займає, є графічні елементи, властиві тільки паспортами (для РФ – особливий візерунок), інші характерні елементи). Чим більше «маркерів» підтвердиться, тим вище буде результат «множник». Наприклад, класифікатор FineReader Engine впевнений в схожості зображення на паспорт на 63%, валідатор знайшов на ньому ключові слова «Паспорт», «Прізвище», «Ким видано», а також фотографію, на якій детектировано обличчя – в такому разі множник дорівнює, наприклад, 1,5 – і підсумкова релевантність виходить 94,5%

Релевантність з такою пост-перевіркою зросла в рази, а продуктивність залишилася на колишньому рівні. Алгоритм ABBYY працює досить швидко і застосовується до великих масивів даних, що дозволяє прискорити роботу програми в кілька разів, валідатор категорій SearchInform працює повільніше, але завдяки класифікації ABBYY він використовується тільки при необхідності і застосовується до істотно меншому масиву даних.

Складністю такої реалізації стало те, що довелося з нуля робити валідатори для багатьох типів даних. Адже ті ж паспорти різних країн мають свої неповторні особливості, і алгоритм пошуку паспорта РФ абсолютно не підходить для пошуку паспорта громадянина України. Те ж саме з кредитними картами – характеристики для VISA істотно відрізняються від MasterCard.

2.Якщо документ схожий на якусь категорію, але вона не відноситься до паспортах або кредитками, релевантність, присвоєна модулем FineReader Engine, залишається без змін – валідатор SearchInform для таких категорій взагалі не застосовується.

Після того, як обчислено підсумкова релевантність, ще раз працює правило, в якому порогом служить вже не значення «мінімальний відсоток схожості», а значення, задане користувачем. За замовчуванням – 70%. Отже, якщо релевантність більше або дорівнює цьому значенню – таким документами підтверджується клас, і з цього класу можна шукати. Якщо вона менше, мітка класу знімається і документ вважається «без класу».

Рішення прикладних завдань
У «Контур інформаційної безпеки» є спеціалізовані засоби аналітики, що дозволяють працювати з архівом даних або виконувати задані політики безпеки.
Безумовно, паспорта і кредитки відносяться до критичним даними, оскільки містять персональні дані, тому їх контроль дуже важливий замовникам. Більш того, зазвичай вкрай складно розробити блокуючу правило, яке такі дані буде «різати» – при створенні таких правил в реальних проектах виникає дуже багато тонкощів, які з'ясовуються поступово, і кожен такий випадок призводить до порушення бізнес процесів у клієнта (оскільки спрацьовує блокування). Тому найчастіше замовники хочуть просто бачити всі рухи подібних документів всередині організації і, особливо, за її межі. А враховуючи те, що це можуть бути не лише паспорта\кредитки, але і будь-які інші типи даних – метод дає велику гнучкість при аналізі.

Розглянемо реальний кейс. Компанія замовника працює зі сканами паспортів. В ній є певний звід правил, що регламентує, де і як покладено такі речі зберігати, за яким електронним каналам і кому можна передавати. Частина даних блокується при передачі – наприклад, якщо це вихідна пошта, призначена не співробітникові компанії і в ній є скан паспорта, текст паспортних даних або що навіть віддалено нагадує паспортні дані. Надіслати скан паспорта назовні можна лише за погодженням з ІБ.



Також фахівці з інформаційної безпеки відстежують передачу таких даних з «особистим» каналах і зберігання цих даних на носіях (зберігання регламентовано, але якщо передача третім особам вважається критичним порушенням, то копіювання в «неправильну татуся» – незначним порушенням).

Коли йде робота в штатному режимі, ІБ покладається на автоматику DLP і працює виключно з звітами системи. Коли йде якесь розслідування, починаються пильні перевірки і з потоком даних починають працювати вручну. Якщо потрібно виявити всі дії, що відбуваються з об'єктом «паспорт», виставляється релевантність політики 70-80%, з мільйона подій фільтрується 500, вони проглядаються вручну і приймаються відповідні заходи. Якщо сталося щось серйозне, звужують політику до «співробітник\дата\час» і релевантність сильно зменшують (до 1%) – даних, що не відносяться до справи, буде на порядок більше, але і ймовірність пропустити критичні події сильно зменшується.



Світлана Лузгіна, служба корпоративних комунікацій ABBYY,
Олексій Парфентьєв, технічний аналітик SearchInform

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.