Блок-листы ресурсов с плохой репутацией (RBL) — распространенный механизм защиты от вредоносного и нежелательного контента в Интернете. Такие блок-листы представляют собой списки IP-адресов, доменных имен или полных URL-адресов известных распространителей спама, страниц, которые используются для фишинга, вредоносных сайтов или прочего нежелательного контента. Мы используем эти источники данных для создания показателей в таких системах, как платформа отчетности ICANN о случаях злоупотребления доменами (DAAR), в том числе для целей исследований, а также в качестве наборов данных для тренировки моделей машинного обучения. Организации могут использовать списки RBL для блокирования входящего или исходящего трафика по отдельным доменным именам, для фильтрования спама, предупреждения о попытках фишинга или для других действий, направленных на защиту пользователей от онлайн-угроз.
Такие списки составляются несколькими поставщиками услуг, многие из которых специализируются в совершенно разных областях, а также отличаются используемыми методиками сбора информации, механизмами доставки и т. п. В результате у разных поставщиков списков RBL есть свои сильные стороны. Кроме того, данные RBL используются для самого широкого спектра задач, и мы понимаем, что не все из них идеально подходят для всех пользователей. Этой проблеме было уделено большое внимание как в публикации Офиса технического директора (OCTO), так и в нашем новом документе, который был представлен и опубликован на техническом саммите Антифишинговой рабочей группы 2023 года.
Чтобы оценить, подходят ли характеристики того или иного списка RBL для предлагаемого конкретного варианта использования, нам сначала необходимо гармонизировать все входящие данные и метаданные, а затем сохранить их в некоем едином согласованном формате. Только после этого можно приступать к измерению и сравнению объемов данных и типов угроз, к которым они относятся, к выявлению дубликатов записей в отчетах и т. п. Кроме того, мы можем также начинать анализировать менее объективно измеряемые показатели, например, возможные ложно определяемые угрозы. Со временем такой процесс гармонизации данных позволил нам создать набор показателей, которые можно использовать для оценки списков RBL как по отдельности, так и в сочетании друг с другом.
В результате мы видим, что не существует какого-то единого списка RBL, который отвечал бы потребностям всех возможных вариантов использования. Объединение списков RBL в единый набор данных оказалось чрезвычайно важным шагом, поскольку сильные стороны списков одних поставщиков зачастую компенсируют недостатки других, и наоборот. В действительности мы неоднократно наблюдали, что совпадения между разными списками RBL небольшие (в большинстве случаев — менее 5%). Это значит, что дополнительные преимущества от их объединения зачастую существенны.
В нашей новой публикации мы утверждаем, что понимание сильных и слабых сторон любого отдельного списка RBL или совмещенного набора разных таких списков является ключевым условием эффективности их применения для того или иного сценария использования. Для извлечения максимальной пользы мы рекомендуем использовать сочетание нескольких разных списков RBL. Это обеспечивает дополнительный контекст и позволяет составить более полную картину происходящего, чем это было бы возможно при использовании любого списка RBL отдельно от других. Ниже приведена сводка нашего участия в этой публикации:
- Мы предложили методику систематической оценки списков RBL, которая позволяет структурировать подход к оценке их эффективности и пригодности к использованию в том или ином случае.
- Мы провели детализированный анализ различных нюансов характеристик списков RBL, таких как объем, пересечение с другими списками, оперативность, текучесть, актуальность, чистота и точность данных.
- Мы представили визуальную демонстрацию практического применения предлагаемых нами показателей, предложив тем самым реальные и доступные рекомендации, которыми могут руководствоваться специалисты, занимающиеся исследованиями, решением практических задач и принятием решений в области кибербезопасности.
Подробнее о наших методиках и выводах см. в публикации офиса технического директора 037.
