I am doing a minor project on information security in which i am implementing techniques listed below to protect a HEALTH CARE database.

  • Preventing SQL Injection (using prepared statements,validating,using a tokenization algorithm)
  • Preventing CSRF attack (inserting a hidden token in the form)
  • Preventing Brute Force attack (locking account after 5 unsuccessful attemts)
  • Preventing XSS
  • Validating every input
  • Initiating Session only on cookies
  • Implementing negative database.(http://en.wikipedia.org/wiki/Negative_database)
  • Encrypting Confidential Information
  • limited privilege for every user

EDIT I am also implementing these points which i dont post earlier bcz i thought they are less important. but the answers here clearly shows the importance of these points:

  • Audit Log
  • Strong password
  • Secure connection using session_set_cookie_params
  • Access Control

So now my question is- Is there anything left that i m forgetting?? i know a few of them like security on network layer etc. I am running my project on localhost so i think i cant do anything on network layer.

  • 12
    That is a decent list in theory... I would worry more about implementing those things correctly than expanding the list.
    – Joel
    May 11, 2014 at 17:49

4 Answers 4

  1. SSL Connection to the server so no one can sniff passphrases or data over the network.
  2. Don't forget your backup: it should be encrypted too. The key should be stored independently so if someone gains access to the backup he cannot use the data.
  3. Depending on your country of residence there can be legal requirements for health data protection.
  4. Manage access permissions: make sure that if someone loses access permissions the account gets canceled.
  5. Limit access to certain IP-addresses. In the ideal case the local network. It is pretty unlikely that someone from another continent needs access so don’t be afraid to block whole countries.
  6. Block too easy passwords. Password123 and similar should not be possible! If an attacker gets hold of enough usernames someone will have a weak password. Using multiple IPs / a botnet an attacker can circumvent your brute force protection.
  • Thanks..i liked 2,4 and 5 point..i will surely try to implement them.. May 12, 2014 at 5:03
  • 1
    @Shubham Gupta - Points 1 and 6 are probably most important. The bad guys have million-word lists of known passwords from past data breaches. It would serve you well to blacklist those passwords. See Peter Gutmann's Engineering Security, and look into a Bloom Filter to approve a user's password choice. Even though it covers millions of passwords, the Bloom Filter is only 30KB in size. Ditch the password policies like complexity/rotation. Its useless in real life, and actually hurts security in some cases (especially the rotation policy).
    – user29925
    May 12, 2014 at 8:26
  • 1
    Please, be careful with 5 : as a traveler and expat in China, having services that I still use from my home country blocked can be very annoying, even I know I am only part of a minority. The GFW of China is already restricting enough ...
    – guigui42
    May 12, 2014 at 8:49
  • @guigui42 True, and attackers can use proxies to access from another country (e.g. using the free Tor program which can be used as a proxy). The average user who doesn't know about proxy is unable to use the services while attackers can easily use a proxy. May 12, 2014 at 9:13
  • @noloader thank you i must say the book that you have referred is awesome. May 12, 2014 at 10:53

I would add fine-grained access control. You need a layer on top of your database that controls who can access which medical record. NIST defines what fine-grained access control entails here.

Once you have that in place, you also need a technique to log all access and all retrieval of information so that users can be held accountable.

Both these techniques are needed to implement data privacy which is particularly important in the medical sector.

Have a look at the Privacy By Design website which will also have some good pointers.

  • 1
    Thank you..I m already implementing access control mechanism in which different user have given access according to their usertype..in this way i am controlling who can access which medical record May 12, 2014 at 5:07
  • Great! Out of curiosity how did you achieve the access control? Is it policy or configuration-based? May 12, 2014 at 5:35
  • As i said i am giving access according to the usertype..so i think its configuration based..am i correct? May 12, 2014 at 10:48
  • Where do you do the user type check? In code? In a SQL statement? May 12, 2014 at 14:58

You have a good list of what needs to be done to protect and harden an application, what it is missing is reporting. Security is not just about protection, it's about management. I'd add to your list a reporting system which can give you some management statistics about failed logins, attempts to crack your security, etc.

  • Oppss.. i forgot to mention it in my list..i am already maintaining an audit log which keeps information of every activity of every user such as IP address, date and time of login, which page he access, failed login attempt etc. May 11, 2014 at 19:58
  • Sounds like you've got it together. A useful thing to add then might be automatic notification on security events like sql injection or out of bounds inputs. That's pretty standard in industry. You could add in automatic response as well, say locking out a user when there's an attempt to crack security.
    – GdD
    May 11, 2014 at 20:03

Good answers here.

I would like to way in regarding 4 points you mentioned:

  • Encrypting Confidential Information
  • Limited privilege for every user
  • Audit Log
  • Access Control

I am looking at them separately because they are the ones that are particularly important when you're handling confidential/personal data such as Healthcare related data. Others such as SQL Injection are usually dealt with on the application layer (Using for example a Web Application Firewall).

Now back to our 4 points, you are going to need a comprehensive DB encryption solution which has all the 4 features.

In a case such as yours, you may want to check out a column-based encryption solution such as D'Amo or MyDiamo if you are using open source DBMS. The so called "Transparent encryption solutions" that are encrypting data on the file level are not going to protect you from someone physically stealing your DB hard disk but they are little more than useless if you need strong access control based on users, applications, IP addresses, time of the day, etc.

Another obvious advantage you get with column-based in a case such yours is that you won't have to encrypt all the data. You can choose to encrypt specific columns which contain sensitive information and define different policies as well as enc/dec encryption keys by column.

Key management is obviously going to be another separate issue out of the scope of this thread.

Hope this helps.

Disclosure: I am a consultant for the above mentioned products.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .