The CISSP is undoubtably one of the most, if not the most, important professional certifications in Information Security. Many organizations and practitioners rely on it as evidence of a solid foundation and track record in Information Security. But the CISSP is only one of the many ways that the (ISC)² attempts to fulfill its mission of developing the Information Security profession.

Board membership is a role of governance, guidance, and passion. Let’s briefly explore how Dan’s track record and past contributions demonstrate his qualification for this post, and possibly your vote.

Passion

Dan is someone who has a passion for promoting and developing the talent needed to continue to grow and mature our profession. Anyone who has seen Dan speak at conferences, local chapter meetings, or in one of his classes knows how passionate Dan is! But anyone who takes the time to approach him knows that he is no ideologue or zealot; Dan is always interested in improving his own understanding, and then sharing that knowledge with others.

Dan has a long track record as a contributor - as a “giver” - to the profession. In addition to teaching over a dozen CISSP review courses, he has also served on multiple (ISC)² committees, is one of the authors of the ISSAP Body of Knowledge (cryptography), and has published primary research on professional certifications. He is also the founder of the monthly Columbus, Ohio Information Security MBA (Masters of Beer Appreciation) meeting - a professional roundtable that attracts practitioners from across the state.

Governance and Guidance 

In addition to past experience serving on (ISC)² committees, which I assume led to the current board’s nomination, Dan has served on numerous Boards of Directors including local and regional community organizations, ISSA chapters,and several Toastmasters clubs. 

Personal Experiences

I have known Dan for almost three yeas. Dan and I have collaborated on a number or projects, including a half-day Cryptographic Controls Seminar and a full-day Identity Management Architecture class. It is my feeling that when you collaborate, work closely, and travel with someone, you really get to know them. You get to do more than hear about their College Sweethearts (which, for Dan, is Rebecca, his wife of 21 years), but you also get to understand their ethics, how they really conduct themselves, how they deal with stress, etc.

Given the entire picture, the understanding that I have of Dan Houser, I can think of no one better suited to representing, guiding and developing the (ISC)². I have voted for Dan, and I hope that you will consider doing the same.

Here is the voting link for (ISC)²: https://webportal.isc2.org/custom/votenow.aspx

Cheers, Erik

CISSPs… Lend me your ears…

After meetings and calls, I was finally able to slip into a conference session – just in time to catch uber-smart analysts Rachel Chalmers (The 451 Group) and Dan Golding (Tier1 Research) engage in a lively and not-so-mock debate on “Hosting Meets the Cloud”.

Now this doesn’t cover the entire debate – and part II is coming tomorrow. But what it does cover is the most interesting questions (to me) and paraphrase the points made by the analysts. I thought they both had very interesting points and more similarities than differences in the end; the real difference is how they thought about the issues and through what lens – for Rachel it was the enterprise and for Dan it was managed hosting providers. (image from inmagine)

Question: What is a cloud and why?

Dan: Shared infrastructure leveraged/run by third parties for the benefit of enterprises, developers, etc. This is not a new idea – just recently “rebranded.” Given all the discussion and disagreement over this now, what will the cloud end up looking like?

Rachel: The cloud is “IT infrastructure as a service” down to the level of a server operating system. Take the example of Amazon web services – in this case it’s not just the infrastructure but also the internal processes built around service delivery, e.g., provisioning, that are being exposed as a commodity to external customers.

Dan’s Question for Rachel: In your opinion, how much is the cloud a fad versus CIOs really trying to solve a problem?

Rachel: For the practical, roll-up-your-sleeves types of CIOs – those coming up from the engineering ranks – that I talk to, the cloud is real, as opposed to SOA and middleware.

What about “internal” cloud computing – built and maintained by an enterprise versus a third-party provider?

Dan: Cloud computing is done by providers for customers. Certainly there are enterprises that have made internal computing investments, e.g., for publishing, large-scale phone systems, etc - but they were stupid ideas made by companies that have too much money. A better question here is does it make any sense for an enterprise to create their own cloud? While an enterprise can play at it, they can’t do it cost-effectively, not in a way that a third party provider can do it.

Rachel: Many CIOs have “managed-hoster” envy – for things like chargeback and billing that hosters understand a do better. Of course there has been a rise in automation and virtualization tools in the enterprise which may not be as efficient and built for scalability as a hoster can achieve, but what is important is that they are customized/specialized for that business.

Dan: Can you give a specific example of optimization to make it worthwhile for enterprises to do it themselves?

Rachel: One example is sovereignty. The privacy laws around financial and healthcare information are not the same everywhere. Clouds and their geographically-dispersed data centers don’t necessarily have “national” borders. This is definitely a concern for the CIO that has to comply with regulations in their industry around privacy protection, for instance. Another example is security. Dow Chemical does a lot of work via joint ventures and has a need to provide but lock down desktops given to contractors as corporate workspaces. For their level of security, they need to “own” their computing resources.

Dan: But why can’t someone like SunGard provide that as they do for many other large companies?

Rachel: It comes down to a question of trust.

Do people trust their hosting providers?

Dan: Yes. Whether it’s for a content delivery network or collocation, hosting the customers of hosting providers are some of the largest companies in the world in industries like energy and financial services. Give me a case when there was a major security issue with a hosting company. In fact, managed hosting providers usually provide better security than enterprises are capable of.

And a question provided by an attendee from EMC: A few years ago, this would have been a grid discussion. How is the cloud different?

Rachel: Grid computing ended up being applicable only for niches – which I predicted. The real opportunity for everyone else with the cloud only comes up when you combine the kinds of automation tools (originally developed for grid computing) with x86 virtualization.

Dan: I agree. Grid was a niche play. There were very few orgs that needed it and that the economics worked for. There were very few enterprises for whom it made sense to build their own for. The cloud is shared/leveraged versus grid computing. It economically makes sense in a way grid never did.

Dan described the Managed Hosting and colocation sector as “on fire” The sector is humming – incredible growth, outstanding execution, blowing away expectations. I must say, looking back 5 years ago after the tech bubble collapse, I can’t believe how strong the sector bounced back from those very difficult times.

His presentation was focused on a future, and a longer view for the industry. The HTS conference is packed this year with the largest attendance of Datacenter owners, Managed hosting and colocation companies ever to attend this conference.

• Demand steady or increasing in all markets, driven largely by capex constraints and greater awareness and choices.
• Supply is growing more slowly in the past 18 months as the credit crunch has hurt the ability of providers to expand ( it is very hard to get mortgages, loans only on new datacenter projects). Expansion build-out of existing shells is occurring, but very little on spec.
• Demand Growth of 15% in 2008. (Steady and increasing in the out years) However after supply growth peaked at 7.5% in 2007 supply growth now has slowed to 5%
• Dan believes that supply growth will pick back up again in 2011

Conclusions – supply is tight, demand is high and growing…this very good news for the industry.

• Some other trends:
  • The green initiatives are more than just a trend as datacenter owners who don’t figure out how to maximize power efficiency will be painted as villains.
  • Internet traffic and services consumption are linked as Internet traffic growth has been doubling every year (2005-2007)
  • Prediction: 2011 -2012 - internet traffic will get an exaflood – it is coming with a new breed of applications (set to boxes HD Video, games, etc.) that will drive new traffic patterns. Growth driven by consumer broadband + applications (HD video) applications, which in turn will drive demand for Managed Hosting / Colocation Services…

Managed Hosting Services Highlights

• Incredibly fast growth 30%+
• $10 Billion worldwide revenue by end of 2008
• We’ll keep growth pace until at least 2011
• Good news, Dan believes that fears about slowdown in growth are wildly overblown.

Why is managed hosting growing so fast?

• Demographic shifts – new breed of IT employees that embrace outsourcing
• Growth in internet applications (SaaS) The acceptance and growth of browser based applications has been enormous!
• Ambiguity between web hosting and managed hosting has turned positive

Dan’s Key success factors managed hosting and services

• High margin services – and not too many – it is so tempting in our day to day business when a customer comes along and wants to come and give us money for a unique on-off service… at this point the answer has to be no – or do it through a partner.
• High level of support delivery is critical – don’t cut pay in support people or outsource support to save a nickel… what you are selling is support. Keep doing this well or you will head into a bad place… just as examples in retail like Home Depot and others who have struggled with customer service challenges – the whole business starts to slide into the toilet… High levels of support delivers a strong word of mouth buying cycle

Final thoughts, the industry is healthy and will continue to thrive. Customers are looking for the one stop shop, one company that is a trusted advisor to the customer. As customers place more eggs in the Managed Service bucket, the industry will need to tighten-up those SLA’s. Today some parts of the industry have been getting away with loose SLA’s… as customers get more sophisticated and have more on the line, they will become more demanding and require robust multi-component SLAs and back-it –up.

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:

1. An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
3. The attack is DNS server-specific. Only users on the same DNS server are affected.
4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during  times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.

Based on posts and Twitters last night from Dan and the snippits of information I gleaned from fellow Security Twits and bloggers… I think we are all aware that the DNS vulnerability is now out in the open.

The team that discovered the vulnerability was due to release details of the exploit at BlackHat (in 2 weeks). However, someone has reverse-engineered the vulnerability and released the details. The contents, or portions of the exploit were accidentally posted on a very prominent security blog yesterday then quickly removed. (Don’t ask, that’s a whole ‘nother story).

If your DNS server has not been patched, you are vulnerable now. More info on Dan’s (discoverer’s) site .  You’ll notice his 13 > 0 post... letting us know instead of 13 days you now have 0. 

If you haven’t patched your DNS server(s), please see my previous DNS vulnerability post, follow the links included for more information and instructions. Consider yourself now at risk.

# # #

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.

• Poison anybody’s DNS cache
• Expose how the actual exploit works

What it does is check whether your ISP’s DNS server is patched. Plain and simple. It looks for one thing — source port randomization. This does not give away the exploit, it checks for the existence of the sledgehammer fix that prevents the exploit from working.

More specifically, there’s some Javascript code that generates a random hex string which is used to create a URL, e.g. http://6313d97e498e.toorrr.com. Your OS then does a DNS lookup for that unique hostname. Your ISP’s DNS server asks toorrr.com’s DNS server (a server Dan controls) to resolve that funky DNS name to an IP address. It sends a few packets in the process. Dan’s server makes a note of the source port of each request and sends back the webserver’s IP address to your DNS server, which sends it back to you.

Now that you have the IP address, your browser can fetch the results page. The web page is generated dynamically by parsing the hex string out of the URL you requested, using Ajax to fetch the relevant port and TXID data stored on Dan’s server, and printing out a “safe” or “vulnerable” message such as:

Your name server, at 71.243.0.38, appears to be safe.
Requests seen for 6313d97e498e.toorrr.com:

71.243.0.38:45298 TXID=13926
71.243.0.38:45310 TXID=25412
71.243.0.38:45338 TXID=30829
71.243.0.38:45332 TXID=13934
71.243.0.38:45321 TXID=2701

That’s all. Nothing tricky. This particular DNS server is deemed safe because the source port varies from one request to the next.

Come to think of it, those source ports don’t really look that random, do they. For anybody “in the know”, is that amount of randomness sufficient to protect against the attack?

Faced with nearly a month of criticism and questioning, and understanding the persuasive power of a technical peer review, Dan decided to expand the inner circle, so to speak. Rich Mogull arranged a phone call with Tom Ptacek and Dino Dai Zovi so that Dan could spill the beans and let them decide for themselves whether it was spin or substance. Turns out there was substance.

Now we sit around and wait until August 6th to cram into a ballroom with a thousand sweaty conference-goers to hear the juicy details. And Dan’s presentations are usually packed to the brim even when he’s not announcing anything.

In the meantime… how about patching those servers?

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses.

The typical response I heard was “what do you mean, it can’t be reverse engineered? I’ll just look at the diffs!”

In hindsight, after examining the BIND diffs (yes, I did it too) and discussing with colleagues, all most people saw was UDP source port randomization and a better PRNG for generating the transaction ID, the latter of which would appear to be related to Amit Klein’s cache poisoning attack from about a year ago.

What Rich was really saying is that you can reverse engineer the patch until you’re blue in the face, but that won’t reveal the specifics of the vulnerability.

Dan’s blog post this morning appeared to confirm that interpretation:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.

To translate the fix strategy into a more familiar domain, imagine large chunks of Windows RPC went from Anonymous to Authenticated User only, or even all the way to Admin Only. Or wait, just remember Windows XPSP2 :) This is a sledgehammer, by design. It cuts off attack surface, without necessarily saying why. Astonishingly subtle bugs can be easily hidden, or even rendered irrelevant, by a suitably blunt fix.

Nate McFeters appears to think that Tom Ptacek has figured it out. I’m going to go out on a limb and say that Tom didn’t figure anything out yet but still wanted to write a pithy blog post. I think that if Tom had figured it out, he would have written it down privately and posted the SHA-1 hash, as is the trendy thing to do these days.

Speculation aside, the title of Tom’s blog entry, Dan Kaminsky could have made hundreds of thousands of dollars with this DNS flaw!, does make an important point — Dan didn’t sell the details to ZDI, he used his influence and reputation to coordinate a massive vendor patch effort. That’s an admirable move.