[isalist] Re: Failing PCI Compliance tests

  • From: Jerry Young <jerrygyoungii@xxxxxxxxx>
  • To: isalist@xxxxxxxxxxxxx
  • Date: Thu, 31 Dec 2009 07:51:00 -0500

They're essentially saying that the server supports older ciphers that could
"potentially" be used for malicious activity.  A registry "hack" will stop
the ISA Server from responding to those older ciphers.  Let me see if I
can't find it (I just recently had to review this for SOX compliance).

On Thu, Dec 31, 2009 at 7:46 AM, Mike Anderson <mike@xxxxxxxxxxxx> wrote:

>  Hello All,
>
>
>
> We have Win2K3 web server behind an ISA 2004 Server, which hosts our
> website (with a SSL Certificate for doing credit card transactions).
>
>
>
> As of 3 months ago, we started getting these warning e-mails from our
> credit card merchant people stating that we failed their PCI Compliance
> test.  If we don’t get this fixed, we will start to be penalized and we
> can’t let that happen.
>
>
>
> SSL Certs are probably one of my weakest areas and I just know enough to
> get by.  The PDF generated from their automated system, outlined the trouble
> areas and offered some websites we could visit that could help remedy the
> problem.  I must say, being a technical person myself, I had a hard time
> navigating the documents in addition to understanding how they applied to
> our problem.
>
>
>
> The next 2 blocks of text are the 2 primary areas that killed our PCI
> Compliance score, and if we can fix this, we should be okay once again.
> BTW, the following blocks of text, correspond to TCP, Port 443 & HTTPS…
>
>
>
> The first one:
>
>
>
> Synopsis : The remote service supports the use of weak SSL ciphers.
> Description : The remote
>
> host supports the use of SSL ciphers that offer either weak encryption or
> no encryption at all.
>
> See also : http://www.openssl.org/docs/apps/ciphers.html *Solution*:
> Reconfigure the affected
>
> application if possible to avoid use of weak ciphers. *Risk Factor*:
> Medium / CVSS Base Score
>
> : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list
> of weak SSL ciphers
>
> supported by the remote server : Low Strength Ciphers…
>
>
>
> The second one:
>
>
>
> Synopsis : The remote service encrypts traffic using a protocol with known
> weaknesses.
>
> Description : The remote service accepts connections encrypted using SSL
> 2.0, which
>
> reportedly suffers from several cryptographic flaws and has been deprecated
> for several years.
>
> An attacker may be able to exploit these issues to conduct
> man-in-the-middle attacks or
>
> decrypt communications between the affected service and clients. See also :
>
> http://www.schneier.com/paper-ssl.pdf *Solution*: Consult the
> application's documentation to
>
> disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead. *Risk Factor*: Medium
> / CVSS Base Score
>
> : 2 (AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:N)
>
>
>
> Now my question is, does the ISA Server come into play with this whole
> thing?  Or is the primary problem relating to our Web Server and how the SSL
> Cert was originally created?  I didn’t create the initial key and purchase
> the original certificate, but I know darn sure that the person who did,
> would have selected the strongest encryption available at the time – which
> would have given us the peace of mind secure transactions.
>
>
>
> I know that in order to get the SSL to pass through the ISA Server, we had
> to export the SSL Cert from the Web Server and install it on the ISA
> Server.  Was there something different that I should have done during that
> process?  Do we possibly have to trash our existing SSL Cert, and reapply
> for a newer strong one?
>
>
>
> Again, I apologize for being so green in this area – I can only be good at
> so many things J
>
>
>
> Thank you all again in advance, for all your wonderful help.
>
>
>
> Mike
>
>
>



-- 
Cordially yours,
Jerry G. Young II
Microsoft Certified Systems Engineer

Other related posts: