Forum Discussion
NimbostratusWildcard in ASM Rapidpolicy building
Hi,
While moving ASM policy(built using rapid policy builder) from learning to blocking mode we have to keep wildcard elements like parameters, url. or we have to remove wildcard.
While working on ASM rapid policy in my lab i observed request were getting blocked if i remove wildcard. But keeping the wildcard in policy mean any quest legal or illegal that match '*' element properties(lenght, metacharacter) would be allowed.
Thanks,
Sachin
Hello Sachin,
By removing the wildcard and configuring the policy to include only explicit entities (parameters, URLs and file types), you are configuring what's called a "positive security model", meaning you are only allowing the known entities within your environment. Anything that's not configured as an explicit entity will result in respective illegal violations.
If you prefer the ASM to not reject all those (some legitimate) traffic that are not configured explicitly, then you will need to have those wildcard entities in place (for URLs, you need to have one for HTTP/HTTPS, depending on whether you've configured your policy to differentiate between the two protocols or not). This is something we refer to as "negative security model", wherein you allow everything and thereby configure explicit granular configuration for particular known ones from there on in.
As for which model you should go with, that's entirely upto you and your environment needs. Each one has its own pros/cons. Let me know if this answers your question.
Ashwin
sachin_80710Thanks Ashwin, Now its more clear about how to move Policy with Rapid deployment temp. from learning to blocking.
Thanks,
Sachin
Ashwin_VenkatEmployee
Hello Sachin,
By removing the wildcard and configuring the policy to include only explicit entities (parameters, URLs and file types), you are configuring what's called a "positive security model", meaning you are only allowing the known entities within your environment. Anything that's not configured as an explicit entity will result in respective illegal violations.
If you prefer the ASM to not reject all those (some legitimate) traffic that are not configured explicitly, then you will need to have those wildcard entities in place (for URLs, you need to have one for HTTP/HTTPS, depending on whether you've configured your policy to differentiate between the two protocols or not). This is something we refer to as "negative security model", wherein you allow everything and thereby configure explicit granular configuration for particular known ones from there on in.
As for which model you should go with, that's entirely upto you and your environment needs. Each one has its own pros/cons. Let me know if this answers your question.
Ashwin
- sachin_80710
Thanks Ashwin, Now its more clear about how to move Policy with Rapid deployment temp. from learning to blocking.
Thanks,
Sachin
