Tuesday, November 23, 2010

A (quick) theorem on the symbiosis of Risk Management, Security, Operations, and Audit in a mature Security Program -or - How I Learned to Stop Worrying and Love the Venn

Recently I had a conversation with a colleague about the relative symbiosis among organizational divisions and how it always plays a huge role in the effectiveness of a given process. We agreed that this is particularly true when that process involves securing information that is critical to the business. Because of the importance of segmenting responsibilities between groups, the protection of information brings about many unique challenges that can call into question divisional roles. For example: Who within the organization defines what information is critical? Who within the organization is responsible for the actual implementation of security controls? Who confirms compliance to agreed-upon standards? Who is in charge of accepting risk for the organization? And perhaps most importantly, how should these groups or individuals align and interact with one another?

After we spoke, I embarked upon a personal mission to better define the problem (and maybe even develop a theorem) through a single diagram.


As part of our conversation, we agreed that any organization with a well-defined information security program should include (at a minimum) the following distinct groups: Risk Management, Information Security, Operations, and Audit. In organizations with mature security programs, there is a well-defined balance of collaboration and autonomy between these groups.


As depicted above, what I came up with was a simple Venn diagram where a circle would represent each group and the area of overlap would represent the collaborative output between groups. I found that doing so provides a visual means to simplify the complex relationships these groups can sometimes share. Remember, although each group listed above is its own autonomous business unit, the “magic” of a mature security model comes from the areas of overlap; the places where collaboration occurs. However, just as it’s important to understand the basic divisions within the organization as they relate to information security, it’s equally important to understand the goals of divisional collaboration.


By focusing on each area of overlap in the Venn, we begin to see some of the cross-divisional responsibilities emerge.




Starting at the top left and going clockwise from there:


It is the shared responsibility of the Risk Management and Security groups to define the security program. This will occur in part by RM working with organizational stakeholders to determine an acceptable level of risk to the organization and Security collaborating to establish policies and procedures that adhere to those standards.


Moving to the right, Security should interact closely with Operations to assess the current state of the organization’s security model to ensure that Operations understands the costs, risks and benefits associated with implementing security controls.


When the Operations and Audit groups collaborate, it should be primarily to monitor the controls that are in place to ensure that critical policies and procedures have been implemented successfully.


And, finally, Audit and Risk Management team up to focus on security compliance; whether with industry standards, governance issues or internal policy.


So far so good, but what about the next level? Can we go even deeper into the Venn to find the amalgam of each blended responsibility? I believe we can.


Again, starting at the top and working our way clockwise, we see the area created by the overlap of Define and Assess has been labeled Plan. Not only does it makes sense that the culmination of definition and assessment is planning, it is also a logical conclusion that when Risk Management, Security, and Operations collaborate, the objective is the establishment of a security program plan.
Next, we have the area between Assessment and Monitoring: Implementation. Within the context of a well-managed security program, placement, monitoring, and upkeep of the controls and countermeasures fall across the Security, Operation, and Audit teams. Although Audit is not directly responsible for implementation activities, any mature security program includes change control and change management processes that will entail the auditing of any and all implementations throughout the enterprise.
Thirdly, to monitor and then, based on the finding of that monitoring, show successful and formal compliance is to Certify, hence the overlap of RM, Audit, and Operations.
And finally, the marriage of Comply and Define: Measure. If you claim you’ve defined it and you claim you comply with it, then you better be able to measure the distance between the two.
After creating the diagram I began to see something pretty amazing. When I striped away the second level overlaps and just focused on the third layer, the responsibilities aligned perfectly with their respective divisions. More specifically, in a mature information security program each division has a primary focus and that focus is called out by layer three: Security plans, Operations implements, Audit certifies and Risk Management measures.
Secondly, the end diagram had an almost suspicious resemblance to the old tried and true PDCA (Deming) cycle diagram used for process improvement and project management by businesses everywhere. Although my diagram is not chronological like the Deming cycle, all the phases are closely represented: Plan (Plan), Do, (Implement), Check (Certify) & Act (Measure). Not exact, but close enough to serendipitously reinforce the importance of balancing intra-departmental collaboration and autonomy.
Bottom line: no one group or individual can manage a well-defined security program alone. Defining the security roles and responsibilities within an organization is a critical first step towards a mature security model and understanding how they work together is equally critical … not to mention that a good diagram can do wonders for organizing your thoughts.
By Chaz Braman, VP of Consulting 

No comments: