There are tellers of tales and debunkers of myths. An organization needs both.
An example: the March of Dimes needed people to have the vision of eradicating Polio. Its very transition from being called the National Foundation for Infantile Paralysis to becoming the popularly known March of Dimes needed the contributions of folks who could tell a story. They also, however, needed the folks who provided the honest assessments of the obstacles to be faced and how to overcome them.
When, in the late 50’s, the foundation had conquered Polio, they needed other tellers of tales to shift the focus of the organization to birth defect prevention. I use the March of Dimes example because it is important to understand that tellers of tales are no less important to an organization and are not less reputable than debunkers of myths. Sometimes the same person can play both roles in an organization (isn’t that Steve Jobs’s reputation?).
Tellers of tales have little or no role in Security. There is a place for hope and leaps of faith, for giving a set of suspicious facts the benefit of the doubt. Security is almost never that place.
For Security to be an effective principle of fair data practices, those who implement it must avoid telling tales. The security function in an organization debunks myths regularly or it risks colossal failure.
I am not overstating this. Granted that hindsight is 20-20, but consider these statements that try to demonstrate certainty. Every one of these statements refers to an actual organization’s attitude prior to a major breach.
- We don’t need additional security, it’s behind our firewalls and only authorized users can get to it
- Of course its secure, we’re compliant
- Yes, its secure, the wireless is encrypted
- We don’t need to test that for security, those devices don’t access the Internet
- We don’t need to encrypt that mobile device, it is against policy to put sensitive information on it
The myth these all have in common is certainty. In the language of mythology, it is hubris that causes the flaw in the hero, or in this case, the whole organization. With regard to security, it is that same attitude that creates defensible but wholly inadequate structures.
The security professional needs to adhere to a framework. Whether formally or informally, as a purist or using a hybrid approach, once the security professional begins to bring order to the organization’s security program, they are implementing a framework. The framework needs to assure that data is protected by defining principles against which controls can be measured.
One classic, data-centric, framework, defines a nine-box grid.
|
Physical |
Technical |
Administrative |
|
| Confidentiality | |||
| Integrity | |||
| Availability |
Arguably, all controls can be placed into one of the nine boxes. Non-disclosure agreements represent an Administrative safeguard protecting Confidentiality; disaster recovery facilities are the Technical infrastructure primarily assuring Availability; badge access to data centers is a physical safeguard for all three, etc.
The flaw in these approaches is that they reduce securing data to a checklist. They rely on auditable technologies and processes that are necessary but not sufficient. Providing both a history and a critique on why a static, auditable approach is insufficient, Richard Stiennon, the executive editor of this website, writes “Sometime in the late ‘90s, Risk Management started to infiltrate the thinking of corporate IT security functions, probably because audit departments and outside consultants such as PwC (where I worked in the past) had to convert a problem into language that CEOs and boards would understand.”
Another way to approach security controls is the recently published Cybersecurity Framework from NIST that takes a broader, functional approach to security. The document explains: “The Framework Core consists of five concurrent and continuous Functions—Identify, Protect, Detect, Respond, Recover. When considered together, these Functions provide a high-level, strategic view of the lifecycle of an organization’s management of cybersecurity risk.” For the framework to be fully dynamic, Stiennon would have us substitute the phrase “an organization’s management of cybersecurity risk” with “an organization’s response to threats.”
Whether you are looking at the shortcomings of risk management or the incompleteness of any list of controls, the point remains the same. Someone evaluating a framework for cybersecurity should insist that it be adaptive to be effective. A successful framework for cybersecurity will make appropriate defensive controls a baseline and agile response a priority.
As a principle of fair data practices, security implies something broader than the other principles. It requires that since people represent the greatest threat to data, only people can fully respond to those threats. And for those people to fashion those responses, they have to see the strengths and weaknesses in their environment and not lull anyone, including themselves, into a false sense of security.