F5 AWAF parent policy serves as a baseline security template from which individual web application security policies can inherit. This approach ensures consistency across all applications, reduces the administrative overhead associated with creating and updating policies, improves overall security by applying uniform and up-to-date security measures, and enhances scalability in managing application security.
In this section, we will discuss and demonstrate the benefits and implementation of the F5 AWAF parent policy.
Table of Contents
Parent and Child Security Policy in F5 AWAF
To start the demonstration, let’s begin by creating a security policy of the type “parent policy“. By default, when you create a security policy, the policy type is set to “security,” which can be assigned to a virtual server. However, you can change the policy type to “parent.” When you switch the “policy type” to “parent,” the security policy can no longer be applied to a virtual server. In this example, we create a security policy named “parent” with the policy type set to “parent,” based on a comprehensive security template with learning mode set to manual.
Next, we create another security policy named “child” with the default policy type “security“, which inherits from the “parent” policy. This policy can still be assigned to a virtual server since it is a standard security policy, but it inherits certain properties from the parent policy. For example, you will see that “signature accuracy” and “signature staging” are inherited from the parent policy and cannot be modified.
If you check the list of security policies, you will notice that the appearance of policies of the “parent” type is different. A hierarchical structure icon is displayed beside the policy name, indicating its role as a parent policy.
In the parent security policy, each setting has three inheritance options:
Mandatory: The child security policy must inherit and cannot change these properties.
Optional: The child security policy inherits these properties from the parent but can override them with its own settings.
None: The properties are not transferred to the child security policy, allowing the child policy to define its own configuration independently.
To see the impact of these three options, we will set “Data Guard” as “Mandatory“, “Attack Signatures” as “Optional,” and “File Types” as “None.”
We will then enable the “Data Guard” feature in the parent policy, set the “pdf” file type to disallowed, and disable a specific attack signature. This will allow us to check how these settings are reflected in the child security policy.
Now, if we check the inheritance settings of the child security policy, we observe the following:
The “Attack Signatures” settings are inherited, but you can decline it and override them with your own policy since the parent policy’s inheritance setting is “Optional“.
The “Data Guard” setting is inherited and cannot be changed, as it is configured as “Mandatory” in the parent policy.
The “File Types” settings are not inherited, as the parent policy’s inheritance option is set to “None“.
Now, if you check the “Data Guard” setting in child security policy, you will notice that it is activated by the parent policy and cannot be changed. The „File types“ security policy is completely independent of the parent policy. The „Attack signatures“ configuration is inherited from the parent policy, but you must decline the inheritance to modify the configuration.
Let’s decline the inheritance in the “Attack Signatures” section of the child security policy to ensure that we can change and override the attack signature configuration.
