This website uses cookies to store information on your computer. Some of these cookies are used for visitor analysis, others are essential to making our site function properly and improve the user experience. By using this site, you consent to the placement of these cookies. Click Accept to consent and dismiss this message or Deny to leave this website. Read our Privacy Statement for more.
Print Page   |   Contact Us   |   Sign In   |   Join
AEA Search
Featured Members
BALA PRASAD PEDDIGARIHyderabad Chapter Volunteer of the month!

What EAs need to know about Risk Management and Open FAIR – A Conversation with Jim Hietala
Blog Home All Blogs
How would you define Risk Management in terms of how it affects Enterprise Architecture? There are two notions of risk that play in when you’re talking about Enterprise Architecture. One is—and the way that it’s described currently in TOGAF® 9.1—is that there are sections on risk that are really related to project risk—projects that start and don’t finish, things like that. That’s a pretty narrow subset of Risk Management. The larger context has to do with things like security risk and other risks that broadly fall into Enterprise Risk as a discipline.

 

Search all posts for:   

 

Top tags: cyber threats  EA  EA profession  enterprise architects  risk management  security 

What EAs need to know about Risk Management and Open FAIR – A Conversation with Jim Hietala

Posted By Administration, Monday, January 18, 2016

What EAs need to know about Risk Management and Open FAIR – A Conversation with Jim Hietala

By AEA Staff

How would you define Risk Management in terms of how it affects Enterprise Architecture?

There are two notions of risk that play in when you’re talking about Enterprise Architecture. One is—and the way that it’s described currently in TOGAF® 9.1—is that there are sections on risk that are really related to project risk—projects that start and don’t finish, things like that. That’s a pretty narrow subset of Risk Management. The larger context has to do with things like security risk and other risks that broadly fall into Enterprise Risk as a discipline.

In the architecture world, we’re working to make sure that future versions of TOGAF better represent the bigger picture and not just project risk, which is important but it’s just a small piece. 

For me, the big thing is that the tools that we use and things like TOGAF have to represent the idea that there are risks that need to be considered with new IT developments and the risks to IT infrastructures that are up and operating. We need to have the right set of tools to be able to measure what those risks are, which is where things like Open FAIR come in.

Why do Enterprise Architects (EAs) need to be aware of risk and risk management issues?

In terms of the ‘why’ it’s because as they’re doing things to re-architect the business or re-architect IT systems, bring new things to the business to improve operations, they don’t want to bring things that have fundamental security issues or risks that will maybe be taken advantage of by cyber attackers or whoever it is. Getting risk and security wrong as you’re doing architecture can result in being in the headlines for the wrong reasons. I think that’s the basic reason to do this is that you’re trying to increase the business’s agility or cost or revenue capture but at the same time you don’t want to introduce things that cause financial harm to the company. That means really understanding what risks are present in a new architecture that you’re building and then doing things to mitigate those risks.

Lots of people tend to think about risk in terms of security and cyber threats—are there other aspects of risk that EAs also need to be aware of?

There are a number of other risks to consider. These include financial, economic, geopolitical, operational, supply chain, environmental, safety, regulatory compliance and cyber security. EAs should consider these to the extent that they are involved and affected by Enterprise Architecture within an organization. 

What can EAs do to better inform themselves about risk and risk management in order to help their organizations?

I think one place where we see gaps sometimes is getting risk and security people involved in Enterprise Architecture projects earlier rather than later so that they’re not blindsided by someone from Information Security or a Risk Management group popping up and saying ‘No, you can’t do that’ or ‘Have you thought about this risk or that risk?’ So I think it’s mostly about making connections to the people who do security architecture or risk management work and making sure that they’re engaged in Enterprise Architecture development activities early on.

In TOGAF, it should be in the preliminary phases when you’re considering things like that. Ideally, security and risk should be considered as soon as possible in the system engineering development lifecycle and at each phase of the development lifecycle as appropriate. This can vary from high-level advice and guidance in the early phase up to a detailed security check in the final phase. In the operational phase, security aspects should be monitored, assessed and reported. Although the operational phase does not begin until the first iteration of the TOGAF ADM is complete, we are currently working on designing and incorporating risk and security capabilities during other phases of TOGAF to provide greater guidance for Enterprise Risk Management and Information Security Management scenarios within TOGAF.

(Note that a whitepaper from The Open Group on the topic of "Integrating Risk and Security within a TOGAF® Enterprise Architecture” will be published and available by February 1, 2016 here: http://www.opengroup.org/open-group-publications.)

Last year, The Open Group published a Risk Management Survey that showed a lot of Risk Management work within organizations was not necessarily being done by Risk Analysts per se. If there aren’t people in your organization doing risk analyses, as an EA what else can you do to better inform yourself if there aren’t analysts that you can bring into your projects?

In TOGAF, this should be done in the preliminary phase during the Business Impact Analysis, which looks at the parts of the business and the potential damages. The idea is that if you do a Business Impact Analysis for a given architecture you can look at what are the potential parts of the business that might be impacted. That’s a good place to start in understanding where you’re going to have risks pop up in a given project or architecture.  

What is Open FAIR?

Open FAIR is a framework and methodology for allowing organizations to communicate about risk and do a better job of measuring risk.

What can EAs get out of Open FAIR and how will it benefit their organizations?

It can be useful in evaluating how much risk is present in given risk scenarios. Let’s say you’re an organization looking at implementing a new web ordering system for your customers, where customers can order things through an e-commerce type website. There are things that you can do to architect that, but you also want to understand, depending on how you build it, how much risk will there be of people compromising credit card details? Open FAIR gives you the methodology to say ‘We’re concerned about attackers from Eastern Europe breaking in, capturing credit card numbers and selling them on the black market.’ Open FAIR gives you the tools to take a risk scenario like that and determine how much risk there is and also to understand the relative value in terms of risk reduction of various security controls you might plug into the architecture. You might say, ‘If we put in a web application firewall to alert us to people trying to hack in, that will cost this much and the risk reduction will be 20 percent on a $1 million risk that we think might happen once every three years?’ Open FAIR gives you the tools to quantify how much risk reduction you get out of alternative A or alternative B in terms of the solution architecture that you plan to use to plug those security holes.

Open FAIR also contains a certification component – what does that entail and how can people become certified if they are interested?

It entails gaining an understanding of the two standards that underpin Open FAIR. There’s O-RT, the Risk Taxonomy Standard, and O-RA, the Risk Analysis Standard. People who want to be certified have to understand those well enough to pass a multiple choice exam. They can take the exams at testing centers throughout the world and get the knowledge necessary to pass the exam either through self-study—there’s a pocket guide and study guide that can be bought from The Open Group website—or you can take a course from an accredited trainer.

In many organizations, risk is left to risk analysts – do you see a growing need for EAs to be better versed in risk management and risk issues moving forward?

Yes, when I do presentations on risk and security and Enterprise Architecture the point that I like to make is that if you look at all the big breaches and big brands that have had very public breaches, their failings tend to boil down three things. Either they got their security architecture wrong or they didn’t really understand the risks so they didn’t really understand what to go fix or they just a lousy job operationally at security. In some of these cases, their security systems were throwing off alerts left and right and they had so many alerts that they just didn’t catch it. But it tends to be one of those three things that they’re getting wrong. For the first two, security architecture and understanding the risks, Enterprise Architects have a role to play. They need to understand how you actually assess the risk in the architectures they’re creating. The operational piece not as much, but for the first two, they need to know.

 

Jim Hietala, Vice President, Business Development and Security, 
The Open Group

Jim Hietala, Open FAIR, CISSP, GSEC, is Vice President, Business Development and Security for The Open Group, where he manages the business team, as well as Security and Risk Management programs and standards activities,  He has participated in the development of several industry standards including O-ISM3, O-ESA, O-RT (Risk Taxonomy Standard), O-RA (Risk Analysis Standard), and O-ACEML. He also led the development of compliance and audit guidance for the Cloud Security Alliance v2 publication.

Jim is a frequent speaker at industry conferences. He has participated in the SANS Analyst/Expert program, having written several research white papers and participated in several webcasts for SANS. He has also published numerous articles on information security, risk management, and compliance topics in publications including CSO, The ISSA Journal, Bank Accounting & Finance, Risk Factor, SC Magazine, and others.

An IT security industry veteran, he has held leadership roles at several IT security vendors.

Jim holds a B.S. in Marketing from Southern Illinois University.



 

 

 

 

 

 

Tags:  cyber threats  EA  EA profession  enterprise architects  risk management  security 

Share |
PermalinkComments (0)
 
Sign In
Login with LinkedIn
OR


Latest News
AEA Events

1/23/2019
Colorado Chapter Introductory Meeting

1/28/2019 » 1/31/2019
The Open Group Scottsdale | Digital in Practice and the Supply Chain

2/5/2019 » 2/7/2019
Info-Tech LIVE | Orlando, FL

2/26/2019 » 3/1/2019
IRM UK Seminar/Workshop | Zachman Enterprise Architecture Certification: Modelling Workshop

 

Join our AEA LinkedIn Group!