Home page logo

pen-test logo Penetration Testing mailing list archives

[PEN-TEST] Your opinions ... more info
From: Jim Miller <MillerJ () FABSSB COM>
Date: Tue, 31 Oct 2000 11:44:44 -0600

Thank you for all of your responses.  It was late and I neglected to include some significant details.  I will try to 
make all clarifications here.  Keep in mind my job function: I am an IT auditor.  My job is to reduce technical 
business risk.  I am consulting to my client, who is not all that cooperative and forthcoming, and appears from my 
experience not to understand completely the technology being deployed.  But that may just be smoke and mirrors to keep 
me from interfering.

Is the certificate authentication process adequate for the cash mgt application, or is a VPN recommended?  All other 
issues are off target.

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.  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.

The bank will issue its own certificates using MS Certificate Server.  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.

The cash mgt application controls password issuance and policy enforcement.  The password data is located with the CMI 
application on the firewall island.  Passwords are set up by a client security admin, who sets up client users.  We 
don't need to get into this, as it is obvious that application based authentication is a weak control at best.  [And to 
add insult to injury, the password length will be 6 bytes.]  The issue is the reliance on the certificate schema versus 
the VPN.  We could argue forever about the effectiveness of authentication by logonid/password, and I'd rather focus on 
the issue.

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.   See:  
HTTP://www.microsoft.com/NTServer/commserv/deployment/planguides/VPNSecurity.asp     From what I read, it is simple to 
implement.   HTTP://www.techrepublic.com/article.jhtml?src=search&id=r00220001018jim02.htm  and is a much more secure 
solution for an application with high risk.  It also would allow the use of NT password policy enforcement, a 
significant improvement over the application password schema.

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?

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.

A penetration test was run on the firewall and it was reported that 3 ports were left open.  I was privy only to the 
summary report, and was told that the open ports were really not a problem, as "they only appeared to an outsider to be 
open.  They were truly secured.".  After learning more, I found a respected source who agreed that open is open.  The 
point being that this certificate schema is only as strong as the 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 client base will not exceed 200, so scaling is not really an issue.  
Whatever solution is implemented, it will be from Microsoft.  I can't fight city hall.
I'm told the client browser screen will show we are using HTTPS, not HTTP.
There is no requirements document and no design specs.  This is typical for small IT shops.  They just wing it.
There will be legal contracts with the customer/client, again a moot point, since the issue is the use of VPN as 
compared to certificates alone.
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.

I hope this will allow us to focus in on the target:  certificates alone versus VPN.


Jim Miller, CISA, CDP
VP & IS Audit Mgr
First American Bank Texas
Bryan, Texas   77805-8100
millerj () fabssb com

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]