F5 DUMP‎ > ‎

F5 ASM basics

posted 10 Jun 2016, 08:46 by Donald Ross   [ updated 13 Jun 2016, 02:49 ]
***in progress

*Ultimately ASM protects web applications
-A web application firewall can inspect each element of an HTTP request.
-An attack signature can be described as known keywords or character sequences.

***An virtual server must have an HTTP profile associated with it in order for an ASM policy to be applied.

*the security policy is always in either blocking or transparent mode.

Deployments Wizard

Assign virtual server
Select deployment method
Configure security policy properties
Assign attack signatures
Choose policy type



Policy Types

Fundamental provides granularity sufficient for most organizations creating a generalized security policy that is easy to maintain. This policy type includes HTTP protocol compliance, evasion techniques, file types and lengths, attack signatures, and the request length exceeds predefined buffer size violation. This is the default setting.
   
Enhanced provides additional granularity and security features suited for customers with higher (and, typically, specific) security needs). This policy type includes all elements in the Fundamental policy type, and also includes parameters and lengths (global level), cookies, and methods.
   
Complete provides the most granular definitions, includes all security features, and is suited for advanced users or customers with extreme security needs. This policy type includes all elements in the Enhanced policy type, and adds URLs and meta characters, parameters (meta characters and URLs), and dynamic parameters (using statistics). This security policy typically takes longer to deploy. (takes longer to develop and maintain)

sampling


Enforcement mode




A mixture of good and bad traffic should drive this process

***Trusted IP address can enhance learning by completing all legitimate requests

Transparent

Blocking
*even in blocking mode there is a staging mode(this prevents false positives)  *remains in staging until changed - automatically or manually enforced (default enforcement time is 7 days)

Enforcement readiness period
Day 1-6 *Observe staged attack signatures which get triggered
Day 7    *Enforces untriggered signatures  /  Keeps triggered signatures in staging for more analysis

After day 7
ASM will block an attack signature that has been enforced.

Thresholds (policy loosening)



Additional Information from Ask F5
During automatic policy building, the Policy Builder builds security policies in three stages. These stages correspond to the three settings in the Rules area of the Automatic Policy Building Configuration screen. Rules in each stage determine when an element in the security policy moves from one stage to the next. The rules have different values depending on whether the traffic comes from a trusted or untrusted source.
   
Accept as Legitimate (Loosen)
During this stage, the Policy Builder identifies legitimate application usage based on seeing repeated behavior from sufficient traffic, over a period of time. The system updates the security policy accordingly. Based on wildcard matches, Policy Builder adds the legitimate policy entities (putting most into staging to learn their properties), and disables violations that are probably false positives.
For example, when the Policy Builder sees the same file type, URL, parameter, or cookie from enough different user sessions over time, then it adds the entity to the security policy.
   
Stabilize (Tighten)
During this stage, the Policy Builder tightens the security policy elements when the rate of security policy changes stabilizes. For example, the Policy Builder enforces an entity type after it records a sufficient number of unique requests and sessions, over a sufficient length of time since the last time an explicit file type, URL, or parameter was added to the security policy.
Similarly, the Policy Builder enforces the entity's attributes (takes them out of staging) after it records a sufficient number of unique requests and sessions, over a sufficient length of time for a particular file type, URL, or parameter since the last time the entity's attributes or settings were updated.
When the traffic to the application no longer includes new elements that need to be added to the security policy and the Policy Builder has enforced the policy elements, the security policy is considered stable and its progress reaches 100%.
   
***Track Site Changes***
If a request causes a violation, the Policy Builder looks for changes to the web site. If the Policy Builder discovers changes, it logs the change (Site change detected) and temporarily loosens the security policy to make the necessary adjustments. When the Policy Builder stabilizes the added elements, it retightens the security policy.
Although it is not recommended, you can disable the Track Site Changes option. If you do, when the security policy progress reaches 100% stability, the system disables automatic policy building. The security policy is not updated unless you manually change it, or restart automatic policy building by re-enabling the Track Site Changes option.


Comments