When I wasn't looking, a colleague (proofreading my resume) asked me 
to do some security work on a software system he is planning to release 
soon to some clients.  The software was built principally by him, and will 
be housed/served out of a data centre.  I'm being consulted for all 
matters (hardware, software, database, network) security related to the new 
venture.  This has inspired me to start my own IT security business in my 
spare time, something I was always going to do one day - just not so soon 
or effortlessly I thought :)

Anyhow, I would like some advice from the Grex community on what 
hardware/infrastructure you would recommend.  He was originally going to 
host the application on a virtual machine share in the data center... it 
did not take rocket science thinking for me to instruct him this was a bad 
idea.  So, we are now more looking at a completely separate box (acquired, 
installed, and managed by us) to be stored in the data center.  

To give you an idea of the requirments, it is a thick-client application 
developed in Visual Basic .Net talking to a SQL Server 2005 database, with 
no (or very little application-main) server logic, except for stored 
procedures in the database.  There will be a small component utilised 
initially for securely registering (think licensing) a customer pool for a 
client organisation, but this is not the core part of the application.  

I'm not so concerned about the security requirements, but I would like 
your input on what hardware (firewalls, VPNs, and specifications for the 
server-class machine we should purchase).  At any one time there may be 
say 30 clients maximum querying the database.  He is thinking Raid-1 for 
backups.

Comments ASAP please :)

19 responses total.

Further info:

- Client users will be (typically) running Windows XP on a Windows 2000 or 
  2003 domain, using a firewall router connected to an ADSL modem.
- The operating system on the server will be Windows 2003 Standard Server.
- Correction: typically each client organisation (let's factor in maximum 
  5 client organisations in the first year) will have anywhere btween 3 
  and 30 potential concurrent users.
- Each client organisation will have a separate database instance (same 
  schema though) on the Microsoft SQL Server Enterprise edition server.
- App configuration being thick client calling stored procedures.
- Following each transaction, the application disconnects - i.e. breaks 
  connection - therefore concurrent connections on the server should be at 
  most times be limited to users that are either fetching, updating, or 
  inserting data and be minimal.
- The client's data is operationally critical meaning it is the only audit 
  trail of cient contact.

Thanks for your hardware advice ASAP, in advance.

From a security standpoint I would recommend against your database
allowing remote connections from the internet, even if such connections
are through a VPN. I think that a compromised client having that type of
access could be disasterous. I think you should look into a way of
serving this "fat client" as a thin-client. This isn't as hard as you
think, and my recommendation to do so would be using Citrix Presentation
Server.

When a client connects to Citrix, the Citrix server will launch the
application and then serve the display and inputs in an x-terminal type
fashion. The advantage is that you only need to install the application
to one machine, the Citrix server. This also means that when it comes
time to upgrade you only have to upgrade the application on one machine,
the Citrix server.

We use Citrix where I work to provide database-driven banking
applications to end-users off-site. It has worked really well for us and
I think it would be worthwhile to check out.

Hardware recommendations:

We have had really good experience with IBM x-series servers. They are
very well built, and the support has been phenominal. We tried Dell for
a short time, but their service was terrible.

As for firewalls and VPNs, I am definetely a Cisco fan-boy so naturally
I would suggest looking into a ASA or PIX firewall. And while Cisco does
have its own VPN system (3000 concentrator), you should look into a
system called Firepass from F5 networks.

Thanks, a couple of questions:

(1)
I like the idea of application virtualization, however I would like a 
way for the virtualized application on the server to be able to have 
some access to the client's machine (for licensing, auditing, and 
determining which database instance to connect to).  Is this possible?
If so, how does it work?  For instance, if the virtualized application 
read a MAC address - would it be grabbing the client machine's MAC 
address or the MAC address of the virtual application network connection?

(2) If the above is NOT possible, does this not just shift (and 
potentially increase) security threats to client organisations?  
Guessed/brute-force attacked/socially-engineered attained login 
credentials of another organisation's clients would allow the attacker 
full access to that other organisation's data.  Or is there a way to 
combine the security of the VPN with the application's hardcoded 
security?




  

Are you managing the entire client or just the .NET application?  I would
recommend a thin client with SSL-VPN if you don't have control over the end
user's machine.

What do you mean by managing the entire client?

Due to timeframe of rollout and hardware/licensing costs the application 
server virtualization approach is not a feasible solution in 
this project.

The .NET application is a self-contained, standalone application - not 
interfacing with any other applications on the client.

One of the likely client organisations has a Cisco 837 Router already in 
place.

We have an understanding that we can ask/demand the client organisations 
to acquire a minimum-spec router/VPN to securely connect to our firewall 
router (to be acuired by us) for communication route ultimately to our 
application.

re #6
Entire client=desktop

The thick client has no interfaces to any other applications on the 
client's OS.  We are not going down the virtualization approach (in any 
form) due to timeframe and costs; that's pretty neat anyhow (least I 
researched it quite a bit and learned a bit more about some technologies 
in that space).

This is going to be a neat little project --- security from many angles, 
and I'll get to play with .NET and SQL Server (*giggles* neither my 
preferred cup of tea normally - but great for the novelty factor and good 
experience).

For those interested, you can take a look at my new business card on 
http://spooked.unixcab.org/   

I'm not a graphic designer, but I think I did an okay job with  the 
layout.  Always could have done better, with more time -- but, I always 
rush fluffy stuff.

The cards will be finished in a glossy coating.  Anyhow, let me know what 
you think.

FWIW, Citrix isn't virtualization, its terminal services. And if you are
going to go ahead and have the clients installed onto end-user
workstations, then I really think you should look into Firepass VPN. It
will sit behind the Cisco 837 router and allow external clients to
connect using a web browser. The browser initiates the VPN networking
and can check to make sure the client has proper anti-virus, etc.

The standard solution for this type of thing is to use a 3-tier architecture,
with an application server sitting in the middle mediating access to the
database.

I am going to have to agree with other posters here and suggest that it
would be better to run the client programme on a secured, controlled
server and simply export the display of it, rather than having the
client out in the wild. If that is not an option, at the very least you
do not want the client to ever have any way of reaching the database
itself, and require it to have its access to the database brokered and
mediated via a server programme that authenticates the client and
actually performs the database transactions. Consider the following
stack of tasks: 

display
client logic
communications
server logic
data access logic
data storage

You gain better control over the behaviour and expose fewer potential
vulnerabilities the higher up on that list you manage to keep
centralized. Additionally, by only exporting the display (either through
a web application like moving the client and server logic into asp.net
or by using an application service like Citrix), you can do upgrades
without having to ship CDRoms or making the customers download a new
client programme. 

Regarding moving the data access logic off of the client, consider this:
you have a legit user who fires one of their employees. This employee is
vindictive and clever and dissects the client programme and figures out
how to connect directly to your database and muddies up all of the data
for their former employer. Since you control the database, your customer
would be pissed off at you. And would probably voice their displeasure
by having their attorney send certified letters to your attorney, and
that can only end badly. 

A good rule of thumb is to keep a database isolated with only two links:
a link directly to the server application and a link into the back-end
for monitoring and for mounting SAN/NAS/CIFS shares. It should only
accept queries and whatnot from the server, which scrubs and sanity
checks everything. 

If you have to keep the client as a "fat client" programme, I would at
least recommend that you move as much of the business logic and data
access logic into the server, and also make use of some sort of
encrypted tunneling system, such as ssh or a VPN (Cisco's ASA is sexy,
and might even be better than the PIX). 

Yes, I know full well that a 3+ tiered architecture is the way to go, in 
any professional Internet-business-data solution.  I have worked in the 
past as a security analyst/programmer and more recently as a Java/J2EE 
architect/lead developer/team leader, so I'm fully aware of good 
application and security design.  

But, in the real-world, often security is added too late in the 
development/production cycle - I have seen it on almost every client 
project I have ever worked on.  Furthermore, clients (including major Telco 
providers and govt departments) not only don't understand (or care) that 
it is more difficult to retrofit good security, but they don't want to 
budget an awful lot of cash for hardening an application.

I'm very limited in changing the architecture of this application, but in 
my report I will of course make the client aware that the parameters I 
have been tasked to work within make the solution less than ideal in terms 
of security.

As long as I make this clear, get it in writing, and get client signoff 
before proceeding - I cover myself as a professional.  It is not ideal, 
but it's business I'm afraid.

Such is life, I guess....

Tell me about it :p

This is slightly off topic, but we use a lot of remotely-hosted Citrix 
applications where I work.  What amazes me about Citrix is how fast it 
is.  I'm used to remote access apps like VNC and pcAnywhere, and 
they're a real pain over Internet links, with the remote system often 
lagging behind mouse clicks and typing.  These Citrix apps, on the 
other hand, could be mistaken for something locally hosted (and 
sometimes are by users.)

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss