Re: [PEN-TEST] Your opinions ... more info

[Drew Simonis <dsimonis () FIDERUS COM>]

Jim Miller wrote:
> (...)
>
> Objective:
> Is the certificate authentication process adequate for the cash mgt
> application, or is a VPN recommended?  All other issues are off target.

One of us is confused here.  IMO, a VPN is not related to
authentication.
(I guess semantics can be argued, but a VPN is to protect data in
transit, certificates are used to verify identity.  Not the same)  It
is quite common to use a certificate based auth method _along_ with
a VPN solution.  In fact, your VPN option specified below does just
that.  Honestly, this whole issue is just rather confusing...

> Configuration:
> On the outside of the firewall is Cisco 1720 with public addressing.
> There is an intrusion detection server connected to it, and of course
> it has connections to the firewall and to the Net.  On the inside of
> the firewall is the internal network using proprietary addressing.

You mean non-routable IP's or some new protocol?  Honestly, it could
be either, so be specific.

> The DMZ/firewall island uses proprietary addressing, and this is where
> the cash mgt application and the certificate server are to be located,
> probably both on the same box.  The firewall is configured to protect
> the island from both inside and outside access.

Having the application and the process used to protect access to it
(the CA) on the same machine is possibly the most foolish thing I
can think of in this situation.  I would have them on seperate
machines with a firewall between them, but I'm paranoid.

> Certificates:
> The bank will issue its own certificates using MS Certificate Server.

Am I the only one who thinks certificate use without the presence
of a trusted third party in such an application as this is a bad
solution?  I don't trust any one group enough, and if I knew that
the CA was on the same system that was running the application,
I would be even more hesitant to use this.

> They will not use the recommended method, certificate hierarchy.
> They will instead manually set up and issue certificates to clients
> when a request is approved.  The certificates will be installed in
> MS IE by our support at client sites after receipt via email of the
> notification of certificate approval.  Any detection of certificate
> compromise will be addressed by revocation and re-issuance to the
> client using the manual / approval process.
>
> Passwords:
> (...)
>
> VPN Solution:
> Windows 2000 Server and Windows 2000 clients was the solution I was
> recommending as a stronger solution.  Given what I have read, I could
> not see where this solution would add any support burden over the
> certificate solution.  This solution uses  client/server IP tunneling
> with PPTP/L2TP, MS-CHAP v.2, and certificate authentication.

You have to seperate the ideas of VPN (encryption) and authentication.
You are really specifying two different schemes, but you are grouping
them oddly.  These are:

Certificate based authentication, SSL encryption.
Odd, MS authentication, SSL through PPTP tunneling.

Personally, I don't like PPTP as a VPN solution.  Its yucky.  But in
any event, the protection of the data in transit is quite different
than the means to authenticate access.  So the real question here is
"Do I use CHAP/MS/Certificate authentication or do I use just
certificate based authentication.  The only addition that PPTP provides
is that tunnel, and for tunneling I say you can't beat IPSec.

> Reasons for not using the VPN solution:
> From the responses I received from IT staff, I was under the
> impression that they were recommending a vendor's solution without
> due consideration of the security problem.  I could not see, based
> on what I read, that the VPN solution would add any more support burden
> than the certificate schema, as they insisted.  But I have never
> administered a VPN.  Am I missing something here?  What is the burden
> of administering a VPN to 50 clients who retain their configuration and
> use it daily?

There are many better ways to secure data in transit, and SSL is one
of those.

> SSL:
> SSL is to be used to secure the packets from view by the public over
> the Net.  A debatable point is whether this solution is equal to the
> security provided by IP tunneling using the MS products above, and if
> I made a mistake saying 132 bit rather than 128 bit, it's a moot point.

> Firewall:
> It's a Cisco PIX Firewall Router, and I'm told not to worry, "It's an
> industry standard.".  What is your opinion?

The PIX is a fine firewall if (big if) configured correctly.  It is a
more challenging firewall to set up, since it is all CLI.  I also agree,
open is open.


> Additional:
        (...)
> Physical security of the client is a recognised issue.  The client can
> be compromised any number of ways if accessible.  Again, not the issue
> under consideration here.

If access is available, then it should be an issue.  You should make it
one. (more billable hours!)