Threat Prevention Profile Causing False Positives on a Business App
A new IPS profile 'Strict' is applied to a gateway protecting a line-of-business application. Within a day, the app's batch job fails. Logs show IPS protections 'SQL Injection' and 'Command Injection' firing on traffic from the app server 10.40.2.15 to the database 10.40.2.20, port 1521. The app vendor says the traffic is legitimate and uses dynamic SQL. The business cannot tolerate the job failing, but security wants protection. The profile is applied to all traffic in the rule. There is no exclusion in place.
1. What is the correct way to handle this without disabling the protections globally?
Read the worked answer
Do not disable the protections in the profile - that removes coverage for all traffic. Instead, use per-protection exceptions scoped to the specific protected object / source / destination. In the IPS profile, add an exception for the 'SQL Injection' and 'Command Injection' protections with:
- Protected scope = the database server 10.40.2.20 (or the app server 10.40.2.15),
- Source/Destination as appropriate,
- Action = Detect (log only) or Inactive,
- Track = Log, and a comment referencing the vendor approval and ticket.
This keeps the protection active for every other flow while allowing the legitimate dynamic SQL from this specific pair. Alternatively, if the app is well understood, create a dedicated profile for the app's rule so the exception is contained.
2. How would you validate the exception and ensure the batch job is not silently exposed?
Read the worked answer
Validation steps:
- Re-run the batch job; confirm it succeeds.
- Check logs: the exception should now show as 'Detect' (logged, not blocked) for 10.40.2.15 -> 10.40.2.20:1521, and no drop.
- Confirm other sources to the same DB are still blocked by the same protections (test from a different host or review logs for blocked events).
- Review the exception periodically - set a review date; if the vendor patches the app to parameterized queries, remove the exception.
- Add a monitoring alert if the exception logs a high volume, which could indicate real exploitation attempts hidden in the allowed flow.
Also confirm the exception is scoped to the object, not 'Any', so it cannot be reused by an attacker from another host.