Высокие технологии стали чересчур высокими. Знания требуются глубокие. “Высота” и “глубина” неизбежно выливаются в узость соответствующих специалистов. Такой специалист всё может сделать, но мало что может объяснить на нормальном человеческом языке.

Чтобы переводить “птичий язык” специалистов на общечеловеческий и дальше — на бюрократический, выдумано немало разных способов. Теория управления рисками (risk management) переводит непонятные технические рассуждения на язык денег. Стандарты такую же технократическую заумь переводят на язык сертификаций и аттестаций. А учение о метриках информационной безопасности (ИБ) пытается перевести речи технарей на простые и понятные проценты.

Задача стоит так: охарактеризовать защищённость информационной системы числом от 0 до 100%. Чтобы и начальству удобно было доложить, и премию вычислить. Естественно, алгоритм вычисления метрики должен быть объективным и проверяемым. Никаких “экспертных оценок”, никаких опросов, никаких “есть мнение”.

Числа

Попробуем выбрать несколько показателей, которые характеризуют качество DLP-системы.

Количество контролируемых каналов

Многие вообще не признают DLP-системами те продукты, которые проверяют менее пяти различных каналов. Но считать каналы можно по-разному. Например, весь веб-трафик можно считать за один канал. А можно учитывать отдельно HTTP, HTTPS, SOCKS. Были предложения каждый канал умножать на долю трафика, который через него проходит. Это плохая идея. Во-первых, затруднительно оценить количество трафика в таких каналах, как распечатка на принтере или запись на CD-R/RW. Во-вторых, у каналов разная информационная насыщенность. Через файлообменные сети (p2p networks) при гигантском трафике редко передаётся нечто значимое, а через instant messengers (типа ICQ) обычно идёт ничтожный объём трафика, но конфиденциальная информация там попадается довольно часто.

Так что придётся остановиться на простом подсчёте числа каналов. В крайнем случае — умножать на весовой коэффициент, учитывающий, какой процент мировых утечек проходит по данному каналу (в нашей компании такая статистика ведётся).

Этот показатель имеет значение только для противодействия неумышленным утечкам (их доля в последние годы колеблется в пределах 40—60%). Применять его для инцидентов умышленных было бы нелогично, поскольку злоумышленник-инсайдер обычно знает, какие каналы контролируются, и пойдёт в обход. Для противодействия таким инсайдерам имеет значение другая характеристика: имеются ли вообще в информационной системе неконтролируемые каналы?

Количество поддерживаемых протоколов и форматов

Этот показатель должен подсчитываться с учётом распространённости протоколов и форматов, то есть фактически надо оценивать процент распознаваемого трафика. И лучше не в мегабайтах, а в коннекциях (tcp-сессиях, flow). Кроме протоколов и форматов имеет смысл учитывать и поддерживаемые кодировки символов, а для “продвинутых” случаев также динамику внедрения новых парсеров по мере появления новых протоколов. Скажем, протокол FTP за последние 10 лет не изменился. А протоколы синхронизации мобильных телефонов плодятся как кролики.

Поддержка используемых языков

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

Число возможных проблем с законом

Этот аспект касается не только само́й системы, но также её внедрения и организационного обеспечения. Не секрет, что DLP-система расположена в опасной близости от границы, разделяющей законное и незаконное. При неумелом обращении эту границу легко перейти, нарушив права на тайну связи и тайну частной жизни (privacy). Но в любом случае идеального вписывания DLP в современные права человека не получается. Всегда остаются риски. Их количество и стоимость могут быть ещё одной метрикой.

Например, заранее получить у работника разрешение знакомиться со всей его будущей перепиской — проще, но не вполне “чисто” и корректно с точки зрения закона. Получать каждый раз разрешение на ознакомление с каждым подозрительным письмом — корректно, но рискованно.

Количество инцидентов

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

Количество ложных срабатываний (false positive)

Если количество выявленных инцидентов характеризует строгость политики безопасности и её соблюдение работниками, то число ложных срабатываний характеризует саму систему и качество её настройки. К сожалению, отделить друг от друга последние два показателя — качество системы и качество настроек — не представляется возможным.

Иными словами, если ваша DLP-система выдаёт слишком много тревожных сигналов, это повод начать работать с персоналом или (что вероятнее) задуматься об адекватности применённой политики безопасности. Обилие же ложных срабатываний при том, что их количество не удаётся уменьшить донастройкой системы, свидетельствует либо о низком качестве внедренного продукта, либо о его неприменимости в данных конкретных условиях.

Эксплуатационные метрики

DLP-система после внедрения должна следовать всем поворотам, которые проходит ваша ИС в своём развитии (ежегодно меняются версии распространенных ОС, каждые полгода появляется новая технология, каждый квартал — новый формат или протокол). Изменяются и бизнес-процессы в компании. Все эти изменения должны влечь за собой как минимум перенастройку DLP, а возможно, и её серьёзный апгрейд.

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

Антиметрики

Как известно, усиление безопасности всегда снижает удобство использования. Мириться с этим уже научились. Но дело пошло дальше: степень создаваемых пользователю неудобств некоторые воспринимают как показатель защищённости. Использовать эту корреляцию для оценки ни в коем случае нельзя. Более того, следовало бы установить лимиты: предельный процент рабочего времени, затрачиваемый работником на исполнение процедур безопасности. Если он превышен, службе ИБ должны начисляться штрафные баллы.

Некоторые показатели делать числовыми критериями ни в коем случае нельзя. Потому что они лишь на первый взгляд характеризуют качество защиты, а на самом деле — качество учёта, окружающую среду или хитрость учётчика. А то и вовсе представляют собой генератор случайных чисел. К таким негодным метрикам относятся количество выявленных инцидентов, предотвращённый ущерб или число сигнатур.

Нормировка

Каждый раз при изменении метрик результат нужно перенормировать, умножив на поправочный коэффициент или поправочную функцию, чтобы текущее значение по новым метрикам было равно текущему (предыдущему) значению по старым. Тогда можно будет оценить долговременную динамику.

Опасности

Во времена социализма экономическая эффективность оценивалась в самых разных показателях, зачастую не имеющих ничего общего с финансовыми. В тех редких случаях, когда правила расчёта отчётного показателя были выбраны удачно, предприятие выполняло свою задачу и работало эффективно. Но чаще всего “отчётный показатель” играл деструктивную роль. Вместо реальной работы всё предприятие от рядового сотрудника до директора направляло свои усилия на достижение лучших цифр в отчётах. Наращивали не абстрактную общественную пользу, а конкретные тонно-километры, академчасы, проценты раскрываемости или средний балл.

Та же опасность подстерегает на пути внедрения метрик ИБ. Неудачно выбранная метрика заставит специалистов делать не то, что потребно для защиты, а то, что приведёт к увеличению отчётной цифры.

Аналогичная проблема есть и у поисковых систем. Релевантность запросу, которая означает место в выдаче результатов, рассчитывается по секретному и всё время меняющемуся алгоритму. Иначе оптимизаторы быстро займут весь “пьедестал” своим спамом. Было бы хорошо аналогично вычислять и рейтинг для DLP-системы. Для этого можно привлечь аутсорсеров.

Критерий

Метрика защиты от утечек сама по себе защищённости не повышает. Однако позволяет оценивать эту защищённость и меры по её усилению. Причём оценивать в простых показателях, понятных любому, даже самому высокому начальнику. И таким образом обосновывать выделение бюджетов на ИБ. Урезание бюджетов, кстати, тоже.

Автор статьи — главный аналитик компании InfoWatch.