5.7 TP Profiles, Best Practice, and Ordered Layers for TP

The Built-In Profiles Revisited

R82 ships with three built-in TP profiles (introduced in section 5.1):

• Basic — minimal inspection. Lowest performance cost, lowest security. Use for traffic you cannot afford to inspect deeply, or for trusted server-to-server traffic.
• Optimized — balanced. Check Point's recommended starting point. Enables high-confidence, low-to-medium-impact protections across all blades.
• Strict — maximum inspection. Adds higher-impact and lower-confidence protections. Use for high-risk traffic where false-positive risk is acceptable.

These profiles are complete configurations maintained by Check Point and updated through ThreatCloud. When a new IPS protection is added, the update includes a decision about which profiles enable it. You can use the built-in profiles as-is, clone them, or build a profile from scratch. The CCSA expects you to know the built-in profiles and what each is for; it does not test from-scratch construction.

Custom Profiles

A custom profile is a cloned or new profile tailored to your environment. Common reasons: disable a specific IPS protection that triggers false positives on a business app; enable Threat Extraction only for email and web downloads; allow an Application Control category the built-in profile blocks; apply URLF Redirect to a custom block page.

The discipline: change as little as possible, document each change, and revisit after ThreatCloud updates. A common failure mode is to clone Optimized, disable dozens of protections, and never revisit — the profile drifts from Check Point's recommendations. Best practice is to track each exception with a ticket and re-evaluate quarterly.

Ordered Layers for TP

TP is configured as its own ordered layer in the unified policy. This means you can write multiple TP rules, each attaching a different profile to different traffic classes. A typical three-rule TP layer:

The first matching rule wins, so rule order matters. Guest traffic hits rule 1 and gets Strict; internal user traffic skips rule 1 (source does not match), hits rule 2, and gets Optimized. The implied Clean-up rule at the bottom catches anything not matched above.

This design lets you apply ** graduated security**: stricter on untrusted traffic, balanced on user traffic, lighter on trusted traffic. It is the canonical Check Point recommended design, and CCSA scenarios test whether you can produce or recognize this pattern.

Best Practice: Start with Optimized

The standard rollout pattern for a new TP deployment is:

1. Enable TP blades on the gateway and verify the licenses are installed.
2. Attach the Optimized profile to the implied Clean-up rule as the default.
3. Install policy and monitor logs for a week. Pay attention to drops, false positives, and throughput impact.
4. Create exceptions for specific false positives, scoped as narrowly as possible (specific source, destination, protection).
5. Add targeted TP rules for high-risk traffic (guest, untrusted partners) with Strict, and for trusted traffic with Basic, where appropriate.
6. Revisit and tune after major ThreatCloud updates and after significant network or business changes.

This pattern is sometimes called "start permissive, then tighten" in the field, but the more accurate description is "start balanced, then specialize." Starting with Basic leaves too many protections off; starting with Strict generates too many false positives. Optimized is the calibrated baseline.

Best Practice: Performance Tuning

Performance tuning for TP focuses on three levers:

• Profile choice — moving a traffic class from Strict to Optimized, or Optimized to Basic, reduces inspection cost.
• Disabling high-impact protections — in a custom profile, disable specific protections with High Performance Impact, especially on saturated links. Re-enable them when capacity allows.
• Scoping exceptions narrowly — exceptions are not free; an exception that is too broad can mask real attacks. Keep exceptions scoped to specific source/destination/protection.

The CCSA expects you to recognize these levers and the order in which to apply them (profile choice first, then per-protection disabling, then exceptions). Disabling IPS entirely is almost never the right answer on the exam — the right answer is to tune down.

Best Practice: Layering with HTTPS Inspection

When HTTPS Inspection is enabled, the gateway decrypts the connection, then passes the cleartext to TP for inspection. Without HTTPS Inspection, TP can only inspect the metadata it can see (SNI, certificate). A profile that includes AV, IPS, and Threat Emulation on HTTPS is only effective if HTTPS Inspection is also enabled for that traffic.

Best Practice: Logging and Continuous Review

TP is not set-and-forget. Review TP logs weekly during initial deployment and monthly thereafter. Key questions: are there new categories of drops indicating a new campaign? Are there false positives that should become exceptions? Are existing exceptions still needed? Has throughput changed and does it correlate with a ThreatCloud update? SmartEvent reports and dashboards support this review.

Common CCSA Scenarios

Typical profiles-and-best-practice questions:

• Choose the right profile for guest traffic (Strict).
• Choose the right profile for trusted server-to-server (Basic).
• Recognize that the implied Clean-up rule has its own profile and that it applies to unmatched traffic.
• Identify the correct tuning order when throughput drops (profile → per-protection → exception, not disable IPS).
• Recognize that TP on HTTPS requires HTTPS Inspection to inspect the payload.
• Recognize the three-rule TP layer pattern (guest Strict / users Optimized / trusted Basic).