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?

Well, sure you can! There is a little trick now, though.

As part of the move to the Microsoft NAP integration, they’ve broken out the wired and wireless supplicant management into two pieces. Until SP3, all 1X was handled in the Wireless Zero Configuration (WZCSVC) service. The wired 1X supplicant is handled now by a different service and must be manually started.

In Windows XP SP3, the supplicants are each handled separately by these services…
    •  Wireless 802.1X: WZCSVC service
    •  Wired 802.1X: Wired AutoConfig service (DOT3SVC)

Instead of duplicating a lott’a text, you can find detailed instructions for manual and pushed wired 1X configurations on Microsoft KB article 953650.

You can also learn more about Microsoft NAP integration in the Network Access Protection Q&A site.

# # #

I am not sure what it is with Richard Stiennon.  Maybe his mom beat him with a NAC stick when he was young.  Hence his Jack Nicholson looks (more like the Joker in Batman, than Col Jessep in A Few Good Men) and his total disdain for NAC.  In any event Richard never seems to miss a chance to take a pot shot at NAC.  I have fired back and debated him many times on this.  In fact I am convinced that Richard's problem with NAC is that like Uncle Joe, he is just moving a little slow.  Richard still thinks of NAC as Cisco???s network admission control, circa Dec ???03.  He has not gotten up to speed on anything happening with NAC since.  Richard is going to debate NAC with Joel Snyder according to this article by Tim Greene today. My prediction is Snyder by a knockout in 3 rounds or less.

Richard???s latest NAC knock comes on a comment to an excellent article by the Hoff.  Chris takes a bold stand for someone working for a vendor and calls BS on the whole analyst thing (I will write more about that later in this article). Richard being an ex-analyst himself (lets face it, with Richard you can take the man out of the analyst job, but you can???t take the analyst out of the man), takes exception to Hoff???s ???whining??? (Richards words, not mine) and tries to tell Hoff that giving up is not the answer and the way to show up analysts, is to prove them wrong.  Great Richard you try to prove them wrong, when because of what they report you don???t have a market, can???t get any capital and have no visibility.  I guess that is when it is time to move on to the next gig, right? Then Richard has a bad NAC deja vu and feels it necessary to write this:

???Look how easy it is to one up the analyst firms, who as near as I can tell support Network Admission Control universally. Everyone except the folks at Updata Ventures know how seriously flawed NAC is with only one viable market, edu.???

I assume Richard is referring to Updata recently leading the Bradford Networks VC round. But more importantly Richard it is time to call a code red on you and give you the cold hard truth.  Richard the fact is that the edu market is not the only viable market for NAC.  In fact, one of the biggest customers of NAC is the DoD.  That is right Richard at least 3 of the 4 armed forces use NAC in helping to secure their networks. To paraphrase my friend Col Jessep - Richard, you want the truth, you can???t handle the truth!  You sleep securely under the blanket of protection that NAC provides.  If it is good enough to help ???clean the sand??? out of laptops coming home from SWA (that is SouthWest Asia, like in Iraq and Afghanistan, in case you don???t know Richard), it should be good enough for you. Think about that next time you are about to bad mouth NAC.

Let me give you some other truths you may not like Richard.  Why do you think every switch vendor (of which we partner with many of them) is lining up and bringing out NAC solutions?  Why has Microsoft put such a big push on NAP?  Why despite the Luddites like you does NAC still draw crowds at conferences like Interop (ask Joel about that).  Richard we are still signing new major OEM partners.  I am afraid you are the one sadly out of touch on this one Richard.  Just as you are out of touch in missing Hoff???s point in his article.

As to Hoff???s article, as I said I give Chris credit for speaking his mind. I spend an ungodly amount of my time speaking with analysts and trying to ???learn??? from them while at the same time trying to educate them.  I am constantly amazed that so many analysts (and press for that matter) just take a vendors word as gospel. I have seen research reports from analysts big and small, that I am sure did not have any more research done than calling a handful of vendors and listening to their spiel. Too many of these vendors if they do speak to customers, base their findings on such a small sample that it is impossible to have an accurate picture.

Personally, like Hoff says, who watches the watchers is the truth. I would like to see a code of conduct among analysts. I would start by dictating that vendors cannot pay analysts.  Take the payola out of the equation the way they did to the DJ/Radio business in the late 50s. Next analyst reports have to come with metrics to back up the findings. I want to know how many customers they spoke to, how big they were, how they were found, etc.  A vendor giving an analyst a real live???pet??? customer is not real research. I want to know if the customer pays the analyst. It is a dirty business.

Hey let me be clear, I play the game as well as the next guy.  But I agree with Hoff we need to clean up the rules to make the whole analyst thing more fair, viable and valuable.

I am not sure what it is with Richard Stiennon.  Maybe his mom beat him with a NAC stick when he was young.  Hence his Jack Nicholson looks (more like the Joker in Batman, than Col Jessep in A Few Good Men) and his total disdain for NAC.  In any event Richard never seems to miss a chance to take a pot shot at NAC.  I have fired back and debated him many times on this.  In fact I am convinced that Richard's problem with NAC is that like Uncle Joe, he is just moving a little slow.  Richard still thinks of NAC as Cisco’s network admission control, circa Dec ‘03.  He has not gotten up to speed on anything happening with NAC since.  Richard is going to debate NAC with Joel Snyder according to this article by Tim Greene today. My prediction is Snyder by a knockout in 3 rounds or less.

Richard’s latest NAC knock comes on a comment to an excellent article by the Hoff.  Chris takes a bold stand for someone working for a vendor and calls BS on the whole analyst thing (I will write more about that later in this article). Richard being an ex-analyst himself (lets face it, with Richard you can take the man out of the analyst job, but you can’t take the analyst out of the man), takes exception to Hoff’s “whining” (Richards words, not mine) and tries to tell Hoff that giving up is not the answer and the way to show up analysts, is to prove them wrong.  Great Richard you try to prove them wrong, when because of what they report you don’t have a market, can’t get any capital and have no visibility.  I guess that is when it is time to move on to the next gig, right? Then Richard has a bad NAC deja vu and feels it necessary to write this:

“Look how easy it is to one up the analyst firms, who as near as I can tell support Network Admission Control universally. Everyone except the folks at Updata Ventures know how seriously flawed NAC is with only one viable market, edu.”

I assume Richard is referring to Updata recently leading the Bradford Networks VC round. But more importantly Richard it is time to call a code red on you and give you the cold hard truth.  Richard the fact is that the edu market is not the only viable market for NAC.  In fact, one of the biggest customers of NAC is the DoD.  That is right Richard at least 3 of the 4 armed forces use NAC in helping to secure their networks. To paraphrase my friend Col Jessep - Richard, you want the truth, you can’t handle the truth!  You sleep securely under the blanket of protection that NAC provides.  If it is good enough to help “clean the sand” out of laptops coming home from SWA (that is SouthWest Asia, like in Iraq and Afghanistan, in case you don’t know Richard), it should be good enough for you. Think about that next time you are about to bad mouth NAC.

Let me give you some other truths you may not like Richard.  Why do you think every switch vendor (of which we partner with many of them) is lining up and bringing out NAC solutions?  Why has Microsoft put such a big push on NAP?  Why despite the Luddites like you does NAC still draw crowds at conferences like Interop (ask Joel about that).  Richard we are still signing new major OEM partners.  I am afraid you are the one sadly out of touch on this one Richard.  Just as you are out of touch in missing Hoff’s point in his article.

As to Hoff’s article, as I said I give Chris credit for speaking his mind. I spend an ungodly amount of my time speaking with analysts and trying to “learn” from them while at the same time trying to educate them.  I am constantly amazed that so many analysts (and press for that matter) just take a vendors word as gospel. I have seen research reports from analysts big and small, that I am sure did not have any more research done than calling a handful of vendors and listening to their spiel. Too many of these vendors if they do speak to customers, base their findings on such a small sample that it is impossible to have an accurate picture.

Personally, like Hoff says, who watches the watchers is the truth. I would like to see a code of conduct among analysts. I would start by dictating that vendors cannot pay analysts.  Take the payola out of the equation the way they did to the DJ/Radio business in the late 50s. Next analyst reports have to come with metrics to back up the findings. I want to know how many customers they spoke to, how big they were, how they were found, etc.  A vendor giving an analyst a real live“pet” customer is not real research. I want to know if the customer pays the analyst. It is a dirty business.

Hey let me be clear, I play the game as well as the next guy.  But I agree with Hoff we need to clean up the rules to make the whole analyst thing more fair, viable and valuable.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Blogger: Dan Blum

One of our service directors likes to quote William Gibson: “The future is here, it’s just unevenly distributed.”

At Microsoft’s Server and Tools Business (STB) Analyst and Tech Ed conferences last week, I saw a vendor and a user community living in the past, present and future with many unevenly distributed capabilities.

In a session on identity management strategy, for example, Microsoft discussed a variety of initiatives. These range from Card Space (futuristic implementation of user-centric Information Card specifications) to ADFS (present day enterprise federation support, though unfortunately lacking full SAML capabilities) to self-service password reset exposed through Office (decidedly backward-looking as this functionality has been available from many vendors through browsers for many years).

In another session on rights management and SharePoint, Microsoft highlighted the opportunity to configure SharePoint libraries to automatically apply Active Directory Rights Management Services protections on downloaded documents. Digital rights management (DRM) is controversial and no strong guarantor of confidentiality. Nonetheless, it is a  way to put futuristic self-protecting wrappers on content so as to prevent its accidental leakage or misuse by honest, cooperative users. Because it’s not something that can resist certain types of malicious attackers, many security professionals look down their noses at rights management. Nonetheless, preventing accidental misuse of enterprise information is a big part of the space. It was clear from the number of people in the room asking intelligent questions suggesting realistic expectations that customers see potential value for this technology.

Finally, I was impressed by a presentation on IPSec, PKI and NAP by a Brazilian university IT manager named Rodrigo Imaginario. Starting three years ago, the university combined its student and administrative networks into a single network. Yet servers running ERP and containing administrative content (such as grading information) need to be protected from a subset of students going through their hacking stage. Imaginario implemented a logical security zoning overlay on top of the network using IPSEC in Windows. In the restricted zone, servers only accept connections from Kerberos-authenticated IPSEC clients in the administrative domain. Today, the authentication is being upgraded to use PKI for secure, all campus wireless networking. Imaginario indicated the university took the Windows IPSEC route approach because no additional software had to be purchased. Configuration was difficult, he said, but will get easier with Windows Server 2008. This sounds like an idea whose time has come.

Blogger: Dan Blum

One of our service directors likes to quote William Gibson: ???The future is here, it???s just unevenly distributed.???

At Microsoft???s Server and Tools Business (STB) Analyst and Tech Ed conferences last week, I saw a vendor and a user community living in the past, present and future with many unevenly distributed capabilities.

In a session on identity management strategy, for example, Microsoft discussed a variety of initiatives. These range from Card Space (futuristic implementation of user-centric Information Card specifications) to ADFS (present day enterprise federation support, though unfortunately lacking full SAML capabilities) to self-service password reset exposed through Office (decidedly backward-looking as this functionality has been available from many vendors through browsers for many years).

In another session on rights management and SharePoint, Microsoft highlighted the opportunity to configure SharePoint libraries to automatically apply Active Directory Rights Management Services protections on downloaded documents. Digital rights management (DRM) is controversial and no strong guarantor of confidentiality. Nonetheless, it is a  way to put futuristic self-protecting wrappers on content so as to prevent its accidental leakage or misuse by honest, cooperative users. Because it???s not something that can resist certain types of malicious attackers, many security professionals look down their noses at rights management. Nonetheless, preventing accidental misuse of enterprise information is a big part of the space. It was clear from the number of people in the room asking intelligent questions suggesting realistic expectations that customers see potential value for this technology.

Finally, I was impressed by a presentation on IPSec, PKI and NAP by a Brazilian university IT manager named Rodrigo Imaginario. Starting three years ago, the university combined its student and administrative networks into a single network. Yet servers running ERP and containing administrative content (such as grading information) need to be protected from a subset of students going through their hacking stage. Imaginario implemented a logical security zoning overlay on top of the network using IPSEC in Windows. In the restricted zone, servers only accept connections from Kerberos-authenticated IPSEC clients in the administrative domain. Today, the authentication is being upgraded to use PKI for secure, all campus wireless networking. Imaginario indicated the university took the Windows IPSEC route approach because no additional software had to be purchased. Configuration was difficult, he said, but will get easier with Windows Server 2008. This sounds like an idea whose time has come.

No not Larry Ellison. StillSecure's oracle of NAC, Dave Greenstein, Chief Security Architect at StillSecure. I write and speak a lot about NAC, but Dave actually lives NAC.  He led our development team that developed Safe Access.  Now he is way out in front researching and designing the next generations of Safe Access and our other products.  Dave doesn't comment on my posts a lot. I am always bugging him to start his own blog.  The best I get is occasionally he will write an article or white paper.  So when he commented on Joel Snyder's article on NAC and my comments, I figured it would make sense to give it some main column play.  Here is what Dave had to say:

In order to use NAP you only need server 2008 for the NPS... Your domain and AD can still be 2003 so I think adoption of NAP will be faster for that reason. Also, XP SP3, which has NAP capabilities, adoption should be pretty fast compared to Vista.

On ACLs, I agree with Joel that ACLs are a great way to do things... But not with routers and DHCP enforcement. If you have HP switches or Extreme Switches then you can do dynamic ACLs per port. Similar to how you assign a VLAN via RADIUS attributes, you can assign ACLs for that port in addition to assigning a VLAN. This is great if you have the right switches. It helps protect the other endpoints within a quarantine VLAN and adds an extra layer of security. Cisco switches do not have this capability unless you’re running Cisco NAC and a Cisco ACS server (ugh). So, buy HP and Extreme switches!

What’s more likely to slow NAP adoption down is it’s total lack of endpoint administration... How do you keep track of what endpoints have which problems? How do you get an endpoint on the network in an emergency even if it has an issue? How do you update the SHAs on your thousands of endpoints? There are a whole host of issues not solved by NAP that make it unusable. That’s where products like StillSecure Safe Access come in.

BTW, if you think Dave makes some sense here and would like to hear more from him, let me know and I will coax him into writing some more! I should also add that I twisted his arm to give Safe Access a plug at the end there. Thanks Dave!