How to self scan Cipher for IIS 6 and how to set higher strength.

Hmmmm.  Well...

ahoffman points you at the right article, KB245030.  Specifically you would set registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128
to DWORD 0x0

That's the technical answer to your question, but it's only part of the answer.  If you were to actually do this it would disable HALF of your export strength algorithms.  RSA_EXPORT1024_WITH_DES_CBC_SHA and RSA_EXPORT1024_WITH_RC4_56_SHA would still be left.

The 40 bit ciphers Nessus is pointing out are in fact more vulnerable to a brute force attack.  What this actually means in practice is subject to debate.  There is a very good argument to be made that this detection should be removed from Nessus.  I can tell you that most large ecommerce sites leave these ciphers enabled.  Amazon.com allows them.  Heck, even Verisign.com allows them.  The common practice when it comes to PCI scanning is to mark the detection as a false positive and move on.  There are real security problems out there - this simply isn't one of them.

Don't believe me?  Go to:
http://demo.iaik.tugraz.at/sslinfoservlet/servlet/iaiksslserverinfo/
and put in www.amazon.com or your favorite large ecommerce site.

As far as doing your own scan, all of the PCI scanning companies that I am aware of use Nessus.  Available for free download from:
http://www.nessus.org/download/

Best of luck complying with the evil PCI-DSS.

Nessus is only 'free' for personal use (HomeFeed).  If you use it on a commercial environment, then it's $1,200 per year (ProfessionalFeed).
I know a lot of people say it's free, but it's not and as always, read the license agreements before installing and running any product.

Back to SSL... now SSL v2.0 was released in 1994.  It was quickly replaced by SSL v3.0 in 1996 due to a number of inherent weaknesses (for example, the client could negotiate a low cipher strength).  Browsers have been fixed since then, so the only real risk is if you have a client running IE 3.0 or less that ends up negotiating a basic cipher strength that is then easily torn apart by anyone with a network sniffer somewhere along the way (which is tricky).

As a QSA for PCI DSS, I would not accept SSL v2.0.  SSL v3.0 is mature, tested technology and all implementations support it, so use it.  I may give you 90 days to fix this, but that would be all!  :)

I'll sort of agree on the Nessus comment.  The "sort of" is that Nessus can be used in a commercial environment for free under either the open source license (version 2) or the proprietary license (version 3), it's only hooking it up to a feed that requires the $1200 a year license.  A lot of people use it without a feed however.  Including myself, when I very briefly played around with it.

In the original post, the poster had already disabled SSL2 and was asking questions about the low-strength export algorithms under SSL3.  My curiosity for the QSA would be whether he would allow the low-strength export algorithms that run on most of the major ecommerce websites.

jfoutz - "The common practice when it comes to PCI scanning is to mark the detection as a false positive and move on".  That would be nice, but any vulnerability with a CVSS score of 4.0 or higher must be fixed in order for the site to comply to PCI DSS.  This includes weak ciphers...