CSO

Few practitioners of information security entered the field with a formal engineering background. Fewer still have made even an informal study of risk management and analysis. Were that not the case, I as a consultant would receive far fewer blank stares when I launch into subjects such as normalization of deviance and cumulative act effect. Instead, most information security practitioners spent the pupal stage of their careers in IT before gradually metamorphosizing into information security. Most are, at their core, technologists who are fascinated by how things can be broken and exploited.

The first instinct of a technologist is to solve a technical problem by applying more or newer technology. This reflex is naturally supported by the people who are selling that technology. No one ever got rich suggesting the technology should be fixed before more technology is heaped on top of it.

Technologists naturally feel most comfortable with technology, and least comfortable engaging leaders of business units who are not themselves technologists. This narrow perceptual view becomes far worse in a crisis. The tendency to fixate on a single activity has caused experienced flight crews to crash into Florida swamps while they troubleshot a burned out light bulb. The bias toward purely technological fixes has little to inhibit its trajectory toward a state of infinitely growing cost and complexity when the information security practitioner reports through a hierarchy made up exclusively of other technologists. The resulting information security programs that I have seen in the 40 on site risk assessments that I have conducted are often more complicated and labor intensive than trying to maintain an old steam locomotive.

Imagine this situation: While reviewing the physical security of a brick building's perimeter, a small door is discovered into the building from the back alley. The door is constructed of thin metal that can't be properly secured. The purpose of the opening was to allow the delivery of coal into the basement that powered a long-since-removed boiler system. Any normal sane person would recommend that the hole be sealed up with brick and mortar. But ask a typical information security practitioner how to close this security gap, and he'll want to install an intrusion detection system using a laser grid and microwave motion detectors along with multiple redundant alarm systems. Bricks aren't sexy, and they certainly don't justify the existence of expensive technologists. After all, anyone can specify bricks and mortar. The organization is left with the same security problem it had before, only now it’s surrounded by lots of fancy bells and whistles - requiring continual maintenance and operation by highly skilled technologists. And the information security practitioner’s technological fiefdom has now been expanded.

One continually sees this scenario in the real world of INFOSEC where superfluous services are exposed on the network. As a consultant conducting risk assessments, I have on several occasions asked why telnet to all of an organization’s routers was exposed to the entire Internet. No one knew why. When I pointed out that the exposure therefore represented a cost with no benefits, and suggested telnet simply be disabled (correcting the vulnerability by removing it), all sorts of interdepartmental defense shields went up. Everyone was fearful of turning the service off for fear it might break something, and no one wanted to admit that they hadn't done the fundamental work of identifying and justifying any of the exposed services on the network. Service inventories just aren't sexy, no one gets rewarded for compiling them. In the worst environments, the technical staff were addicted to the ego boost, status enhancement, and adrenalin of fighting fires in an ad hoc environment that was experiencing daily security failures. All that hubbub certainly justified their existence.

When is the last time you saw a resume of an information security practitioner that listed accomplishments along these lines? “Conducted an exhaustive inventory of all assets and services. Assigned sensitivity classifications to all categories of information. Certified all network services and removed all network-exposed services that were determined to be superfluous.”

The concept of Classification goes all the way back to Aristotle – 2,300 years! – and yet one rarely sees this basic business process listed in the accomplishments of information security practitioners. Why? It just isn’t sexy. In an environment of the technologists, for the technologists, and by the technologists – no one gets raises and bonuses for exerting that effort. And it therefore seems a waste of time to anyone whose sole experience is that of a technologist. It’s thought to be “bean counter” work. But how can anyone protect what they don’t know they have, how can they detect anomalous activity on a network when they don’t know what’s normal, and how can they provide appropriate authentication and authorization to information that has no sensitivity classifications? I assert that the failure of information security practitioners to consider basic business needs and processes, and its aversion to conventional business processes such as asset inventories, is in large part the cause for the emergence of the field of IT Audit (of which I am a practicing member).

I believe all this is just an aspect of a bigger problem. I have seen a direct correlation between the degree of INFOSEC dysfunction and the degree to which the practice of information security is buried within the IT reporting structure. Every organization I have seen that has information security reporting directly to IT has had its information security practice hobbled to such an extent that it is incapable of performing any activity beyond putting out fires and implementing technology (two activities that IT understands). This reporting structure forms a direct conflict of interest since IT's incentivized goals are to complete its own initiatives on schedule, and information security's role is (or should be) to act in a quasi-quality control and oversight function over those activities which may delay completion of the initiative. In short, information security is a hindrance to IT's furtherance of its own goals. So it behooves IT to keep the information security practitioners as disabled as possible. And the rationalization that is usually trotted out in response to objections from the INFOSEC practitioners – is the promise to fix the security problems in “phase 2” of the project. Alas, phase 2, like the old saying about tomorrow, never comes.

Business risk falls into three broad categories: operational, financial and regulatory. But more often than not, the information security practitioners report to none of the real stakeholders: the CFO, Legal, or the COO. Instead, they either report through IT - who reports to the CIO - or they report directly to the CIO. The actual stakeholders who are responsible for controlling the real business risk within the realms of their authority -- have no direct view into or control over the activities of the information security practitioners. There’s no direct feedback loop or accountability. Few corporations have implemented the role of CISO, and of those that have, the CISO is often under the CIO, thus negating much of the benefit of implementing that position.

I personally see the root cause of the current INFOSEC dysfunctions to be shared between two groups: certainly the practitioners themselves, who have taken little interest in the fundamentals of business operations - including learning how to incorporate basic and sometimes-ancient business processes harkening back to the dawn of the industrial era (like maintaining inventories) rather than investing inordinate energies into building self-perpetuating technological empires. Some of the INFOSEC technologists I have met are practically allergic to anyone who isn’t a fellow technologist. But the responsibility also falls to the executive staff and board members who fail to understand that part of the price of the incredible achievements that have been realized in operational productivity - where the stenographers, typing pools, and file clerks of the not-too-distant past have all been replaced by modern technology - is an investment in information security so we might come close to recapturing the levels of information security that were inherent in that pre-computing era. And unless those executives long for a return to stenographers taking dictation with shorthand, those executives need to spend a few hours understanding the fundamentals of information security, so that they and the INFOSEC practitioners might share at least a few words of a common lexicon.

While many of my colleagues approach information security challenges from a purely technological perspective, my experience as a consultant and IT auditor have taught me to also engage the elements that technology depends on: organization, people and process. Working as an information security consultant for the last four years, I have seen more than 40 different approaches to the same set of information security challenges. And as an incident investigator, I have also seen some spectacular security failures. Drawing from all that experience, I have come to fully appreciate how most information security failures find their root causes in organizational and process breakdowns -- not in the failure of the technology or its administrators. I have learned how to effectively implement the basic business processes that prevent the majority of information security failures - problems that are seldom solved with more money and technology. While the first reaction of many in my field is to correct a technological weakness with even more technology, the conservative engineering approach is to first verify that the current technology is being properly implemented, and to review the basic business practices before burdening an information system with additional complexity and administrative overhead. One of the most basic rules of engineering dictates that technological weaknesses cannot be solved simply by adding more technology.

As an investigator, I recently accepted two confidential assignments. I was brought in to function in a position that neither company could keep filled – and report on what was causing the turnover. Both companies had hired competent people who were passionate about information security, and those people consistently quit after very short stints in their roles. Both of those positions had the same problem: the Information Security staff reported to IT. Assuming these practitioners didn’t have the diplomatic skills of Henry Kissinger, they found themselves hamstrung by the overt hostility they encountered when they told their boss (the IT Director) that his baby was ugly. These competent practitioners were positioned in a severe state of role conflict by having to inform their manager that the initiatives previously thought to be fully completed now had to be reworked.

As I shall explain below, Information Security and IT are natural adversaries at the most fundamental behavioral level: what motivates them to come to work each day, and it makes no more sense for Information Security to report to IT than does the opposite arrangement. In both cases, I explained to my client that all enterprise risks fall into three broad categories: Operational, Financial, and Regulatory, and that none of those risks fall directly within the accountability of IT. There consequently was no direct feedback loop and information security was kept insolated from the real risk factors. Depending on which category of risk seemed greater to the organization; either Legal, the CFO, or the VP of Operations were the natural positions to which the information security staff should report – in the absence of any formal Risk Management structure. Naturally, IT responded like a scalded cat to my suggestions, since they were accustomed to disabling and redirecting the information security practitioners’ activities in order to prevent them from being an inhibitor to IT’s initiatives.

Albert Einstein is often quoted as saying: “We cannot solve our problems with the same thinking we used when we created them.” People who design systems are rarely good at troubleshooting them. And people who construct systems are rarely adept at finding the vulnerabilities that can tear them down. Those different sets of skills each require a different mindset, temperament, and perspective. The best and most talented people in IT are the people who get a real charge out of building things. It’s in their blood, they’re passionate about it. They want to go home at night thinking: “I built something great today!” Artisans like that naturally have very little patience with people who they perceive to sit on the sidelines pointing out the flaws in their work. Take that passion and pride, reverse it’s direction by 180 degrees, and you get the internal thoughts of an information security practitioner at the end of a productive day doing vulnerability assessments: “I found new ways to demolish and disrupt something critical!” Is it any wonder that forcing information security to report to IT would result in a less-than-optimal outcome? The mental activities that these two groups find to be rewarding at the deepest levels of their personalities is in diametric opposition. And every time information security approaches IT with what is perceived to be a gift in its hands, IT responds with indignance. This is obviously not an effective way to motivate people. Rather than trying to force oil and water to mix, it is far more productive, and far more likely to foster peaceful coexistence, to have information security report to someone else – practically anyone else.

Schneier seems to classify scenarios and attack trees as stories and fairy tales and proactive security practises as fight or flight reactions. Securing systems based on boolean logic is like preventing a leak from a water balloon with unknown number of holes. Schneier better have his towel ready. I know I have.

Ya know, Shniver is alright in my book. Bardin is the problem we need to look after. http://www.cnnbcvideo.com/index.html?nid=J7kBOOE5SO6qBL3atFS4tjMxNDUzMjc-&referred_by=10993288-h_IWoNx

I had to chuckle when I read the CSO blog posting by Jeff Bardin, Schneier on the Shnive. Jeff is one of those top CISO/ex-CISO types .... http://www.riskbloggers.com/jimreavis/2008/10/schneier/

Bruce occasionally goes off the deep-end - as you've noted. Every once-in-awhile I find myself agreeing with him - which is always a frightening experience. This isn't one of those times.

How, I wonder, does he propose that threats be addressed/evaluated? Guess I'll have to read the article.