Updating attack signatures (best practice)

This is not the best practice, it's just something I'm doing personally. Also note that the time consumption values are completely subjective, but you may find them to be accurate if you have around 50-100 individual policies in your environment. It also varies from person to person, determined by how security concious someone is (individual level of paranoia).

There are many more minor things to do/check, but the outline below should help you determine the key steps in your initial routine. So here it goes:

Pre update (30-60 min work, unless there’s unfinished work from previous update cycle)

• Step 1: Verify no pending learning suggestions exist in the Manual Traffic Learning section. Note that you must scroll through all policies since the suggestions are linked to individual policies. (Step impact risk = none);

OR

Come up with a conclusion what will be done with pending learning suggestions in Manual Traffic Learning section, before applying a new signature update which will inevitably bring up more Learning Suggestions. All signatures of all policies must be moved out of stating; placed either into Enforced(eligible for blocking) or Disabled state. It’s important because over time the learning suggestions will pile up and differentiating between potential false positives and malicious occurrences will become more difficult. (Step impact risk = medium - high)

The update itself (20-40 min work if manual, 0 min if automated)

• Step 2: Update the system-provided ASM signatures manually. If you are tuning your policies on a daily basis (someone is always keeping an eye on Manual Traffic Learning section), you may consider the automatic update feature. If you update manually, you must check a tickbox to imply that any new and modified signatures will be put into Staging Mode. (Step impact risk = none – low)

Note: Asking for functional application tests and verification is not needed here as the update is non-impacting until Step 3 is done. A small margin for human error does apply to step 2.

Post update (40-60 hours work)

• Step 3: Evaluate learning suggestions in Manual Traffic Learning section (X number of weeks after the update. For a start, X can be 2). Come up with a conclusion if the new/modified signatures will be disabled of enforced, extend the evaluation period by another week if needed. (Step impact risk = medium – high)

• Step 4: Application testing mandatory if any new signatures, or modifications to existing signatures were enforced. If all the Learning Suggestions were disabled as false positives, or if none of the updated signatures are in use by your policies (you better be certain of that), the application tests are not required. (Step impact risk = none)

To roll back a signature update, you must manually download and install a previous signature file release. There's no bigip.conf.bak or anything similar for ASM. Consider creating an UCS snapshot as step 1 to be safe.

You will still need to consider non-technical steps in the between to ensure everything is done according to Change Procedure in your enterprise. To come up with a conclusion if a signature update should be enforced or not, my personal rule of thumb is that signature violation occurrences in excess of 100 (over a period of 2 weeks), from more than 10 unique IP addresses from many different countries are false positives (generally applies to 80% of all Learning Suggestions); the hard part is coming up with a conclusion for the rest. Usually, the evaluation period must be extended for 20% of the updated signatures whereas obvious conclusions can be made just 2 weeks after the update for 80% of the updated signatures. With most of my clients, we typically update system-provided signatures 2 or 3 times a year.

Regards,