Inadvertently Blocking Legitimate Traffic

Inadvertently Blocking Legitimate Traffic


A large government agency using Microsoft SharePoint had been attempting to put important security controls in place for
years. Using various vendors and highly skilled system integrator resources, they attempted to get WAF protection in place.
However, upon deploying the protection, they discovered a large proportion of legitimate traffic was blocked. Repeated attempts
to tune out the false positives were fruitless forcing the controls back to alerting, not blocking traffic. At its peak, there
were days where 300,000 false positives were observed.

After years of trying, someone suggested giving RedShield a call.



RedShield applied its unique WAF deployment approach to the agency’s SharePoint application. First, RedShield researched
and deployed a baseline profile which was designed to be application change tolerant in the first place. Rather than taking
a machine learning approach, RedShield took a test-centric approach using vulnerability scanners and reviews of pen test
reports to determine which parts of the baseline policy were not required. RedShield believes if controls are not actually
required to protect security flaws and could cause problems, they should not be in place.

RedShield security researchers, analysts, engineers and developers then tuned the profile and documented status to aid
troubleshooting post deployment. Should there be an issue, responding experts must know the profile well enough to make
critically accurate changes. They must know if the customer has no increased breach risk, or if the customer has increased risk
and then potentially invoke emergency change control. All of which must occur in minutes.

If a machine had developed the profile, it is not possible to make these assessments, and the resulting behavior is typically to
turn the controls completely off while the machine learns again. The Cloud WAF approach of reducing applied security levels
with a “dial” until the false positive disappears, is a blind swapping of false positives for false negatives (increased breach risk)
without any risk analysis and decision by the appropriate management.

After the initial controls deployment in pre-production (in transparent mode), RedShield experts periodically reviewed the
alert logs. After 6 weeks, they had got them down to zero. At that point RedShield submitted a change request to turn on
blocking. The request was accepted and a further 2 weeks of rigorous testing was applied to the pre-prod instance. No false
positives were reported. RedShield then submitted a change request to place the profile in production. The CR was accepted,
and RedShield went through its standard deployment technique transitioning through transparent and into blocking in the
following week.

“RedShield are truly experts in deploying application security controls. We had “the best of the best” giving us excuses and regularly explaining in crisis meetings why this was such a hard problem to address, RedShield just stepped in and without fuss just deployed. The 3rd party security tests show what they did is effective, but the lack of fuss and customer complaints is what has really impressed me. Their reporting is great and I know I have security experts available to respond if required.”


In the 2 years since deployment, the profile has remained in blocking mode and not a single false positive has been reported.
To date, RedShield deployments are cumulatively running at a 0.0002% false positive rate which is 2-3 orders of
magnitude better than the industry. The RedShield average reported false positive resolution time is running at 15mins.
RedShield analysts’ reports are delivered monthly, scans are conducted weekly, pen tests are passed periodically, but in
general there is very little activity to report and customer complaints have disappeared.
FOOTNOTE: “Microsoft SharePoint is a trademark of Microsoft Corporation.”.

May 21, 2020