Hello folks: my name is Sam.  My first anniversary at RSA just passed, and it seemed like as good a time as any to plunge into the security blog-o-sphere. I sit in a unique position within RSA: in the middle of the customers, the partners, the markets and the technology. In the course of the last year, I’ve met with hundreds of people with whom we do business, with whom we do science and with whom we look to change the way the world works. And, let me tell you this: things are becoming more complex...

FP: And what about drilling? Republican presidential candidate Sen. John McCain, his running mate Gov. Sarah Palin, and President George W. Bush are implying that lifting environmental restrictions on drilling is the way to promote energy independence.

TF: Well, I think it’s patent nonsense. No one believes that somehow offshore, there’s enough oil in any near term and even the long term to provide us oil independence. It’s the wrong approach because in a world that’s hot, flat, and crowded, fossil fuels—and particularly crude oil—are going to be expensive and exhausting. Therefore the focus should be on the next great global industry: clean energy technology. When I hear McCain pounding the table for “drill, drill, drill,” it reminds me of someone pounding the table for IBM Selectric typewriters on the eve of the IT revolution.

I’m not against offshore drilling, by the way, because I believe the technology and the safety has improved far beyond where it was back in the 70s, 80s, and 90s, even. What I’m against is making it the centerpiece of our energy policy. If all McCain said was, “Let’s drill, but let’s also throw everything into innovating the next generation of clean-energy technologies,” I’d say, “You’ve got it exactly right, pal.”

Recently, Thinking Problem Management wrote on the concept of Hansei-Kaizen.  That started me thinking about Information Risk Management, Information Security, the role of the security group and the analytical function. The following isn’t necessarily a revelation, but as I’ve a friend interviewing for a CISO-type job at a Fortune 20 this week and they are focused on a not dissimilar business management philosophy, I thought I’d write a little about the subject.

Hansei-Kaizen is the process of relentless reflection (Hansei) and continuous improvement (Kaizen).  It might be thought of as part of the Deming Plan, Do, Check, Act cycle.  In fact, Taiichi Ohno, father of Toyota’s production system (Lean Manufacturing) is quoted as saying:   “Check (in PDCA) is Hansei”.

image from the awesome Panta Rei weblog

Now those who have had exposure to Six Sigma and management theory are already probably very well acquainted with the concept of Kaizen.  I think anyone who has held a security management position would argue that continuous improvement is a very admirable goal.  And I don’t think we need to talk necessarily about what improvement is and why it needs to be continuous.

But what is usually not given a great deal of consideration in  our profession is this concept of “relentless reflection”, the “Hansei” bit. And a lack of Hansei can be a source of frustration to those we work with and report to.  In fact, there’s a great presentation by Dr. Hwang Chi Hong available via search engines that explains:

Hansei (reflection) alone only generates staff unhappiness.  Kaizen (continuous improvement) alone only wastes creativity.

Cool huh?

So what’s this got to do with Risk Analysis?

If we can agree that continuous improvement is an admirable goal for security management, security departments, and even security vendors, then in light of the quote above we have some questions to ask ourselves;

• what is this relentless reflection (Hansei),
• what should we be relentlessly reflecting about, and
• how much work is being put into, and how good are we at, Hansei?

I’d like to focus on that for the next few blog posts this week, because I think that adding structure around this concept may be a “pragmatic” (Hi Mike!) compliment to many of the CISO  “self-help” books I’ve been seeing.

“In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers."

I think it is great that Google has a security program they are willing to talk about and I could not agree more with the ‘security as a cultural value’ philosophy. But isn’t there something really fundamental missing here? Design? There is a lot more to software engineering other than coding and testing.
 
The SDL has a very large set of implementation-related requirements, but there are many design-related requirements also.

Computer security experts have known since the early 1970s that you have to get the design right; and our experiences with the SDL over the last 5 years have taught us that you need to consider security and privacy (but remember, you have to ship too!) very early in the design phase and have a consistent end-to-end process if you truly hope to reduce vulnerabilities and create more secure software. This is how the SDL is helping to create ‘security as a cultural value’ at Microsoft.

We’ve seen a general trend downward in security vulnerabilities in Microsoft products, and the IBM X-Force 2008 mid-year report backs the assertion that we’re making progress; according to the report Microsoft’s share of total vulnerabilities decreased from 3.7% in 2007 (1st place) to 2.5% (that’s 2.5% for all Microsoft products; a more appropriate comparison might be Windows vs Linux vs Mac OSX, or SQL Server vs Oracle vs DB2) in the first 6 months of 2008 (3rd place.) This is an encouraging signal that the SDL is working on a large scale… of course, it might also show that vulnerability researchers are moving to easier targets, which, to me shows the SDL is working too.
 
What do you think?

Like most of the service providers we talk to, they look to virtualization to provide immediate benefits to the business – e.g, cost savings from server consolidation and support for Green IT through cutting power/cooling requirements. And one more dimension to virtualization – Opus launched a new service, vClustr, which is a virtual dedicated server that provides the benefits of a fully managed dedicated server at a fraction of the cost…managed by EM7, of course.

We were happy to help Opus by working with them to implement our EM7 solution. Their growth plan was severely limited by inefficient processes and tools. As Opus grew rapidly in 2006, the tools they had in place were not easy to integrate as they were managed independently. There was a manual billing and ticketing infrastructure in place, and valuable engineer time was spent on maintaining what they had instead of enabling business growth. The company faced a choice, either grow by adding overhead and bodies or grow through automation.

Opus chose automation. They needed an automated solution to cover their immediate needs, and also enable them to scale processes for emerging technologies and future service offerings. Throughout their growth, Opus wanted to maintain their “customer first” philosophy and expand their green efforts.

By choosing EM7, Opus was able to replace their multiple, disparate tools with a single, integrated management system for networks, servers, applications, service desk assets and virtualization infrastructure. EM7 provided automated billing, ticketing, alerts and escalation options as well as a branded customer portal for transparency and self-service ticketing.

The results were tremendous. Opus Interactive recouped $130k per year of engineering resources. They automated critical operations to increase efficiency, enabled proactive monitoring and prepared for growth, while giving the business the processes and tools to grow the business without additional human capital resources.

We’re glad that we could help such a great company achieve their goals of providing an efficient “best-in-class” solution that combined superior customer service with a green philosophy.

Get the entire case study here.

ShareThis

What’s more interesting to me, now that I’ve digested the big secret, is how this whole situation has played out in the security community.

The security community has been polarized for the past two weeks, not so much over the technical details being withheld, but about Dan’s plea that people not speculate about the vulnerability. As many pointed out, the “bad guys” won’t stop trying to figure it out just because the “good guys” keep quiet. To be honest, my own lack of public speculation wasn’t because I agreed with the philosophy; I just wasn’t smart enough to figure out the vulnerability myself.

People implied — or stated outright — that Dan just didn’t want anyone stealing his thunder. Considering the timing of the release and the subsequent BlackHat talk, it’s obvious why such accusations were made. Personally, I think it’s a little of each. I believe the coordinated patch effort was undertaken with the best of intentions, but I also think Dan relished some of the glory and media attention as well. It’s hard to blame him for that; if you were in his shoes, wouldn’t you want some recognition too?

By many accounts, dealing with the DNS vulnerability from the operational side has been an exercise in frustration. Plenty of IT people wanted to patch but couldn’t get approval without being able to justify the operational risk. “Because Dan said so” is apparently not a convincing enough argument. Some wondered why the people who were responsible for creating the problem should be blindly trusted to implement an appropriate fix?

Ultimately, vulnerability disclosure is a minefield. No matter how you choose to disclose, somebody will always disagree.

P.S. If you didn’t figure out the title of the post by now, Nate was one of the unlucky few to draw the same timeslot at BlackHat as Dan Kaminsky.

What’s more interesting to me, now that I’ve digested the big secret, is how this whole situation has played out in the security community.

The security community has been polarized for the past two weeks, not so much over the technical details being withheld, but about Dan’s plea that people not speculate about the vulnerability. As many pointed out, the “bad guys” won’t stop trying to figure it out just because the “good guys” keep quiet. To be honest, my own lack of public speculation wasn’t because I agreed with the philosophy; I just wasn’t smart enough to figure out the vulnerability myself.

People implied — or stated outright — that Dan just didn’t want anyone stealing his thunder. Considering the timing of the release and the subsequent BlackHat talk, it’s obvious why such accusations were made. Personally, I think it’s a little of each. I believe the coordinated patch effort was undertaken with the best of intentions, but I also think Dan relished some of the glory and media attention as well. It’s hard to blame him for that; if you were in his shoes, wouldn’t you want some recognition too?

By many accounts, dealing with the DNS vulnerability from the operational side has been an exercise in frustration. Plenty of IT people wanted to patch but couldn’t get approval without being able to justify the operational risk. “Because Dan said so” is apparently not a convincing enough argument. Some wondered why the people who were responsible for creating the problem should be blindly trusted to implement an appropriate fix?

Ultimately, vulnerability disclosure is a minefield. No matter how you choose to disclose, somebody will always disagree.

P.S. If you didn’t figure out the title of the post by now, Nate was one of the unlucky few to draw the same timeslot at BlackHat as Dan Kaminsky.

“Linux is a movement, a philosophy, where programmers and technical people take control of their own destiny.”  — Tim Bass

Ref:  Email signature, Re: Future of 2.0.36, G.W. Wettstein (greg@wind.enjellic.com), Sat, 24 Oct 1998 10:09:27 -0500

ScienceLogic: What is “BSM Lite” and how is it different from “heavy” BSM?

Doug McClure: I think the concepts that Peter Sevcik from Net Forecast initially outlined in his blog post sum up what “BSM Lite” is all about: a simpler, less expensive, more responsive way of achieving the goals and objectives of Business Service Management (BSM).  He’s contrasted this nicely against what he termed “BSM Heavy” being the larger investments in time and resources to deploy domain specific tools and solutions each providing a view into the business service delivery with some aggregation and consolidation to tie up all of the disparate tool’s information into a concise end-to-end business service management story.

I’m pleased that he leveraged some of my thinking around a better working definition of what BSM really is from the BSM Defined page on my blog. Of course, these definitions are going to vary depending on whom you talk with and how they see the overall BSM Maturity Model.  I’ve created a BSM Maturity Model that aligns with the famous Gartner IT maturity model.  I’d like to think that a “BSM Lite” solution is one attacking the low hanging fruit, enabling one to achieve value quicker, and in a more tactical manner.  The “BSM Heavy” solutions are capable of the same, but span all along the BSM Maturity Model by adding additional point solutions, products and technologies from their broader portfolio. 

ScienceLogic: Does “BSM Lite” just refer to the tools, or can it refer to the process and methodology as well?

Doug McClure: I think that BSM is as much a philosophy as it is technology, process, people and methodology.  If we can get people to think, operate and respond differently than they do today with a focus on the business, customers, quality, revenue, or whatever else is most important to their business goals and objectives, than that is Business Service Management and could be “BSM Lite” if you will. 

Being that I work for IBM Tivoli, one of my personal objectives is to identify ways to use our key BSM enabling products in a more efficient, effective and BSM centric way. This was a huge driver for trying to hold DevCampTivoli focused on “Collaborative Development of End-to-End BSM Solutions”. 

In my opinion, we don’t make things very easy for our clients and the answer can’t be to “buy this product, module or widget” to fill in the gaps.  In my opinion, we must establish a BSM overlay within IBM Tivoli’s development and product management organization that ensures that we have clearly thought about how to enable BSM with the hundreds or products that we sell.  In my opinion, every product release must incorporate the fundamentals of enabling BSM in addition to the core domain specific functionality intended. I hope to keep this spirit alive and get our smartest IBMers and clients thinking about the best way to take a “BSM Heavy” solution and make it “lighter”. I hope to share more about my plans here and guidance for the industry in general soon.

That said, I am always interested in consulting with clients and collaborate with peers in the industry to figure out how to get the focus on the people, process and technology as key components of their BSM strategies.  I am absolutely convinced that without a documented BSM strategy, roadmap and top level sponsorship within the business and IT, the chances of BSM success greatly diminish.

ScienceLogic: Given the complexities involved in implementing a BSM strategy and dealing with the people and processes components of any business, how does “BSM Lite” really work? Should the expectations and outcomes be “lite” as well?

Doug McClure: Time will tell if “BSM Lite” will work.  I’m seeing emerging companies that are already breaking down some of the barriers to BSM success.  I do not expect that those choosing to begin with a “BSM Lite” approach should expect “lite” outcomes. 

The outcomes are the same regardless of the approach IF you’ve got a documented BSM strategy, roadmap and top level sponsorship in place before you begin. New features, capabilities and technologies will be needed as the needs of the business change and companies mature in BSM and fundamental IT management. This will likely force companies to move in more “BSM Heavy” directions to fill those gaps. 

In my opinion, this is the ideal scenario now as it gives “BSM Lite” vendors opportunities to grow their products and solutions. It also GREATLY improves the chances for success with a “BSM Heavy” solution because the organization would have already had matured enough to approach a “BSM Heavy” solution than if they hadn’t done a “BSM Lite” solution in the past.

ScienceLogic: Is “BSM Lite” more appropriate for a small or midsized organization, or does it apply equally to large companies? Is there an ideal profile for a company that can successfully implement a BSM strategy? Is there a different profile for “BSM Lite”?

Doug McClure: From an economic perspective, the concepts of “BSM Lite” are appropriate for all companies.  Remember, with “BSM Lite” we’re focused on identifying ways to make the goals and objectives of BSM easier to implement and in a more cost effective way.  Any company concerned about their IT cost overhead should care about this, especially when the risks of starting out with a “BSM Heavy” type deployment are much greater and the time to value generally much longer.

The “ideal” profile for any company is one where the BSM initiative begins by establishing top level buy in through creation of a formal BSM strategy for the company. This BSM strategy personalizes how the company defines what BSM is, what value the company expects from it, and how it will use BSM as a competitive differentiator for delivery of its business and IT services, products, etc.

The organizational “profile” I’ve seen most successful is when implementing a BSM strategy originates from within or actively includes a group that many companies have now that serves as a liaison or relationship management role between the various lines of business and IT. Sometimes this group is often seen as the gatekeeper to filter (and hinder) business driven requirements into the IT organization. In the ideal scenario, this group works very closely with the business and IT (usually staffed by business people and not IT people) to understand both the business side and IT side of complex business services and applications. 

Apart from the traditional IT components, what this group can do is help IT really understand the business perspective.  Analysis of the impact on the business in business terms is only possible by collaborating with a group such as this.  True value oriented BSM becomes attainable when we get to this level of IT and business alignment, cooperation, collaboration and communication.

If BSM is an IT only initiative, this will likely result in an IT centric perspective severely lacking in the necessary business perspective.  In these cases where IT doesn’t invest their BSM efforts with the business as an equal partner, the implementation ultimately becomes a “CYA” tool for IT and not achieve the desired value oriented expected.

To some degree “BSM Lite” may have an entirely different profile. If we see the price points, complexity and time to value change significantly we may see these types of deployments originate exclusively within the Line of Business. The possibility may exist where large enterprises operating in a shared IT services or IT outsourcing type model that the Line of Business brings in a “BSM Lite” solution to gain the visibility, checks and balances needed to ensure that the LoB’s needs are being met from the internal/external provider. I’d envision that “BSM Lite” may even be capable of operating within a “SaaS” model or other managed service type offering where the price points are below the signing levels triggering broader IT involvement and review.

To Be Continued…

ShareThis