According to the New York Times, 8/10 doctors still use paper record keeping. As I stated in an earlier blog, the stimulus package will spend a “ga-jillion” dollars on converting paper records to electronic medical records. Techworld.com cited in an article in 2007 that “a key tenet of HIPAA’s data privacy and security requirements is a need for data access accountability, i.e. the ability to understand ‘who is doing what to which data and by what means?’ “
In my previous post I talked about how one could secure personally identifiable information by placing the data behind the Netscaler Application Firewall to block or “X” out Social Security Numbers and Phone Numbers. In this post I will discuss a new feature in the Netscaler 9 product called AAA Traffic Management. This new feature will allow you to impose Authentication, Accountability and Authorization on downstream data that may be on servers that do not live within your AD Domain infrastructure. Regardless of what platform the content lives on and which identity management system they are using, you can force users to authenticate and have their access logged meeting several regulatory rules and ensuring the ability to see “who’s doing what to which data”.
The incumbent identity management solution for Company A, a publicly held company on the NYSE, is Active Directory. They recently acquired another company who was not public and not subject to the regulatory framework that Company A is and lacks any security measures on key data that now must be secured. To make matters worse, much of their data resides on an OS390 that has a 3rd party web server.
- You can quickly make this data available by creating a service on the Netscaler that maps to the OS390 web server.
- When you create the VIP to present the data, enable authentication and bind a AAA Traffic Management VIP.
- Create an LDAP Authentication policy that leverages your existing AD Domain Controllers.
Now when users connect to the VIP on the Netscaler they are redirected to the Authentication VIP and forced to log in with the domain credentials. This will help limit the number of logins that they have as well as the amount of RACF administration that needs to be done. Also, the Netscaler will syslog all access to this data.
You ARE a local doctor who is moving to electronic data by scanning files into a database and making them available via a PDF archive. You are bound by HIPAA to account for every single person who looks at that data. You place the PDF’s on a web server, index them and allow end users to access them but cannot report on who accessed what PDF archives.
- Again, we deliver the web server via a VIP on the Netscaler and enable authentication
- Ensure that everyone who accesses the data has to provide one or two-factor authentication
Now every binary file, including the PDF’s, that are accessed is logged into the syslog database or event correlation engine.
You a web server in the DMZ that has a few corporate presentations that you want your staff to be able to access but you do not want to be available to the general public. Since the system is in the DMZ you cannot provide AD Authentication but you want to account for everyone who accesses the presentations and you do not want to use an impersonation account or replicate your existing AD Database with ADAM or DirXML.
- Yet again, place the presentations behind a Netscaler and create a VIP to present web server housing the presentations.
- Create an authentication policy using Secure LDAP over TCP 636.
- Set up an ACL allowing the NSIP to traverse the firewall to a domain controller (or in my case, a VIP consuming several domain controllers)
- Bind the authentication policy to an Authentication VIP.
- Configure the VIP for the presentations to use the FQDN of the Authentication VIP.
You are a CRM vendor like envala or Sales Logix and you have a customer who wants to access their Customer database hosted using SaaS (Cloud Computing). They would like users to log in against their LDAP server to access the CRM data so that identity management can be handled on their end. That way if a salesman leaves they can disable their account with out the fear of them logging into their CRM database and stealing leads or the delay in removing that account while the create a support ticket. Also, since they are consuming this as a SaaS solution, they want you to provide logs of who accessed the system.
- Have them make their AD Domain Controller available securely via LDAPs on TCP 636 or they could also use a netscaler to provide a VIP that brokers to the same domain controller. They can also set up an ACL allowing your NSIP to traverse their firewall for authentication.
- Create an authentication policy using Secure LDAP over TCP 636 and point the Server to the customer’s LDAP server.
- Set up an Authentication VIP assigning the policy you created for the customer to ensure that it consumes the appropriate LDAP server.
- Create a VIP on the Netscaler that front-ends their CRM website.
- Configure the VIP for the presentations to use the FQDN of the customer’s Authentication VIP.
Figure A: (Shows external users being redirected to an an external Authentication source via Policy)
As I stated previously, my experience with HIPAA is limited and much of the accountability has been accommodated by back end database programming, including down to the actual record. However; as the security screws become tighter and tighter, on a collision course is continued access of data with “IUSR_” or “apache” accounts and the mandate(s) for accountability and the demand to be able to report on who accessed what. I believe that the AAA Traffic management feature provides a great tool enabling you to impose your identity management solution to any web based content regardless of platform. Additionally, you get the ability to perform endpoint analysis on incoming clients who can be interrogated for specific registry entries, services and files that can be hidden in a system to ensure that only certain computer systems can access certain files. Having been part of a paper-to-electronic transition that did not go so well several years ago, I can attest that having tools that can bridge the regulatory gap between legacy systems and today’s heavily gaurded environments will make life a lot easier.
See this technology in action at
According to the Baltimore Sun, President Obama has promised to spend $50 billion dollars over the next five years coax hospitals, medical centers and the like to begin the process of offering electronic data. So nurses, occupational therapist and other allied health personnel as well as Doctors may be carrying something like a Kindle around instead of a clip board. With this comes an exstension of their existing regulatory framework such as HIPPA, CISP (as no one gets away from a visit to the Doctor without putting the plastic down these days) and future restrictions that will be put in place as a result of pressure from Libertarians and ACLU members.
Ensuring that none of my personally identifiable information is left on someone’s screen while they walk away from their PC is a very big concern. As these systems are brought online, ensuring that the data is protected, not so much from hackers, but also from basic behavioral mistakes that could result in someone leaning over a counter and getting my date of birth, social security number and credit card number.
While my security experience is very limited with HIPPA I can say that keeping this information hidden from the wrong eyes is a basic function of any security endeavor. How vendors, System Integrators and IT personnel can best bridge this gap could have a direct correlation on how successful they are in this space. How much of that $50 billion over five years will go to IBM? EDS/HP? Perot Systems? What have you done to show these Systems Integrators as well as smaller partners how your product will help them meet this challenge and how will you deal with a security screw that seems to only get tightened? Fact is, there are millions and millions of medical documents, and finding out which parts of which documents contain sensitive data is virtually impossible. One solution is to pattern-match the data and block it so that it is not visible to the wrong people. You could do this with a DBA who ran ad hoc queries to match the data and replace it with an “X” but then someone in billing may need that data (keep two copies?) not to mention the staggering cost (Y2K Part 2?). The best way I can think of is to place the data behind a device that can capture the patters in the header and “X” the data out in real time. Enter the Netscaler Platinum that will not only add compression, authentication, caching and business continuity, but will keep the wrong people from seeing the wrong data. I am not sure when the money will start flowing but as I understand it, some hospitals having as much as $1.5 million dangled in front of them to meet this challenge.
In this lab, I present how I used the Netscaler Platinum Application Firewall feature to secure personally identifiable data with a rule called “Safe Object” as well as how to deal with a zero day worm/virus using the “Deny URL” Rule. This “Safe Object” feature, when coupled with the Netscaler policy engine, will allow you the flexibility to ensure that certain job types (Nurses, Doctors, etc) based on either login (setting authentication on the VIP) or subnet; do not see things like Social Security Numbers, Credit Cards and other sensitive data. While at the same time, ensuring that information is available to billing and accounts receivable personnel.
For this lab, I used a basic Dell 1950 G6 with a virtualized Netscaler VPX that functioned as a VPN allowing me to establish a secure tunnel to the sensitive data on a non-wired network that resided on that server. An Apache server on the non-wired network with bogus phone numbers and social security numbers was used as the back end web server. Again, in a real world scenario, you could either hypervise your web server and place it on a non-wired network as covered in my “VPX Beyond the lab” blog or you could ACL off your web server so that only the MIP/SNIP of the Netscaler was allowed to access your web content.
See the lab here: