Experience in HIPAA compliance with Web applications

The most basic risk factor in secure software applications is cost, and the second is fear. Fear is a cost based threat - fear of lawsuits either by the government for not adhering to the HIPAA regulations or by private party class action suits when private information becomes public.

Planning and building secure environments is expensive, and generally does not add to the functionality of a site. Explaining the costs along with the risks helps engage senior management to make excellent decisions concerning the privacy of customers, and to secure confidential information -- for example an insurance agent's book of business.

There are a couple of different aspects when considering the security of secure sites, and to replace fear with appropriate risk management. Many people understand Web authentication software, a component of Web access control, for example a login with password and userID to control access to secure sites, because they are familiar themselves with using secure sites, and even with common Internet technology such as cookies. What is less well understood is the backend side of secure business sites which includes both software and hardware. The hardware includes the Web application server, other application servers, database servers, networking equipment, and the software that runs them, along with Web access control software already mentioned.

Because they require certain functionality on a specific timeline many senior and middle managers make decisions solely based on cost without concern for the constant need to evaluate and ensure security, especially as new applications, Web sites, portals, and functionality are deployed.

IT departments generally build what is requested, and like an old house added to over several generations, the result can be what gets built may have no focus on how it can be secured.

As more complex networking and applications are added to a overworked, aged, poorly networked, or patched together environment organized in such a way that it can not be secured -- the higher the risks become -- not just in terms of intentional attacks but also due to simple technical failure, such as unpatched software with published security flaws or other security oversights.

When IT and security managers request funds to cover the higher costs associated with re-organizing, updating and securing hardware and software in networked environments, often management will not agree to the use of resources nor provide funds for the networking hardware / software, qualified techs, network designers, and programmers, and the time needed to secure backend environments, test, and audit them, in preference to other apparently more demanding needs, especially those they believe will enable the company to increase earnings.

It follows that management needs to understand the risks and will then be more willing to invest the money to plan and secure the environment. This includes providing appropriate secure access control both to the resident software applications and information exchange (such as email and back office data transfer including between 3rd parties), especially via the Internet.

In building secure Web-based applications, obtaining management buy-in is based on explaining the risk factors and costs, so management clearly understands what is at stake for their customers and required. Within the medical industry these laws include data security; specifically the 1996 Federal Health Insurance Portability and Accountability Act, also known as HIPAA or Title II.

HIPAA regulations address the security and privacy of health data; they specify national standards for electronic health care transactions. They are expected to improve efficiency and effectiveness of the nation's health care system by standardizing the use of electronic data within health care administration, via Web-based and networked systems that individuals, providers, employers, and insurers have access to.

Each group will have secure access to differing components or varying degrees of private information.

As a program manager our job is explain the risk and obtain management approval and department co-operation in creating a secure application based on a secure environment. With a new application, a technically competent program/project manager can not make the assumption that the hosting environment is secure -- you need proof. A 3rd party security audit provides proof.

Working with a Northwest medical insurance firm (which has offices in Alaska, Washington, and Oregon) to develop their first true Web application, we drafted an executive summary on security, which could be applied to the firm's ongoing Internet, Intranet, Extranet, and Portal based software. We presented the idea of Web-based application and software environmental security to the company leadership and proposed hiring a 3rd party security firm to perform an audit.

We researched security companies; contacting a member of the Board of Directors, he referred the same security firm which we had already identified. We contracted with the firm to perform a technical security audit.

Setting a new standard for the company, we included the department managers and staff from Audit, Data Security, and Legal on the proposal, planning, meetings, execution, findings, and results of the process for the beta pilot and Go Live versions of the product to launch.

In financial firms Internal Audit holds power; therefore it is crucial to involve Audit as early as possible. Auditors know that if they must they can call any senior management or officer, and ask many difficult and pointed questions on the behalf of their constituency.

We obtained, reviewed, and reviewed and edited proposed legal contacts. We planned and arranged for all meetings and technical access (using encrypted communications with public keys), and followed each security detail up with the development team, and Q/A for final approval.

There was some hands on: to verify changes made by development and verified by Q/A, we retested some functions, checking off the highest level security bugs.

To assure user centric design of the Web-based product we managed the company's relationship with a user interface design and testing firm, to advise on developing an excellent user focused function and design for the product. We also requested legal documentation be created and written for the site, making "Terms of Use", "Conditions of Use", and a "Security Policy Statement" a standard for ongoing sites.

In advocating the use of 3rd parties for a variety of legal and security factors, our primary concern is the privacy of end-users, those the site is intended to serve. However, it is not a small matter that substantial fines are possible when a firm is found responsible for ignoring business standards regarding individual and group privacy of medical information. Of these two things, customer's privacy verses the cost of failure, the second may hold the most interest when communicating risk with management who must in the course of their jobs pay strict attention to the bottom line.

Effective and direct communication, backed up with Audits, cost estimates, and an analysis of real life ("in the past this system was broken into by such and such a person and this particular information was exposed, misused, or sabotaged) and potential risk factors ("if we don't fix this in X amount of time, the risks climb"), and even cite examples of successful lawsuits for similar privacy infractions.

Clearly if a secure site is compromised, regardless of intent, and the company is using standard e-Business security practices for any Operating System to protect the site, the company is not likely to be fined in a court of law. We describe security "Lockdown" (used regarding server hardware) to describe a number of business issues combined with technical issues:

"Security investment requires creating a secure environment both for the people involved and for the software and hardware. This means secure access control throughout the hosting environment, resident software applications, with regular audits, and rigorous follow up with software updates -- as well as excellent communication between IT, Data Security, and senior management."

A future is approaching very swiftly in which, if a system was compromised and your security practices do not measure up, your firm is responsible. That is where the finger pointing begins, and lawyers take over. The same approach holds for data loss as well, such as PII (Personally Identifiable Information).

This kind of responsibility for trust and security, not only for individual secure sites, but also for national security sites, can mean that companies responsible for the secure application software and its configuration on hardware, such as Microsoft, and consultants, as well as other firms become likely to be successfully sued for breaches of data security, and accompanying aspects of reliability, trust, and confidence. This is especially true for financial and medical businesses.

Encouraging the use of qualified 3rd parties to audit security on secure medical and other private sites will enable it to become a standard throughout the medical insurance industry as they engage HIPAA regulations in the interim between current softer standards, and those which also pass data through verification and enumeration hardware (chips) on individual devices.

Program Managers and Project Managers can sleep more soundly when a site is complete and locked down, knowing they have advocated the best advice and alternatives possible in providing secure HIPAA sites.

Questions & Answers on Security Standards for HIPAA Regulations

"Linda, I read one of your articles dating back to June of 2002 titled Security for Secure Sites. I am doing some research for a client of mine and was trying to figure out something that perhaps you could answer.

I've done a lot of internal and file transfer work that falls under HIPAA regulation, but I haven't really gone into the arena of displaying health information over web-sites.

I understand the issues that fall on the backend of a web-app, such as the database server, network structure, etc., but I haven't found information on any regulations that require a site itself to be secured.

In other words, can a password protected site that has 128-bit encryption under SSL suffice? Is there a standard that governs how a query must be structured from a web-site and how the returned data must be presented?"

CEO from a Midwest Tech Firm
July 16, 2004

"You and your client must be sure the medical data is secure. Security investment requires creating a secure environment both for the people involved and for the software and hardware.

This means secure access control throughout the hosting environment, resident software applications, with regular audits, and rigorous follow up with software updates -- as well as excellent communication between IT, Data Security, and senior management.

Your best option is to hire a third party Security Audit firm and obtain their advice. 128bit is highly secure. However userIDs, passwords and 128 bit encryption will not suffice if the server environment is not truly secure or if the doctor is careless with accessing confidential records. Most people can be more easily spoofed into security leaks through social tricks than the likelihood of breaking 128bit encryption.

Hire an expert, ask for recommendations locally, and talk with a couple of reputable software security companies to make your decision. Help medical personal establish policies and procedures to live by. Eliminating fear by promoting appropriate business practices is sound risk management.

In Security vernacular this is termed "lockdown." -Linda