Click here to learn more about author David Schlesinger.
In any enterprise of size, there is a cyber security department. Were you to partner with this team to classify corporate data you would find them able and willing to assist you. They would arrive at the data classification meetings with policies in binders and have designated security classifications. They believe that applications are made more secure by applying security classifications. They’ve been taught this, and trained this way. They are partly correct.
Security classifications deal with whomever “needs-to-know” the information. Only those who need to know the information to do their job should be allowed to access it. This is a military scheme and works well in the military and for certain types of corporate data. In all aggregations of data, the field with the highest security classification determines the security classification of the entire aggregation. For users with partial views of the database, the authorized user entitlement view is ruled by the single highest security classification in the entitlement. When the worker “needs to know” the information to do the job, the manager gives them authorization. End of story.
Unfortunately, this simple scheme is concerned with protecting information, not protecting the enterprise in the new global environment of governance regulations. A worker may need to see HIPAA information to perform their defined job, but the law may say they are not “Allowed-to-know” this information. The same may be true with certain sensitive Private Personnel Information (PPI), and certain information is affected by Payment Compliance Industry (PCI) Data Security Standards, EU privacy laws, and certain US critical technology laws. Here is where the security classifications cease to be helpful. “Allowed to know” trumps “Need to know.”
Allowed to Know Requires a Separate Scale
Security classifications cannot inform developers, analysts, or approving managers that a few fields in a certain user entitlement views display HIPAA data, and a few fields show Personally Identifiable Information (PII), and one field shows PCI data that needs to be kept encrypted. That is not why security classifications were created, and that is not what they do.
Each of these types of data sensitivities demand a different, and often legally specified type of protection. Further, a single aggregation of data from the database, or user view can only have one security classification, but may (and usually does) contain several regulatory categories.
Security classifications are important to be sure, but data regulatory categories need their own existence. Data sensitivity categories need to be recognized as Metadata elements to be managed. They may then apply to the content in every user entitlement view, and this may affect whether or not the manager may legally approve access authorization to specific users.
Not Allowed to Do Your Job?
For perhaps the first time, a business may be faced with the situation where the business process demands that an employee “needs to know” certain data to complete their job, but is not “allowed to know” the data. In this case, writing an exception report and putting it in a book may not be sufficient to prevent punitive legal or regulatory action against the company. The solution must be that the actual business process needs adjustment: a new paradigm.
Interestingly enough, your friendly cyber security professionals down in the basement can help. There are many cases where sensitive information is required for specific identification purposes, and there are a large number of tricks and tools that the cyber security community can provide to obscure the actual information and keep it protected while providing the employee with a type of information needed to fulfill the business objectives. (Notice how your health provider now asks for birthdates rather than social security numbers.)
Security classifications and regulatory categories remain apples and oranges. Both are useful, but they are not the same and neither one does the job of the other. Together they make a tasty fruit salad.