John talked about Microsoft’s mission, his perspectives on key industry trends and market opportunity; he touched on Cloud Computing and Virtualization and took some Q&A from the audience of Managed Service Provider executives.

One of his first proclamations - Microsoft has really embraced the heterogeneous environment. Really? How in the world is Microsoft going to help convince IT line managers, or mid level managers to believe this statement? I think they have a long way to go to achieve this vision with any credibility in the marketplace.  I do know that they are making small strides.

Microsoft has been widely credited with some very good blogs that are self critical and introspective. They have also been quite active in the standards boards within DMTF and many others such as Open WSMAN and CIMON (Open Pegasus). Microsoft in February published 30,000 pages detailed technical specifications – protocol documentation for Exchange, since that time they have published another 15,000 pages. They have had over 224,000 downloads since February 21, 2008. Thus they are trying to be more open by making some of these secret sauce protocol resources directly available on the web.

So for now, I will take a very cautious wait and see approach to this proclamation. Time will tell.

Trends

• Rapid growth continues
• Hosting Competition has a new face
  • Platform gorillas (amazooglesoft)
  • Ad supported Web 2.0 hosters (Google, Facebook,)
• Utility Cloud Computing models are expanding to non-traditional hosting companies
  • Wells Fargo vSafe - hard to believe that a big bank would start to offer a SaaS offering
  • New tools and markets digital ribbon, CohesiveIT

IDC Data shows that growth of SaaS ISV’s is the biggest layer of growth. The fastest growing services are complex, custom applications. IDC says this area will be bigger than the hosting area in the next 5 years. John said that Microsoft is spending a lot of time, money and energy on this right now.

John said:

“when Microsoft thinks about the building blocks that make-up the cloud, virtualization is a core piece of the puzzle. However you also need also identity services, Operating system with standard set of libraries to tap into… or remote storage that application developers will tap into.. Developers will consume these set of services, but you will also need a set of tools to manage your physical, virtual and geographically distributed datacenter infrastructure.” (that is where ScienceLogic comes in!!)

He went on to say,

“In some ways, virtualization enables decentralization – allows you to move from data centers, enables fast scaling out, business to move from on premise to the cloud and off again…. Automation is very important – this will help you scale your business – this is core to your future success.”

He talked about a new breed of knowledge worker: He called them Digital Natives (compared to grey haired guys like me who are left out of this category).

Definition of a Digital natives? A young adult who has grown up with cellphone, web based applications, Facebook account, as their primary mode of communications.

John commented that we are 5 years into a 10 year journey. Only 12% of all servers in the world are virtualized today… in the next 4 years it will double to 25%. This is the time to think through how this business will affect you.

‘Virtualization without good management is more dangerous than not using virtualization in the first place.” Thomas Bittman, Analyst Gartner

Patching and provisioning nightmare – no scalable administration – sprawl chaos.

John posed a question to the audience: How do you partner to provide the ISV support in application development with specific market needs… partner by keeping the hosting to SaaS solution providers up and running and provide the quality of service that their customers expect…. Complimentary services of storage and backup is a big win with a huge market-upside over the next 5 years..

John said that Microsoft continues to make  huge investments with Managed Service Providers.

• Investing in the windows hosting platform
• Hyper V and SQL2008 GoLive program - getting beta code out to service provides to find as many bugs as early as possible.
• Software + Services (S+S) incubation center program
• Partnering for cloud platform market offers
• Cloud platform guidance and best practices

During the Q&A, David Burns from Cincinnati Bell asked the very best question… “when are you going to make it easier for the Service Provider market to deal with the Microsoft Service Provider Licensing Agreement (SPLA) quarterly statistics pull and change the SPLA pricing to be more efficient and creative for the new Virtualization and Cloud offerings you have talked about?”

John’s response: “We hear your frustrations loud and clear and are working on some new ideas for the future version of SPLA.” My interpretation – “Dear Service Providers don’t expect anything new or easier to deal with in the next 6 months!”

His closing remarks: “Cloud is evolving = very early stages, lots of hype, but think of how this evolution will effect your business and how you can plug into it.”

We chatted about the growth of the show and how much that growth reflects the industry itself. Since the bust earlier in the decade both Interop Las Vegas and New York shows have grown year over year – not just in attendees and exhibitors but in topics covered in the conference tracks. As any of us who are in the space know, it’s a rapidly changing market and Interop strives not just to cover the latest trends but also to get ahead of them while still making sure that they are relevant.

The show’s mission overall has expanded beyond “just” networking to cover performance and new trends like virtualization, cloud computing and SAAS that all affect network performance. It is a mirror for the demands on the network (and network admins) and the convergence we see going on that make managing the network so complex today.

Responding to criticisms about the lack of interoperability at the show, Lenny says, “Our special sauce is interoperability.” And in fact the expanded mission of the show ensures that there are more interoperability issues to deal with and he invites the community to comment and share feedback on this core mission.

Last, we talked about InteropNet. We’ve loved our participation in it this year for a variety of reasons – from the opportunity to work with other cool vendors in an intensive and real-life/real-time environment to the true sense of camaraderie and “getting it done” that everyone shares on the InteropNet team to the wonderful atmosphere of hard work AND hard play that you have to experience to believe.

We talked with Lenny about how he measures InteropNet “success” and the answer was illuminating. They’ve got high expectations at Interop; they expect the network to just work, so the focus is actually not on uptime and SLAs – that’s a given. “Nothing less than perfection works here.” (Let me tell you, after my horrible experience with the super slow and inaccessible network at the VMworld conference, that is definitely not always the case. Maybe InteropNet should sell its services…hmmmm…) Rather, it’s about being able to showcase technologies and strategies for networking and interoperability – or as we’re interpreting that, basically “walking the walk – which in the end is what InteropNet is all about.

See the full video here.

1. The Sun-Sentinel newspaper in Fort Lauderdale accidentally republishes a six-year-old news story about the bankruptcy of UAL. It wasn't on the home page, but instead buried somewhere inside the web site.
2. Google's news crawler (an automated thing, remember) finds the story and incorporates it as part of its news feed.
3. Investors see the story, and immediately react. When UAL's stock plunged 76% to a low of $3, Nasdaq shut down trading. Eventually trading resumed, and the stock closed at just under $11, losing about 11%.
4. United blamed Tribune Company (the owner of the Sun-Sentinel) for "irresponsibly" changing the date on the story and demanded a retraction.
5. Tribune Company blamed Google, claiming they've had issues with Google's crawler "for months."

Who will blame be shifted to next?

Look -- if people haven't realized by now that the Internet pretty much lacks a delete function, then (IMNSHO) it becomes the requirement of each and every one of us to pay close attention to what we're reading, to use our own big brains and fine-tuned bullshit detectors to suss out whether something makes sense.

Since this is my blog, I'm going to parcel out blame the way I see it:

• United: 0%. If the concept of "negative blame" made any sense, then I'd actually write −∞ (that's a negative infinity, in case your character set is different than mine).
• Google: 5%. How can an automated crawler know that a newly-dated story isn't really new? Well, those folks over there at Google are smart. Certainly it shouldn't be that difficult to compare a "new" article against existing ones. Content hashes won't work as a comparison tool, because the date would be included in the hash computation, thus making the hashes different anyway. Full-text comparisons? Sure, it would take a lot of horsepower. Perhaps not every "new" story needs comparison, but at least the crawler could submit to the comparator any stories that ought to be verified (say those with the word "bankruptcy" in them).
• Tribune Company: 30%. Hey guys, you changed the date on the article. Don't go blaming someone else for your screw-up.
• Investors: 65%. If you're using an automated news aggregator (remember, an aggregator is not a source of news) to make major financial decisions -- decisions that affect the livelihoods of thousands (maybe millions) of people -- well, you're a moron. You should know that incorrect information can be just as instantly available as correct information. Verify potentially damaging claims before engaging in reckless behavior.

What's this got to do with security? I don't know, maybe nothing directly related. But it certainly raises the question -- what if someone intentionally wanted to cause nearly permanent damage to a person or a corporation? Malicious content, disguised as "news," certainly seems to have become a potentially successful attack vector this week.

Worried about a social engineering attack on a massive scale? I suspect that what happened Monday (8 September) was the largest social engineering attack in history -- although I wouldn't classify it as intentionally malicious. Just you wait until the idea spreads.

Well here’s a story where the tradeoff for speed and efficiency caused a massive stock dump erroneously.

Apparently, many traders use automation software that trolls the Web for news stories and then, depending on what it finds, executes stock trades automatically. It was United Airline’s bad luck that an old article about its 2002 bankruptcy-court filing showed up on Google’s news service and somehow made it to the list of most popular stories. In one of a series of mistakes here, the story had no date on it – which means Google’s algorithm for assessing popularity didn’t have a way to exclude it as an “old” story – OR (because there are conflicting accounts) the South Florida Sun-Sentinel actually put “today’s” date on the page that the story appeared on. This got picked up by the Income Security Advisors newsletter and sent over to Bloomberg News as a one-line brief. Plus there’s the inevitable conspiracy theory that people manipulated the web traffic for this story to adversely affect UAL. Regardless, on Monday afternoon, the stock plunged 76% in less than a day.

But the real problem here is the growing use of automated programs to trigger stock trades without any human interaction – instead based on news headlines and earnings data. According to the Wall Street Journal, these automated programs were responsible for a very surprising 25% of NYSE trades in the last week of August.

I’m sure we’ll hear more as the lawyers are now involved trying to figure out who should get the blame.

The issues affect Windows Media Player, Windows Media Encoder, and five problems in the Windows Graphic Device Interface (GDI). Patch today, because the exploits are coming fast on these, according to other experts.

Visit Microsoft for the updates.

I know that I am always looking for better, cheaper, and faster ways to do what I do now. As regulations like PCI become more prescriptive, as discovery and compliance tools get better, as organizations embed security more seamlessly in the business, and as security itself becomes part of more expansive and, theoretically, more valuable business roles, will security professionals need to reinvent themselves?…

Very few jobs in any large organization look like they did 20 years ago; some of security’s most traditional work may see big changes ahead. How do we prepare our colleagues and teams for those challenges and turn them into opportunities?

Read the whole article here.

It's become a big deal in IT security, too. Many corporate customers are demanding ROI models to demonstrate that a particular security investment pays off. And in response, vendors are providing ROI models that demonstrate how their particular security solution provides the best return on investment.

It's a good idea in theory, but it's mostly bunk in practice.

Before I get into the details, there's one point I have to make. "ROI" as used in a security context is inaccurate. Security is not an investment that provides a return, like a new factory or a financial instrument. It's an expense that, hopefully, pays for itself in cost savings. Security is about loss prevention, not about earnings. The term just doesn't make sense in this context.

But as anyone who has lived through a company's vicious end-of-year budget-slashing exercises knows, when you're trying to make your numbers, cutting costs is the same as increasing revenues. So while security can't produce ROI, loss prevention most certainly affects a company's bottom line.

And a company should implement only security countermeasures that affect its bottom line positively. It shouldn't spend more on a security problem than the problem is worth. Conversely, it shouldn't ignore problems that are costing it money when there are cheaper mitigation alternatives. A smart company needs to approach security as it would any other business decision: costs versus benefits.

The classic methodology is called annualized loss expectancy (ALE), and it's straightforward. Calculate the cost of a security incident in both tangibles like time and money, and intangibles like reputation and competitive advantage. Multiply that by the chance the incident will occur in a year. That tells you how much you should spend to mitigate the risk. So, for example, if your store has a 10 percent chance of getting robbed and the cost of being robbed is $10,000, then you should spend $1,000 a year on security. Spend more than that, and you're wasting money. Spend less than that, and you're also wasting money.

Of course, that $1,000 has to reduce the chance of being robbed to zero in order to be cost-effective. If a security measure cuts the chance of robbery by 40 percent -- to 6 percent a year -- then you should spend no more than $400 on it. If another security measure reduces it by 80 percent, it's worth $800. And if two security measures both reduce the chance of being robbed by 50 percent and one costs $300 and the other $700, the first one is worth it and the second isn't.

The Data Imperative

The key to making this work is good data; the term of art is "actuarial tail." If you're doing an ALE analysis of a security camera at a convenience store, you need to know the crime rate in the store's neighborhood and maybe have some idea of how much cameras improve the odds of convincing criminals to rob another store instead. You need to know how much a robbery costs: in merchandise, in time and annoyance, in lost sales due to spooked patrons, in employee morale. You need to know how much not having the cameras costs in terms of employee morale; maybe you're having trouble hiring salespeople to work the night shift. With all that data, you can figure out if the cost of the camera is cheaper than the loss of revenue if you close the store at night -- assuming that the closed store won't get robbed as well. And then you can decide whether to install one.

Cybersecurity is considerably harder, because there just isn't enough good data. There aren't good crime rates for cyberspace, and we have a lot less data about how individual security countermeasures -- or specific configurations of countermeasures -- mitigate those risks. We don't even have data on incident costs.

One problem is that the threat moves too quickly. The characteristics of the things we're trying to prevent change so quickly that we can't accumulate data fast enough. By the time we get some data, there's a new threat model for which we don't have enough data. So we can't create ALE models.

But there's another problem, and it's that the math quickly falls apart when it comes to rare and expensive events. Imagine you calculate the cost -- reputational costs, loss of customers, etc. -- of having your company's name in the newspaper after an embarrassing cybersecurity event to be $20 million. Also assume that the odds are 1 in 10,000 of that happening in any one year. ALE says you should spend no more than $2,000 mitigating that risk.

So far, so good. But maybe your CFO thinks an incident would cost only $10 million. You can't argue, since we're just estimating. But he just cut your security budget in half. A vendor trying to sell you a product finds a Web analysis claiming that the odds of this happening are actually 1 in 1,000. Accept this new number, and suddenly a product costing 10 times as much is still a good investment.

It gets worse when you deal with even more rare and expensive events. Imagine you're in charge of terrorism mitigation at a chlorine plant. What's the cost to your company, in money and reputation, of a large and very deadly explosion? $100 million? $1 billion? $10 billion? And the odds: 1 in a hundred thousand, 1 in a million, 1 in 10 million? Depending on how you answer those two questions -- and any answer is really just a guess -- you can justify spending anywhere from $10 to $100,000 annually to mitigate that risk.

Or take another example: airport security. Assume that all the new airport security measures increase the waiting time at airports by -- and I'm making this up -- 30 minutes per passenger. There were 760 million passenger boardings in the United States in 2007. This means that the extra waiting time at airports has cost us a collective 43,000 years of extra waiting time. Assume a 70-year life expectancy, and the increased waiting time has "killed" 620 people per year -- 930 if you calculate the numbers based on 16 hours of awake time per day. So the question is: If we did away with increased airport security, would the result be more people dead from terrorism or fewer?

Caveat Emptor

This kind of thing is why most ROI models you get from security vendors are nonsense. Of course their model demonstrates that their product or service makes financial sense: They've jiggered the numbers so that they do.

This doesn't mean that ALE is useless, but it does mean you should 1) mistrust any analyses that come from people with an agenda and 2) use any results as a general guideline only. So when you get an ROI model from your vendor, take its framework and plug in your own numbers. Don't even show the vendor your improvements; it won't consider any changes that make its product or service less cost-effective to be an "improvement." And use those results as a general guide, along with risk management and compliance analyses, when you're deciding what security products and services to buy.

This essay previously appeared in CSO Magazine.

Preface

The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them.

While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.

Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.

The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.

As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.

Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.

There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.

This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.

Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.