Steve Riley on Security : access technologies

Enabling Secure Anywhere Access in a Connected World

Steve Riley — Tue, 06 Feb 2007 23:47:00 GMT

A few times each year, Bill Gates or Steve Ballmer publish an executive memo. The first memo was Bill's essay on trustworthy computing, in July 2002. Today Bill has a new memo, one that is very important for all of us who strive to achieve a balance between being secure and, well, getting work done.

Some of my favorite points from the memo:

[It] is no longer a question of the power of our devices and the speed of our connections. The real issue today is security. Ultimately, anywhere access depends on whether we can create and share information without fear that it will be compromised, stolen, or exploited.
No company is immune to the danger. Malware targets products from virtually every software vendor. Every business is vulnerable to the risks that come with unauthorized access to corporate information.
...striking the right balance is extremely difficult. Easy access speeds communications but increases the danger that confidential information will be exposed. Stringent security measures reduce risk, but can make it too difficult for employees to access information or communicate with customers and partners and too complex for IT professionals to deploy and manage solutions.
...new technologies for managing the way people and information move between corporate networks and the Internet are essential. In the face of a rapidly evolving threat landscape, the firewall...is no longer adequate.

Several times in the memo Bill mentions the importance of policy. Most of you have probably heard me speak of similar ideas. Policy-based security allows us to finally divorce information protection from the mechanism used to transmit that information. This is essential because the ubiquitousness of mobile computing demands it. Regardless of where information is stored, how it is transmitted, policies that apply to the information will move everywhere with it. We will no longer be constrained by the topologies of any particular network, because the network will lose its role in managing access to information and revert to the single thing it does best: move bits around as fast as possible.

Did you know that you ALREADY have an e-mail policy?

Steve Riley — Mon, 11 Sep 2006 03:34:00 GMT

An email access policy can be expressed in one of two ways:

E-mail is mission critical to our business. Therefore, we permit employees to read and compose e-mail from any location in the world where employees can access the Internet, using either company-issued devices or public Internet terminals. This allows our employees to be maximally productive.
E-mail is mission critical to our business. Therefore, we permit employees to read and compose e-mail only from company-owned computers built and maintained according to IT standards. This ensures the security and integrity of our e-mail systems and data.

Which policy is yours? You can't have both, of course.

Selecting a policy should never be a technical exercise, and the decision isn't up to the IT department or even the security group. It's a decision the business makes. The decision begins with the answer to the question, "What does mission critical mean to our business?"

For some, mission critical means maximum access -- that no matter where an employee is, or what the employee might be doing, if there's a device with an Internet connection, the employee should do some mail. Timeliness is of utmost importance; the organization will accept the risks associated with using public terminals (and deal with any exposure caused by potential threats that materialize).

For others, mission critical means absolute integrity -- that the organization simply can't tolerate the risks associated with access from unknown computers and will therefore permit access only to those on the corporate network (or maybe connecting via a VPN, but even that can be too much for some).

Which definition of mission critical is yours? It can't be both, of course.

Outlook Web Access = your email policy

If your organization uses Outlook Web Access, then it's already selected its policy: the first one. An organization who uses OWA values anytime, anywhere, any-device access as being necessarily critical to the success of its business that it's willing to accept the risks associated with such access. Let's consider some of the risks of using public terminals:

Malware infects an e-mail message
Keystroke logging software steals credentials
Evil person reads and writes e-mail after a user walks away without logging out
Evil person reads left-over attachments sitting in the browser's cache
Someone shoulder-surfs (an employee at a competing organization, for example)

But yet, for many organizations, the benefits of OWA outweigh the risks -- and there's nothing inherently wrong with that. In some cases, it's possible to mitigate the risks. Returning to our list, consider:

Malware scanners on the e-mail gateway
Two-factor authentication like RSA SecurID or VeriSign Unified Authentication (note: while 2FA helps guard against credential theft, it's powerless to stop malware)
- The folks at CryptoCard have some interesting products, including a software token that you can run on a Windows Mobile device or a Blackberry for generating the token that you then enter into the OWA login page -- however, I've got no experience with their stuff
Forms-based logon with a timeout (using a browser cookie)
Attachment conversion like Messageware AttachView -- converts to non-cached HTML
Not being stupid

Risk awareness and mitigation: the security group's job

Our job, as security experts, is never to say "no." Rather, our job is to enable the business to succeed as safely and securely as possible. We do that by staying close the business, understanding (perhaps even anticipating) its needs, and making it aware of any associated risks. It's up to the business to make the decision. Then the work returns to us, and now we select and deploy appropriate processes and technologies to mitigate the risks we can, while perhaps simply ignoring or transferring (by buying insurance) the remainder.

I know of few organizations who choose the second e-mail policy: prohibiting remote access to e-mail. Indeed, I would wonder if that kind of organization really knows what e-mail is for. Work in the modern age is rarely limited to daylight hours in traditional offices. If your organization is among the majority that expects its employees to work for free (ha ha), then it's your job to make sure the business understands the risks and deploy appropriate processes and technology to mitigate those risks.

And this is only the beginning. Done right, an OWA architecture can be extended into a general access model that's simpler to design, build, and maintain; its simplicity results in cost savings and greater security. I'll have more to say about the "web-enabled data center" in a future blog post. My goal is to shove all DMZ-laden complex network beasts into the dustbin of history.

Configure your router to block DOS attempts

Steve Riley — Mon, 10 Jul 2006 23:27:00 GMT

Some time ago I had a discussion with a friend. He disagreed with my recommendations on how to configure a border router and the firewall behind it. I claimed that in the border router between you and your ISP, configure the six rules to block most denial of service traffic; in the firewall, configure additional packet filtering and content inspection. He claimed that it's better to repeat the router rules in the firewall, and if possible repeat the firewall rules in the router.

This struck me as disingenuous: "Why do the same work twice?" I asked. "It's defense in depth," came the expected reply. "If a bad guy gets through the router, maybe the firewall will stop him."

No, it isn't defense in depth. Defense in depth is about doing the correct things at all layers, and only things that are appropriate for each layer. When defense in depth degenerates into duplication of effort, the resulting security posture becomes more brittle and, arguably, less secure.

There are three kinds of vulnerabilities:

Code: an error in the software that you fix with a patch
Configuration: an error a human made while setting something up
Circumvention: an error in a security policy that encourages people to look for ways to get around the policy

By far, the most commonly occuring type (according to some research from CERT) is the second: configuration vulnerabilities. Given that it's far more likely for me to make a mistake in my rules than for the code in the router or firewall to be buggy, it's far more likely for a bad guy to break in through my error-ridden rules than for him to break in through a code vulnerability in either device.

Complexity is the enemy of security. Simplicity always wins. Therefore, to keep a network simple (and more secure), ensure that your defense in depth measures are tuned and specific for each layer, not merely duplicates of something you've taken care of at another layer.

Blocking DOS attacks

Now, back to the title of this post. In a border router, you should have six rules that will block almost all denial of service attacks. Remember the attack against the Internet in February 2000? Mafiaboy, the 17-year-old Canadian script kiddie, brought down 11 sites using 75 computers in 52 countries to send 10,700 messages in 10 seconds, causing an estimated $1.7 billion in damages. (Canadian police discovered him from his boasting in chat rooms. In 2001 he pled guilty to 56 charges and was sentenced to two years in a juvenile detention center).

Why did Yahoo, Buy.com, eBay, CNN, Amazon.com, ZDNet, ETrade, Dell, and Excite all succumb to the attack? Because they lacked one or more of these six important rules. MSN and Microsoft were targeted, but because our routers have these rules, we escaped the attack. The rules:

Block all inbound traffic where the source address is from your internal networks. Why in the world would there be traffic on the outside that originates from the inside? This is a sign that someone is spoofing you.
Block all outbound traffic where the source address isn't from your internal networks. This is the inverse of #1: there's never any reason for your network to emit traffic that's sourced from some other network. Somone on the inside is spoofing someone else (we have a term for such people: employee).
Block all inbound and outbound traffic where the source or destination addresses are from the private address ranges. Defined in RFC1918, these addresses are for use in internal networks; ISPs agree not to route such traffic. Of course, ISPs make configuration mistakes, too; I've seen traffic with these addresses on the Internet. So don't trust that your ISP is perfect, block the stuff yourself. And remember to include the Windows automatic private IP addressing block. The ranges, then, are: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16.
Block all source-routed packets. Way back in 1970, when "routers" were Unix computers running a routing deamon, they weren't all that reliable. So IP includes a provision for the headers of a packet to indicate the route the packet should take from its source to its destination. Source-routing was necessary then, but it's completely unnecessary today: routers are some of the most reliable gear around. Source-routed traffic is the sign of an attack: drop it all.
Block all broadcast packets, including directed broadcasts. Broadcasts are useful inside a network, but have pretty much zero utility between networks, so don't let the stuff in (or out). And good old smurf attacks, still seen as a form of revenge in IRC, rely on directed broadcasts. [Thanks to Michael Dragone for suggesting this additional rule.]
Block all packet fragments. Fragrouter is an old but wonderful tool, imminently useful for evading network intrusion detection. With it, an attacker can create packet fragments -- TCP or UDP packets missing the TCP or UDP header -- and, for example, map out your firewall policy and prod for holes and mistakes in your configuration. With one notable exception, fragments are generally not created, so there's no reason to permit them into your network. What's the exception? IPsec -- or, more precisely, IKE authentication in IPsec. During the authentication sequence, IKE performs six round trips between the peers. As the peers negotiate a protection suite and exchange keys, IKE generates fragments: very rarely will the key fit in a single packet. So if you're allowing IPsec between the Internet and something behind your border router, you'll need to skip this final rule.

There you go. Program these six rules in your border router (and consider dropping whatever else you've got there now) and you, too, can tell the likes of Mafiaboy to go pound sand. Oh, and guess what? By being more secure yourself, you directly affect -- negatively -- the security posture of your neighbors and competitors! Did you ever think that a router configuration could become strategic competitive advantage? :)

Should your ISA Server be in your domain? Film at 11!

Steve Riley — Thu, 22 Jun 2006 02:21:00 GMT

So it would seem that a statement I made during TechEd US last week in Boston has mildly stirred a bit of controversy -- no surprise there, I guess, heh. One of my presentations gave an overview of what's new in ISA Server 2006 (download your copy of the release candidate or try it out in some virtual labs). An important new feature is expanded support for additional authentication methods on web listeners and web publishing rules. You can now select LDAP, SecureID, and other one-time password mechanisms, and finally make real use of client certificates through support for Service4User2Proxy in Windows Server 2003 Kerberos.

I made the statement that this additional flexibility makes it easier to build your ISA Server standalone -- rather than domain-joined -- and still enjoy the improved security benefits of authentication delegation. Tom Schinder, our beloved ISA Server MVP, prolific author, and host of the fine www.isaserver.org community site, attended the presentation. It was my apparent preference for standalone servers that Tom disagrees with -- and he wrote about it in a whitepaper on his site.

I have enormous respect for Tom. ISA Server's popularity and success is due in large part to his unflagging dedication and support. He's an entertaining writer, from whom you can not only learn something new but enjoy yourself while doing it. Plus, he advocates improved security that addresses modern threats and rails against the old guard unwilling to give up their stone knives and bearskins.

In this particular case, though, either Tom misunderstood my point or I misstated my point -- it doesn't really matter which. My preference is that, indeed, your ISA Servers should belong to your account domains. In his paper, Tom puts forth some very well-reasoned arguments for doing this -- arguments for which there is very little room to disagree. I don't believe I ever said "the ISA Server should never be a domain member" during the presentation, but honestly I don't remember now.

Yet there's a certain reality among many of the customers I work with, a reality that simply won't abide any firewall having access to account information. This reality is exactly the kind of fossilized thinking that Tom (and I) become so disgusted with. The fact is, ISA Server is one of the strongest, most resilient firewalls on the market. In the seven years since ISA Server 2000 was released, only ten security bulletins were issued for it, and of those, only three are marked critical. In the three years since ISA Server 2004 was released, zero security bulletins have been issued. ISA Server is some of the best code Microsoft has ever created. I have yet to learn of customers experiencing attacks that compromise either an ISA Server or a network protected by one.

Still, all this evidence isn't enough to convince the old guard. Very rarely do we see ISA Server replacing older, less capable firewalls in an organization. What we do see is a slow (too slow) migration toward using ISA Server in the DMZ, configured to publish resources in the internal network. And it is the intrusion of, yes, a Microsoft firewall into the realm of the "networking guys" that requires a delicate dance even still today. I've been advocating this architecture since 2002; you'd think these days we wouldn't even have to discuss DMZs as anything other than the paleo-networking artifacts they are, huh? (And I used to be one of those "networking guys.")

ISA Server's ability to remain standalone while still enabling authentication delegation solves two rather intractable problems: it protects internal web servers from attack while simultaneously existing in a configuration that the networking guys will grudgingly allow. Tom's excellent arguments in favor of domain membership reveal the deployment scenarios probably more common in his consulting work: using ISA Server as a forward proxy. The customers I have conversations with typically use that DMZ-located ISA Server only for reverse proxy. So it's from that viewpoint that I talk about standalone ISA Servers during presentations at conferences.

Tom, you and I are approaching the problem from different experiences, that's all. We are in violent agreement here, and that's a good thing. :)

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!

Remote Access Quarantine (TechNet Magazine article)

Steve Riley — Wed, 01 Mar 2006 02:58:00 GMT

http://www.microsoft.com/technet/technetmag/issues/2006/03/SecurityWatch/default.aspx

In those good old easy-to-manage pre-mobility days, personal computers presented few actual threats to a network. Sure, there was the occasional virus you’d get from a borrowed floppy disk, but the rate, or at least the speed, of infection was pretty low—limited substantially by the low bandwidth and high latency of "sneakernet" technology. In those days, computers were bulky behemoths that squatted on desks and never moved. They were secure because the network was secure, if there was one at all.

Alas, those halcyon days are behind us now, relegated to the dustbin of history. And indeed they should be. Mobile computers are wonderful! We can work, well, just about anywhere, slay monsters anywhere, play solitaire anywhere. The true advance, of course, was the combination of mobility and a network connection. Got 10 minutes? Haul out the laptop and check that e-mail. Who needs an office anymore?

Of course, Murphy never gets to rest. It seems that with every technological advance (that’s a euphemism for "another way your employer squeezes more work out of you"), there’s a dark side. Connected mobility’s dark side is the ease with which unscrupulous people can wreak havoc across an entire network.

Armed with a portable computer that’s routinely connected to multiple public networks, out-of-date machines operated by people with an "I don’t really care" attitude are the most dangerous thing I can envision. And when "I don’t really care" then wants to connect back to his corporate network, need I really describe the resulting carnage? Indeed, this exact scenario is arguably one of the fastest-growing infection vectors imaginable.

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.

Securing Terminal Services over the Internet

Steve Riley — Tue, 28 Jun 2005 19:54:00 GMT

In my presentation on remote access at TechEd, I gave three scenarios:

web-based access to internal resources, published with ISA Server
"desktop over the Internet" using Terminal Services and the remote desktop web connection
full IP-based virtual private networks with L2TP+IPsec

In the discussion on TS over the Internet, I failed to mention a very important bit. There is no mechanism built into RDP to authenticate the server to the client. This creates an opportunity to conduct a man-in-the-middle attack. Tools now exist to do exactly this.

In Windows Server 2003, you can configure TS to use TLS for server authentication and data encryption. This is extremely important for anyone running TS over the Internet. See KB 895433 for the step-by-step details.

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