Forefront TMG Beta 3 NIS – Signature Details Properties

Playing around with the IPS from TMG Beta 3, and a thing “intrigued” me a little bit about its signatures details properties for the moment.
Information seems to be a key word about the IPS signatures. By default looks very easy to find information about a particular signature, either using the local available information, or use the online resources, which is a great thing about an enterprise level IPS.

Local info on TMG Beta 3 for a signature:

sig_1
sig_2
sig_7

 

Online resources for the same signature(as writing):

sig_3
sig_4
sig_6
sig_5

 

Among the “usual” details like related bulletins, CVE numbers, protocol, severity, vendor, etc., TMG’s NIS has a Business Impact details property. One may say that if the Severity for a vulnerability is Critical, the Business Impact would also be High, but as can be seen from the bellow screenshots, this is not the case.
Also, there is a Category details property, and the signatures are grouped by(as currently writing): Others, Policy, Exploit and Vulnerability.
The Category details property(local info) seems to have the same meaning with the Class/Type from the online resources.

Would be interesting to understand the logic behind where goes what(well, at least into the Other category for the moment went the test signatures and we probably can imagine what would be the Business Impact of them –:) ),  as in theory, for example, for now, the categories do not seem very flexible and intuitive(say why not have a DoS or XSS category) or the business impact seems a sort of a rating mechanism(why not be the ones under attack, say desktop(browsers, OS’ …) or servers(DNS or web servers …) ).
For the moment, it’s not quite easy to quickly say(group) which signatures offers protection to your desktops or to your servers(or both) or if a service(say IIS) is protected by a signature or maybe a specific browser(say IE 6).

sigs
sigss

But there is another interesting details property, and it’s called Fidelity, the one that actually intrigues me a little bit. The above details properties have some kind of logic, but this one sounds interesting, fidelity of what, as it’s fidelity and not accuracy, like say a sort of a rating mechanism for a particular signature(accuracy would be a double-edged sword: you want the signature to block bad traffic only, and to really block the needed bad traffic –if we were to skip the technical terms and phrase it commonly-).
Actually as can be seen from the above images showing the online info for the pictured signature(as writing), there are no Known false positives and the Signature detection is set to Medium, same as the Fidelity(local info on TMG Beta 3). So are they(Signature detection and Fidelity) having the same/related meaning ?

 

Let’s take a look at another signature, say the one for WebDAV Authentication Bypass on IIS 5.0, 5.1 and 6.0 and “play” a little bit.
No particular logic in choosing this one, except it’s a recent vulnerability, it may be easy to test(at least for the “catch the needed bad traffic” part) and there are many Unicode encodings that will “work”, thus signature detection rate is a key word here. And the info about this signature is quite “interesting”.
Its Fidelity is set to Low(local info on TMG). But now the Signature detection is set to Medium(online resources).(is this a non-synchronization of resources –beta stuff-, or maybe Fidelity and Signature detection do not have the same meaning ?).
Also note that the Severity is set to Moderate(local info on TMG). And the Severity Rating is set to Critical(online resources) –that’s interesting, even Microsoft’s bulletin MS09-020 does not rate it like so-.

sig1_1
sig1_2
sig1_3
sig1_4
sig1_5
sig1_6

 

How “good” is this signature(as writing) ? 
Well, as said above this may be easy to find out, at least for the “catch the needed bad traffic” part. Have a web server publishing rule to publish a vulnerable IIS web server, a “lame” web server publishing rule(we don’t want to be bothered by the HTTP filtering or any other possible settings of this web publishing rule) and a “client” accessing the vulnerable IIS web server behind TMG Beta 3.

 

First let’s see the IIS server throwing at us the “authentication required thing” when we normally anonymously access our “needed” file, just to make sure the test settings are “OK”:

req1
req1_log

 

Next a quick test, for a request similar with the one described by the vulnerability founder and posted at Milw0rm, and as can be seen from bellow “we’re cool“(well, not us, TMG’s NIS –:) ):

req2
req2_log1
req2_log2

 

A “variation” of our request, and “we’re not cool“ anymore:

req3
req3_log1
req3_log2

 

Another variation, and again “we’re not cool“:

req4
req4_log1
req4_log2

 

So, maybe I’m just fooling around, but I can’t stop wondering if the Fidelity details property is just a polite way of saying if a signature is lame or not, and to let us know that when a new signature set version will be released, and if the Fidelity of a signature will go from Low to Medium or so, this signature was improved and can catch more accurately the needed bad traffic.
I’m just guessing here, so I could be miles away of what Fidelity stands for.
But I probably would not set the Signature detection rate to Medium. –;)

Now where is the False Negative rating of a signature ? –:)

Comments are closed