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.

1. Write and follow a data protection plan.
2. Follow specific steps in the directive in order to protect specific data access.
3. Be able to audit this and prove that you protected the data according to your plan.

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?

Submitted by David Schlesinger CISSP

There is a story about a fellow who goes to a Doctor because of head pain. The General Practitioner sends him to see a specialist. The next day the fellow sees a specialist.  The specialist tells him that he has a problem in his nose.

“Can you help me?” the fellow asks, and she says, “No, I only specialize in ears and throat. You need to go to a nose specialist.

So the next day the fellow goes to a nose specialist.  The nose specialist looks at him and says, “You clearly have confabulation of the left nostril.”  The fellow asks what can be done to treat it and the Doctor replies, “I don’t know, I’m a right nostril specialist myself.”

Sometimes I feel the same way when I see a presentation by the Data Privacy specialist in a company, or the Sarbanes-Oxley specialist, or the PCI specialist. The list goes on. They all seem unaware of each other.

Now, don’t get me wrong, this knowledge and these people are valuable, what drives me buggy is each working in isolation as if their issue was the only one that needed governance.  All these regulations require attention in a balanced manner.

Consider the following possible example:

Let’s say I was in a traffic accident and the Emergency Room Paramedic can’t get access to my drug allergies because of overprotective privacy access restrictions.  If I’m unconscious, all I care about is that my allergies be available.  Privacy is a low priority for me at that time.

Worse, what if my records have been altered by some disgruntled person: in that case, what I care about includes data integrity!   So, who in your company is in charge of data integrity?  Most probably your data security people and your data quality people manage data integrity. Are they both part of the Data Privacy team?

Regulatory compliance likewise includes the good folks governing Insider Information (SEC Regs.), and other folks making sure data processes have appropriate Separation of Duties (GAAP), the group managing the confidentiality of NDA business information, and others overseeing the GLB laws, and don’t forget the guys in the basement doing backup so the data can be available even after the server dies and is replaced. Often, all these people operate separately. They report to different budget areas, and are rewarded for separate achievements.

Privacy is not an island. SOX and PCI are not nearby islands. The Data Quality effort you no doubt also have, possibly works isolated from information security.  Lack of  data governance integration is one root cause why millions of personal and sensitive records are lost or stolen each year. (http://datalossdb.org/statistics)

In an integrated system, all the specialists are part of one practice, and they rapidly review a case while consulting together.   Splintering data management into myriad isolated interest groups, (often competing for budget), is a cause of corporate inconsistency as well as regulatory confusion. Separating these solutions slows down business response. We often don’t see it because of an incorrect belief that information can somehow take care of itself.  Back when we could trust a carbon copy of a purchase order on a clipboard things were different.  Now, the failure of your web system to reflect an inventory update by only an hour can lose thousands of online sales.

When the Information Management and Protection Team contains all the various specialists, and they develop an integrated approach to control and protect information, we’ll see less data loss and better regulatory compliance, as well as greater data accuracy.  This increases corporate agility, because having trust in accurate, clearly defined, timely and secure information is a requirement for fast corporate decisions ( i.e. agility).