"Need to Know": The Intersection of Trust and Relevance
Today, organizations are pushed and pulled with respect to enforcing "need to know." They are pushed to implement effective information sharing and collaboration, but simultaneously are pulled back by security and privacy constraints that require "compartmentalization" rather than collaboration. One of Colts Neck Solutions' principal practices is to design means to enable customers to succeed in both collaboration and compartmentalization.
For example, if a physician's ability to care for a patient is impeded because his or her access to needed information is blocked, the process of linking the physician to data resources has failed. However, if that same system permits the physician to obtain data on patients outside his or her proper "need to know" boundary - for example, information for marketing purposes - the system has failed and, probably, HIPAA has been violated.
As illustrated in the Venn diagram, individuals access to data through an authorization process, generally governed by ID's, passwords, tokens, etc. Access might be via a system or to physical records - e.g. if an access card grants access to physical libraries of X-ray images.
An individual's "need" for information stems from assigned roles and tasks. His or her need may not be fully addressable, perhaps because information is not accessible, or because the individual does not have sufficient clearance/entitlement.
In practice, the most hurdle is that people are overwhelmed by information that is permitted and accessible, but not relevant to them for a given task. Therefore, success consists of providing an individual with access to the information he or she needs, tailored to business requirements, and with the security boundaries of "permitted" access being congruent with those needs. A bonus - which in effect compensates the individual for the burden of "need to know" enforcement - is that an effective process cut downs on the "permitted" but irrelevant information subset.
Note that enforcing "need to know" restrictions may be far more important than the task that is impeded by their enforcement. For example, a securities analyst may have a very great practical need to learn advance information about some company's earnings or the terms of an acquisition, but the sound working of the securities market dictates that he or she wait until the general release date of the information.
Often, in today's world the purported solution to implementing "need to know" is to collapse the needs of individuals into generic "roles" or to rely on very coarse file-level, database or directory access controls. Such simplifying measures reduce the burden involved in cross-checking and cross-linking people's needs against the nature and sensitivity of the data itself. However, both common sense and the laws and regulations pertaining to security and privacy suggest that "generic" and "coarse" often are not adequate. Also, "generous" access often is not in fact generous, because it leaves the user figure out how to cut through the irrelevant data. The objective is to achieve "fit for purpose" - to tailor access to the given situation.
There are lessons for everyone in terms of "business need" in the detailed analysis of the 9/11 Commission Report. For example, the 9/11 Commission's report described the CIA as typically playing "zone" defense - e.g., an agent's counter-intelligence assignment would cover a "territory" - while in contrast an FBI assignment might be "man-to-man" - an individual agent might be assigned a case irrespective of geography. In the more work-a-day world of sales, medical practices, logistics management any many others, this same "territorial" versus "case" alternative has to be addressed, and often an
organization will implement some blend. There is no one right answer, and in
fact some blend may be appropriate, so the prudent approach is to architect the
systems and access management processes to offer sufficient agility to support multiple scenarios.
However difficult it is to attain success in both sharing data and protecting data,
for many readers, failure is not an option. Those responsible for governmental
security, medical records privacy, employee privacy, the implementation of
financial information security and many other sensitive areas cannot opt out,
because of the high stakes and regulatory consequences of failure. Additionally, even access to routine business data such as pricing or contract terms also needs to be "surrounded" by an appropriately granular need to know process to protect business opportunities and to avoid overwhelming users with irrelevant information.
The way to success is to use the technologies that are creating these difficulties to get us out of difficulty. As discussed elsewhere on this site (TBD), "brute force computing," XML "tags", web services and the like can be blended to create dynamic data access capabilities and controls that are appropriately fine-grained and dynamic..