Превращение индикаторов угроз Cloudflare в правила WAF в реальном времени

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

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

Правила могут быть быстрыми при условии, что их можно отменить

Когда индикатор угрозы попадает в WAF, первым теряет терпение обычно не злоумышленник, а дежурный. Потому что как только правило вступает в силу, за ним следует не абстрактное «улучшение безопасности», а конкретные случайные травмы, апелляции, откаты и проверки. Индикаторы уровня IP легче всего делегировать. У них одноточечное попадание, короткое время выживания и низкие затраты на восстановление. Такие индикаторы, как ASN, сегмент сети, отпечаток TLS и комбинация запросов, являются гораздо более осторожными. Они покрывают большую площадь и имеют более тяжелые побочные эффекты при ударе.

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

Между слоем индикатора и слоем действия должен быть оставлен буфер.

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

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

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

Эта структура выглядит простой, но на самом деле она очень важна. Когда confidence низкий, вызов в первую очередь больше похож на инженерную оценку, чем на прямой перехват; Срок действия ttl автоматически истекает после истечения срока действия, чтобы избежать зависания старой информации на стороне; scope сокращается до пути или сегмента трафика, поэтому зона случайного повреждения не увеличивается бесконечно.

Без проверки правила станут только длиннее и будут выглядеть как куча мусора.

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

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

Этот набор инструментов подходит только для команд, у которых уже есть возможности по утилизации.

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

После внедрения системы такого типа ценностью становится не просто «быстрая остановка». Что еще более важно, так это превратить безопасное удаление из единовременного ручного решения в отзывную, проверяемую и градуируемую цепочку выполнения. Преимущество такой платформы, как Cloudflare, заключается не только в том, что она может получать больше сигналов об угрозах, но и в том, что она имеет возможность передавать сигналы на уровень правил, а затем подключать этот уровень обратно к мониторингу, откату и аудиту. Без этой цепочки в режиме реального времени ошибки будут происходить быстрее; Благодаря этой цепочке правила действительно могут войти в производство.