Ten days before VMworld and VMware still can’t get good press. First their CEO, Diane Greene, gets ousted, then a high-profile licensing bug is found and now the Director of R&D, Richard Sarwal, leaves his $1.25 million salary after just 7 months. (Note to self: get into R&D) It will be interesting to take the pulse of the VMware community at the show and in person. And in the meantime, Microsoft Hyper-V comes out of the gate with customers already touting its benefits.

The hypervisor is the “new” operating system. If you didn’t think that before, take a look at Red Hat’s purchase of Qumranet for $107 million. With Qumranet, Red Hat gets KVM, described by CTO Brian Stevens as an extension to the Linux kernel that allows it to be used as a bare-metal hypervisor, running directly on the underlying hardware and hosting guest operating systems. But according to Brian Madden, the “press” around the purchase is all focusing on the not-so-interesting part. Along with KVM, the SolidICE product includes Spice, a remote display protocol for VDI.

I wonder if this will be like Symantec buying Altiris or Microsoft buying Softricity, where the portion that we care about sort of loses focus as The Borg concentrates on the parts of the acquired technology that are more relevant to them?

(I’m a sucker for quotes that reference The Borg)

Network World publishes “10 open source companies to watch”. On the list, Qumranet!

Also on the list: Kickfire, Marketcetera, Vyatta, Sonatype, Untangle, XAware, SnapLogic, Acquia and Openmoko. What’s best about the list: Matt Asay gives it a thumbs up.

It’s a good reminder for all you folks– always plan ahead and have a good backup and recovery strategy. It might also be a good idea to make sure someone on your staff has first aid and medical training in case of office emergencies, acts of god, and the occasional pirate attack.

Lo and behold time works its wonders and I can type again. Watch me rejoice! And post interesting articles for your professional entertainment. Stay tuned.

So I got my iPhone 3G on Friday morning and have been using it for a few days now. I have never used one before, don't use an iPod or even a Mac computer.  The iPhone was incredibily easy to use and without using and manuals quickly had a most everything working and downloaded a bunch of apps from the app store. 

Over all, the iPhone just is really nice to use and in many ways very easy, polished and intuitive. In other ways, it is still missing some key features in my book:

1. Sort and filter email be date, sender, etc.
2. Select more than one mail at a time to delete, move, copy.  Yes I know you can go to edit and select messages to work on, but you still have to select them one at a time. In Windows Mobile you can just run your finger over multiple messages to complete this.
3. Deleting duplicate contacts in bulk.  Doing them one at a time is just painful
4. A task manager. I would like to see some list that shows me which apps are running, how many resources they are using, battery usage and stuff like that.  Also to shut down running apps
5. Better calendar integration. I tried to click on and open calendar items, but just does not seem to work.
6. The battery sucks! I am not getting more than about 6 to 7 hours of battery time. I think I have to turn off the push for my Exchange email.  This is much less that I was getting on my Windows Mobile phone.

I do like the phone, the iPod MP3 and camera and the overall "feel" of the phone. Went to the Apple store in the maill (which was jam packed) and bought a rubberized case, but was unable to get a phone car charger for it yet.  I ordered one for 5 bucks on Amazon and will see it if works.

All in all, things are OK but I am going to withhold my final verdict for a while yet.

So I got my iPhone 3G on Friday morning and have been using it for a few days now. I have never used one before, don't use an iPod or even a Mac computer.  The iPhone was incredibily easy to use and without using and manuals quickly had a most everything working and downloaded a bunch of apps from the app store. 

Over all, the iPhone just is really nice to use and in many ways very easy, polished and intuitive. In other ways, it is still missing some key features in my book:

1. Sort and filter email be date, sender, etc.
2. Select more than one mail at a time to delete, move, copy.  Yes I know you can go to edit and select messages to work on, but you still have to select them one at a time. In Windows Mobile you can just run your finger over multiple messages to complete this.
3. Deleting duplicate contacts in bulk.  Doing them one at a time is just painful
4. A task manager. I would like to see some list that shows me which apps are running, how many resources they are using, battery usage and stuff like that.  Also to shut down running apps
5. Better calendar integration. I tried to click on and open calendar items, but just does not seem to work.
6. The battery sucks! I am not getting more than about 6 to 7 hours of battery time. I think I have to turn off the push for my Exchange email.  This is much less that I was getting on my Windows Mobile phone.

I do like the phone, the iPod MP3 and camera and the overall "feel" of the phone. Went to the Apple store in the maill (which was jam packed) and bought a rubberized case, but was unable to get a phone car charger for it yet.  I ordered one for 5 bucks on Amazon and will see it if works.

All in all, things are OK but I am going to withhold my final verdict for a while yet.

ScienceLogic: Can you share any of the strategies/advice that you give to companies embarking on their BSM journeys?

Doug McClure: Well, first they’ve got to have a BSM strategy. Nearly all the clients I talk to or hear about wanting to do BSM do not have a BSM strategy. I talk a lot about this on my blog and with clients and it is relevant whether you’re going to think about “BSM Lite” or “BSM Heavy” approaches.

Once we have a BSM strategy, we need to establish a BSM roadmap that guides us in how we’ll implement the BSM strategy in a more tactical manner, focusing on short term iterative quick wins and 30-60-90 day projects. For more of my thoughts on BSM strategy and roadmapping, see the following blog posts.

• Elements of Business Service Management Part 3: Getting Business Service Management on the Radar Screen

• Elements of Business Service Management Part 4: What’s your Business Service Management Strategy?

As I’ve alluded to previously, a client first must define and understand what “BSM Lite” may mean to them. Don’t take what the analysts or the vendors pitch for what you should do to achieve BSM or what value you should get from it.

For any type of BSM to be successful, each client must define what BSM means to them and state what they expect to get from BSM. They must make it personal, make it a part of their company culture and elevate it to be as an important initiative as compliance, risk management, SOA, ITIL, or other initiatives may be within the company.

Please don’t get scared off from this strategy thing. Please don’t blow this off as something that the secret enterprise architecture council should be doing. If you’re unable to get an audience in these areas within your company, start within your own sphere of influence.

Your strategy could be as simple as enabling the local operations center to more efficiently classify, triage and resolve problems based on a simple business service or application contextual understanding. Focus on how this changes the game within your environment. Come up with your own metrics and measures to assess the value this has to this organizational use. Trust me, you’ll need to justify your investment some time in the future.

Another trait of successful BSM implementations is that of the formal monitoring and management tools group has established some sort of database or knowledge repository that enables them to “manage the business of IT management and monitoring” if you will. In my opinion, the vendor community has let their clients down significantly in this area. The CMDB may be the correct answer, but most companies just don’t value monitoring enough to demand that this be included in their formal CMDB initiatives.

In my last job, we developed an application that I referred to as the “Service Management Database” or “SMDB”. Others may call it something else, but in essence, it was the database that captured what was monitored, how it was monitored, who owned it, what business services and applications it supported, the impact an outage or event from it had on the business services or applications, etc.

One key component of this “SMDB” was establishing the relationships of real and synthetic user and transaction monitoring steps to associated servers and applications. This is a significant gap area in many tools and vendor CMDBs.

Clients who have instituted something formal such as this generally have a very good handle on management and monitoring within their environment. Far too many clients do not have adequate monitoring (read visibility) in place to begin their BSM journey.

I’d strongly recommend a good hard look at how well the client’s monitoring and management practices are implemented and managed. Simply put, if they don’t have adequate visibility into how well those business services and applications are performing, you can’t expect to manage what you can’t “see” that may be impacting the business, clients, revenue, etc.

Just ask yourself this – can you explicitly state what monitoring is in place for a given business service or application? Can you quantify the impact of a simple event to a business service or application? Can you explain why something is red, yellow, purple or green and what causes it to change from one color to another? If you can’t, your BSM journey will be challenging.

Those with formal CMDB initiatives have their hands full with high risk, long time to value projects to just get a handle with traditional configuration management models. Taking these low level configuration items (CI’s) and establishing application and service dependencies comes after a lot of work getting through the organizational challenges of getting systems access to populate the CMDB.

I strongly recommend that the formal monitoring and management tools group create an authoritative database that enables them to establish end-to-end visibility into the service and application delivery chain and the impacts it has on the business, customer, etc. This ultimately becomes part of a more realistic federated CMDB within the business.

ScienceLogic: Can you provide an example of a successful implementation of BSM? Were there specific factors that especially contributed to its success?

Doug McClure: I’ve touched on the highlights of the most successful BSM implementations throughout my previous answers. Clients that have rallied around an organizational change or transformation focusing every team member’s efforts and energy towards ensuring that the business goals and objectives are being met through the delivery of highly available business services and applications.

Far too often the “change” never happens and it’s the “talking heads” that are preaching to the choir about what should be done. Every person on the front line, in the support teams, at the help desk, etc. must understand how they support or impact the business in business terms. Try putting this simple phrase after job titles “Hi, my name is Doug. I’m a Systems Administrator, Supporting the Business”.

That was a mouthful, but simply put, these clients have an impressively instrumented business and IT environment with the right amount of visibility into each area, joined together with an organization that thinks, operates and responds based on their understanding of the business goals and objectives and how these business services and applications enable business success.

The operational model for an organization fully adopting BSM identifies ways to establish a service management mentality across the entire business service and application delivery and support chain. The delivery, operations and support organizations must be incented to manage the services and applications being delivered with this end-to-end context.

A leading, outside the box “service management organization” may include the traditional IT silos but within a matrixed fashion focused on one or more key business services and applications. The “service management organization” is then incented to work together, as a team, for the end-to-end delivery and support of these services or applications.

It’s no longer one’s job to just be the systems administrator, database administrator or network engineer, their job is now to support specific business services and applications. They provide the subject matter expertise needed to support the services and applications together, as a team, eliminating the finger pointing or “not my problem” attitudes that exist in the majority of IT organizations today.

Overall, the KISS approach is what will enable BSM of any type (lite, heavy) to be the most successful. If it just feels natural, doesn’t take any additional effort, clicks or tasks to do then it’s going to work. BSM should be transparent and not just another buzz word. It’s not a form that gets filled out or a special process to follow in the run book. It’s doing the right thing for the business, no matter what the situation, crisis, buzz word or technology initiative of the day is.

ScienceLogic: How did you get involved in BSM?

Doug McClure: I think the foundations of my service management background and passion were initially established during my service in the US Navy. Today, I relate that experience to what I call BSM for the Military or Mission Services Management (MSM).

We had been taught over and over that extreme attention to the details of the mission at hand (aka “the business”) was the number one priority and that all of our technology, services, and applications existed for those Sailors and Marines on the other end (the “customer”). I can recall countless instances where mission critical communications services (telephony, orderwires, teletypes, command and control systems, etc.) were impacted in one way or another. It was extremely critical that we understood who was impacted and to what degree so that contingency plans could be activated. We weren’t just talking about lost revenue, poor sales or customer experience; we were talking about human lives and the security of the United States.

It is that military bearing, attention to detail and real world experience that drives me with many of my modern day BSM endeavors. That migration from “Mission Services Management” to BSM was honed working for over 10 years working in the Internet Service Provider (ISP) and datacenter, hosting and colocation business.

In those rapid growth businesses during the Internet boom, service differentiation was what “made you millions” or paved your way to bankruptcy. The companies I worked for had an extreme passion and focus on ensuring that their services, applications and Internet access products were of the highest quality, highly reliable and just plain better than the competition.

Again, the IT infrastructure, service quality and customer experience relationship was ingrained in all of our heads. It was all hands on deck when Webmail, Internet access, DNS, or the network experienced problems. We were measured in terms of how many customers experienced a busy signal or dropped connection or if you couldn’t log in fast enough to read your email. Companies like Keynote Systems and LionBridge/Veritest/Inverse tested the quality of our networks, services and applications and publicly ranked us against our competition. We thought in terms of customer experience and impact every minute of the day, 24×7.

It was in my last job managing a traditional enterprise management and monitoring development group for a nationwide ISP where I was able to work with emerging technology to help get a handle on the complexities of these rapidly growing IT environments filled with emerging technologies and products. Applying this early technology to complex service problems in our environment proved to me that the technology, coupled with the right emphasis on how the technology was implemented and an emphasis on the people and processes within the organization could bring BSM to life.

Where I felt left out in the cold was with my vendor relationship. While their technology gave me the potential, they didn’t teach me how to work through the organizational and technological problems to successfully implement the BSM strategy. My very first end-to-end BSM pilot was extremely successful and provided visibility into the IT environment and business service impact that have never been available before.

And here I am today, working at a software vendor for the first time. Welcome to the “dark side” as they say. The approach and methodology we followed for BSM has become the basis of the core BSM Methodology that I teach IBMers and our clients around the world today.

My personal mission and drive here at IBM Tivoli is to ensure that BSM is something that the typical monitoring tools administrator can actually implement and that our BSM story is something that any of our clients can be successful with. The sales and marketing slicks must be backed up by something like this whomever you are these days. Clients shouldn’t put up for “marketecture”, me too and gee whiz buzz words.

BSM takes a partnership and commitment to every client’s success, and I want to be involved in those BSM efforts in every industry or market worldwide. We need more thought leaders collaborating together in an open and public forum to change legacy attitudes about BSM and do what we can to enable client’s to be as successful as they can be.

ShareThis

1. We don’t believe that the goal of Quantitative Risk Analysis is to be precise.  We believe the goal is to be accurate. Subtle but important difference.
2. FAIR can be used both Quantitatively and Qualitatively.   The decision on which method to be used depends on various factors that Steve lays out nicely in the article there.
3. We believe that Risk Management is more than looking at specific vulnerabilities, their likelihood and impact.  It must encompass all aspects of the organizations ability to effect the probable frequency and magnitude of loss on an aggregate level, not just within the context of a discreet technical or policy issue.

That last point is important.  And it’s related to my post today.

WHAT DO YOU MANAGE TOWARDS?
This blog is blessed to have some very smart people be part of it.  There are security managers from all sorts of industries that read and comment and contribute.   And so today’s blog is more of an open-ended question for you all.  It’s a question that, if I have a comfortable relationship with the organization I like to first ask the senior manager, and then subsequently ask the direct reports.

When you think about it, Sales & Marketing managers have goals they manage towards.  CFO’s have goals that they manage towards.  COO’s have goals and measurement that they manage towards (cost management, production, etc…).  So what does the CSO manage towards?  I’m guessing if we took a national poll, we’d get all sorts of very nice sounding answers to that question.  I thought I’d list some of the answers I’ve heard and talk about them with you today.

1.)  Being Secure or “Managing to Security”

Generally, this concept of being secure is the most common answer.  And when I’m given that answer, it generally means that management focuses on Vulnerability Management, Patch Management, and to some degree, log analysis from various sources.  These are very basic core security functions, and the  belief is that if we do these well, we will be “secure”.  Ok, well… what does this “secure” mean, and how can we talk to management about whether we are meeting this goal?   If you examine that question, you actually find out what a “Being Secure” organization is really managing towards, another answer I hear often:

2.)  Being Incident-Free or “Managing to Perfection”

Security Person:  “Alex, our goal is not to have any incidents.”  Alex:  “Good luck with that.”

OK, that’s not what I really say, but here’s the problem I see with this common answer and the one above both of these common answers:  How do you know if you’re good or just lucky?

Well, are you, punk? (youtube link)

In my six years of working with a Penetration Testing team, nobody ever really “passed” with a perfect score*.  Some did better than others, some folks looked really, really good - but the degree  of good/bad was really more dependent on scope than the actual state of controls or the ability of the team to overcome them.  That is to say, when pressed, the mature security professional must admit that, given a strong, capable threat community -  there is no secure.   And therefore any state of “incidentlessness” deals with some combination of amount of control strength, and some lack of attacks (frequency!) by someone with enough skills and resources to overcome those controls.  If that last sentence sounds very FAIR-Like, that’s because it is.  If FAIR really accounts for those things that create Risk, then Managing to security or lack of incident means that you’re primarily concerned with FAIR Vulnerability, and ignoring other critical aspects of risk (like frequency of attacks, controls that reduce the probable impact of an event due to an ability to respond well to external stakeholders, etc…).

3.) Being Compliant or “Managing to Compliance” (External Compliance Pressures)

Because that’s what business buy, right?  They buy compliance!   Or so I’m told.  So let’s say that you go out and actually twist senior managements arm to get them to cough up enough dough so that you can be as compliant as Large Accounting Firm says you need to be.  Good on you!

But what I always wonder is, what happens when you want to manage something beyond compliance?  What happens when the checklist you’re managing towards is run by a bureaucracy that can’t keep up with a changing threat landscape?   For many people, the answer is “GOTO 1″ and try to sell upper management using FUD (hey, it used to work, maybe it’ll work again).  An alternative is to get to the next step:

4.)  Being Measured or “Managing to Metrics”

Say what you will, but “quants” have one thing right.  What gets measured gets done.  And a few mature organizations have spent a ton of time and effort on being able to create dashboards of KPI’s that attempt to measure security.  Problem is, that we don’t know if a 98% on patch levels is good or bad or just right.  We don’t know what value, if any, does creating metrics around the number and severity of vulnerabilities found in a monthly scan actually have.  So we’ve come up with this thing called “GRC” that’s supposed to make sense of those things we can measure empirically and help you find out if/when you’ve fixed them. And while GRC tools can tell you some good information about systems out of compliance, they tend to give you fantastic information like how your “risk = 57“.

Wha….?

Risk = 57 means very little to someone who doesn’t spend their life in the machinations of the GRC indicies.  So again, measurement without a (good) model still falls down when faced with that ultimate business decision.  Or, as Shurdlu so eloquently puts it in her post on GRC:

“By contract, risk is personal.  It’s variable as hell.  It “governs” what you spend your money on, and therefore, with or without a dashboard, your CEO is already doing risk assessment every time she decides what your security budget is going to be.  Will you really be able to change her mind by showing her the dashboard and saying, “But—but—the needle is pointing to RED!” when you’re sitting there with your line items in your fiscal shopping cart? “

5.)  Using Risk or “Risk Management”

Which brings us to my favorite, using risk (as defined as the probable frequency & probable magnitude of loss event(s)) as a means to manage.  Now many industry veterans will tell you how jaded we all are on the term “Risk Management”.  And we have every right to be, as Risk Management has been horribly abused by vendors, committees and standards bodies alike.

These days, the term has been narrowly defined to mean an extension of vulnerability management.   This is small, small thinking, IMHO.  To me, Risk Management isn’t the management of individual issues deemed as “risky” as much as it is measuring (see 4) our ability to make decisions through the lens of risk.  Maybe I should start saying “Risk-Based Management” instead of “Risk Management”.

This Risk-Based Management approach provides meaning to metrics. We can know what we’re measuring and why we care about it.  And why we care about it needs to match what management cares about.  If your approach to Risk Management results in some metric or KPI that non-IT (or non-security) management doesn’t understand or speak to them in an evident language, it’s time to find a new model.  This is why “Quants will win” and where risk = 57 is wrong.  Risk, expressed as “expect a once in 5 year chance to lose $875,000 if we don’t spend $90,000 now” actually gives executives something beyond an arbitrary ordinal number or color to work with.  And what’s interesting is, if your model does the right things in getting you to that expression - then metrics and KPIs - those “why/when/where” questions we have a tough time answering about metrics - they become easier to discover.

DISPROVING RISK MANAGEMENT

As a side note, originally I was going to write today a completely different post on how we can disprove whether or not OCTAVE or 800-30 or ISO 27001 risk management efforts are really “Risk Management” - and one significant point was “Does your non-IT management really care about the deliverable?”   This thought came to me after seeing a few too many emails into the ISO27001 mailing list asking “How can I get management to fund ISO 27001 certification?”  Of course, the value of implementing the ISMS and the value of certification are two separate business propositions, but if you can’t sell the first, then are those efforts really good risk management?  You know, the kind of effort that we can use to make meaningful reporting?

=============================

* I can tell you that at times we were asked to test products out for clients before they made a significant investment.  One biometric device stands out in memory as not being “hacked” in the time alloted for the engagement by a defense contractor.  After it passed the “Gummi Finger” test - we were going to try using a recently severed finger, but oddly enough nobody on the team volunteered their digit for the sake of security.  Bunch of slackers.

Blogger: Ramon Krikken

A seemingly innocent question on a mailing list - which I paraphrased for brevity - set in motion a series of events with dire consequences. The specific code, which was generating error messages in a certain software quality assurance tool, happened to be a critical part of the random number generator in a cryptographic library package. By removing this code, the strength of the cryptographic key material was reduced to a point where cracking the key would take minutes instead of decades. The unfortunate thing about cryptography and randomness is that good and bad can be virtually indistinguishable, and in this case the result still looked so random that the problem went unnoticed for about two years. The impact - needing to regenerate two years worth of key material, and casting doubt on encrypted communication and access performed with those keys - has understandably led to some vigorous discussion and finger pointing. Search Google for "debian openssl" for more discussions than I can link to.

The action - making a change without following a standardized process  - is certainly not unique to this situation, and "the system was slow so I turned off this feature", or "I just fiddled around with it and it just started working" are phrases all too commonly heard in many aspects of IT. Some might argue that a commercial development process would likely have prevented this occurrence, but to simply turn this into a comparison of open source and commercial development ignores some very important aspects. There are important lessons to be learned that could benefit any software development process, particularly when process parts are being adapted to encompass ever changing development and security landscapes. In the ideal world, source code would be based on well-documented requirements, consistently structured, well commented, and maintained by easy-to-reach teams that understand the code inside and out. The reality of dealing with the pressure of delivery deadlines, distributed development teams, and code written either long ago or by a third party can make coding a daunting task ... and quality assurance next to impossible, especially if breakdowns in process or communication occur. The myriad of testing tools, sometimes producing output that can run in the hundreds of pages, coupled with a lack of understanding about their testing coverage, doesn't make the task any easier.

Looking at how this specific event unfolded can lead us down many paths of analysis, all of which will provide valuable information in attempting to determine a root cause. Unfortunately - and this is something that is also not unique to any specific kind of environment - not all parties involved are neutral, and there can also be a tendency to fixate on symptoms rather than the cause. One reason for this may be the assumption that it's possible to fix specific process parts without necessarily re-evaluating the process as a whole; another is that risks and the resulting need for assurance, including process assurance, may be underestimated. Looking at the failures in the flaw finding process purportedly followed in the Therac 25 accidents it's easy to see how this can result in unacceptable consequences. And while likely not resulting in loss of life, the potential economic loss associated with a failure of a cryptographic module suggests that a critical security component can't be treated like just any other piece of software.

How ever unfortunate, this event presents a good opportunity to take a moment and look at our own development processes. Particularly as we start to embrace service orientation, where we loosely couple different business functions while relying on centralized, and often externally developed, security and reliability services, we increase the possibility of creating situations such as this. Using a risk-based process, and testing and revisiting the process itself to ensure it stays current, will be vital in providing appropriate levels of software, system, and information assurance. Building a high-assurance component using a low-assurance process just isn't worth the risk.