Steve Riley on Security : authentication

Directly connect to your corpnet with IPsec and IPv6

Steve Riley — Wed, 25 Jun 2008 23:55:00 GMT

Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.

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 Enterprise or Ultimate editions (those with Business edition and Software Assurance can upgrade to Enterprise)
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.

Plan now to eliminate "power users" from your domains

Steve Riley — Mon, 11 Feb 2008 21:03:17 GMT

I've seen some conversations lately about the Power Users group -- how powerful is it, really, and why did we remove the group from Windows Vista?

That group had rights install software and drivers. And if you can install software and drivers, then you can elevate yourself to Administrator or SYSTEM. Vista includes a signed installer that allows standard users to install packages signed by a trusted root. (The "Trusted Installer" is a service that has a SID, so you'll see it in the permissions list on various objects throughout the operating system.) The installer validates the signature chain, then elevates itself to perform the actual installation. Now, standard users can install and update approved software without having to grant membership in the too-powerful Power Users group.

We deprecated the Power Users group and removed it wherever we detected it on ACLs. We recommend that you do the same.

Microsoft IPsec diagnostic tool

Steve Riley — Fri, 01 Feb 2008 14:39:04 GMT

IPsec is a wonderful technology for identifying computers and securing the exchange of data between them. I've written and spoken extensively about in the past. It is, however, a bit of a challenge to configure, especially if you're newly learning about it. Microsoft recently released a diagnostic tool to help you create and test your policies. It checks for common network problems on host machines and suggests repair commands. It collects IPsec policy information on systems and parses IPsec logs to deduce why a failure might have happened. Beyond IPsec, it offers trace collection for VPN, NAP client, Windows Firewall, Group policy updates, Wireless, and System events. The tool's diagnostic report derives its conclusions from the system logs collected by the tool during its analysis phase, which are sufficient to diagnose any network related issue. For further assistance, you can share the logs with network administrators or Microsoft support.

Get the tool here: http://www.microsoft.com/downloads/details.aspx?FamilyID=1d4c292c-7998-42e4-8786-789c7b457881&displaylang=en

It works on these versions of Windows:

Windows Server 2003 Service Pack 1
Windows Server 2003 Service Pack 2
Windows Server 2003 Service Pack 2 x64 Edition
Windows Server 2008
Windows Vista Business
Windows Vista Business 64-bit edition
Windows Vista Enterprise
Windows Vista Enterprise 64-bit edition
Windows Vista Ultimate
Windows XP 64-bit; Windows XP Home Edition
Windows XP Professional Edition
Windows XP Service Pack 1
Windows XP Service Pack 2

Myth vs. reality: Wireless SSIDs

Steve Riley — Tue, 16 Oct 2007 10:08:58 GMT

Do you ever wonder sometimes how it is that some ideas just won't die? Like the thought that not broadcasting your wireless network's SSID will somehow make you more secure? This is a myth that needs to be forcibly dragged out behind the woodshed, strangled until it wheezes its last labored breath, then shot several times for good measure.

Folks, there are fundamental differences between names, which are public claims of identities, and authenticators, which are secrets used to prove identities, and I've written extensively about this before. An SSID is a network name, not -- I repeat, not -- a password. A wireless network has an SSID to distinguish it from other wireless networks in the vicinity. The SSID was never designed to be hidden, and therefore won't provide your network with any kind of protection if you try to hide it. It's a violation of the 802.11 specification to keep your SSID hidden; the 802.11i specification amendment (which defines WPA2, discussed later) even states that a computer can refuse to communicate with an access point that doesn't broadcast its SSID. And, even if you think your SSID is hidden, it really isn't. Let me explain.

All 802.11 wireless networks, regardless of the kind of operating system or encryption you might use, also emit unencrypted frames at times. One kind of unencrypted frame is an association frame. This is what a client computer, or "supplicant" in the 802.11 protocol vernacular, emits when it wants to join a wireless network. Contained within the frame, in clear text of course (since the frame is unencrypted), is the SSID of the network the supplicant wants to join.

Both Windows XP and Vista work best when your access points broadcast their SSIDs. XP really doesn't behave well at all with nonbroadcasting SSIDs. Vista has some added smarts to improve this a bit. Normally, Vista continually sends probe requests for nonbroadcasting networks. These probes are similar to unencrypted 802.11 association frames, and will generate clear-text responses from the access points if a nonbroadcasting network is present. You can reduce, but not entirely eliminate, these probes by configuring the wireless client to probe only for automatically-connected nonbroadcasting networks.

Both these behaviors make it very easy for an attacker to discover your SSID. The bad guy, perhaps a contractor or a guest in your facility, could run one of many wireless sniffer programs and simply capture the hundreds of association frames or probes that litter your air. No amount of "hiding" configured in your access points can prevent this kind of traffic interception.

So there you have it, simple SSID discovery. The old axiom remains true: security by obscurity is no security at all. Hiding an SSID will not hide a wireless network, so ignore any such advice -- and it's amazing how often I continue to see this. By the way, also ignore any advice that says to use MAC address filtering. It's amazingly trivial to spoof the MAC address of an allowed supplicant -- simply sniff the traffic, look at the MAC addresses, and use the neat little SMAC utility to change your MAC to one that's permitted.

Nonbroadcasting networks are not secure networks. The right way to secure a wireless network is to use protocols that are designed specifically to address wireless network threats. If you're still using WEP, either static or dynamic, I encourage you to move to WPA2 as soon as possible. For those of you at home running XP and have kept it updated, or if you're running Vista, then, you simply need to enable WPA2. We've got some additional guidance for home/small offices and for enterprise networks with certificate services or without. If you have hardware that's more than two years old and you can't upgrade it, check to see whether it supports WPA (an interim specification released before WPA2 was ratified). Both WPA and WPA2 are built on sound cryptographic principles, they're proven in the field, and they'll keep the bad guys out -- even when you're broadcasting your SSID to the world.

Password policies. Once again.

Steve Riley — Wed, 05 Sep 2007 01:14:00 GMT

Recently in the newsgroups (news:microsoft.public.security, to be specific) the question of password polices and the out-of-box defaults came up. The poster lamented a number of things: that Microsoft doesn't enable account lockout by default, that we don't have a built-in mechanism for automatically disabling unused accounts, that the 42-day default expiration is troublesome. Here's my response; figured that it would make for a useful blog post, too.

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.

Why administrative passwords will never be like nuclear missile launchers

Steve Riley — Tue, 21 Nov 2006 13:16:22 GMT

During the past few months many people have lamented that Windows lacks a nuclear missile style control option for administrator passwords. Surely you've read about or seen photographs of missile silos where two operators, separated by a distance greater than the span of a single human's arms, must each simultaneously turn a key in a switch to launch a missile. Such a fail-safe is important when considering missile launches: presumably a nation can't thus be committed to global thermonuclear war on the deranged whims of a single raving lunatic.

At first glance, it seems reasonable to allow for similar control over domain and enterprise administrator accounts. A while back I wrote about the fundamental requirement of trust in administrators; missile control-style passwords (is there some official term for this?) might lessen the requirement for such trust, goes the thinking. Well, I'm not convinced that the logic that works for missile silos extends to administrator passwords. Let's examine the differences.

It works for missile silos because the fail-safe is tuned to the characteristics of its environment. It takes two keys, each of which must be rotated simultaneously, and they're separated by around ten feet or so: therefore, two humans absolutely are required. To accidentally or intentionally launch a missile when not under orders, both people must be either equally stupid or equally insane -- and in the second case, also equally trust that each is, in fact, a criminal, rather than one acting as a double agent attempting to entrap the other. Furthermore, both operators perform the function in full view of a whole lot of government staff and military officers. The environment and the fail-safe work together to keep the deadly missiles in the ground. Another important aspect is this: the silo and its control system are designed by and operated by the same entity, the government.

Now compare that to a domain controller. Let's say that it's possible to enable a feature that requires entering two passwords. Where would you do this? A logon screen with two password entry fields lacks both physical and human separation: one person could enter both passwords if he or she knew them. It's no better with smartcards -- again, one person could insert both cards into the readers. Replicating a silo-like environment using a pair of computers isn't the answer, because unlike the silos and their control systems, Microsoft designs Windows but you operate it. The fail-safe works for the silos because of the required physical separation. Microsoft can't dictate, and certainly can't enforce, that you have two domain controllers, separated by at least ten feet. Not everyone can afford all the necessary hardware; plus, think of the demands that would place on space and power in a data center. And besides, even with separated domain controllers, a malicious admin need only to enter the first password or insert the first smartcard in one computer then wheel over to the other one and enter the second password or smarcard there. I'm not sure there's a way to check for simultaneous credential entry.

Separation and delegation of administrative duties is, of course, a good and important concept, one that we'll continue to refine throughout the operating system. There's a lot of power granted to administrators right now, this power we will help you segregate among multiple roles (humans) in your organization. But because of the nature of computer systems, any human granted a particular bit of administrative power must be trusted with that power. Computer systems and the data they store, process, and protect aren't silos; applying silo-style security is the wrong approach to mitigating security risk.

Mythbusters beat "unbreakable" fingerprint door lock

Steve Riley — Thu, 21 Sep 2006 08:15:00 GMT

My good friend Jamie Sharp sent me this link today. It's amazing: watch how Adam and Jamie easily defeat a fingerprint lock the manufacturer claims has never been broken. As if to snub the claims, they break it three times! Supposedly it monitors pulse, sweat, temperature, and other attributes. First, Adam obtains an impression of a fingerprint already present on the reader and creates a latex copy that he adheres to his own thumb. Initial attempts fail, but when Adam licks the latex, the door opens. Next, Jamie tries a ballistics gel copy of the fingerprint. Sure enough, the door opens right away. Adam remarks that some cheap computer fingerprint reader was actually more difficult to hack than the "unbreakable" door lock! Finally, Adam tries the simplest of all attacks: a photocopy of the authorized fingerprint. No warmth, no pulse, only a lick -- and again, the door opens.

Biometrics is identity, not authentication. Authentication requires a secret of some kind, like a PIN or password. Anything you leave behind, like the fingerprint Adam lifted from the reader, can never be used as a secret, and thus can't be considered authentication.

Security myths and passwords

Steve Riley — Sun, 30 Apr 2006 19:07:00 GMT

I like this a lot.

http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/

In the practice of security we have accumulated a number of “rules of thumb” that many people accept without careful consideration. Some of these get included in policies, and thus may get propagated to environments they were not meant to address. It is also the case that as technology changes, the underlying (and unstated) assumptions underlying these bits of conventional wisdom also change. The result is a stale policy that may no longer be effective…or possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example of exactly this form of infosec folk wisdom.

From a high-level perspective, let me observe that one problem with any widespread change policy is that it fails to take into account the various threats and other defenses that may be in place. Policies should always be based on a sound understanding of risks, vulnerabilities, and defenses. “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

What do YOU need out of two-factor authentication?

Steve Riley — Fri, 21 Apr 2006 01:37:00 GMT

Two-factor authentication continues to grow in popularity and emerge as a security requirement for many people I meet with. At Microsoft, we use smartcards internally for VPN access right now; soon we'll be requiring smartcards for domain logon, too.

We are also looking at ways to require two-factor authentication for web-based services, like Outlook Web Access, published SharePoint servers, and other bits in our extranet. I love smartcards, and it's Microsoft's preferred product direction and corporate IT approach. But here we encounter a problem with them: most public workstations (kiosks, Internet cafes) don't have smartcard readers. So how do we require two-factor authentication when the infrastructure can't support it?

Ideally, my answer would be: too bad. Public workstations are too great a risk. No self-respecting organization would ever allow access to corporate resources from unknown machines, right? What possible business justification would ever permit exposure to such risk?

A lot, it turns out. Any organization (Microsoft included) that permits access to corporate resources, like OWA, is making a risk statement, whether they know it or not. That statement is this: "Our business activities require access to certain resources from any device, anywhere, at any time. We accept the risks associated with this because the value to the business is determined to be higher."

But just like us, many organizations are starting to become wary of these risks. Two-factor authentication can help to mitigate some, but not all, of them. The choice, then, is which kind of two-factor authentication to use? If smartcards won't work because readers aren't yet ubiquitous (they will someday -- remember, once upon a time a mouse was a rarity), what's left to choose? (I wish we'd include smartcard readers in every box of Windows we ship, just like we included mice in Office.)

Some form of token card with a one-time password is generally the option, with RSA SecurID being the most popular. Lately I've been reading about VeriSign's Unified Authentication product -- a number of you have mentioned your success with it, and you like that it integrates natively into Active Directly without requiring a separate authentication infrastructure (unlike SecurID, which requires an ACE/Server). I would like to play with this myself someday (hint hint).

I want to hear from you, though. What do you need from a two-factor authentication mechanism? What are your requirements? Have you used the products currently on the market? What do you like or not like? What do you want to see done differently? Would you like for Microsoft to develop something, or do you prefer to rely on partners?

Tell me what you think. Our IT department is engaged in a lot of research here; I'd like to know what you've learned in your research and through your experience, too. Post a comment here or email me if you'd prefer to remain private. Either way, I'd really like to get a good body of customer thinking on this. Thanks!

It's me, and here's my proof: why identity and authentication must remain distinct

Steve Riley — Thu, 16 Feb 2006 20:41:00 GMT

My February Security Management column is posted:

http://www.microsoft.com/technet/community/columns/secmgmt/sm0206.mspx

No matter what kinds of technological or procedural advancements occur, certain principles of computer science will remain -- especially those concerning information security. I’ve noticed lately that, among all the competing claims of security vendors that their latest shiny box will solve all your security woes, a basic understanding of computer science fundamentals is missing. Because good computer science never loses importance, and because knowing the science can help you choose products and develop processes, from time to time I will cover such topics in this column. This month I’d like to explore the concepts of identity, authentication, and authorization, to help you understand their important distinctions, and to help guard you against the increasingly common tendency to combine the first two.

How to secure your wireless network

Steve Riley — Sat, 12 Nov 2005 10:43:00 GMT

I'm now a contributing editor for TechNet Magazine. Everyone with a TechNet subscription automatically receives it; if you don't have one, you can still get the magazine free. The magazine's published three issues so far: Winter 2005, Spring 2005, and November-December 2005. You'll especially enjoy the "Hacking" series in the first issue, where Jesper writes up his "Anatomy of a hack" conference session that always seems to score a hundredth of a point or so higher than me! (LOL) Good news: the magazine is increasing its frequency; it'll be bimonthly through June 2006, then monthly after that.

Anyway, in the November-December 2005 issue, I've co-written (note I don't say "co-authored"; "author" is not a verb!) with Kathryn Tewson an article on wireless security for the Security Watch column. We describe the threat, some wireless security basics, how not to secure a wireless network (hint: bogus advice regarding SSIDs and MAC addresses figures prominently here), and details on access control and encryption. We also describe three common scenarios.

Read through the article for information on the various technologies and our recommendations -- which is pretty simple these days: WPA or WPA2 are really the only logical choices. While you're at it, subscribe to the magazine, too. I think you'll enjoy it. Look for more articles of mine in the magazine over time; for the January-February 2006 issue, I'll have an article describing VPN quarantine (just sent it to the editors today, actually).

August article: 802.1X on wired networks considered harmful

Steve Riley — Thu, 11 Aug 2005 20:55:00 GMT

Several months ago I learned from Svyatoslav Pidgorny, Microsoft MVP for security, about a problem in 802.1X that makes it essentially useless for protecting wired networks from rogue machines. Initially I was a bit skeptical, but the attack he described is in fact true -- I've seen it myself now. So I've been explaining the attack at conferences lately and have also included information about it in the book. However, I don't believe the danger presented by wired 802.1X is getting enough reach, so I've written about it in the August security management column.

As you read the article, remember that the vulnerability enabling the attack is a fundamental weakness in the protocol -- it authenticates only upon connection establishment and assumes all traffic after authentication is legitimate. The vulnerabiliy exists in wired networks because there's no follow-on packet authentication. You really should be using domain isloation with IPsec to thwart rogue machines, and at the article's end are links to information about that. Also, understand this particular vulnerability isn't present in 802.1X-protected wireless networks, because the authenticators and supplicants have established authentication and encryption keys that protect individual 802.11 frames.

New column -- Using IPsec for network protection

Steve Riley — Thu, 10 Feb 2005 20:59:00 GMT

I'm now writing semi-regular articles for TechNet. These are part of the security management series, and they're also linked from the security newsletter.

The first column is a two-parter about IPsec. Part 1 describes the technology: how it operates, its various modes and methods, a bit on IKE, and how it works over NAT.

http://www.microsoft.com/technet/community/columns/secmgmt/sm121504.mspx

Part 2 illustrates three excellent scenarios that you can apply IPsec to today: stopping worms, protecting servers, and isolating domains -- a very cool approach for requiring domain membership of all your computers. Get rid of the rogues!

http://www.microsoft.com/technet/community/columns/secmgmt/sm0105.mspx

Security newsletter

If you haven't already, I urge you to sign up for the security newsletter. Hundreds of thousands of subscribers -- many of whom might be your competitors (LOL) -- already benefit from the tips, tricks, updates, guidance, and news we publish every month. So sign up today! My columns are always linked from here, too.

http://www.microsoft.com/technet/security/secnews/default.mspx