Некорректное тестирование на конкретном примере

В феврале 2017 года мы опубликовали блог-пост, в котором объяснили, как бизнесу ориентироваться в тестах, каковых в индустрии кибербезопасности великое множество. Главная мысль материала была такой: тест заслуживает доверия, лишь когда его методология и публикуемые результаты абсолютно прозрачны. Все его участники должны понимать, как и в каких условиях проводились испытания и не закрались ли в отчет ошибки измерения. А также иметь возможность повторить любой эксперимент исследователей и перепроверить его результат.

Казалось бы, а разве бывает иначе? Ведь у любого тестера в отчете или хотя бы на сайте есть раздел «Методология», где разъясняется, как и с помощью каких именно угроз испытывалось решение. Однако этого мало. От информации «Из 20 свежих вредоносных файлов продукт поймал 15» проку нет. Что это были за вредоносы? Действительно ли они представляли угрозу? Различались ли между собой? Удостоверился ли тестер в отсутствии ошибок, и если да, то как?

В общем, тонкостей много. Мы покажем вам это на примере недавнего исследования решений класса Advanced Endpoint Protection, проведенного компанией NSS Labs.

А что, собственно, произошло?

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

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

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

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

И тут оказалось, что изучить логи невозможно, потому что трассировка была отключена. Уже достаточно, чтобы усомниться в результатах исследования. Но были и другие странности.

Какие угрозы задействовались в тестировании?

Чтобы повторить эксперимент и понять, как решение могло пропустить атаку, вендору нужно тщательно разобраться в произошедшем. Для этого тестировщики, как правило, выгружают семплы, предоставляют сделанную во время атаки запись сетевого трафика или же, если атака распространенная, говорят, как воспроизвести ее с помощью известных конструкторов угроз: Metasploit, Canvas и других.

Так вот, в NSS Labs отказались предоставлять некоторые угрозы, сославшись на то, что механизм проведения атак с их применением является чьей-то интеллектуальной собственностью. Единственное, что они указали, — это CVE-номер уязвимости, эксплойт под которую наш продукт предположительно не остановил. В известных и доступных нам конструкторах такой уязвимости не было, а следовательно, мы не имели возможности воспроизвести ее на своей стороне и вообще убедиться в ее состоятельности.

Мы не подвергаем сомнению права на интеллектуальную собственность. Однако против того, чтобы оправдывать ими нарушение принципов, которые определяют прозрачность результатов тестирования. От того, что вендоры ознакомились бы с техникой атаки на условиях неразглашения информации о ней, никто не пострадал бы. Тестеру, на наш взгляд, нужно было оговорить эту возможность с владельцами прав на тестовые кейсы. Безусловно, чем больше уникальных атак используется, тем более полным и полезным будет само тестирование. Но какова ценность его результатов, если успешность атаки нельзя проверить впоследствии? В конце концов, общая цель индустрии — обеспечить безопасность конечных пользователей. Выяви недочет в продукте, зафиксируй результат, но сделай все, чтобы решить проблему и уберечь людей от нее.

В сухом остатке большинство промахов, приписываемых нашему продукту, не получило прямых доказательств.

Какие еще файлы применялись в тестировании?

Чаще всего в тестах защитным системам «скармливают» вредоносные файлы. Если продукт их детектирует и блокирует, получает плюс. Иногда, напротив, суть теста заключается в проверке на ложноположительные результаты. Тогда решению преподносят легитимные файлы и ждут его реакции. Если продукт не определяет их как вредоносные и не препятствует их работе, зарабатывает плюс. Безусловно, в ходе тестов коллекции чистых и зловредных кейсов можно и нужно смешивать друг с другом. В частности, чтобы предотвратить «заточку» продуктов под конкретные тесты (по сути, обман тестера). Но сейчас не об этом.

В NSS Labs пошли по третьему пути. Они использовали оригинальную утилиту PsExec из пакета PCTools (SysInternals) от Марка Руссиновича, имеющую подлинную цифровую подпись Microsoft, и сочли, что продукты должны распознать и удалить эту программу. А между тем многие администраторы используют ее для автоматизации. По такой логике в категорию потенциально нежелательного ПО ничто не мешает включить даже cmd.exe.

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

Впрочем, взгляды на «потенциально нежелательное ПО» у разных вендоров, тестеров и пользователей нередко расходятся. По нашему мнению, считать такие программы однозначно опасными нельзя. Для кого-то это легитимные инструменты, для кого-то — дополнительные факторы риска. Поэтому применять их в тестах по меньшей мере некорректно.

А какая версия продукта тестировалась?

Как вскрылось при разборе опубликованных результатов исследования, в большинстве тестовых кейсов базы нашего продукта не обновлялись дольше месяца, что никак не было отражено в методологии (напротив, она предполагала наличие свежих баз). На наш вопрос «Почему?» представители NSS Labs ответили, что это нормально, ведь у кого-то из пользователей может быть необновленный продукт.

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

Процесс взаимодействия

Чтобы исключить все возможные ошибки, крайне важно, чтобы при анализе результатов теста у всех участников была исчерпывающая информация о нем. В данном случае работа с результатами исследования велась очень странно, и это мешало разобраться, что же произошло в ходе теста, и, больше того, препятствовало пониманию материалов, предоставленных для изучения вендорам. Возможно, виной тому спешка, вызванная необходимостью подготовить отчет к конференции RSA. Сроки предоставления корректных данных для разбора сдвигались так, что у наших экспертов практически не осталось времени на то, чтобы подробно изучить результаты и воспроизвести их. Практически до предпоследнего перед публикацией результатов дня отсутствовало описание ряда выполненных сценариев, а также не был понятен смысл полей таблицы с результатами. Ответы на уточняющие вопросы поступали с большой задержкой. Да и вообще на ресурсе, куда тестер выкладывал семплы для вендоров, царил хаос. Там отсутствовали нужные файлы, которые, по утверждению NSS Labs, были загружены; файлы периодически менялись; некоторые не соответствовали таблице результатов и так далее.

С учетом всего изложенного можно ли считать результаты такого исследования корректными и прозрачными? Нам так не кажется. Сейчас мы ведем обсуждение с тестовой лабораторией, и часть наших аргументов была ею принята. Однако согласие достигнуто не по всем вопросам. Например, в NSS Labs держатся мнения, что, если семпл выявил в системе работающий защитный продукт и не выполнил свою вредоносную задачу, а следовательно, не был детектирован по поведению, это промах. Но ведь по факту пользователь был защищен, и именно благодаря решению для обеспечения кибербезопасности. Считающих иначе хочется спросить: а зачем тогда вообще запускать семплы?

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

• Тестер должен предоставлять логи продукта, записанный сетевой трафик и доказательства пропуска. В противном случае кейс не может считаться неудачей.
• Тестер должен предоставлять файлы или тест-кейсы для воспроизведения, по крайней мере те, что, по его оценке, были пропущены продуктом. Иначе они должны исключаться из отчета как неверифицируемые.
• Необходимо иметь доказательство того, что атака, которая была симулирована в ходе тестового сценария и пропущена продуктом, в действительности наносит вред системе. Если такового нет, эти семплы должны либо исключаться из исследования, либо как минимум не маркироваться как пропущенные продуктом.
• Чистые файлы могут и должны использоваться во время теста как для проверки уровня ложных срабатываний, так и для выявления потенциального обмана со стороны вендоров, но в качестве угроз их рассматривать нельзя. В частности, это касается модифицированных чистых семплов (от модификации, как бы та ни проводилась, они не перестают быть чистыми).
• Потенциально опасное ПО должно рассматриваться в контексте конкретного кейса, и то, что оно не было детектировано, следует считать ошибкой только при подтверждении реального вреда от него.
• Материалы для подтверждения корректности результатов должны предоставляться всем участникам тестирования в одинаковом объеме. Недопустима ситуация, когда один участник может проверить результаты, а другой нет.