Home > General Rants & Raves, Information Security, Unified Threat Management (UTM) > Unified Risk Management (URM) and the Secure Architecture Blueprint

Unified Risk Management (URM) and the Secure Architecture Blueprint

Gunnar once again hits home with an excellent post defining what he calls the Security Architecture Blueprint (SAB):

The purpose of the security architecture blueprint is to bring focus to the key areas of
concern for the enterprise, highlighting decision criteria and context for each domain.
Since security is a system property it can be difficult for Enterprise Security groups to
separate the disparate concerns that exist at different system layers and to understand
their role in the system as a whole. This blueprint provides a framework for
understanding disparate design and process considerations; to organize architecture and
actions toward improving enterprise security.

Securityarchitectureroadmap

I appreciated the graphical representation of the security architecture blueprint as it provides some striking parallels to the diagram that I created about a year ago to demonstrate a similar concept that I call the Unified Risk Management (URM) framework

(Ed.: URM focuses on business-driven information survivability architectures that describes as much risk tolerance as it does risk management.)

Here are both the textual and graphical representations of URM: 

Managing risk is fast becoming a lost art.  As the pace of technology’s evolution and adoption overtakes our ability to assess and manage its impact on the business, the overrun has created massive governance and operational gaps resulting in exposure and misalignment.  This has caused organizations to lose focus on the things that matter most: the survivability and ultimate growth of the business.

Overwhelmed with the escalation of increasingly complex threats, the alarming ubiquity of vulnerable systems and the constant onslaught of rapidly evolving exploits, security practitioners are ultimately forced to choose between the unending grind of tactical practices focused on deploying and managing security infrastructure versus the strategic art of managing and institutionalizing risk-driven architecture as a business process.

URM illustrates the gap between pure technology-focused information security infrastructure and business-driven, risk-focused information survivability architectures and show how this gap is bridged using sound risk management practices in conjunction with best of breed consolidated Unified Threat Management (UTM) solutions as the technology anchor tenant in a consolidated risk management model.

URM demonstrates how governance organizations, business stakeholders, network and security teams can harmonize their efforts to produce a true business protection and enablement strategy utilizing best of breed consolidated UTM solutions as a core component to effectively arrive at managing risk and delivering security as an on-demand service layer at the speed of business.  This is a process we call Unified Risk Management or URM.

Urmv12

(Updated on 5/8/07 with updates to URM Model)

The point of URM is to provide a holistic framework against which one may measure and effectively manage risk.  Each one of the blocks above has a set of sub-components that breaks out the specifics of each section.  Further, my thinking on URM became the foundation of my exploration of the Security Services Oriented Architecture (SSOA) model. 

You might also want to check out Skybox Security’s Security Risk Management (SRM) Blueprint, also.

Thanks again to Gunnar as I see some gaps that I have to think about based upon what I read in his SAB document.

/Hoff

  1. May 6th, 2007 at 04:22 | #1

    Dang it, I'm working my own response to Gunnar's paper and you beat me to it.
    I'm going to now have to include URM.
    A couple of quick notes:
    One of the things that I like about Gunnar's model is that business goals are at the top. While he mentions "risk tolerance" in the article, there must be something more "solid" (ideally an ongoing process) whereby those goals are translated into risk tolerance. Now if that is the case, then policy should be driven by risk tolerance (and risk analysis).
    In addition, I'm starting to become a big believer that the ISMS must be governed in order to be actually useful to the CSO. In other words, "Great, I've got my controls in place, I've even been certified, now what?" – there's still a question there that needs to be answered (and no, that's not just making certification a hamster wheel of pain).
    I think there are hints in the ISO that recognize that (the "management must buy in" crap and awareness), but it falls far short of what that "other thing" must truly be.

  2. May 6th, 2007 at 04:38 | #2

    I think you're right, Alex. I like the fact that Gunnar's model "flows" from the top down. Mine represents more of a constrained mash-up of the (some of the) bounding elements that make up the risk management model I'm describing.
    I think that the governance issue most certainly needs to be addressed and I personally used some metrics/dashboarding to provide the transparency into not only answering my "now what?" question(s) but invite others to ask me their own.
    I wonder if I can retool the model to include the "workflow" elements you describe?
    Great points, thanks.
    /Hoff

  3. May 6th, 2007 at 19:03 | #3

    Thanks for the post. This is exactly what I wanted to learn about but hadn't found a suitable starting point. You just gave it to me.

  4. May 8th, 2007 at 09:32 | #4

    I've updated the URM graphical model with some prudent additions.
    /Hoff

  5. October 4th, 2011 at 03:18 | #5

    granda a ernadente si esara aralmos con ilerra. cossuas iremos se ondonsiol son ebirio mi entos dentort y ogebam rendo fraco.

  1. No trackbacks yet.