Re: Secure site for medics

[Kent Hoxsey <khoxsey () ix netcom com>]

Alex Melichar wrote:
> I've been asked to come up with a recomendation for a secure medics
> site. I'm posting in the hope someone can point out major holes in my
> thoughts. Thanks in advance.

In your message, you've spelled out a number of the technical details in
your proposal, without describing the requirements that drive them. For
example, you're talking about server architecture (Apache w/ SSLeay, no
mail or ftp) and asking about a firewall, but you haven't spelled out
the
types of transactions that are required and the level of sensitivity of
the information involved.

I see this quite a bit with clients who want to deploy an application on
the Web, jumping in to design an application without first analyzing the
business requirements to determine the level of allowable risk.

> The aim of the proposal is to have a database that contains sensitive
> patient data. This database is to be accessed by about 30-50 users
> ...Their are several different
> locations they will be accessing the database from but will have
> Window (95 or NT) machines. The last part is the hardest: The
> administrator will have who printed what.
>
> So how does one provide a secure server?

Since you say the database contains sensitive patient data, and has
only 30-50 users, there are probably far more secure ways to provide
the data to the users without going so far as to publish the database
on the Internet.

> Where is this solution weak (in terms of how can patient data be
> accessed by unathorised users - this server will be left in a lecked
> location so i'd prefer answers of how someone can get at it from the
> outside not the inside)?

Your comment about keeping the server in a locked location is a good
one,
it means that you're thinking about the physical security of the system.
However, there are a number of other types of security you need to plan
for as well.

> Given that the server will only be a web server (no mail, no ftp,
> etc.) and nothing else, i can't see any immediate holes.

The web server itself is an exploitable link in your plan. If it is
compromised, the cracker would have full access to your database. If
you've set up the webserver to access your database through a firewall,
(and haven't planned for this contingency) there's a good chance the
cracker would have full access to everything on your internal network.

> Also there
> will be only a very small turnover of users

If there is low turnover in users, it would seem like there were other
possible solutions that would be much easier to implement, have less
overall risk than an Internet web site, and require significantly less
support staff to keep running. I won't start proposing designs without
a more-clear understanding of your requirements (that's the same old
problem all over again...) but any good network consultant should be
able to provide you with a number of possibilities - once you can 
clearly describe your needs.

> As this is a firewall mailing list, something more on topic: What
> firewall protection do need to implement?

As I've said above, it's hard to say without knowing your requirements,
your resources (programmers, sysadmins, other support staff), or your
security policy. Without some idea of what you're really trying to
accomplish, and your organization's risk/reward coefficient, it's hard
to do much more than point out weak spots.

However, given that you've put some effort into providing security
in many of the levels of the proposed system, it would seem to me that
there is a high level of sensitivity to this data. Therefore, I would
recommend that you put the design of this project on hold until you 
better understand your security requirements and how to balance them
against your business needs.

If you can afford a consultant, you should start looking for one. If you
can't, I would recommend spending some money on good books and doing
some
reading: 'Practical Unix and Internet Security', 'Building Internet
Firewalls',
both from O'Reilly & Associates, are great books.

HTH

Kent Hoxsey
Database geek