The latest Microsoft patch MS08-68 is a great example. It is a problem with NTLM authentication where the attacker can force a client to authenticate to him and the credentials, while not exposed in cleartext, can be relayed to another server or brute forced to obtain the cleartext. This is a very classic crypto protocol vulnerability. It’s not the crypto algorithms that are the problem, but the protocol implementation.

Microsoft recently fixed the problem, perhaps due to the availability of exploit code, the availability of an easy to use Metasploit implementation, or perhaps Microsoft’s changed tolerance for vulnerabilities. We can sum it up as a change in the threat space that made it worth fixing. But make no mistake, this is a very old problem.

News reports have been citing Sir Dystic’s SMBrelay tool, which was published in March, 2001, as the first knowledge of this vulnerability. Eric Shultze who worked at MSRC in 2001 just yesterday is quoted as saying, “I have been holding my breath since 2001 for this patch.” Obviously it is a long time coming. But this wasn’t the first publication of the problem. In 2000, one of my collegues on the research team at @stake, Christian Rioux (aka Dildog) published the telnet NTLM authentication vulnerability.

Rioux’s advisory has a great description of the credential relay and cracking weaknesses. I have talked to him and he says he discovered these problems independently, but he didn’t find them first. Dominique Brezinski published exactly these NTLM vulnerabilities in the SMB protocol in 1996 in a paper titled, “A Weakness in CIFS Authentication”. The earliest reference I can find on the paper on the net is here where it is included in another paper published in 1997. Such is the ad-hoc world of independent security research of 12 years ago which still continues today.

It seems ridiculous that a field like security research, which is so important to the running of modern society is so ad-hoc. Shouldn’t we know who discovered a vulnerability? Shouldn’t all researchers and engineers know about it? More importantly if someone implements a tool that takes advantage of a vulnerability shouldn’t they credit the discoverer? Don’t get me wrong. Implementation takes a lot of work and sometimes makes all the difference in makeing people aware of a security problem. After all when I was at the L0pht our slogan was, “Making the theoretical, practical”. I still think researchers should get credit when credit is due.

The security community has gotten better at documentating our research but I still see instances of independent discovery, misplaced credit, and tools giving no credit to researchers. I hate to say it but getting a bit more academic is in order. Credit is the currency of a researcher and placing it well will reward the right people and we will all benefit.

I’ve often read people who say that we (security, risk management) need to “think like the attacker”.  And when you read this sort of article, that usually alludes to trying to anticipate the tactics an attacker might use to mess with your C, I, or A.  Smart stuff, that, and very useful when architecting security solutions.  But as I was training some folks Monday, I was thinking in the back of my head about Threat Capability (TCap) in FAIR.  As you might know, we like to estimate the capability of a threat to apply some level of “force” against our assets.  This ability to apply force is a byproduct of the attacker’s skills and resources.  And thinking of how an attacker applies skills and resources, I came across another way we might “think” like an attacker.

Traditionally, I’ve thought of “skills” as being a byproduct of the toolset an attacker has.  This mindset probably stems from my time with Penetration Testing teams, where in the process of scoping the  PenTest I would ask our clients to select the level of effort that they wanted us to throw at them.  If a client chose “high” we’d throw every ‘spoit we had at them.  If they chose “low” we’d limit ourselves to a more commonly available toolset.

But while the resources part of TCap is time & materials (money) - the skills are really more than just the toolset.  Skills would include the ability of the attacker to be creative and innovative.    As an example of that innovation from those PenTesting days - when we got a “high” effort request, we would always try to couple that with some “social engineering”-type of attack, or some unique means of delivering an existing exploit.  Our creativity was not necessarily a byproduct of a unique exploit or tool we had, but the process by which we might deliver pre-existing or commonly available exploits.  I remember when we first got ahold of a handful of 32mb thumb drives (hey, 32mb was huge back then) and “dropped” a few in the lobby of a client’s retail space.  The keystroke loggers and phone-home script weren’t new, but using the thumb drive as delivery vehicle certainly was.

So I’ve started to really think about this concept of innovation, and how if “thinking like an attacker” means to be innovative, we ought to do the same.  I’ve been thinking of two main categories of innovation this morning.

INNOVATION

The first I’ll call Technology Innovation.  And by Technology Innovation, I mean some new, unique, “ahead of the curve” technology that an attacker can use against us.  The obvious example of which is a zero-day.  It’s that “high” tool set our PenTesters would use against the clients.  For security departments, this might be the latest security product designed to enhance our ability to P, D, and/or R.

Alternately, we can be creative in the way we deliver (manage) existing technology.  I think of this as Process Innovation.  It’s doing more with what we already have, just like the PenTest team would be creative in the delivery of an existing exploit.

Unfortunately for us - attackers have traditionally had quite a leg up on us in terms of Process Innovation.  It is much easier fro them to be creative, as they are free of political constraints and bureaucracy.  In contrast, when the security industry tries Process Innovation, the results are checklists and “standards”.  It’s committees and consensus.  An extreme example of which might be something like SABSA - a great work if you want to understand some very smart people’s comprehensive understanding of organizational security  - but the “adoption”of which will do very little to help you be innovative in P/D/R.

It’s worth noting that ultimately, this is one reason I don’t like regulatory compliance efforts - they simply serve to prove how mundane your security department is,  wasting valuable resources that could be spent on creating ways to be more effective.

PROCESS INNOVATION AS A SUBSTITUTE FOR TECHNOLOGY INNOVATION

As we come to the close of 2009, some surveys suggest that security spending isn’t horribly impacted yet by the economy (the latest from E&Y points to only 5% of their respondents getting budget cuts).  But if this is a protracted downturn, and because InfoSec is an operational expense, I would expect cash to become more and more difficult to keep.  And regardless if technology spends do slow, I believe it makes sense to think about Process Innovation because I see Process Innovation as a means to increase effectiveness without significant capital expenditures (effectiveness increases because our ability to manage risk has a direct correlation to the amount of risk we have).

The bad news is, of course, that great innovation is hard.  It is R & D.  Failure is usually a pre-requisite to success.

The good news is, our current state is so bad that many of us don’t need to come up with a whizbang new way of reducing software defects in the SDLC as innovation.  Simply inserting a risk analyst into the PMO’s processes might count as a big enough victory. Be cautioned, though,  that if we’re substituting the risk reductions provided by technology acquisition - Process Innovation might actually be even more “expensive” as it requires us to expend political capital.   But there are (forgive the term) innovative ways to spend this political capital.

For example, by taking a second now and figuring out the 3 things that the rest of the organization can do to make your life easier, when that “I need to reduce your budget” talk comes, you can be prepared to negotiate.  Get a political capital “loan” or “investment” from the C-Suite reducing your budget.  Something to the effect of: “I expected this, and am happy to give up my budget.  But if our tolerance for risk hasn’t changed, what I’d like to do is get you to personally back my office on three projects I’ve identified that can reduce our risk without requiring significant capital expenditure.”

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.

One easy, inexpensive way to actually increase your effectiveness in 2009 is to, right now, make a quick review your risk management processes.  As you take a look at how you’re using risk in your organization, I’d ask you to make sure that those processes are providing value for the energy you’re spending.  If they’re not - if you’re not successfully using risk within security and with the other lines of business that you serve - then I’d like to invite you to  come take advantage of RMI’s public training session for 2008, held in Columbus Ohio on December 10-12.  >A brochure is here<.

For three days and $1,995 - you’ll get real answers to many of the commonly voiced frustrations RMI hears concerning risk & risk management.  Answers around measurement, application, communicating risk to other lines of business, heck, basic answers as to what risk is and how to get consistent, defensible values that actually mean something.

Not to mention - Strengthening your Risk Management processes increases your ability to manage risk, which reduces the amount of risk you actually face.

NEW TO THE PUBLIC STUFF!

I’m personally excited because this is the first time that our public training we’ll feature measurement “calibration” exercises and include excel tools to take home and use for quantitative FAIR analysis.  These are benefits we’ve only previously reserved for private client workshops.

I know that FAIR can help you and your organization, but as the sales guys always say, “don’t take my word for it”.  Here’s something we recently received (unsolicited) from the CSO of one of the 10 largest banks in the US, who has had several of his analysts receive this same basic training:

I would like to also add my deep appreciation for what FAIR and RMI has brought to (us) and how we go about the business of risk analysis. We have had some great conversations around risk with the lines of business that have ended very favorably for us.

More information can be found on RMI’s website here:  http://www.riskmanagementinsight.com/12_2008_training.html

Thanks.

Oh and tomorrow, we’ll talk a little bit about quantitative and qualitative risk.

The best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.

On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?