Saturday, February 6, 2010

ISM3 brings greater standardization to security measurement across enterprise IT

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: The Open Group.

Security may be the hottest topic in IT. But it's also one of the least understood.

So BriefingDirect assembled a panel this week to examine the need for IT security to run more like a data-driven science, rather than a mysterious art form.

Rigorously applying data and metrics to security can dramatically improve IT results and reduce overall risk to the business. By employing and applying more metrics and standards to security, the protection of IT becomes better, and the known threats can become evaluated uniformly.

Standards like Information Security Management Maturity Model (ISM3) are helping to not only gain greater visibility, but also allowing IT leaders to scale security best practices repeatably and reliably.

With standards and greater reliance on data, security practitioners can understand better what they are up against, perhaps gaining close to real-time responses. They can know what's working -- or is not working -- both inside and outside of their organization.

The security metrics panel and sponsored podcast discussion are coming to you from The Open Group’s Enterprise Architecture Practitioners Conference in Seattle on Feb. 2, 2010. The goal is to determine the strategic imperatives for security metrics, and to discuss how to use them to change the outcomes in terms of IT’s value to the business.

Our panel consists of a security executive from The Open Group, as well as two experts on security who are presenting at the consortium's Security Practitioners Conference: Jim Hietala, Vice President for Security at The Open Group; Adam Shostack, co-author of The New School of Information Security, and Vicente Aceituno, director of the ISM3 Consortium. The discussion is moderated by Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:
Hietala: We think there's a contribution to make from The Open Group, in terms of developing the ISM3 standard and getting it out there more widely. [Being a data-driven security organization means] using information to make decisions, as opposed to what vendors are pitching at you, or your gut reaction. It's getting a little more scientific about gathering data on the kinds of attacks you're seeing and the kinds of threats that you face, and using that data to inform the decisions around the right set of controls to put in place to effectively secure the organization.

A presentation we had today from an analyst firm talked about people being all over the map [on security practices]. I wouldn’t say there's a lot of rigor and standardization around the kinds of data that’s being collected to inform decisions, but there is some of that work going on in very large organizations. There, you typically see a little more mature metrics program. In smaller organizations, not so much. It's a little all over the map.

... The important outputs of a good metrics program can be that it gives you a different way to talk to your senior management about the progress that you're making against the business objectives and security objectives.

That’s been an area of enormous disconnect. Security professionals have tended to talk about viruses, worms, relatively technical things, but haven't been able to show a trend to senior management that justifies the kind of spending they have been doing and the kind of spending they need to do in the future. Business language around some of that is needed in this area.

Shostack: We have an opportunity to be a heck of a lot more effective than we have been. We can say, "This control that we all thought was a really good idea -- well, everyone is doing it, and it's not having the impact that we would like." So, we can reassess how we're getting real, where we're putting our dollars.

The big change we've seen is that people have started to talk about the problems that they are having, as a result of laws passed in California and elsewhere that require them to say, "We made a mistake with data that we hold about you," and to tell their customers.

We've seen that a lot of the things we feared would happen haven't come to pass. We used to say that your company would go out of business and your customers would all flee. It's not happening that way. So, we're getting an opportunity today to share data in a way that’s never been possible before.

Aceituno: The top priority should be to make sure that the things you measure are things that are contributing positivity to the value that you're bringing to business as a information security management (ISM) practitioner. That’s the focus. Are you measuring things that are actually bringing value or are you measuring things that are fancy or look good?

Because metrics are all about controlling what you do and being able to manage the outputs that you produce and that contribute value to the business ... you can use metrics to manage internal factors.

I don’t think it brings a bigger return on investment (ROI) to collect metrics on external things that you can't control. It’s like hearing the news. What can you do about it? You're not the government or you're not directly involved. It's only the internal metrics that really make sense.

Basically, we link business goals, business objectives, and security objectives in a way that’s never been done before, because we are painfully detailed when we express the outcomes that you are supposed to get from your ISM system. That will make it far easier for practitioners to actually measure the things that matter.

Business value approach

Shostack: Vicente’s point about measuring the things you can control is critical. Oftentimes in security, we don’t like to admit that we've made mistakes and we conceal some of the issues that are happening. A metrics initiative gives you the opportunity to get out there and talk about what's going on, not in a finger pointing way, which has happened so often in the past, but in an objective and numerically centered way. That gives us opportunity to improve.

Hietala: There's some taxonomy work to be done. One of the real issues in security is that when I say "threat," do other people have the same understanding? Risk management is rife with different terms that mean different things to different people. So getting a common taxonomy is something that makes sense.

The kinds of metrics we're collecting can be all over the map, but generally they're the things that would guide the right kind of decision making within an IT security organization around the question, "Are we doing the right things?"

Today, Vicente used an example of looking at vulnerabilities that are found in web applications. A critical metric was how long those vulnerabilities are out there before they get fixed by different lines of business, by different parts of the business, looking at how the organization is responding to that. We're trying to drive that metric toward the vulnerabilities being open for less time and getting fixed quicker.

Shostack: We've seen over the last few years that those security programs that succeed are the ones that talk to the business needs and talk to the executive suite in language that the executives understand.

We've seen over the last few years that those security programs that succeed are the ones that talk to the business needs and talk to the executive suite in language that the executives understand.



The real success here and the real step with ISM3 is that it gives people a prescriptive way to get started on building those metrics.

You can pick it up and look at it and say, "Okay, I'm going to measure these things. I'm going to trend on them." And, I'm going to report on them."

As we get toward a place, where more people are talking about those things, we'll start to see an expectation that security is a little bit different. There is a risk environment that's very outside of people's control, but this gives people a way to get a handle on it.

Aceituno: The main task of the ISM3 Consortium so far was to manage the ISM3 standard. I'm very happy to say that The Open Group and ISM3 Consortium reached an agreement and, with this agreement, The Open Group will be managing ISM3 from here on in. We'll be devoting our time to other things, like teaching and consulting services in Spain, which is our main market. I can't think of anything better than for ISM3 to be managed from The Open Group.

Hietala: You have metrics and control approaches in various areas and you can pick a starting point. You can come at this top-down, if you're trying to implement a big program. Or, you come at it bottoms-up and pick a niche, where you know you are not doing well and want to establish some rigor around what you are doing. You can do a smaller implementation and get some benefit out of it. It's approachable either way.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: The Open Group.

Thursday, February 4, 2010

ArchiMate gives business leaders and IT architects a common language to describe how the enterprise works best

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: The Open Group.

Our next podcast discussion looks at ArchiMate, a way of conceptualizing, modeling, and controlling enterprise architecture (EA) and business architecture.

ArchiMate provides ways to develop visualizations and control of IT architecture to more swiftly obtain business benefits. To learn more, we interview an expert on this, Dr. Harmen van den Berg, partner and co-founder at BiZZdesign.

This podcast was recorded Feb. 2 at The Open Group’s Enterprise Architecture Practitioners Conference in Seattle the week of Feb. 1, 2010. The discussion is moderated by Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:
Gardner: I really enjoyed your presentation on ArchiMate. How did the standard come about?

Dr. Harmen van den Berg: ArchiMate was developed in the Netherlands by a number of companies and research institutes. They developed it, because there was a lack of a language for describing EA. After it was completed, they offered it to The Open Group as a standard.

Gardner: What problems does it solve?

Van den Berg: The problem that it solves is that you need a language to express yourself, just like normal communication. If you want to talk about the enterprise and the important assets in the enterprise, the language supports that conversation.

Gardner: We are talking about more and more angles on this conversation, now that we talk about cloud computing and hybrid computing. It seems as if the complexity of EA and the ability to bring in the business side, provide them with a sense of trust in the IT department, and allow the IT department to better understand the requirements of the business, all need a new language. Do you think it can live up to that?

Van den Berg: Yes, because if you look at other language, like UML, which is for system development and is a very detailed language, it only covers a very limited part of the complete enterprise. ArchiMate is focused on giving you a language for describing the complete enterprise, from all different angles, not on a detailed level, but on a more global level, which is understandable to the business as well.

Gardner: So more stakeholders can become involved with something like ArchiMate. I guess that's an important benefit here.

Van den Berg: Yes, because the language is not focused only on IT, but on the business as well and on all kinds of stakeholders in your organization.

Gardner: How would someone get started, if they were interested in using ArchiMate to solve some of these problems? What is the typical way in which this becomes actually pragmatic and useful?

Van den Berg: The easiest way is just to start describing your enterprise in terms of ArchiMate. The language forces you to describe it on a certain global level, which gives you direct insight in the coherence within your enterprise.

Gardner: So, this allows you to get a meta-view of processes and assets that are fundamentally in IT, but have implication for and reverberate around the business.

Don't have to start in IT

Van den Berg: You don't have to start in IT. You can just start at the business side. What are products? What are services? And, how are they supported by IT?" That's a very useful way to start, not from the IT side, but from the business side.

Gardner: Are there certain benefits or capabilities in ArchiMate that would, in fact, allow it to do a good job at defining and capturing what goes on across an extended enterprise, perhaps hybrid sourcing or multiple sourcing of business processes and services?

Van den Berg: It's often used, for example, when you have an outsourcing project to describe not only your internal affairs, but also your relation with other companies and other organizations.

Gardner: What are some next steps with ArchiMate within The Open Group as a standard? Tell us what it might be maturing into or what some of the future steps are.

Van den Berg: The future steps are to align it more with TOGAF, which is the process for EA, and also extending it to cover more elements that are useful to describe an EA.

It's often used, for example, when you have an outsourcing project to describe not only your internal affairs, but also your relation with other companies and other organizations.



Gardner: And for those folks who would like to learn more about ArchiMate and how to get this very interesting view of their processes, business activities, and IT architecture variables where would you go?

Van den Berg: The best place to go is The Open Group website. There is a section on ArchiMate and it gives you all the information.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: The Open Group.

You may also be interested in:

'Business architecture' helps business and IT leaders decide on and communicate changes at the new speed of business

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: The Open Group.

What's the difference between enterprise architecture (EA) and business architecture (BA)? We pose the question to Tim Westbrock, Managing Director of EAdirections, as part of a sponsored podcast discussion coming to you from The Open Group’s Enterprise Architecture Practitioners Conference in Seattle, the week of Feb. 1, 2010.

The discussion is moderated by me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:
Gardner: I really enjoyed your presentation today. Can you tell us a little bit about some of the high-level takeaways. Principally, how do you define BA?

Westbrock: Well, the premise of my discussion today is that, in order for EA to maintain and continue to evolve, we have to go outside the domain of IT. Hence, the conversation about BA. To me, BA is an intrinsic component of EA, but what most people really perform in most organizations that I see is IT architecture.

A real business-owned enterprise business architecture and enterprise information architecture are really the differentiating factors for me. I'm not one of these guys that is straight about definitions. You’ve got to get a sense from the words that you use.

To me enterprise business architecture is a set of artifacts and methods that helps business leaders make decisions about direction and communicate the changes that are required in order to achieve that vision.

Gardner: How do we get here? What's been the progression? And, why has there been such a gulf between what the IT people eat, sleep, and drink, and what the business people expect?

Westbrock: There are a lot of factors in that. Back in the late '80s and early '90s, we got really good at providing solutions really quickly in isolated spots. What happened in most organizations is that you had really good isolated solutions all over the place. Integrated? No. Was there a need to integrate? Eventually. And, that's when we began really piling up the complexity.

We went from an environment, where we had one main vendor or two main vendors, to every specific solution having multiple vendors contributing to the software and the hardware environment.

That complexity is something that the business doesn’t really understand, and we haven’t done a real good job of getting the business to understand the implications of that complexity. But, it's not something they should really be worried about. It's our excuse sometimes that it's too complex to change quickly.

Focus on capabilities

We really need to focus the conversation on capabilities. Part of my presentation talked about deriving capabilities as the next layer of abstraction down from business strategy, business outcomes, and business objectives. It's a more finite discussion of the real changes that have to happen in an organization, to the channel, to the marketing approach, to the skill mix, and to the compensation. They're real things that have to change for an organization to achieve its strategies.

In IT architecture, we talk about the changes in the systems. What are the changes in the data? What are the changes in the infrastructure? Those are capabilities that need to change as well. But, we don't need to talk about the details of that. We need to understand the capabilities that the business requires. So, we talk to folks a lot about understanding capabilities and deriving them from business direction.

Gardner: It seems to me that, over the past 20 or 30 years, the pace of IT technological change was very rapid -- business change, not so much. But now, it seems as if the technology change is not quite as fast, but the business change is. Is that a fair characterization?

Westbrock: It's unbelievably fast now. It amazes me when I come across an organization now that's surviving and they can't get a new product out the door in less than a year -- 18 months, 24 months. How in a world are they responding to what their customers are looking for, if it takes that long to get system changes products out the door?

BA is a means by which we can engage as IT professionals with the business leadership, the business decision-makers who are really deciding how the business is going to change.



We're looking at organizations trying monthly, every six weeks, every two months, quarterly to get significant product system changes out the door in production. You've got to be able to respond that quickly.

Gardner: So, in the past, the IT people had to really adapt and change to the technology that was so rapidly shifting around them, but now the IT people need to think about the rapidly shifting business environment around them.

Westbrock: "Think about," yes, but not "figure out." That's the whole point. BA is a means by which we can engage as IT professionals with the business leadership, the business decision-makers who are really deciding how the business is going to change.

Some of that change is a natural response to government regulations, competitive pressures, political pressures, and demographics, but some of it is strategic, conscious decisions, and there are implications and dependencies that come along with that.

Sometimes, the businesses are aware of them and sometimes they're not. Sometimes, we understand as IT professionals -- some not all -- about those dependencies and those implications. By having that meaningful dialogue on an ongoing basis, not just as a result of the big implementation, we can start to shorten that time to market.

Gardner: So, the folks who are practitioners of BA, rather than more narrowly EA, have to fill this role of Rosetta Stone in the organization. They have to translate cultural frames of mind and ideas about the priorities between that IT side and the business side.

Understanding your audience

Westbrock: This isn't a technical skill, but understanding your audience is a big part of doing this. We like to joke about executives being ADD and not really being into the details, but you know what, some are. We've got to figure out the right way to communicate with this set of leadership that's really steering the course for our enterprise.

That's why there's no, "This is the artifact to create." There's no, "This is the type of information that they require." There is no, "This is the specific set of requirements to discuss."

That's why we like to start broad. Can you build the picture of the enterprise on one page and have conversations maybe that zero in on a particular part of that? Then, you go down to other levels of detail. But, you don't know that until you start having the conversation.

Gardner: Okay, as we close out, you mentioned something called "strategic capability changes." Explain that for us?

. . . There's a missing linkage between that vision, that strategy, that direction, and the actual activities that are going on in an organization.



Westbrock: To me, so many organizations have great vision and strategy. It comes from their leadership. They understand it. They think about it. But, there's a missing linkage between that vision, that strategy, that direction, and the actual activities that are going on in an organization. Decisions are being made about who to hire, the kinds of projects we decide to invest in, and where we're going to build our next manufacturing facility. All those are real decisions and real activities that are going on on a daily basis.

This jump from high-level strategy down to tactical daily decision-making and activities is too broad of a gap. So, we talk about strategic capability changes as being the vehicle that folks can use to have that conversation and to bring that discussion down to another level.

When we talk about strategic capability changes, it's the answer to the question, "What capabilities do we need to change about our enterprise in order to achieve our strategy?" But, that's a little bit too high level still. So, we help people carve out the specific questions that you would ask about business capability changes, about information capability changes, system, and technology.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: The Open Group.

You may also be interested in:

The Open Group SOA Work Group making strides to deepen link between TOGAF and SOA

This guest post comes courtesy of Mats Gejnevall, a global enterprise architect from Capgemini.

By Mats Gejnevall

As an attendee at this week’s Open Group Seattle Conference 2010, I met with an international group of enterprise architecture (EA) thought-leaders including Dave Hornford, the new chair of The Open Group Architecture Forum, Tony Carrato from IBM, Steve Bennett from Oracle and Chris Greenslade from CLARS to enhance the TOGAF practical guide to do service oriented architectures.

In case you’re wondering, the practical guide is a best-practice tool for EA practitioners to speed-up and unify the way the industry creates service oriented architectures (SOA). One item we hope to make clear to the industry is that service orientation is not only about producing some web-services and hoping that will improve the agility and cost structures of the organization.

The evolution to service orientation should be a carefully orchestrated process that includes everything from assessing an enterprise’s ability to change, to identifying the areas that really need service orientation properties, to creating the strategic, segment and capability architectures for those areas and finally, to defining the transition roadmap to implement the SOA strategy.

Our discussions focused on creating a guide that is easy-to-understand and use, but that would also serve as a complete description of how the different phases of TOGAF should be adapted by an enterprise. The result is a user-friendly path through the TOGAF framework with continuous references to the TOGAF content meta-model.

One important issue to always keep in mind is that EA is not about doing low-level IT design . . .



Our work validates the claim that TOGAF is valid for all types of architecture styles, while also proving that there are many “ifs” and “buts” during an organization’s adoption path.

One important issue to always keep in mind is that enterprise architecture (EA) is not about doing low-level IT design, but about creating structures in your organization that fulfill your long-term business goals and ambitions. The low-level design activities will be performed during the actual implementation of the project.

Additionally, we discussed the practical guide’s relationship with other Open Group SOA projects (such as SOA Governance and SOA Reference Architecture) in great detail to ensure that the input from the meta-model objects to these projects were properly included and identified.

The resulting practical guide is due the first part of this year. More information on The Open Group SOA Work Group can be found here: http://www.opengroup.org/projects/soa

This guest post comes courtesy of Mats Gejnevall, a global enterprise architect from Capgemini.

The Open Group seeks to spur evolution of security management from an art to a science

This guest post comes courtesy of Jim Hietala, Vice President of Security for The Open Group.

By Jim Hietala

As we wrapped up day one of the Security Practitioners Conference Plenary here at The Open Group Seattle Conference this week, I must say we heard excellent presentations on security management and metrics from Adam Shostack at Microsoft, Vicente Aceituno from ISM3 Consortium, Mike Jerbic at Trusted Systems Consulting, Phil Schacter from The Burton Group, and Kip Boyle from Pemco Insurance.

Some of the key takeaways included:
  • There is a real need for better external, big-picture data about attacks and the available controls that are in place and the control effectiveness. Without objective data of this sort, it’s difficult to have an intelligent discussion as to whether things are getting better or worse, to develop an understanding of attacks and threat vectors, and what really constitutes best practice controls. Data from sources such as the Verizon Data Breach Investigations report and DataLossDB are highly valuable, but more data (and more detailed data) is needed.

  • There’s also a clear need to instrument our security programs, being careful to measure the right things. Security metrics are best when they directly support decision-making supporting business goals. Put another way, for an e-commerce company, a security metric that informs management as to how many viruses are scrubbed from desktops is not really relevant to the mission. A metric that measures the mean time to remediate web application vulnerabilities is directly relevant, as reducing this is very consequential to the overall business goal.

  • Adding a maturity level approach to information security management (as is done in ISM3, a new security management project in The Open Group Security Forum) makes this method a lot more approachable for more kinds of businesses. In other words, a higher maturity level that might be appropriate for a Fortune 100 company or a defense firm is unattainable for a typical small- to medium-sized business.

  • Continuous improvement in managing information security depends on effective, relevant metrics.
It's clear that security management is steadily moving from art to science. Effective metrics and a maturity model approach are critical to helping this transition to happen.

For more information about the work The Open Group Security Forum is doing to encourage the evolution of security management, please visit: http://www.opengroup.org/security/.

This guest post comes courtesy of Jim Hietala, Vice President of Security for The Open Group.