Data Classification (Tutorial)
I recently made a post about an (ISC)2 member, a CISSP at that having posted their resume with an "Orange Book" style human readable data classification label of “Confidential” on their resume, which they made publicly available. Clearly data classification and its use can be a mystery, even to such “experts”.
1. Classification Types:
There are two standard (read “common”) sets of data classification, although these are by no means comprehensive (I believe some government systems have ~64 hierarchal data classifications) they serve well as an example. The first of these systems is better suited to government and military work and from bottom to top it is:
2. Sensitive But Unclassified (SBU)
5. Top Secret
The private sector is better suited to:
2. Determining Appropriate Classification:
While these systems are simple, they lend themselves to one big question… “What makes something Private?” and unfortunately the best answer tends to be: “Something is Private if its protection is more critical than Sensitive and less critical than Confidential.” So, the whole system is contextual? Kinda sorta usually yeah… however… this doesn’t mean that rules can’t be made. A very simple (though perhaps not very good) example I’ve seen was implemented after a risk assessment and objects were classified by their exposure factor (EF). (What percentage of an asset would be lost with their disclosure.) Objects with a 0% EF were labeled “Public”, objects with Efs from 1-5% “Sensitive” 6-15% “Private”, and above 15% “Confidential”.
This method had the advantage of rapid risk calculations on the fly more or less. The disadvantage is that a shared object might have different valuations between multiple units and could be classified too high to be useful for some of the larger units (a loss of $1,000 to a $5,000 project and a loss of $1,000 to a $50,000,000 project for the disclosure of the same object). The only way to mitigate this is by taking each object’s total value to the organization, which can be far more difficult to calculate especially within a facilitated risk assessment system.
The best method of classification still seems to be either relying on vague terms of damage (“not serious” vs. “some” vs. “serious” vs. “exceptionally grave”) or defining the top and bottom (“Were ruined!” and “Old Press Release”) and filling in the middle contextually.
The object’s value (or more likely its impact if lost) is, but one consideration when classifying data. Another important consideration is the duration of the classification, which is based on a number of factors. If an object is old it may become public/declassified, in fact government classifications work on this principal… some data like the Marines failed attempt to overthrow the Bolsheviks was classified for 75 years, while the CIA’s involvement in the Chilean coup (over phone service) of the early 70’s was only classified for 25 years. The government felt one issue was far more damaging than the other. The same applies to corporate classification; data of wrong doings past the statute of limitations may be declassified down to a lower level. The reasoning behind this is that additional resources are required to secure data at higher levels, so naturally you want as little data as possible at each ascending level.
Useful life is another area where data may be declassified, clearly battle plans for tomorrow should be secure, but battle plans from 2 years ago? Not so much. Same for technology, once a technology has obsoleted itself, no reason to keep protecting it. Original versions of data that has been significantly modified since also falls under this category.
3. Classification Roles:
Subjects fall into three categories within a data classification system, they are:
The owner, despite popular belief is NOT necessarily the creator of the object. The owner is likely an executive (C-Something, VP, Director) or maybe even Manager. It is the owner’s role to establish the object’s initial classification, potentially including any declassification schedule. The owner also reviews data classifications on a schedule compliant with the policy to ensure that data is classified correctly according to the environment’s potentially unforeseen changes. Lastly the owner assigns the responsibilities for actually enforcing the classification’s requirements to data custodians.
The custodian may be a Security Administrator, Security Officer, System Administrator, or some other system’s role depending on the organization. The custodian’s role might involve maintaining the security implementation is cohesive with the security policy (and bridging any gaps if needed) regarding the data classifications. Backup and restoration of the classified data may also be required. The custodian will also address and ideally resolve any day-to-day problems the data users may encounter.
The user can be anyone including the object’s creator, owner, or even the general public, anyone that uses the data in question. Users must adhere to the policy regarding the handling of data at various classifications, though in a perfect world the custodian would be able to remove the possibility of otherwise from the user’s hands. Users must also practice “due care”, which should be detailed in the policy, typically this deals with things like not leaving the data just laying out for unauthorized users to view or “open view” as such an action is called.
4. Classification System Procedure:
There are several universally accepted steps in establishing a data classification system and a lot of other steps that may be required for specific environments and situations. The basics are:
1. OWNER defines the CUSTODIAN(S)
2. OWNER defines data classification scheme and criteria
3. OWNER defines controls for each classification level
4. OWNER defines exceptional controls
5. Data is classified by the OWNER in accordance with the #2
6. OWNER informs the organization of the scheme and controls
Other requirements such as the transfer of custody, review of any/all of the steps, and objects that exist outside of the classification scheme, but still require protection may exist as well.
5. Violating Classifications:
Sometimes the classification controls may/must be violated, consequently provisions for such actions must be available and defined in the policy. Instances of such violations include:
- External contracts
- Executive/Owner Approval
External contracts with either customers or vendors may require the sharing of classified data such as part specifications. This is straightforward enough and is usually accompanied by a Non-Disclosure Agreement (NDA) and or some other legal control to prevent the other party for disseminating the classified information.
The subpoena should be pretty obvious, if a court says you need to present specific documents, you need to present those specific documents, regardless of their classification. Of course you can fight this, but eventually, if you lose the classification is thrown out the window. (though the court may keep the information from the general public)
Finally we have executive or owner approval (depending on which has the ability) to violate the classification scheme. This may be done for a number of reasons, including but not limited to corporate strategy and tactics such as mergers and partnerships or because the damage from protecting the data may be greater than the cost of releasing it, such as instances of negative but incorrect press. The repair of the corporate image may be greater than the loss of some protected material.
Hopefully this will give at least a few of you a better idea about how data classifications are created and managed.