Що аудитори бачать, коли запитують про засоби контролю PII
Під час аудиту наглядового органу GDPR або оцінки ISO 27001 одним зі стандартних запитань є: «Які технічні засоби контролю у вас є для анонімізації PII?»
Аудитор шукає чітку, обґрунтовану відповідь: конкретний засіб контролю, що застосовується послідовно, з документацією про те, як він працює, та свідченнями його ефективності.
Відповідь, що створює ризик відповідності: «Ми використовуємо різні інструменти залежно від контексту. Для веб-перегляду ми використовуємо розширення Chrome, для документів Word — макрос, для масових файлів наша команда з даних має скрипт Python, що вони написали, а для термінових запитів ми використовуємо веб-застосунок».
Ця відповідь викликає уточнення: «Які відмінності в охопленні між цими інструментами? Як ви забезпечуєте послідовні результати між інструментами? Де журнал аудиту, що демонструє послідовне застосування?»
Це запитання, на які фрагментовані інструменти не можуть відповісти чітко.
Проблема послідовності охоплення
Різні інструменти виявлення PII використовують різні підходи до виявлення:
Інструменти лише на основі regex: Шукають конкретні шаблони (формат ІПН, формат електронної пошти, формат кредитної картки). Пропускають сутності на основі NER (імена людей, організації, що не відповідають відомому списку), контекстуальні ідентифікатори та формати, відмінні від американських.
Інструменти лише на основі NER: Виявляють типи сутностей за допомогою навчених моделей. Пропускають сутності на основі шаблонів (IBAN, номери рахунків зі специфічними форматами), спеціальні організаційні ідентифікатори та сутності, що не входять до навчальних даних.
Інструмент А проти Інструменту Б проти Інструменту В: Кожен має різне охоплення типів сутностей, різні пороги достовірності, різну обробку граничних випадків. Той самий документ, оброблений через Інструмент А та Інструмент В, може дати різні результати виявлення.
Проблема відповідності: якщо Інструмент А (використовується для PDF) виявляє дати народження, а Інструмент Б (використовується для Excel) — ні, то та сама дата народження суб'єкта даних у PDF анонімізується, тоді як його дата народження в електронній таблиці Excel — ні. Системний засіб контролю відповідності має прогалину, що залежить від формату документа.
Для розслідувань органів із захисту даних ця прогалина може бути виявлена. Якщо стався витік даних і розслідування виявляє, що версія записів суб'єкта даних в Excel не була анонімізована, тоді як версія PDF була, непослідовність між інструментами є сприяючим фактором.
Проблема журналу аудиту
Документація відповідності вимагає свідчень того, що засоби контролю застосовуються послідовно. Для анонімізації PII свідченням є журнал аудиту: що було оброблено, коли, ким, за допомогою якого інструменту та який був результат.
Чотири різних інструменти виробляють чотири різних формати журналу аудиту — або взагалі не ведуть журналу аудиту. Макрос Word не веде журналу аудиту. Скрипт Python може записувати в локальний файл, що не інтегрований зі системою управління відповідністю. Розширення Chrome може вести журнали на стороні браузера, що не доступні для документації відповідності. Лише веб-застосунок може вести централізований журнал аудиту.
Для розслідування органу із захисту даних, що вимагає свідчень журналу аудиту, відповідь «ми обробляли цей документ у макросі Word, ці журнали знаходяться на локальній машині розробника» є незадовільною. Відповідь «ось централізований журнал аудиту, що охоплює всю обробку анонімізації на всіх платформах за запитаний період» є задовільною.
Обробка на єдиній платформі забезпечує єдине охоплення журналом аудиту. Фрагментовані інструменти унеможливлюють централізований журнал аудиту.
Проблема дрейфу конфігурації
З часом різні інструменти, що використовуються різними членами команди, розвивають різні конфігурації:
- Розширення Chrome налаштоване з власними типами сутностей організації
- Скрипт Python не оновлювався при додаванні власних типів сутностей
- Макрос Word був налаштований членом команди, що вже пішов, і ніхто не знає поточних налаштувань
- Пресет веб-застосунку оновлявся минулого місяця для виключення імен підрядників, але це оновлення не було поширено на інші інструменти
Дрейф конфігурації створює проблему непослідовності у зворотному напрямку: навіть якщо всі інструменти спочатку виробляли подібні результати, обслуговування одного інструменту без оновлення інших створює розбіжність з часом.
Для засобів контролю ISO 27001 вимога до документації конфігурації робить це особливо проблематичним. Аудитор ISO, що запитує «покажіть мені конфігурацію для ваших засобів контролю анонімізації PII», не може бути задоволений відповіддю «у нас є чотири інструменти з чотирма різними конфігураціями, і ми не впевнені, що вони всі актуальні».
Висновок ISO 27001
Команда консалтингової компанії з 15 осіб використовувала чотири різних інструменти: інструмент веб-скрапінгу для онлайн-даних, автономний інструмент Windows Desktop для масових файлів, макрос Word для юридичних документів та розширення Chrome для AI-інструментів.
Аудит ISO 27001 виявив: «Непослідовні процедури анонімізації даних на різних платформах. Різні інструменти, що використовуються для різних контекстів, виробляють різні результати виявлення і не мають централізованого журналу аудиту. Це створює прогалину в засобі контролю ISO/IEC 27001:2022 Додаток А 8.11 (Маскування даних) — засіб контролю не може бути продемонстрований як послідовно застосований».
Висновок аудиту вимагав плану коригувальних дій. Впроваджена коригувальна дія: консолідація до єдиної платформи анонімізації для всіх випадків використання.
Результати після консолідації:
- Той самий рушій виявлення на всіх платформах (веб-застосунок, настільний застосунок, Office Add-in, розширення Chrome)
- Ті самі пресети, що застосовуються у всіх контекстах
- Централізований журнал аудиту для всієї обробки
- Висновок ISO 27001 закрито на наступному наглядовому аудиті
6-тижневий проект консолідації усунув висновок аудиту, що вимагав 12-сторінкової відповіді з коригувальними діями.
Тест наративу відповідності
Корисний тест для оцінки фрагментації інструментів PII: чи можете ви чітко відповісти на такі запитання?
- Які типи сутностей виявляються на всіх платформах, що ваша команда використовує для анонімізації PII?
- Яким є поріг виявлення (рівень достовірності) для кожного типу сутності, послідовно на всіх платформах?
- Де знаходиться централізований журнал аудиту для всієї обробки анонімізації за останні 12 місяців?
- Як ви гарантуєте, що зміни конфігурації послідовно застосовуються на всіх платформах?
Якщо будь-яке з цих запитань викликає вагому відповідь, фрагментація створює ризик відповідності. Чітка відповідь на всі чотири запитання є досяжною — але лише за умови єдиного рушія на всіх платформах.
Джерела: