Committing and Activating Ruleset Changes

Changes to your rulesets need to be explicitly committed and activated.

Changes to application mapping must also be committed, but this is done separately in Application Mapping. See Editing Application Mapping. Changes relating to the system as a whole (for example, adding and changing applications or users) become active automatically and immediately, so they don’t have to be committed (see also When Changes Are Saved and Become Active). For further information regarding the underlying principles and how vWAF is structured and controlled, see Basic Principals of Use.

What's saved? What becomes active?

When you commit, vWAF stores a new version of the ruleset that’s currently being edited (the loaded ruleset) in its database. This doesn’t influence ongoing detection and protection in any way, as the detection and protection rulesets don’t change in this process.

When you commit and activate, however, vWAF not only stores a new version of the edited ruleset, but in the same process also makes this version the detection or protection ruleset:

  • if detection mode is active for the application to which the committed and activated ruleset belongs, the new version automatically becomes the detection ruleset
  • if protection mode is active for the application to which the committed and activated ruleset belongs, the new version automatically becomes the protection ruleset. So, when you commit and activate, there’s no need to change the version manually via version control.

When to commit

Usually you should only commit when you’ve completed a new setting. However, you need to commit your security configuration at the latest before you log out or close your browser, otherwise the current changes are lost.

ATTENTION
When there hasn’t been any activity within the administration interface for some time, a warning message appears on the status display, showing you how much time remains until you’re automatically logged out by the system. If the system logs you out before you’ve committed the ruleset, all uncommitted changes are lost.

In general, you should try to avoid running commit operations too often, to keep the version history as clear as possible.

Use the comment field offered for the commit function to document the history of your security configuration in detail and to specify the reasons for specific settings and changes to the security configuration.

When to commit and activate

You should only commit and activate your security configuration once you’ve made all the settings as required.

When in protection mode, after activation test your web application thoroughly for error- free functioning. It could be that some of the rules have been set too restrictively. For that reason, choose a time outside standard business hours for the activation process whenever possible.

When you’ve modified a ruleset, you can test it before you apply it. This eliminates the risk that the access to your running web application is affected by a faulty or by a too restrictive or too loose ruleset.

To achieve this you can run two versions of a ruleset in parallel. Run the old version as the protection ruleset, and the new version as the detection ruleset. While the old version continues to protect your web application, the new version (the detection ruleset) only writes entries to the log files when a handler becomes active, but doesn’t block any traffic. Later, you can analyze the log files to check whether the ruleset has behaved as intended. Only when the new version works fine, make this ruleset the protection ruleset (see Version Control).

Procedure

  1. In the navigation area, click the green arrow symbol next to the application whose changes you want to commit. Note that this arrow symbol only appears if there actually are any pending changes to commit.

    If the application is still selected for editing, you can alternatively also click the green arrow symbol in the Changes section on the status display.

  2. The Changelog appears with an overview of the current changes of the application.

  3. Check whether or not you definitely do want to apply the changes listed (a description of the entries displayed can be found under Reviewing and Discarding Ruleset Changes).
  4. In the Enter Commit Comment field, enter a comment that you and others can use later on to follow why you made those particular changes. This comment appears in the Version Control.
  5. Click one of the following buttons:
    • Click Commit only to save the ruleset permanently to the vWAF database, but not to activate it.
    • Click Commit / Detection to save the ruleset permanently, and to activate it as the detection ruleset at the same time.
    • Click Commit / Protection to save the ruleset permanently, and to activate as the protection ruleset it at the same time. (This button is only available when the application is in protection mode.)

ATTENTION
If you’ve committed and activated the ruleset as protection ruleset: Immediately test your web application to ensure that it continues to work correctly in combination with the new rules.

If your web application denies all requests following activation, you may still need to enable the traffic for the application. If you feel that your ruleset might be too restrictive and block desired traffic, you can simulate its behavior without actually blocking traffic. You can do this by making it a detection ruleset (see Detection Mode, Protection Mode and Version Control).