Rational Survivability

Network Security is Dead...It's All About the Host.

No, not entirely as it's really about the data, but I had an epiphany last week. 

I didn't get any on me, but I was really excited about the -- brace yourself -- future of security in a meeting I had with Microsoft.  It reaffirmed my belief that while some low-hanging security fruit will be picked off by the network, the majority of the security value won't be delivered by it.

I didn't think I'd recognize just how much of it -- in such a short time -- will ultimately make its way back into the host (OS,) and perhaps you didn't either.

We started with centralized host-based computing, moved to client-server.  We've had Web1.0, are in the  beginnings of WebX.0 and I ultimately believe that we're headed back to a centralized host-based paradigm now that the network transport is fast, reliable and cheap.

That means that a bunch of the stuff we use today to secure the "network" will gravitate back towards the host. I've used Scott McNealy's mantra as he intended it to in order to provide some color to conversations before, but I'm going to butcher it here. 

While I agree that in abstract the "Network is the Computer," in order to secure it, you're going to have to treat the "network" like an OS...hard to do.   That's why I think more and more security will make its way back to the actual "computer" instead.

So much of the strategy linked to large security vendors sees an increase in footprint back on the host.  It's showing back up there today in the guise of AV, HIPS, configuration management, NAC and Extrusion Prevention, but it's going to play a much, much loftier role as time goes on as the level of interaction and interoperability must increase.  Rather than put 10+ agents on a box, imagine if that stuff was already built in?

Heresy, I suppose.

I wager that the "you can't trust the endpoint" and "all security will make its way into the switch" crowds will start yapping on this point, but before that happens, let me explain...

The Microsoft Factor

I was fortunate enough to sit down with some of the key players in Microsoft's security team last week and engage in a lively bit of banter regarding some both practical and esoteric elements of where security has been, is now and will be in the near future. 

On the tail of Mr. Chambers' Interop keynote, the discussion was all abuzz regarding collaboration and WebX.0 and the wonders that will come of the technology levers in the near future as well as the, ahem, security challenges that this new world order will bring.  I'll cover that little gem in another blog entry.

Some of us wanted to curl up into a fetal position.  Others saw a chance to correct material defects in the way in which the intersection of networking and security has been approached.  I think the combination of the two is natural and healthy and ultimately quite predictable in these conversations.

I did a bit of both, honestly.

As you can guess, given who I was talking to, much of what was discussed found its way back to a host-centric view of security with a heavy anchoring in the continued evolution of producing more secure operating systems, more secure code, more secure protocols and strong authentication paired with encryption.

I expected to roll my eyes a lot and figured that our conversation would gravitate towards UAC and that a bulk-helping of vapor functionality would be dispensed with the normal disclaimers urging "...when it's available one day" as a helping would be ladled generously into the dog-food bowls the Microsofties were eating from.

I am really glad I was wrong, and it just goes to show you that it's important to consider a balanced scorecard in all this; listen with two holes, talk with one...preferably the correct one ;)

I may be shot for saying this in the court of popular opinion, but I think Microsoft is really doing a fantastic job in their renewed efforts toward improving security.  It's not perfect, but the security industry is such a fickle and bipolar mistress -- if you're not 100% you're a zero.

After spending all this time urging people that the future of security will not be delivered in the network proper, I have not focused enough attention on the advancements that are indeed creeping their way into the OS's toward a more secure future as  this inertia orthogonally reinforces my point.

Yes, I work for a company that provides network-centric security offerings.  Does this contradict the statement I just made?  I don't think so, and neither did the folks from Microsoft.  There will always be a need to consolidate certain security functionality that does not fit within the context of the host -- at least within an acceptable timeframe as the nature of security continues to evolve.  Read on.

The network will become transparent.  Why?

In this brave new world, mutually-authenticated and encrypted network communications won't be visible to the majority of the plumbing that's transporting it, so short of the specific shunts to the residual overlay solutions that will still be present to the network in forms of controls that will not make their way to the host, the network isn't going to add much security value at all.

The Jericho Effect

What I found interesting is that I've enjoyed similar discussions with the distinguished fellows of the Jericho Forum wherein after we've debated the merits of WHAT you might call it, the notion of HOW "deperimeterization," "reperimeterization," (or my favorite) "radical externalization,"  weighs heavily on the evolution of security as we know it.

I have to admit that I've been a bit harsh on the Jericho boys before, but Paul Simmonds and I (or at least I did) came to the realization that my allergic reaction wasn't to the concepts at hand, but rather the abrasive marketing of the message.  Live and learn.

Both sets of conversations basically see the pendulum effect of security in action in this oversimplification of what Jericho posits is the future of security and what Microsoft can deliver -- today:

Take a host with a secured OS, connect it into any network using whatever means you find
appropriate, without regard for having to think about whether you're on the "inside" or "outside." Communicate securely, access and exchange data in policy-defined "zones of trust" using open, secure, authenticated and encrypted protocols.

If you're interested in the non-butchered more specific elements of the Jericho Forum's "10 Commandments," see here.

What I wasn't expecting in marrying these two classes of conversation is that this future of security is much closer and notably much more possible than I readily expected...with a Microsoft OS, no less.   In fact, I got a demonstration of it.  It may seem like no big deal to some of you, but the underlying architectural enhancements to Microsoft's Vista and Longhorn OS's are a fantastic improvement on what we have had to put up thus far.

One of the Microsoft guys fired up his laptop with a standard-issue off-the-shelf edition of Vista,  authenticated with his smartcard, transparently attached to the hotel's open wireless network and then took me on a tour of some non-privileged internal Microsoft network resources.

Then he showed me some of the ad-hoc collaborative "People Near Me" peer2peer tools built into Vista -- same sorts of functionality...transparent, collaborative and apparently quite secure (gasp!) all at the same time.

It was all mutually authenticated and encrypted and done so transparently to him.

He didn't "do" anything; no VPN clients, no split-brain tunneling, no additional Active-X agents, no SSL or IPSec shims...it's the integrated functionality provided by both IPv6 and IPSec in the NextGen IP stack present in Vista.

And in his words "it just works."   Yes it does.

He basically established connectivity and his machine reached out to an reachable read-only DC (after auth. and with encryption) which allowed him to transparently resolve "internal" vs. "external" resources.  Yes, the requirements of today expect that the OS must still evolve to prevent exploit of the OS, but this too shall become better over time.

No, it obviously doesn't address what happens if you're using a Mac or Linux, but the pressure will be on to provide the same sort of transparent, collaborative and secure functionality across those OS's, too.

Allow me my generalizations -- I know that security isn't fixed and that we still have problems, but think of this as a half-glass full, willya!?

One of the other benefits I got form this conversation is the reminder that as Vista and Longhorn default to IPv6 natively (they can do both v4&v6 dynamically,) as enterprises upgrade, the network hardware and software (and hence the existing security architecture) must also be able to support IPv6 natively.  It's not just the government pushing v6, large enterprises are now standardizing on it, too.

Here are some excellent links describing the Nextgen IP stack in Vista, the native support for IPSec (goodbye VPN market,) and IPv6 support.

Funny how people keep talking about Google being a threat to Microsoft.  I think that the network giants like Cisco might have their hands full with Microsoft...look at how each of them are maneuvering.

/Hoff
{ Typing this on my Mac...staring @ a Vista Box I'm waiting to open to install within Parallels ;) }

On Flying Pigs, DNSSEC, and embedded versus overlaid security...

I found Thomas Ptacek's comments regarding DNSSEC deliciously ironic not for anything directly related to secure DNS, but rather a point he made in substantiating his position regarding DNSSEC while describing the intelligence (or lack thereof) of the network and application layers.

This may have just been oversight on his part, but it occurs to me that I've witnessed something on the order of a polar magnetic inversion of sorts.  Or not.  Maybe it's the coffee.  Ethiopian Yirgacheffe does that to me.

Specifically, Thomas and I have debated previously about this topic and my contention is that the network plumbing ought to be fast, reliable, resilient and dumb whilst elements such as security and applications should make up a service layer of intelligence running atop the pipes. 

Thomas' assertions focus on the manifest destiny that Cisco will rule the interconnected universe and that security, amongst other things, will -- and more importantly should -- become absorbed into and provided by the network switches and routers.

While Thomas' arguments below are admittedly regarding the "Internet" versus the "Intranet," I maintain that the issues are the same.  It seems that his statements below which appear to endorse the "...end-to-end argument in system design" regarding the "...fundamental design principle of the Intenet" are at odds with his previous aspersions regarding my belief.  Check out the bits in red.

Here's what Thomas said in "A Case Against DNSSSEC (A Matasano Miniseries):

...You know what? I don’t even agree in principle. DNSSEC is a bad thing, even if it does work.

How could that possibly be?

It violates a fundamental design principle of the Internet.

Nonsense. DNSSEC was designed and endorsed by several of the architects of the Internet. What principle would they be violating?

The end-to-end argument in system design. It says that you want to keep the Internet dumb and the applications smart. But DNSSEC does the opposite. It says, “Applications aren’t smart enough to provide security, and end-users pay the price. So we’re going to bake security into the infrastructure.”

I could have sworn that the bit in italics is exactly what Thomas used to say.  Beautiful.  If, Thomas truly agrees with this axiom and that indeed the Internet (the plumbing) is supposed to be dumb and applications (service layer) smart, then I suggest he should revisit his rants regarding how he believes the embedding security in the nework is a good idea since it invalidates the very "foundation" of the Internet.

I wonder what that'll do internal networks? 

That's all.  CSI is on.

/Hoff

(Written @ Home drinking Yirgacheffe watching UFC re-runs)

A Funny Thing Happened at the Museum Of Science...

One of the benefits of living near Boston is the abundance of amazing museums and historic sites available for visit within 50 miles from my homestead.

This weekend the family and I decided to go hit the Museum of Science for a day of learning and fun.

As we were about to leave, I spied an XP-based computer sitting in the corner of one of the wings and was intrigued by the sign on top of the monitor instructing any volunteers to login:

 

Then I noticed the highlighted instruction sheet taped to the wall next to the machine:

 

If you're sharp enough, you'll notice that the sheet instructs the volunteer how to remember their login credentials -- and what their password is ('1234') unless they have changed it!

"So?" you say, "That's not a risk.  You don't have any usernames!"

Looking to the right I saw a very interesting plaque.  It contained the first and last names of the museum's most diligent volunteers who had served hundreds of hours on behalf of the Museum.  You can guess where this is going...

I tried for 30 minutes to find someone (besides Megan Crosby on the bottom of the form) to whom I could suggest a more appropriate method of secure sign-on instructions.  The best I could do was one of the admission folks who stamped my hand upon entry and ended up with a manager's phone number written on the back of a stroller rental slip.

(In)Security is everywhere...even at the Museum of Science.  Sigh.

/Hoff

NAC Attack: Why NAC doesn't work and SN(i)F doesn't, either...alone

I have to admit that when I read Alan Shimel's blog entry whereby he calls out Richard Stiennon on his blog entries titled "Don't Bother with NAC" and "Network Admission Control is a Blind Alley," I started licking my chops as I couldn't wait to jump in and take some time to throw fuel on the fire.  Of course, Mike Rothman already did that, but my goal in life is to be more inflammatory than he is, so let the dousing begin!

I've actually been meaning to ask for clarification on some points from both of these fellas, so no better time than the present. 

Now, given the fact that I know all of the usual suspects in this debate, it's odd that I'm actually not siding with any of them.  In fact, I sit squarely in the middle because I think that in the same breath both Richard and Alan are as wrong as they are right.  Mike is always right (in his own mind) but rather than suggest there was a KO here, let's review the tape and analyze the count before we go to the scorecards for a decision.

This bout is under the jurisdiction of and sanctioned by the Nevada Gaming Commission and brought to you by FUD -- the offical supplier of facts on the Internet. ;)

Tale of the tape:

Richard Stiennon:

1. Richard Stiennon highlighted some of Ofir Arkin's NAC "weaknesses" presented at Black Hat and suggests that NAC is a waste of time based upon not only these technical deficiencies but also that the problems that NAC seeks to solve are already ameliorated by proper patching as machines "...that are patched do not get infected."
2. Somewhat confusingly he follows on with the statement based upon the previous statement that "The fear of the zero-day worm or virus has proved ungrounded. And besides, if it is zero-day, then having the latest DAT file from Symantec does you no good."
3. Richard suggests that integrating host-based and network-based security is a bad idea and that the right thing to do is based upon  "de-coupling network and host-based security. Rather than require them to work together let them work alone."
4. Ultimately he expects that the rest of the problems will be fixed with a paradigm which he has called Secure Network Fabric. 
5. Richard says the right solution is the concept he calls "Secure Network Fabric (SNF)" wherein "...network security solutions will not require switches, routers, laptops, servers, and vendors to work in concert with each other" but rather "...relies most heavily on a switched network architecture [which] usually involve[s] core switches as well as access switches."
6. SNF relies on the VLANs that "...would be used to provide granularity down to the device-level where needed. The switch enforces policy based on layer 2 and 3 information. It is directed by the NetFlow based behavior monitoring system.
7. Richard has talked about the need for integrating intelligent IDP (Intrusion Detection and Prevention) systems coupled with NBA/NBAD (Network Behavioral Analysis/Network Behavioral Anomaly Detection) and switching fabric for quite some time and this integration is key in SNF functionality.
   
   
8. Furthermore, Richard maintains that relying on the endpoint to report its health back to the network and the mechanisms designed to allow admission is a bad idea and unnecessary.
9. Richard maintains that there is a difference between "Admission Control" and "Access Control" and sums it up thusly: "To keep it simple just remember: Access Control, good. Admission Control, bad."

Alan Shimel:

1. Alan freely admits that there are some technical "issues" with NAC such as implementation concerns with DHCP, static IP addresses, spoofed MAC addresses, NAT, etc.
2. Alan points out that Richard did not mention that Ofir Arkin also suggests that utilizing a NAC solution based upon 802.1x is actually a robust solution.
3. Alan alludes to the fact that people deploy NAC for various reasons and (quoting from a prior article) "...an important point is that NAC is not really geared towards stopping the determined hacker, but rather the inadvertant polluter."  Hence I believe he's saying that 802.1x is the right NAC solution to use if you can as it solves both problems, but that if latter is not your reason for deploying NAC, then the other issues are not as important.
4. Alan points to the fact that many of Richard's references are quite dated (such as the comments describing the 2003 acquisition of TippingPoint by 3Com as "recent" and that ultimately SNF is a soapbox upon which Richard can preach his dislike of NAC based upon "...trusting the endpoint to report its health."
5. De-coupling network and host-based endpoint security is a bad idea, according to Alan, because you miss context and introduce/reinforce the information silos that exist today rather than allow for coordinated, consolidated and correlated security decisions to be made.
6. Alan wishes to purchase Pot (unless it's something better) from Richard and go for a long walk on the shore because Mr. Stiennon has "the good stuff" in his opinion since Richard intimates that patching and configuration management have worked well and that zero-day attacks are a non-entity.
7. Alan suggests that the technology "...we used to call behvior based IPS's" which will pass "...to the switch to enfore policy" is ultimately "another failed technology" and that the vendors Richard cites in his BAIPS example (Arbor, Mazu, etc.) are all "...struggling in search of a solution for the technology they have developed."
8. Alan maintains that the SNF "dream" lacks the ability to deliver any time soon because by de-coupling host and network security, you are hamstrung by the lack of "...context, analytics and network performance."
9. Finally, Alan is unclear on the difference between Network Access Control (good) and Network Admission Control (bad.)

So again, I maintain that they are both right and both wrong.  I am the Switzerland of NAC/SNF! 

I'll tell you why -- not in any particular order or with a particular slant...

(the bout has now turned from a boxing context to a three man Mixed-Martial-Arts Octagon cage-match!  I predict a first round submission via tap-out):

1. Firstly, endpoint and network security MUST be deployed together and ultimately communicate with one another to ultimately effect the most visible, transparent, collaborative and robust defense-in-depth security strategy available.  Nobody said it's a 50/50 percentage, but having one without the other is silly.  There are things on endpoints that you can't discover over a network.  Not having some intelligence about the endpoint means the network cannot possibly determine as accurately the "intent" of the packets spewing from it.
2. Network Admission Control solutions don't necessarily blindly trust the endpoint -- whether agent or agentless, the NAC controller takes not only what the host "reports" but also how it "responds" to active probes of its state.  While virtualization and covert rootkits have the capability to potentially hide from these probes, suggesting that an endpoint passes these tests does not mean that the endpoint is no longer subject to any other control on the network...
3. Once Network Admission Control is accomplished, Network Access Control can be applied (continuously) based upon policy and behavioral analysis/behavioral anomaly detection.
4. Patching doesn't work -- not because the verb is dysfunctional -- but because the people who are responsible for implementing it are.  So long as these systems are not completely automated, we're at risk.
5. Zero day exploits are not overblown -- they're getting more surgically targeted and the remediation cycles are too long.  Network-based solutions alone cannot protect against anomalies that are not protocol or exploit/vulnerability signature driven...if the traffic patterns are not abnormal, the flags are OK and the content seemingly benign going to something "normal," it *will* hit the target.
6. You'll be suprised just how immature many of the largest networks on this planet are in terms of segmentation via VLANs and internal security...FLAT, FLAT, FLAT.  Scary stuff.  If you think the network "understands" the data that is transported over it or can magically determine what is more important by asset/risk relevance, I too would like some of that stuff you're smoking.
7. Relying on the SNF concept wherein the "switch enforces policy based on layer 2 and 3 information," and "is directed by the NetFlow based behavior monitoring system" is wholly shortsighted.  Firstly layer 2/3 information is incredibly limited since most of the attacks today are application-level attacks and NOT L2/L3 and Netflow data (even v9) is grossly coarse and doesn't provide the context needed to effectively determine these sorts of incursions.  That's why NetFlow today is mostly used in DDoS activities -- because you see egregiously spiked usage and/or traffic patterns.  It's a colander not a sieve.
8. Most vendors today are indeed combining IDP functionality with NBA/D to give a much deeper and contextual awareness across the network.  More importantly, big players such as ISS and Cisco include endpoint security and NAC (both "versions") to more granularly define, isolate and ameliorate attacks.  It's not perfect, but it's getting better.
9. Advances in BA/NBA/NBAD are coming (they're here, actually) and it will produce profound new ways of managing context and actionable intelligence when combined with optimized compute and forwarding engines which are emerging at the same time.   They will begin, when paired with network-wide correlation tools, to solve the holy trinity of issues: context, analytics and performance.
10. Furthermore, companies such as ISS and StillSecure (Alan's company) have partnered with switch vendors to actually do just what Richard suggests in concept.  Interestingly enough, despite the new moniker, the SNF concept is not new -- Cisco's SDN (albeit without NAC) heavily leverages the concepts described above from an embedded security perspective and overlay security vendors such as ISS and Crossbeam also have solutions (in POC or available) in this area.
11. Let's be honest, just like the BA vendors Alan described, NAC is in just the same position -- "struggling in search of a solution for the technology they have developed."  There are many reasons for deploying NAC: Pre and Post-inspection/Quarantine/Remediation and there are numerous ways of doing it: agent-based/agentless/in-line/out-of-band... The scary thing is with so many vendors jumping in here and the 800 pound Gorilla (Cisco) even having trouble figuring it out, how long before NAC becomes a feature and not a market?  Spending a bunch of money on a solution (even without potential forklifts) to not "... stop the determined hacker, but rather the inadvertant polluter" seems a little odd to me.  Sure it's part of a well defined network strategy, but it ain't all that yet, either.
12. With Cisco's CSO saying things like "The concept of having devices join a network in which they are posture-assessed and given access to the network in a granular way is still in its infancy" and even StillSecure's CTO (Mitchell Ashley) saying "...but I think those interested in NAC today are really trying to avoid infection spread by an unsuspecting network user rather than a knowledgeable intruder" it's difficult to see how NAC can be considered a core element of a network security strategy WITHOUT something like SNF.

So, they're both right and both wrong.  Oh, and by the way, Enterprise and Provider-class UTM solutions are combining ALL of this in a unified security service layer... FW, IDP, Anti-X, NBA(D) and SNF-like foundations.

[Tap before it breaks, boys!]

We need NAC and we need SNF and I've got the answer:

1. Take some of Richard's "good stuff"
2. Puff, puff, pass
3. Combine some of Alan's NAC with Richard's SNF
4. Stir
5. Bake for 30 minutes and you have one F'N (good) SNAC
   (it's an anagram, get it!)

There you have it.

Chris

More debate on SSO/Authentication

Mike Farnum and I continue to debate the merits of single-sign-on and his opinion that deploying same makes you more secure. 

Rothman's stirring the point saying this is a cat fight.  To me, it's just two dudes having a reasonable debate...unless  you know something I don't [but thanks, Mike R. because nobody would ever read my crap unless you linked to it! ;)]

Mike's position is that SSO does make you more secure and when combined with multi-factor authentication adds to defense-in-depth.   

It's the first part I have a problem with, not so much the second and I figured out why.  It's the order of the things that got me bugged when Mike said the following:

But here’s s [a] caveat, no matter which way you go: you really need a single-signon solution backing up a multi-factor authentication implementation. 

If he had suggested that multi-factor authentication should back up an SSO solution, I'd agree.  But he didn't and he continues not to by maintaing (I think) that SSO itself is secure and SSO + multi-factor authentication is more secure.

My opinion is a little different.  I believe that strong authentication *does* add to defense-in-depth, but SSO adds only depth of complexity, obfuscation and more moving parts, but with a single password on the front end.  More on that in a minute.

Let me clarify a point which is that I think from a BUSINESS and USER EXPERIENCE perspective, SSO is a fantastic idea.  However, I still maintain that SSO by itself does not add to defense-in-depth (just the opposite, actually) and does not, quantifiably, make you more "secure."  SSO is about convenience, ease of use and streamlined efficiency.

You may cut down on password resets, sure.  If someone locks themselves out, however, most of the time resets/unlocks involve then self-service portals or telephone resets which are just as prone to brute force and social engineering as calling the helpdesk, but that's a generalization and I would rather argue through analogy... ;)

Here's the sticky part of why I think SSO does not make you more secure, it merely transfers the risks involved with passwords from one compartment to the next. 

While that's a valid option, it is *very* important to recognize that managing risk does not, by definition, make you more secure...sometimes managing risk means you accept or transfer it.  It doesn't mean you've solved the problem, just acknowledged it and chosen to accept the fact that the impact does not justify the cost involed in mitigating it. ;)

SSO just says "passwords are a pain in the ass to manage. I'm going to find a better solution for managing them that makes my life easier."  SSO Vendors claim it makes you more secure, but these systems can get very complex when implementing them across an Enterprise with 200 applications, multiple user repositories and the need to integrate or federate identities and it becomes difficult to quantify how much more secure you really are with all of these moving parts.

Again, SSO adds depth (of complexity, obfuscation and more moving parts) but with a single password on the front end.  Complex passwords on the back-end managed by the SSO system don't do you a damned good when some monkey writes that single password that unlocks the entire enterprise down on a sticky note.

Let's take the fancy "SSO" title out of the mix for a second and consder today's Active Directory/LDAP proxy functions which more and more applications tie into.  This relies on a single password via your domain credentials to authenticate directly to an application.  This is a form of SSO, and the reality is that all we're doing when adding on an SSO system is supporting web and legacy applications that can't use AD and proxying that function through SSO.

It's the same problem all over again except now you've just got an uber:proxy.

Now, if you separate SSO from the multi-factor/strong authentication argument, I will agree that strong authentication (not necessarily multi-factor -- read George Ou's blog) helps mitigate some of the password issue, but they are mutually exclusive.

Maybe we're really saying the same thing, but I can't tell.

Just to show how fair and balanced I am (ha!) I will let you know that prior to leaving my last employ, I was about to deploy an Enterprise-wide SSO solution.  The reason?  Convenience and cost.

Transference of risk from the AD password policies to the SSO vendor's and transparency of process and metrics collection for justifying more heads.    It wasn't going to make us any more secure, but would make the users and the helpdesk happy and let us go figure out how we were going to integrate strong authentication to make the damned thing secure.

Chris

On two-factor authentication and Single-Sign-On...

I've been following with some hand-wringing the on-going debates regarding the value of two-factor and strong authentication systems in addition to, or supplementing, traditional passwords.

I am very intent on seeing where the use cases that best fit strong authentication ultimately surface in the long term.  We've seen where they are used today, but Icub wonder if we, in the U.S., will ever be able to satisfy the privacy concerns raised by something like a smart-card-based national ID system to recognize the benefits of this technology. 

Today, we see multi-factor authentication utilized for:  Remote-access VPN, disk encryption, federated/authenticated/encrypted identity management and access control, the convergence of physical and logical/information security...

[Editor's Note: George Ou from ZDNet just posted a really intersting article on his blog relating how banks are "...cheating their way to [FFIEC] web security guidelines" by just using multiple instances of "something the user knows" and passing it off as "multifactor authentication."  His argument regarding multi-factor (supplemental) vs. strong authentication is also very interesting.]

I've owned/implemented/sold/evaluated/purchased every kind of two-factor / extended-factor / strong authentication system you can think of:

• Tokens
• SMS Messaging back to phones
• Turing/image fuzzing
• Smart Cards
• RFID
• Proximity
• Biometrics
• Passmark-like systems

...and there's very little consistency in how they are deployed, managed and maintained.  Those pesky little users always seemed to screw something up...and it usually involved losing something, washing something, flushing something or forgetting something.

The technology's great, but like Chandler Howell says there are a lot of issues that need reconsideration when it comes to their implementation that go well beyond what we think of today as simply the tenents of "strong" authentication and the models of trust we surround them with:

So here are some Real World goals I suggest we should be looking at.

1. Improved authentication should focus on (cryptographically) strong Mutual Authentication, not just improved assertion of user Identity. This may mean shifts in protocols, it may mean new technology. Those are implementation details at this level.
2. We need to break the relationship between location & security assumption, including authentication. Do we need to find a replacement for “somewhere you are?” And if so, is it another authentication factor?
3. How does improved authentication get protection closer to the data? We’re still debating types of deadbolts for our screen door rather than answering this question.

All really good points, and ones that I think we're just at the tip of discussing. 

Taking these first steps is an ugly and painful experience usually, and I'd say that the first footprints planted along this continuum do belong to the token authentication models of today.  They don't work for every application and there's a lack of cross-pollinization when you use one vendor's token solution and wish to authenticate across boundaries (this is what OATH tries to solve.)

For some reaon, people tend to evaluate solutions and technology in a very discrete and binary modality: either it's the "end-all, be-all, silver bullet" or it's a complete failure.  It's quite an odd assertion really, but I suppose folks always try to corral security into absolutes instead of relativity.

That explains a lot.

At any rate, there's no reason to re-hash the fact that passwords suck and that two-factor authentication can provide challenges, because I'm not going to add any value there.  We all understand the problem.  It's incomplete and it's not the only answer. 

Defense in depth (or should it be wide and narrow?) is important and any DID strategy of today includes the use of some form of strong authentication -- from the bowels of the Enterprise to the eCommerce applications used in finance -- driven by perceived market need, "better security," regulations, or enhanced privacy.

However, I did read something on Michael Farnum's blog here that disturbed me a little.  In his blog, Michael discusses the pros/cons of passwords and two-factor authentication and goes on to introduce another element in the Identity Management, Authentication and Access Control space: Single-Sign-On.

Michael states:

But here’s s [a] caveat, no matter which way you go: you really need a single-signon solution backing up a multi-factor authentication implementation.  This scenario seems to make a lot of sense for a few reasons:

• It eases the administrative burdens for the IT department because, if implemented correctly, your password reset burden should go down to almost nil
• It eases (possibly almost eliminates) password complaints and written down passwords
• It has the bonus of actually easing the login process to the network and the applications

I know it is not the end-all-be-all, but multi-factor authentication is definitely a strong layer in your defenses.  Think about it.

Okay, so I've thought about it and playing Devil's Advocate, I have concluded that my answer is: "Why?"

How does Single-Sign-On contribute to defense-in-depth (besides adding another hyphenated industry slang) short of lending itself to convenience for the user and the help desk.  Security is usually 1/convenience, so by that algorithm it doesn't.

Now instead of writing down 10 passwords, the users only need one sticky -- they'll write that one down too!

Does SSO make you more secure?  I'd argue that in fact it does not -- not now that the user has a singular login to every resource on the network via one password. 

Yes, we can shore that up with a strong-authentication solution, and that's a good idea, but I maintain that SA and SSO are mutually exclusive and not a must.  The complexity of these systems can be mind boggling, especially when you consider the types of priviledges these mechanisms often require in order to reconcile this ubiquitous access.  It becomes another attack surface.

There's a LOT of "kludging" that often goes on with these SSO systems in order to support web and legacy applications and in many cases, there's no direct link between the SSO system, the authentication mechanism/database/directory and ultimately the control(s) protecting as close to the data as you can.

This cumbersome process still relies on the underlying OS functionality and some additional add-ons to mate the authentication piece with the access control piece with the encryption piece with the DRM piece...

Yet I digress.

I'd like to see the RISKS of SSO presented along with the benefits if we're going to consider the realities of the scenario in terms of this discussion.

That being said, just because it's not the "end-all-be-all" (what the hell is with all these hyphens!?) doesn't mean it's not helpful... ;)

Chris