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?

• The user is logged on as a local administrator
• The user, or some code the user runs, enables IP routing

By default, all forms of IP routing (including NIC bridging) are disabled. Only local administrators (or group policy) can enable them. So the risk, actually, is minimal.

If you have a stroll through group policy, you'll discover this setting: "Prohibit installation and configuration of Network Bridge on your DNS domain network" (more here, here). This setting allows you turn a computer into a router that bridges two networks. The bridging works only when one of the interfaces is in the same DNS namespace it was in when the bridge setting was enabled, and it works only when the Windows firewall is disabled on both interfaces (never a good idea). Additionally, regardless of the group policy setting, the function doesn’t even appear as an option when the user is logged in as a non-admin. The group policy setting simply removes the option from people who are local admins of their computers. So here's a way you can remove the ability even for local admins to enable routing.

However, let me admit that I wish we did have a way to implement your request, but for an entirely different reason: IP address preservation. Consider what happens when I'm on my own corpnet in my office. I put my laptop in its dock, which is connected to the Ethernet. I never bother disabling my wireless (I'm lazy). So whenever I'm in my office I'm taking up two IP addresses: one on the Ethernet and one on the wireless. Such wasteful profligacy, I know! (Note this isn’t a problem for any Bluetooth adapter, which always uses APIPA in its default configuration; I can’t imagine a scenario where you’d want Bluetooth to use DHCP.)

If you agree with me that this is something we should address post Windows 7, not for "security" reasons but as a good general networking practice of being conservative with address allocation, please speak up. Now's the time for your input.

http://blogs.technet.com/steriley/archive/2008/06/25/directly-connect-to-your-corpnet-with-ipsec-and-ipv6.aspx#3122377

Hey Steve you and your montize buddy Scott will soon have your hands full after the federal officers come down on your data scams and as for your educational acts i'm not buying it and if others are willing to trade your data for their profits guess there are fools born everyday tunnels oh I see drug dealers right Stevo

Normally I delete spam from my comments, and have occasionally deleted mindless ranting criticism (I encourage vigorous discussion of ideas, but won't allow personal attacks). However, this guy's comment is just...weird.

• What's a "montize buddy Scott"? I know lots of Scotts, and once even admired a particular "Montgomery Scot." But "montize"? Maybe it's a new kind of malt.
• I don't believe I'm perpetuating any data scams, none that I know of, anyway. If any of you, my readers, feel that I'm scamming your data, I guess I haven't concealed that fact well enough. Oops, sorry! We'll have to add another item to the constantly-growing list of data breaches.
• While it's true that some of my conference appearances aren't free, no one is certainly forced to buy any of my "educational acts." A lot of my presentations you can download for free!
• I never look in tunnels for my supplies, they're too dark and you can never be totally certain of what you're getting.

Thanks, dodacrazy, for a good Thursday morning laugh!

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.

Account lockouts

Account lockout is a poor substitute for good passwords -- and is one of the most expensive security features you can use. Let's think about this by considering the threat. What threat does account lockout (attempt to) mitigate? Password guessing. How can you make password guessing attacks become useless for an attacker? Two ways: implement lockouts or use good (meaning long) passwords.

Consider the first choice, account lockouts. The typical cost to an organization to reset locked accounts is US$75 per help desk call. In a medium or large organization, this can become a very high monthly maintenance cost. In nearly all instances, the call results from users locking themselves out (too many vodka tonics on the plane, maybe?), not users encountering locked out accounts because some bad guy was trying to guess passwords. Account lockouts have one more -- very bad -- problem: they create opportunities for bad guys to conduct denial-of-service attacks against accounts or entire domains! Even if you use a timed unlock of, say, 15 minutes, then the attacker can write his script to churn through thousands of bogus logon attempts every 15 minutes 2 seconds. So, contrary to the claim, enabling this setting actually can have significant impact on usability.

Account lockout is there for people who absolutely need it. But I can't think of any instance where this is true. Instead, have a policy that requires simple passwords at least 15 characters long. Forget about complexity rules that force people to write down passwords. A simple 15-character passphrase (think short sentence) is easy to remember, quick to type, and far stronger than any short complex password. A passphrase like this will withstand any kind of automated password attack, including those based on rainbow tables. And you can even use a method that helps you remember unique phrases for each site, if you wish:

• web mail: "my dog and i got the mail"
• shopping: "my dog and i bought some stuff"
• office: "my dog and i went to work"

This is why we disable account lockout by default. There are much better --  and much less expensive -- ways to mitigate the threat.

Disabling unused accounts

You're right, there's no built-in method to automatically disable unused accounts. A variety of third-party products can provide you with this functionality. I suspect some of them might be free, perhaps simple scripts even. I tried searching on "automatically disable unused accounts" and saw a few hits that looked promising. This particular function, however, rightly belongs in the HR process. A number of customers I've spoken with have automated the account creation/disablement/deletion process, incorporating it into HR systems. When a new user is hired, the account is created; when the user departs, the account is disabled; some time later, it's deleted. The HR systems take care of this, not domain or enterprise administrators. I wrote more about this subject in "When you say goodbye to an employee."

Password expiration

Password expiration is an important setting for everyone. It mitigates two threats: employees sharing passwords and bad guys discovering passwords. Because we can eliminate the second threat using long simple passphrases as I described above, then we have only one remaining threat: password sharing. Your estimation of how prevalent this threat is in your environment will guide you toward choosing an expiration time that works for you. 42 days is a reasonable default; our own corpnet uses 70 days. My experience with most customers shows that password sharing isn't a problem. So for those who do enforce long simple passphrases, I suggest that a reasonable default for expiration is 120 days.

Windows begins notifying you 14 days before your password expires. You can change this time period through group policy. I was in a similar situation recently. Last month my domain password expired while I was in Australia for TechEd there. I could continue to log on to my laptop with cached credentials, but couldn't use Outlook Web Access or RPC+HTTP of course. So I connected to a Terminal Server computer we have on the Internet, logged on there, and changed my password.