Managed Rules vs Custom Rules cho WAF: Nên dùng gì?

Managed Rules và Custom Rules không phải hai lựa chọn loại trừ nhau. Trong một WAF được vận hành tốt, Managed Rules thường tạo baseline protection do nhà cung cấp duy trì, còn Custom Rules xử lý context riêng của website như admin access, webhook, endpoint abuse, virtual patch hoặc policy đặc thù.

Câu hỏi đúng không phải “nên chọn Managed hay Custom?”, mà là: rủi ro nào đã có coverage generic đáng tin cậy và rủi ro nào chỉ đội vận hành của bạn mới hiểu đủ để viết policy?

Hai loại rule khác nhau ở đâu?

Managed Rules là gì?

Managed Rules là các ruleset được nhà cung cấp hoặc dự án bảo mật duy trì để phát hiện nhiều attack pattern, vulnerability class hoặc technology-specific threat. Nhà cung cấp cập nhật logic theo threat landscape và thường cho phép override action, disable một rule hoặc tạo exception.

Ví dụ, Cloudflare Managed Ruleset hiện được cập nhật thường xuyên; tài liệu khuyến nghị bật các rule/tag phù hợp với technology stack và không mặc định bật toàn bộ rule chỉ để tối đa số lượng protection, vì điều đó có thể tăng false positive.

Custom Rules là gì?

Custom Rules là policy do chính tổ chức định nghĩa từ các thuộc tính request mà WAF cho phép quan sát: hostname, path, method, header, cookie, IP, ASN, country, attack score hoặc các field khác tùy nền tảng. Mỗi rule kết hợp expression và action như log, challenge, block hoặc skip.

Custom Rules phù hợp khi quyết định phụ thuộc vào context riêng mà managed rules không thể biết. Ví dụ: “chỉ payment provider A được gọi /payment/callback” hoặc “/admin chỉ được truy cập từ VPN”.

So sánh Managed Rules và Custom Rules

Tiêu chí	Managed Rules	Custom Rules
Ai duy trì logic detection	Nhà cung cấp/dự án ruleset	Đội vận hành của bạn
Phạm vi	Generic attack pattern, CVE, technology stack	Application/business context riêng
Time-to-value	Nhanh hơn để có baseline	Cần phân tích use case trước
Khả năng hiểu app riêng	Hạn chế	Cao nếu owner hiểu ứng dụng
Maintenance	Provider cập nhật rule; bạn vẫn phải tune	Bạn chịu trách nhiệm toàn lifecycle
False positive	Có thể xảy ra khi traffic hợp lệ giống attack	Có thể xảy ra nếu expression/scope sai
Use case tốt	SQLi/XSS patterns, known exploits, baseline	Admin policy, webhook, bot abuse, emergency rule

Khi nào dùng loại nào?

Khi nào nên ưu tiên Managed Rules?

Khi mới triển khai WAF và cần baseline nhanh.
Khi application dùng công nghệ phổ biến có technology-specific rules.
Khi cần coverage cho nhiều attack class mà tự viết signature không thực tế.
Khi tổ chức không muốn tự duy trì hàng trăm detection rule.
Khi cần cập nhật nhanh hơn trước các vulnerability phổ biến.
Khi muốn dùng provider intelligence nhưng vẫn giữ khả năng override/tune.

Tuy vậy, managed không có nghĩa “bật lên rồi quên”. Bạn vẫn phải theo dõi event, hiểu rule change, test critical flow và xử lý false positive.

Khi nào nên viết Custom Rules?

Access policy: admin chỉ từ VPN/bastion hoặc partner network.
Webhook/API policy: endpoint machine-to-machine cần source/header/token condition riêng.
Endpoint abuse: search/login/API bị gọi quá mức hoặc theo pattern bất thường.
Virtual patch: chặn exploit pattern cụ thể trong lúc chờ sửa ứng dụng.
Bot policy: kết hợp nhiều signal để challenge automation không mong muốn.
Origin/business context: policy gắn với hostname, tenant, path hoặc operation đặc thù.

Custom rule nên tồn tại vì có một problem statement cụ thể, không phải vì “có chỗ để viết rule”. Cách xây rule an toàn được tách tại WAF Rule là gì?.

Chiến lược thực tế: Managed baseline + Custom gap coverage

Managed Rules
  ↓ baseline coverage
Security Events / Logs
  ↓ identify gaps + false positives
Custom Rules / Exceptions
  ↓ application-specific policy
Testing + Monitoring
  ↓
Maintenance / Review

Đây thường là mô hình dễ vận hành nhất: không tự viết lại detection mà provider đã duy trì tốt, nhưng cũng không kỳ vọng generic rules hiểu authorization, partner integration hoặc traffic semantics của ứng dụng.

Tuning, exception và technical debt

Managed Rules vẫn cần tuning

Managed Rules hoạt động trên traffic của nhiều loại ứng dụng nên false positive là điều có thể xảy ra. Ví dụ rich-text editor, search query, code snippet, JSON API hoặc file upload có thể chứa chuỗi giống attack payload.

Khi một rule managed gây lỗi, ưu tiên xử lý đúng rule và scope bị ảnh hưởng. Cloudflare hiện khuyến nghị không tắt toàn ruleset nếu chỉ một rule gây false positive. OWASP CRS cũng khuyến nghị exception càng hẹp càng tốt.

Quy trình chuyên sâu nằm ở WAF False Positive là gì?.

Custom Rules có thể tạo technical debt nhanh hơn

Mỗi custom rule là code/policy bạn phải sở hữu. Qua thời gian, rule có thể bị trùng chức năng, dùng field cũ, conflict với rule khác hoặc không còn liên quan sau khi application thay đổi.

rule không có owner;
rule emergency không có expiry;
allowlist quá rộng;
nhiều expression gần giống nhau;
priority/order khó hiểu;
custom rule trùng với managed coverage mới;
không biết rule nào còn match traffic.

Vì vậy custom rule cần lifecycle và maintenance chặt hơn managed baseline.

Có nên tự viết rule SQLi/XSS thay Managed Rules?

Thông thường không nên bắt đầu bằng việc tự viết một bộ signature SQLi/XSS từ đầu nếu managed ruleset đáng tin cậy đã có coverage. Attack syntax rất đa dạng và detection chất lượng cần nhiều edge case/tuning. Custom rules hợp lý hơn khi bạn có context bổ sung hoặc cần virtual patch chính xác cho một vulnerability cụ thể.

Nếu managed rule chưa đáp ứng, hãy xác định gap bằng telemetry trước khi thêm custom signature. Điều này giảm duplication và maintenance cost.

Có nên bật tất cả Managed Rules?

Không nên coi “nhiều rule hơn” là “an toàn hơn” trong mọi trường hợp. Cloudflare hiện cảnh báo việc bật tất cả available rules bằng override có thể tác động legitimate traffic; họ khuyến nghị lựa chọn rule phù hợp technology stack. Các ruleset nghiêm ngặt hơn cũng thường có trade-off false positive cao hơn.

Thay vì bật tối đa, hãy đặt mục tiêu coverage rõ ràng rồi rollout theo quy trình log → test → enforce → verify.

Exception thuộc Managed Rules hay Custom Rules?

Tùy nền tảng. Một số WAF có cơ chế exception/override riêng cho managed rules; một số dùng skip rule được tạo từ expression. Điều quan trọng là hiểu exception đang bỏ qua đúng rule/ruleset nào và ở scope nào. Exception đặt sai level hoặc order có thể không có tác dụng hoặc bỏ qua protection rộng hơn dự kiến.

Trên Cloudflare hiện tại, exception có thể skip một rule, một managed ruleset hoặc phần managed processing tùy cấu hình; scope account và zone cũng có thứ tự riêng. Không nên copy exception từ môi trường khác mà không kiểm tra execution order.

Cách quyết định rule nào thuộc nhóm nào

Yêu cầu	Ưu tiên	Lý do
Baseline chống exploit phổ biến	Managed	Provider duy trì detection
Known CVE phổ biến đã có managed coverage	Managed + verify	Tránh duplicate custom signature
Admin chỉ từ VPN	Custom	Context của tổ chức
Webhook chỉ từ provider xác định	Custom	Business integration riêng
False positive một managed rule	Managed override/exception	Giữ coverage phần còn lại
Exploit zero-day chưa có coverage	Temporary custom	Virtual patch có expiry
Bot abuse đặc thù endpoint	Custom/rate limit	Cần traffic context

Lifecycle và review

Managed Rules thay đổi theo thời gian

Một ưu điểm của Managed Rules là provider cập nhật detection. Đồng thời đây cũng là lý do bạn cần change awareness: rule mới hoặc rule được chỉnh sửa có thể bắt đầu match traffic trước đây không bị tác động. Cloudflare hiện công bố changelog và release cycle cho managed rules để khách hàng review thay đổi.

Nếu nền tảng có changelog, RSS hoặc scheduled changes, hãy đưa nó vào quy trình maintenance WAF. Đừng giả định “managed” đồng nghĩa cấu hình sẽ luôn giữ nguyên hành vi.

Custom Rules cần review khi application thay đổi

thêm subdomain hoặc API version mới;
đổi login path;
thêm payment provider/webhook;
migrate CDN/reverse proxy;
thay framework/plugin;
đổi authentication flow;
deploy feature có payload mới;
thay origin architecture.

Những thay đổi này có thể khiến expression cũ match thiếu hoặc match quá rộng.

Checklist triển khai kết hợp

Inventory technology stack và critical flows.
Bật managed baseline phù hợp stack ở mode quan sát nếu có thể.
Review top matches và false positives.
Tạo exception hẹp cho legitimate traffic đã xác minh.
Xác định gaps mà managed rules không thể hiểu.
Viết custom rule cho từng gap cụ thể.
Test cả legitimate và malicious cases.
Chuyển enforcement theo scope nhỏ.
Read-back event và functional health.
Đặt owner/review date cho custom rule và exception.

Sai lầm phổ biến

Tắt cả managed ruleset vì một false positive.
Viết custom rule trùng với managed detection đang có.
Bật toàn bộ managed rules mà không test.
Tạo custom block dựa trên một tín hiệu yếu.
Không theo dõi changelog của managed provider.
Không review custom rule sau khi app thay đổi.
Không có expiry cho virtual patch.
Dùng allowlist quá rộng thay vì exception có scope.

Kết luận

Managed Rules nên là nền tảng cho detection generic mà nhà cung cấp có thể duy trì tốt ở quy mô lớn. Custom Rules nên bổ sung những policy chỉ tổ chức của bạn mới biết: access boundary, partner integration, endpoint abuse và emergency mitigation.

Mô hình bền vững nhất thường là Managed baseline + Custom gap coverage + exception hẹp + telemetry + review định kỳ. Khi đó WAF có coverage rộng nhưng vẫn phù hợp application context mà không biến thành một tập rule tự phát.

Managed Rules và Custom Rules: nên dùng loại nào cho WAF?