Реестр защищаемой информации и информационных потоков: поля, сбор, актуализация

На вопрос «где у вас хранятся персональные данные клиентов и кто к ним ходит» в большинстве компаний отвечают по памяти. Ответ содержит три места, а на деле их девять: выгрузка у бухгалтера, копия в тестовой базе, файл в почте руководителя. Пока нет письменного списка, нельзя ни защитить данные, ни ответить регулятору, ни понять, что утекло при инциденте. Реестр решает эту задачу. Ниже два связанных документа: реестр защищаемой информации (что и где лежит) и реестр информационных потоков (откуда и куда это ходит), способ собрать их за неделю и поддерживать актуальными без отдельного человека.

Как присвоить данным категории: классификация данных. Реестр оператора ПДн, который подаётся регулятору, — другой документ: уведомление об обработке. Автоматический поиск данных в хранилищах — тема отдельной статьи в очереди.

Что куда записывается

Первый реестр отвечает на вопрос «что защищаем», второй показывает «куда это уходит». Утечки чаще происходят в потоках, чем в хранилищах: данные уезжают по почте, в мессенджеры, в облачные сервисы и к подрядчикам. Поэтому второй реестр без первого бесполезен, а первый без второго неполон.

Как выглядит запись о потоке

Одна строка реестра потоков — это одна схема: источник, данные, канал, получатель и владелец. Если какого-то звена не хватает, запись неполна.

Реестр защищаемой информации: поля

Реестр потоков: поля

id,dataset,src_name,src_cidr,dst_name,dst_cidr,port,channel,protection,schedule,owner,basis
FL-014,Данные клиентов,CRM,198.51.100.21/32,1С,198.51.100.30/32,22,SFTP,"шифрование в канале; файл 24 ч",ежедневно 02:00,Руководитель продаж,внутренний
FL-021,Данные клиентов,CRM,198.51.100.21/32,Платёжный сервис,203.0.113.0/24,443,HTTPS API,"TLS 1.2+; ключ в Vault",по событию,Финансовый директор,договор 14

Поля с адресами нужны не для красоты: они позволяют сверять реестр с реальным трафиком скриптом (ниже). Записи для внешних получателей ссылаются на договор и поручение: поручение обработки.

Как собрать за неделю

1. День 1–2: система за системой. Возьмите перечень систем из реестра активов и для каждой задайте владельцу четыре вопроса: какие данные обрабатываются, где лежат, откуда приходят, куда уходят.
2. День 3: почта, файлы, мессенджеры. Спросите подразделения про выгрузки и пересылки «вручную»: отчёты в Excel, файлы для подрядчиков, обмен с банками и налоговой. Чаще всего самые рискованные потоки — именно они.
3. День 4: подрядчики и облака. Просмотрите договоры и список внешних сервисов: что отправляется и в каком виде. Для облачных сервисов с ПДн: ПДн в облаке.
4. День 5: проверка находками. Запустите поиск персональных данных на файловых серверах и в тестовых базах инструментом поиска по паттернам (номера документов, маски телефонов и адресов). Всё, что нашлось в неожиданных местах, вносите в реестр или удаляйте.
5. Согласование. Каждый владелец подписывает свои строки. Неподписанная строка — не реестр, а заметка аналитика.

Владелец данных: кто это

Владелец — человек, который отвечает за набор данных и решает, кому давать доступ: руководитель подразделения, которое данные создаёт или использует. Не администратор базы и не ИБ. ИТ хранит, ИБ защищает, а решает владелец. Закрепите это в положении о данных и в заявках на доступ: владелец шары и матрица доступа.

Сверка реестра потоков с реальным трафиком

Реестр, который никто не сверяет с действительностью, устаревает за квартал. Самая полезная проверка — найти потоки, которых нет в реестре. Если у вас работает IDS Suricata с включёнными записями о потоках (flow в разделе eve-log), скрипт сравнит их с реестром:

#!/usr/bin/env python3
"""Потоки из eve.json (Suricata), которых нет в реестре потоков.
Использование: flow_check.py flows.csv /var/log/suricata/eve.json"""
import csv
import ipaddress
import json
import sys
from collections import Counter

known = []
for r in csv.DictReader(open(sys.argv[1], encoding='utf-8-sig')):
    known.append((ipaddress.ip_network(r['src_cidr']), ipaddress.ip_network(r['dst_cidr']), int(r['port'])))

def is_known(src, dst, port):
    s, d = ipaddress.ip_address(src), ipaddress.ip_address(dst)
    return any(s in a and d in b and port == p for a, b, p in known)

internal = [ipaddress.ip_network(n) for n in ('10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16', '198.51.100.0/24', '192.0.2.0/24')]
unknown = Counter()
for line in open(sys.argv[2], encoding='utf-8'):
    try:
        e = json.loads(line)
    except ValueError:
        continue
    if e.get('event_type') != 'flow':
        continue
    src, dst, port = e['src_ip'], e['dest_ip'], e.get('dest_port', 0)
    if not any(ipaddress.ip_address(src) in n for n in internal):
        continue                          # смотрим только исходящие и внутренние потоки
    if port in (53, 123, 67, 68):
        continue                          # служебные, ведутся отдельно
    if not is_known(src, dst, port):
        unknown[(src, dst, port)] += 1

for (src, dst, port), n in unknown.most_common(30):
    print(f'{src} -> {dst}:{port}  потоков: {n}')

Ожидаемо: список самых частых потоков, не описанных в реестре. Большая часть — служебный шум (обновления, мониторинг), его добавляют в реестр как «технические потоки» или исключают правилом. Остаток — это то, что нужно изучать: неожиданный получатель, выгрузка на внешний адрес, обращение рабочей станции к серверу, к которому ей не нужно. Адреса внутренних сетей и список служебных портов подставьте свои. Поток не обязан быть опасным, он обязан быть описан.

Как поддерживать актуальность

«Обновляется ежедневно» не значит, что кто-то каждый день вносит записи вручную: значит, что есть автоматическая проверка, которая ежедневно показывает расхождения, и процесс, обязывающий их разбирать. Правки вносятся через репозиторий с обязательным согласованием: история коммитов служит журналом обновлений.

Доступ к самому реестру

Реестр защищаемой информации — карта, на которой отмечены самые ценные данные. Её утечка помогает атакующему. Поэтому доступ ограничьте: хранение в закрытом репозитории или зашифрованном хранилище, права по ролям (чтение у ИБ, владельцев данных и ИТ-руководства, запись у ответственного за реестр), доступ только по защищённым каналам, заявки на предоставление доступа к реестру. Журнал обращений должен сохраняться.

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Безопасность данных» (хаб: безопасность данных, карта: карта зрелости). На первом уровне утверждён состав защищаемой информации, определены места хранения и способы защиты; на втором для критичных систем определены категории данных и назначены владельцы. На пятом уровне ведётся реестр информационных потоков с владельцами, критичностью и категориями доступа, обновляется ежедневно, а доступ к нему ограничен.

Как проверить

1. Для пяти случайных систем есть строки реестра с владельцем, категорией и местами хранения.
2. Для пяти случайных потоков есть владелец, канал и защита, а для внешних получателей договор.
3. Скрипт сверки запускался за последние сутки, результаты разобраны.
4. В истории репозитория реестра видны изменения с датами и авторами.
5. Доступ к реестру ограничен, список имеющих доступ сверен с ролями.

Источники

• CIS Control 3, защита данных: cisecurity.org/controls.
• NIST SP 800-53 Rev. 5, управление информационными потоками (AC-4): csrc.nist.gov.
• Suricata, формат EVE JSON и записи о потоках: docs.suricata.io.