Small Office, Big [Software/eHealth] Problems

Disclosure - this post contains information that is non-specific on purpose; if you feel like this may impact you - please contact me directly to discuss!


I recently spent some time thinking about small business -specifically medical practices.  Working for a company like Hewlett Packard I have the luxury of having some of the largest customers in the world in literally every vertical as my customers ...but what about those smaller SMB-sized companies?  How does software security assurance (SSA) apply to them?  How do they apply principles that I wax philosophically about here to their daily activities to decrease risk and avoid being victims?


Well, I still don't have all the answers, but I did find something that I think you need to know if you're operating a non-enterprise business ...more specifically a small to medium sized medical practice.


If you're running an SMB (small to medium sized business) you more than likely have a very tight budget and are very deliberate and frugal about how you spend on technology.  Technology really has to enable something game-changing or cash-producing to enact a purchase.  With that in mind, it's no surprise that a lot of open source software packages have found their way into SMBs.


I'm not saying that open source sofware has more issues than commercial, closed-source code ...but I don't think I'll find anyone to argue against that it's more difficult to find corporate-level accountability with open-source software especially if you're a business.  So ...why does this make a difference?  Let's just say I've managed to review some of those packages and can tell you for a fact that you can drive a Mack truck through every single one I've evaluated.  There's a good, long, list of some of them on the Wikipedia here.  Obviously to protect those who are using these platforms I'm not about to tell you which ones are "hole-y" and how bad... but the situation is dire.


See, the problem is this: If you're a small business you don't have the cash to spend on a professional, well-designed eHealth or eMed platform... therefore when you use one of these poorly written open source platforms you probably won't be testing the security of what you're implementing.  As a result of this - you're putting your practice and your patients in huge risk!  This leads to an unfortunate downward death-risk-spiral, which there may be no return from if you're in a state which prosecutes and punishes for medical data breaches.


So you're stuck between the proverbial rock and a hard place right?  You can't afford commercial apps which at least come with the luxury of risk transferrence -and you can't afford to do the right thing and see for yourself...or can you?


I'd like to urge you to take a look at your practice and if youre using an eHealth or eMedical platform that you're not 100% sure is reasonably secure - send me a note.  I don't often blatantly advertise "Come talk to us" but your patients are depending on you to do the right thing and keep their privacy and security in mind.  It's not just about being cost-conscious because cost can and often will come back and bite you on the back end when you cut corners with security...


Go test your eHealth applications... before you get a "free" test from someone who won't likely share the results, and will keep the data.

(anon) | ‎11-18-2010 11:13 AM

What you're arguing, although I think not deliberately, is security by obscurity. Proprietary software doesn't let you find those gaping holes, so it is in fact a higher, unknown risk than open source tools, where you can actually identify the risk level.


And there's not a huge benefit to risk transference itself.  If you have an EPHI data breach, the patients aren't going to care whether you used "1337 Open 50ur(3" brand software, or AT&T's data services.  It might help you hold onto your security job, but the damage to the patients and your organizational reputation will already be done.


More important than WHAT is used is HOW it is used. A well-managed open source in-house tool, is better security than a poorly-managed and poorly-implemented proprietary tool. If you have a EPHI exposure it's game over, regardless of what you use. Secure processes are what will protect you from an exposure, even with imperfect tools.


For example, if you limit exposure by reducing data batch sizes and improving detection, you may have only a 100-record exposure rather than a 100,000-record exposure.  If you segregate EPHI from regular data, you may have a DB exposure that you can demonstrate touched no EPHI.  But if you don't have the response processes to confirm this, then you have to treat the exposure as an EPHI exposure.


No tool can be trusted, open-source or not.  Secure processes can offer the needed protections.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation