In 2006 I completed the Masters program in Information Security Management at the George Washington University. As part of that process, I completed a Masters thesis, in which I performed a high level review of "models, frameworks, and methodologies" under the umbrella of "assurance" (aka "information security, "infosec assurance," "computer security," etc). The goal of this initial literature review was to find a single model that could be used across an entire assurance program, incorporating what I posited as the core competency areas of Enterprise Risk Management, Operational Security Management, and Audit Management. The result of this first phase was a determination that no such model existed. Being stymied and frustrated by this lack of enterprise-level models for instituting assurance management, I embarked on creating my own. The resultant Total Enterprise Assurance Management (TEAM) model accomplished this goal, and then some (I'll come back to this in a bit). It's worth noting, incidentally, that the literature review is now about 2.5 years old, yet I firmly believe that the conclusions are just as valid today.
I bring this all up now because security philosophy has been bugging me over the past couple weeks. In returning to security consulting, I am again reminded that not everyone understands security beyond their niche, which can be very problematic when trying to work in a cross-organizational manner.
The main challenge seems to be related to the notion that security largely grew out of the IT function, as least as far as the mainstream is concerns. This suspect original really puts the industry as a whole at a significant disadvantage because there is a lot more to security than simply technology.
Where the industry has failed evolve effectively, I think, is in establishing a high-level presence within organizations that is not strictly technical in nature, but is instead business-oriented with a risk management philosophy. If you need proof that this type of focus is still not overly prevalent within the industry, you need only look at the protracted "discussions" between the concretist and Bayesian philosophies of statistics and how they relate to ROI/ROSI and risk assessment.
Don't confuse this criticism with thinking that these issues are trivial. On the contrary, the topics are quite advanced, driving to the heart of evolving Scientific and Mathematic schools of thought. Unfortunately, the partisan nature of these discussions has hindered the ability of the industry to resolve the open questions in a satisfactory manner. But I digress...
As an industry, we are philosophically and abstractly stagnated. Despite the continued evolution of tools, we lack adequate consensus and creation on key matters such as business-technology cooperation, collaboration, and integration. What we need is a different way to get the message into the minds of business leaders that security must be an integral, cooperative aspect of everything that they do. At the highest level, this means enterprise risk management (including having a risk management strategy that cuts across the entire organization); it means properly defining your organization (i.e. you cannot have accountability if nobody knows who is accountable to whom); it means performing business impact analysis (BIA) that properly considers all aspects, from business requirements straight through technical and technical security requirements; and so on.
As security professionals, we have to wear not only technical hates, but we also need to wear business consultant hats. It's in this latter part that we see the most failure, because it is still relatively rare to find techies who truly understand business, or business people who truly understand technology.
This problem is not new. The concept of "IT alignment" (or "realignment") has been around for decades. However, despite this being an old problem, one with many posited solutions, there seems to be a lack of traction with the upper echelons of management. Moreover, the regulatory landscape has seemingly created more trouble, whether it be SOX or HIPAA or GLBA or PCI DSS. Specifically, auditors - through organizations like the PCAOB, COSO, AICPA, ISACA, and the ITGI - have tried to drive agendas (in and of itself a problem) without understanding either the business OR the technology landscape of a given organization. All these competing stimuli seem to have resulted in the calcification of upper management, effectively locking out the "bridge builders" who are able to play liaison between business personnel and technologists.
For this reason, I created the TEAM model. After performing the literature review, I concluded that the industry was full of self-serving interests pushing a specific agenda within a specific competency area, without any general formalized model (meaning, high-level abstract approach) for pulling all key competencies together. I thus set forth to create such a model, focused on requirements, around which the ISO Plan-Do-Check-Act lifecycle could be deployed.
Without going into full details (you can read my thesis for that), I'd like to highlight a few key aspects of the model. As an aside, please note that I've made one tweak in the above diagram from the version in the thesis itself; namely, I'd previously distributed "Act" across all competencies, but have now put that within the Enterprise Risk Management competency, where I think it rightly belongs. Read the PDCA page at Wikipedia for more information, as I think it'll help one understand this decision.
A quick terminology/acronym primer:
* Model: An abstract, conceptual construct that represents processes, variables, and relationships without providing specific guidance on or practices for implementation.
* Framework: A fundamental construct that defines assumptions, concepts, values, and practices, and that includes guidance for implementing itself.
* Methodology: A targeted construct that defines specific practices, procedures and rules for implementation or execution of a specific task or function.
* Universal Requirements Matrix (URM): At the core of the model, the URM represents a single definitional construct that incorporates all levels of applicable requirements, from business to technology to compliance/regulatory, etc.
* Enterprise Risk Management (ERM): The first of three competency areas, it provides the overall organizational direction for assessing and managing risk, has ownership of the policy framework, and takes on both the "Plan" and "Act" phases of the PDCA lifecycle.
* Operational Security Management (OSM): Responsible for the "Do" phase of the PDCA lifecycle, this second competency area is the recipient of directional guidance from the ERM, working to align itself to requirements articulated in the URM. OSM is a joint owner in the policy framework, with particular responsibilities for process and procedure and joint responsibility for ensuring the sanity of standards and policies.
* Audit Management (AuM): The third, and final, competency area, AuM is responsible for the "Check" phase of the PDCA lifecycle, with a requirement for maintaining independence from the other two competencies. Independence is important so as to server as an objective observer when testing controls, evaluating performance against requirements, as well as providing input to the business (represented by ERM) on potential areas of non-conformance with external requirements (such as regulations). The AuM competency does not serve to direct, but to inform, the ERM.
The goal of this model is two-fold. First, it is intended to bring a requirements-centric approach to organizational management, insomuch as that the business must define what it does and clearly articulate its needs in execution around that objective. Second, the model is intended to free each competency to follow whatever frameworks and methodologies it deems appropriate, independent of each other competency, within the constraint of serving the needs of the business and meeting the requirements set forth in the URM.
This second goal comes as a direct result of my frustration in research models, frameworks, and methodologies during the literature review. As mentioned above, everything I found seemed to have been designed to meet an agenda from within one of the competency areas. COBIT is a good example in that it grew out of the audit industry and was really created to improve the efficiency and effectiveness of control auditing. However, it was, and still is in some cases, misrepresented as the end-all-be-all solution for "security" within an organization, even though its focus was not on security, but rather IT controls.
In the end, through implementation of the TEAM model, an organization can allow AuM to map their preferred framework to the rest of the business, independent of the other competencies. Similarly, ERM can choose a risk management approach that is appropriate to the business, and conducive to writing policies and promulgating requirements. Meanwhile, OSM can adopt whichever conventions best facility service delivery within the constrained set forth through the URM and the policy framework. The policy framework is represented in the diagram by the tiered triangle on the right side, reflecting its source in ERM, base in OSM, and gradations of detail from Policy to Standard and Guideline to Process and Procedure.
Some have said that this model for enterprise assurance management is obvious and logical. Good - I hope so! Such comments have been leveled as criticism, and yet nowhere have I found a formalization of this approach. My hope is that putting this information out there for review and consideration will be helpful to individuals and organizations grappling with how to best move their security programs forward. Industry stagnation is, in my opinion, directly attributable to a failure to consolidate theory, reach consensus, and regroup for a new push. To borrow from Guy Kawasaki, we need to jump to the next curve, which means that we need to stop fighting the old battles and start thinking about new paradigms.
