topic Re: How vulnerability profiles work in General Topics

How vulnerability profiles work

mahmoodm — Fri, 06 Oct 2017 19:27:51 GMT

Hi Guys,

Please need your supprt in understanding how vulnerability profiles work or in general how security profiles work.

I have done a lot of studying in this regard and all they say is that it works on the basis of signatures.Below is my understanding.

Signatures:Its like any specific pattern or a behaviour in the traffic ,payload etc,please correct me if i am wrong.

So if the PA sees any such it will apply the rules defined in the security profile,is this correct..?

In addition how to understand the client/server critical etc.

Thanks

Re: How vulnerability profiles work

mahmoodm — Mon, 09 Oct 2017 14:14:58 GMT

Hi Guys,

Re: How vulnerability profiles work

reaper — Tue, 10 Oct 2017 07:10:32 GMT

hi @mahmoodm

yes, signatures are used to identify threats. a signature is a specifc patern in a packet or series of packets

first off a session needs to match a specific security policy before it can match a security profile

so for example you have a client making an http connection out to a webserver and matches your browsing policy

if this policy contains security profiles, these will be active throughout the session and scan for suspicious packets/payload/signatures

if the client tries to send a malicious payload, like for example a header overflow, that is intended to crash the webbrowser, this will be the 'server' host (because the server is being attacked)

if the server tries to send something malicous to the client to try and run scripts on the client (cross site scripting), this is the 'client' host

vulnerability is determined based on the potential impact of a threat

informational, low and medium are usually threats that have very limited impact or a patch has been made available for a long time already, high and critical are dangerous and could cause serious harm to your systems

Re: How vulnerability profiles work

mahmoodm — Tue, 10 Oct 2017 06:31:34 GMT

Hi reaper,

Thanks for the response and it clears most of the doubts.

Please can you explain whether the file blocking profiles work the same way i.e the session is scanned for all the traffic to look for signatures of the files which are to be blocked/allowed etc..?

And one more confusion is that why do we need to have both the wildfire and file blocking profile applied to the same security rule while if we define the file blocking profile to block certain files then why would we want them to be send to wildfire for analysis.

Thanks

Re: How vulnerability profiles work

reaper — Tue, 10 Oct 2017 07:20:15 GMT

Hi @mahmoodm

Yes, the fileblocking profiles work mostly the same way by verifying payload (threat looks at the entire session while fileblocking is only interested in payload) for and looking if a specific type of file is being transferred. It looks at the type of file, and not just the extention (so hiding an .exe by changing extention to .txt does not work)

wildfire will only send allowed files out for analysis, so if you block PE files, these will not be forwarded.

- if a file is blocked it will cut off the tcp session early on and the 'rest' (payload) of the file will not be received, rendering the file unuseable for forwarding

Re: How vulnerability profiles work

mahmoodm — Tue, 10 Oct 2017 19:23:05 GMT

Hi,

Thanks a lot for great clarification.

So is it recommended to have the wildfire profile and file blocking profile on the same security rule or what is the best practice.

Or we need to segregate the rules for separate profiles.

Thanks

Re: How vulnerability profiles work

Raido_Rattameister — Thu, 12 Oct 2017 14:19:48 GMT

Security policies are evaluated top to down.

First policy that matches traffic will be used to either allow or deny traffic.

If traffic is denied/dropped then no other policy is checked.

Security profiles are checked only if security policy permitted traffic. So yes you need to add all profiles to all security policies with "Allow" action.

AppID can change during single session (incomplete > web-browsing > sharepoint-base > sharepoint-admin etc) so single session can match to different security policies but only one policy at the time.