Updating attack signatures (best practice)

no, you update all signatures at once, not per asm policy. the effect within an asm policy depends on the settings for that policy and as long as you use signature staging no signature will have a direct effect. on the other side some currently enforced signature will be taken out of enforcement and put into staging.

a lot depends on the backing you get from higher up. do they want top security then update en just enforce directly. might cause some extra false positives but will certainly give better protection. if they want to be more careful with unneeded block, update and watch the manual traffic learning to look at the hit signatures in staging. after a week enforce everything without hits and work on the ones with hits.

You may have quite a few new signatures added to the attack signature pool after you update because they are cumulative. By default, ASM should place all newly added attack signatures into staging. That way, if your policy is in blocking mode, a triggered signature will not block the request, and you have time to deal with false positives. Before you update, ensure that the Signature Staging option (on the Attack Signatures Configuration screen) for the overall policy is enabled. If Signature Staging for the overall policy is not enabled, you run the risk of enforcing all signatures as soon as you add them. If the policy is blocking mode, and an enforced signature is triggered, the request will be blocked.

If you enable signature staging for the overall policy, then the answer to the question "Will all new signatures be in staging by default?" is yes. The idea is to only enforce attack signatures which you are certain will not block legal requests.

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,

I doubt that there won't be any impact by updating the Signature Database if you put newly added signatures into Staging.

We have seen a case where all the Manual Traffic Learning violations been taken care. We upgraded the signature database and it was found that a couple of rivisioned signatures started triggering the false positives.

Since customer is having 2 different F5 setup, one for DC and one for DR, we have upgraded the Signature set only for DR and during the testing, traffic started hitting an enhanced signature and the old Signature was also there.

Production traffic was passing through the DC Site and there were no violations. There I learned that updating the Signature Database can have minor or major impact on traffic processing, irrespective of the fact that newly added signatures are in Staging.

I hope this would help.

Cheers! Darshan

Umm... The last incident was observed on 11.6.1 HF6. The signature got detected was "src http: (Parameter) (2)". However the old signature exist was "src http: (Parameter)" without (2).

The updated signature i.e. "src http: (Parameter) (2)" automatically took place and followed the ASM Policies' action i.e. Blocking.

So I think this needs to get verified.