OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: Secure site for medics

Re: Secure site for medics

Steve George (stevepo.i-way.co.uk)
Mon, 7 Dec 1998 10:26:20 GMT

Hi Alex,

Bit early for me so excuse if some of this is not in order...

Two things come to mind with this system:

1) The authentication scheme that you use with the doctors logging in
will be the weakest link. There are 50 users who can be socially
engineered and as you have said they are not that computer literate so
will probably choose bad passwords/write them down. You might want to
consder additional stuff like blocking on source IP (spoofable but better
than nothing) and rolling the passwords over after X time.

2) The current design doesn't offer much protection if the system is
cracked. So if there is an unyet known problem with the OS (and there is
bound to be) you can be cracked and the data reached. Depending on the
form of the data you might consider encryption of the d/base. You would
want to FW access to the web site I would guess by location and port:
minimum would be a screening router. If the site is going to be directly
accessible you probably want to use the standard security techniques and
set up lots of warnings/lures so you are *hopefully* warned about any
attacks.

As always the security available is balanced against ease-of-use and
budgetary constraints.

Steve

---Reply to mail from Alex Melichar about Secure site for medics
>
> Hi,
>
> 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.
>
> 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
> (maybe more later) - all non-literate users (please think of users who
> ask what icons are. I'm meaning to deride them just that the solution
> has to be transaparent and secure). 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? My thoughts are. Use Caldera
> Linux (comes with Sybase SQL server). Get Apache, get the SSLeay
> modules and use the server as a web server. As the UK has no
> restrictions on key size we can use 128 bit (thereby making it secure
> for sometime, important for patient data). Make the whole weeb site
> user-authorisation access only. To solve the print problem use a
> non-print friendly html page when information is asked for (say a
> patients records) and have print friendly pages where prescriptions
> can be printed from (given that people log in a list of who asked for
> what pritn page can be compiled).
>
> 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)?
>
> Personal thoughts:
>
> 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. Also there
> will be only a very small turnover of users and as this is patient
> data, human engineering is unlikely to work (doctors are used to
> junkies asking for free prescription pads etc). As access will be
> using only SSL (v3?) i can't see leaks when data is going over the
> net. Essentially i think this will work. However i have this feeling
> of "I'm missing something *huge*".
>
> As this is a firewall mailing list, something more on topic: What
> firewall protection do need to implement? I hope that i don't need to
> as i'll only allow ssl connections....If i need to can it done cheaply
> and what do people suggest?
>
> Thanks in advance.
>
> Alex
> -------------------------------------------------------------
>

---End reply

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:12:10 CDT