Security Viewpoint – October 2008
See other Security Viewpoint columns

By Steve Riley, Senior Security Strategist, Trustworthy Computing, Microsoft Corporation

- - - - - - - - - - - - - - - - - -

You know where your servers are. You know how they’re configured, you monitor their performance, you control access to their data, and you fine tune their behavior—with centralized security policies and unified management consoles. You feel good, and rightly take some pride in your work.

Now what about all those client computers proliferating like rabbits? It’s difficult enough keeping track of the ones you know about. Yet that one business group over there, you know—the one that gives each employee $2,000 and says “Go get whatever you want!”—can’t stand them, can you? And that other group whose employees work only from home, on the same machines their kids use for spyware-infected online games and privacy-busting social networking, while connected to an insecure wireless access point? Hmm, I sense your blood boiling. Calm down, relax, listen to the soothing sounds of my gentle voice (well, imagine that you can), and let me help you sort through it all.

Let’s put a framework around the problem. Access requests come from known and unknown people, using known and unknown machines. Here’s a handy chart:

Now we can decide, for each class, what the use scenarios are, what kinds information should be made available, what client security responsibilities you might have, and what sorts of protection (if any) would be required.

Class 1: unknown users, unknown computers

Scenario: random individuals browsing your public web sites.

Available information: public.

Client security responsibilities: none. Well, maybe something more than none. Part of being a good Internet citizen is ensuring that your own sites don’t create security problems for the people who visit you. The important thing here, of course, is to make sure your public web applications are free of cross-site scripting errors and your web servers are free of malware that propagates via browsers (keep them patched!).

Class 2: unknown users, known computers

Scenario: owners of public kiosk computers.

Available information: anything.

Client security responsibilities: follow the Kinko’s model. Don’t assume that the people who use your kiosks won’t make mistakes or won’t try something malicious. You could heavily lock down the machines, but even then, you can’t be totally certain that someone didn’t manage to sneak malware that runs as standard user. Have you ever used a public computer at a Kinko’s? Check it out sometime. Each new user gets a freshly built operating system install. When the user logs out (and her credit card is billed), the workstation is wiped, formatted, and rebuilt from an image, in just a few minutes. You can build this yourself with Windows SteadyState, a free add-on for Windows XP and Vista that’s ideal for shared computers in schools, libraries, and internet cafés.

Class 3: known users, unknown computers

Scenario: people logging in with an identity you provide (or trust) using home computers or kiosks.

Usage examples: checking Outlook Web Access, interacting with internal web applications published through ISA Server or IAG, running remote sessions over Terminal Server.

Available information: internal data and documents (plus anything on the Internet).

Client security responsibilities: vary depending on how much control you can exert over the computer. If employees use home computers, then they’re most likely logging on as local administrators. You can publish your web applications through Microsoft Intelligent Application Gateway and use its endpoint compliance checking capability to verify the presence of malware scanners and the state of the Windows firewall. You can have IAG download an attachment wiper to the PC that removes potential confidential information that might get left behind if users save attachments or open SharePoint files. Because home computers often access dodgy Internet sites, it’s good to try to enforce some minimal amount of protection on them, if you can and if your employees are willing to permit that.

If users are at kiosks, then they most likely won’t have admin rights, so your IAG policies would prohibit saving attachments or saving SharePoint files while still permitting reading content in the browser. IAG places a no-cache directive in every HTML stream it delivers. The same applies if your employees won’t permit any security policies to be placed on their computers: treat them like you would kiosks.

Of course, access through Windows Terminal Server presents the least amount of risk, and gives you a variety of user experience options with TS RemoteApp, TS Web Access, and TS Gateway.

One other option is Microsoft Application Virtualization, which allows you to stream pre-installed application components to client PCs. You can place expiration times on the streamed components, and if you’re streaming Office, the components will keep themselves updated from Microsoft update. I suspect most of you would be comfortable with the idea of streaming applications to home computers, but probably not to kiosks.

Class 4: known users, known computers

Scenario: people logging in with an identity you provide (or trust) using computers owned by your organization.

Available information: internal data and documents, some of it potentially sensitive (plus anything on the Internet)

Within this class the computers can be divided into four sets:

• Desktop computers you manage
• Desktop computers you don’t manage
• Laptop computers you manage
• Laptop computers you don’t manage

For desktop computers that you manage, the Optimized Desktop helps you achieve the right level of control while still allowing users enough flexibility to get their work done. The menu item on the web page offers a few videos you can watch that describe various possibilities.

For desktop and laptop computers you don’t manage, it’s tempting to lump these back into class 3. But remember in this case, because they’re owned by the organization and not by individuals, the reality is that the users will expect the same behavior and capabilities they’d get on managed computers (I’m imagining the instance of where departments provide budget for each employee to purchase her own computer). Check out the Kidaro technology we recently acquired. With this approach, you could provide your standard IT environment on the machines your organization owns but aren’t under IT’s control. You could even use Kidaro’s virtualization technology in class 3 (known users, unknown computers)—indeed, I’ve recently spoken with many customers who are planning to pilot an implementation soon.

Finally, for the set of laptops you do manage, let me give you a different idea.

At TechEd this year, I gave a presentation called “21st century networking: time to throw away your medieval gateways.” I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. VPNs work, but they’re expensive resource hogs (time, hardware, power) that require users to have to change their behavior when they’re remote vs. local—sometimes discouraging people from working when they otherwise would (think: 10-minute logon times, ugh).

The goal is to provide true anywhere access, anywhere in the world, directly to resources in the corporate data center from managed and secure client computers—while at the same time offering a full user experience no matter where she got her Internet connection from. 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.

Recently I wrote about this in more detail. It requires a good number of parts, but you already know most of them; I’m simply providing a recipe. Once this year’s round of TechEds winds down, I plan to write a guide that you can use to build such an environment in your organization. Until then, please read the article on my blog and let me know what you think.