Vulnerability understanding

[helenio.sartori]

I'd like to figure out the meaning of a vulnerability alert

let say that I have an alert like:

Severity          Name                                                                                                                               ID                  Direction

critical         Adobe Flash Player Bounds Checking Remote Code Execution Vulnerability  33967      server-to-client

This mean that in my network I have a client that has this kind of vulnerability or meas that an external server is trying to exploit the vulnerability ?

Or the client is downloading a file that potentially has this vulnerability ?

[mikand]

Direction is set to "server-to-client" which means that you need to check in the traffic log to find out who is the "server" and who is the "client" for this connection.

The "client" is the one who initiated the connection.

Edit: Meaning that the client tried to download something from the server which then was blocked.

[helenio.sartori]

Thank's for the reply ...

This vulnerability is not on blocking mode but only in alert, therefore no session was blocked.

For me is not clear if this is "only" a vulnerability alert or is alerting about an active ongoing exploit ?

[rmonvon]

Hi...you are correct.  Alert action is equal to 'permit & log' and alert does not block the threat. You certainly can change the action to block if desired.

The event is indicating that the vulnerability was detected and it may or may not be exploited.  Thanks.

[mikand]

A common setup seems to be to set Critical, High and Medium to block while Low and Informational is set to alert.

Unless you are paranoid like me and prefer to set them all to block :smileysilly:

The problem with the later case is that you will need to hunt down the false positives in order to whitelist those cases (since Low and Informational seems to contain a a higher grade of false positives than the other categories).

[helenio.sartori]

At the moment I block only Critical and after your gently post I'll go also for High and I'll think about Medium too, thank's.

Once you saw Critical and Hight Block alarm did you had a chance to check the client to see if it was I false positiv or not ?

You have policy to patch clients in this case ?

In case of Block did you had claim from client about service, i.e session drop or pgae not reacheable etc ..

What is from your experience in the impact on services in case of block Critical, Medium, High ?

[mikand]

Depends on what the alarm is about.

If its a pdf which is suspicious then I would try to cross-test it with another AV such as Kaspersky or similar or if the file is public then upload it to www.virustotal.com to see what the other 42 AV-vendors think of the file.

Usually when false-positives occurs you get support-tickets from clients (or server-owners) that some flow didnt work as expected - for example that they cannot download this particular pdf or such.

However dealing with an IDP solution you must on daily basis look at it and tweak it in order to learn whats the baseline in your particular network. This way you get experience from what can be a false-positive and whats most likely not a false-positive. Its not uncommon that developers doesnt stick to RFCs and other guidelines or even best practices and use all sort of dirty stuff to communicate over the network and when you put a NGFW such as a PAN into your network then suddently all these bad behaviour shows up in the logs (for example when developers tries to tunnel stuff over already approved TCP/UDP-ports where old firewalls would allow TCP80 even if its SSH where PAN will block such attempts (if you configure it that way)).

A common problem with IDPs is the chicken race regarding if blocking should be used or not.

An IDP which use for example "failopen" for its interfaces is in my opinion not an IDP you can rely on. You should in this case see this unit as an IDS (or IDS+ :P) because when it fails it will suddently not block any traffic att all but let everything pass through.

There can however be situations where a strict block policy can be bad....

For example what will happen if your firewall/idp/whatever suddently stops traffic from your CRL-server?

In this case (in my opinion) you should verify how the equipment which relies on the CRL will function. A VPN-concentrator which cannot reach its CRL shall in my opinion not allow any new clients until the CRL can be reached again (or allow a manual override but this should really be a manual override).

If you are still chicken about blocking you could then whitelist just this CRL server in your configuration and let all the other flows be blocked by default (while bad traffic to/from your CRL perhaps is set to alert).

For example:

Default
Critical: Block
High: Block
Medium: Block
Low: Block
Informational: Block

VIP
Critical: Block
High: Block
Medium: Alert
Low: Alert
Informationl: Alert

VIP_Alertonly
Critical: Alert
High: Alert
Medium: Alert
Low: Alert
Informationl: Alert

It also depends on which resources you are trying to protect.

For example traffic to/from Internet I would prefer block for all levels (Critical, High, Medium, Low and Informational) while traffic to/from your internal servers to/from your internal clients I could accept to block just Critical, High and Medium (and set the rest to alert).

Also you must take into account that the levels is set by PA themselfs and there are probably cases where they set something to Medium where you might consider it to be Low or even worse the other way around - if PA set something to Low which you would assume is at least Medium (for the case where Medium and higher is blocked and Low and lower is alert).