If You Are Not Looking At Data – What are You Protecting?by Fred F. Farkel, Friday, April 13th, 2012
Submitted by David Schlesinger, CISSP
Imagine a water purity inspector not knowing the source of the water being inspected. Certainly the analysis tools do not care, but knowing the source of contaminated water is important to assure the contamination is eliminated. But in the data world, the Access Security system only knows if the person has received an authorization in order to allow access. The Access Security system usually has no idea which criteria the authorizing manager used. While this at first appears to be out of Information Security’s jurisdiction, this lack of information makes it very difficult to eliminate an authorization when these criteria are no longer met. If the person still works for the company, and works in the same department, they usually keep the authorization forever and ever. This was often thought to be OK in days before the Internet.
If the laws and regulations regarding access to specific information were not becoming more restrictive we would not consider this a problem. However, we face a legislative response to businesses losing and exposing millions upon millions of private, sensitive, and financially confidential records year after year. Thus, the logical response from those in charge has been to demand that corporations comply with data protection regulations.
The list is large: Sarbanes-Oxley, HIPAA, GLB, SEC, California statutes, European Privacy Directive, PCI, FISMA, FTC, SB 1386, Patriot Act, and numerous other laws regarding data collection and retention. These legal regulations and, in the case of PCI, contractual, requirements, all have three basic parts.
Corporations now have to know which systems and which user-views (entitlements) contain regulated information, and also the work status of the person who is entitled to have and authorization. The data combined with the user now make up the access allowable formula.
The Access Security system has to be aware of the sensitivity of the information systems and the status of the individual workers. Surprisingly, this is all documented.
Information system developers know all the data content because they need to define the technical metadata for all the data fields. Your Data Analysts know the actual business definition of the data so that it can be linked to the correct fields in screens and in transformational routines. All this was documented during the project and then put somewhere where nobody could find it. Obviously, nobody ever asked for it.
What is missing for regulatory compliance and intelligent Access Control is review of the data definitions at that precise point during new application implementation to identify which information is sensitive to a regulation, what security classification to give it, and where it is placed in tables in the database and fields in the application. The people who know with this are all in the same room together many times during the development process. If information governance and information security were to work with them at that point, the definition of sensitive data and where it was located could be determined and captured where it could be referenced in a Data Dictionary and in the Active Directory
The next step is to look at the data protection plan (You have one, right?) and see the protection requirements for each data type. You will discover that most regulations have a lot of overlap, and only a few families of compliance actions will take care of 80% of your information.
For example, HIPAA data is a subset of the Personally Private Information family. So if the protection rule for PPI is to encrypt the tables in the database holding it, you have also fulfilled most of the HIPAA protection. When it comes to individual user authorizations however, you need to examine the sensitivity content of each view produced by the application (available from the previous step) and then apply the “Allowed-to-Know” criteria to the Access Control process. When a worker in HR changes jobs to one that is not “allowed-to-know” according to HIPAA, the Access Control system can know it and end authorization. (This requirement is now in combination with “Need-to-Know”)
Since this control is automated, the Access Control system can produce a log of actions as the documented audit trail of your compliance to the regulation. Policy, action, enforcement, and audit are the criteria for compliance.
Numerous solutions can be implemented. The important point is that the people who know the definition of the data, the folks who know the regulation, and the people knowing the location of the data at rest and in user display, need to work together to define the access governance requirements to be enforced by Information Security’s Access Control system. I know this sounds crazy when it is easier to just buy some outrageously expensive equipment, but why not give consultation among professionals a try?