Werking ASM

POSITIVE security model is deny all, allow only what is known to be good.
NEGATIVE security model allow all, deny only what is know to be bad.


NEGATIVE security model is essentially signature scanning engine with 2k+ signatures. Each signature is a known method of attacking an application by exploiting the underlying application, database or circumventing application logic.

POSITIVE security model is essentially ASM learning your application. Put it in the right learning mode and tell your app testing guys "What you don't test, wont work. So make sure you test everything." ASM will then pickup all URL's, filetypes, parameters and the data flowing through them. It build an application ruleset for whatever you are trying to secure.

Then you then refine what it has learnt into entry and exit points to provide page protection for those web pages that should only be accessed by authorised users. Pretty much everything except main and login page. There are may other things as well but thats the core of positive model.

With both together it is great combined model because it protects against many zero day threats by default. Security is top priority with ASM. There is a ton of L7 DOS protections, including load based attack protections. Cookies and dynamic parameters can all be protected with digital signatures. ASM is very strong in this area and its one of the reasons its a leading WAF product.

For clarification I have included a few URL's below to explain how ASM sees them... the following URL's

Learning mode
This is how ASM sees requests as they come in...
Site using https
Application is www.myasm.com
Valid URL is /mojo/special.htm
Valid parameter is myval and myname
Valid Cookies may be sessionid
Valid characters permitted in myval,myname is alphanumeric

Site entry/exit points means only after these can you get to special.htm above.
https://www.myasm.com/login.aspx (entry)
https://www.myasm.com/logoff.aspx (exit)

Session tracking (session tracking)
Cookie: sessionid=randomstringrepresentinguser
Administrator defined session tracking

So some defaults that are useful to know..
Rapid deployment policies are pretty much just negative security logic, they are often used for compliance requirements.

Every object defined can be in staging. Think of this as a pre-policy state for any objects. Objects in staging cannot be used to block anything. ASM watches them to see if they need to be updated during the staging period based on application traffic and learning mode. If they do not need further modification, ASM will recommend you take them out of staging.