Security Considerations for an Internal .NET Database utilized in Medical Software

Welcome to LockBoxx, your home for digital security solutions. Throughout the Spring, I' ve been working on a medical database writen in C# and MsSQL, for my university. Although the database is being created for internal use only, due to the highly sensitive nature of 'medical information' (such as client PII, health records, and insurance information), I believe this application should have strong security controls. Therefore, I would like to take a moment to consider the security posture of my current implementation, some ideas I still want to implement, and also create a spot where people could suggest new security implementations. The GUIs are all created with classic Microsoft .NET form constructors, and then rely on event calls to trigger specially crafted functions and records, which then retrieve the database information. Through this layer of abstraction, we attempt to deter SQL injection, which would be an easier attack vector if the GUI events called the database directly. This object oriented approach also supports a secure foundation, with strong type input and built in bound protections. Using parametrized queries is another benefit to this object oriented approach, and greatly deters injection by predetermining functionality and basing it off of a minimal amount of user input. I also try to white list user input wherever possible (via drop down menus), but there are still areas that require strings such as 'address', and 'notes'. I still need to tighten my 'blacklists' in these areas, possibly through recursively scrubbing bad charters. Another idea I've had, is curbing the insight of error messages through try{ } / catch { } blocks, and then having these call generalized error functions. After the entire program has been obfuscated, generalized error messages will greatly help to keep internal functions covert. I also need a method of analyzing existing database records, as a way of catching any second order SQL injection. It is certainly a tough beast to tackle, but likewise its always good to have these security considerations in the beginning rather than as an after thought. In this manner, we can justify the object oriented approach not just from a computer science perspective, but a security perspective as well. If you have any ideas, or suggestions that could improve the overall quality or security of a database like this, feel free to comment! Also, don't forget to check back later in the Summer, as I will be sure to post some proof of concept scrubbing code, as well as some good try{ }/catch{ } error code!!