Windows 7 & DNSSEC Support

10 best features in Windows 7 for IT professionals

Federated search and enterprise search scopes

One of the big themes in Windows 7 for the corporate user is allowing easier access to information no matter where it's located. The big push here is for a unified interface for any given search, with results brought in from a variety of locations into one convenient window. Out of the box, Windows 7 allows users to search beyond their own computers. Some of the nice features here include one-click auto preview, the ability to search within specific "libraries" of information (libraries being a defined set of resources or locations to narrow the scope of a search) and integrated results presentation from SharePoint sites and beyond.

DirectAccess

In my humble opinion, this is one of the coolest features of Windows 7 with Windows Server 2008 R2 (also known as "Windows 7 Server" in some circles). Imagine the virtues of being connected to a VPN: access to your corporate network, file shares, intranet, seamless authentication with company resources and so on. Now imagine not having to create that expensive, giant tunnel through which these resources are accessed. That's DirectAccess. It requires deploying IPv6 and IPsec -- no small tasks by any means, though they should be on your radar already. The advantages? With DirectAccess, you can have essentially an "always managed" infrastructure, so you as the administrator can ensure that updates are distributed, that Group Policy is applied and that your known machines are trusted, anywhere, all the time. That's powerful.

BranchCache

BranchCache extends some of the improvements made in Windows Server 2003 R2 and Windows Server 2008 by caching downloaded information from the Web and intranet sites within a branch office the first time it is requested. Since branch offices often operate on lower-speed Internet links, user productivity is improved as the day goes on because more and more files are present within the cache. In a demo, a document was downloaded over a 512Kbit/sec. connection, taking about 30 to 45 seconds. After the cache, when another user in the same site requested that information, the transfer was nearly instantaneous. BranchCache works not only with a branch office server but also on a peer-to-peer basis among Windows 7 clients in the same location.

BitLocker to Go

Quick poll: how many USB thumb drives do you think exist within the four walls (or eight, or 16, or however many pertain to you) of your organization? I run a small company, and I am confident the number is over 100; frankly, I couldn't attempt to remember what kind of information is on each one, or even if I have lost one at some point in time. Consider the security risk that this tiny device represents. With BitLocker to Go, you as the administrator can set policies that require removable drives to be encrypted prior to allowing write access to them. You protect from the beginning, thereby reducing the risk of data loss or theft. The encryption process in most cases seems to take less than a minute and the process can alert the user automatically when he plugs in a not-yet-encrypted drive.

AppLocker

You might recall software restriction policies from Windows XP, a good-hearted but clumsy way for administrators to restrict certain binaries from running on the network. Enter AppLocker, which is exactly what it sounds like: a Group Policy-based way to identify applications that are permitted to run on your infrastructure. You can filter by publisher, which identifies a program's digital signature -- a much easier and more reliable method than a checksum or binary file name. You also get more granular control on the strength of the rule, allowing certain versions or groups of versions (i.e., Version 9 or above) to run, much more easily than having to create rules over and over again.

DNSSEC Support

Many security pundits have said that the next big plague facing the Internet is the inherent insecurity of the Domain Name System (DNS). Now DNSSEC comes to the rescue as a set of extensions to DNS that prevent spoofing address information. Windows 7 comes with DNSSEC support out of the box.

VHD Boot

VHD Boot works with a virtualized desktop infrastructure to ensure image consistency among client computers. If you have an environment employing strong Group Policy configuration, folder redirection, roaming profiles and the like, then you can feasibly boot from a virtual image. For example, the image used by a customer support team that works remotely could be the same one used on physical PCs for those users who require access to discrete hardware.

Windows Troubleshooting Platform

The Windows Troubleshooting Platform is a new, comprehensive approach to solving end user problems via troubleshooting packs that can be applied to PCs throughout the environment. And the Windows Troubleshooting Toolkit allows you as the administrator to create your own troubleshooting packs when you identify specific problems within your own infrastructure. Also, a separate new tool called Problem Steps Recorder allows an end user to record the steps he takes leading up to a problem and then capture those steps into automatically created screen grabs, and e-mail them to an administrator or help desk representative for easier problem resolution.

Windows PowerShell Integrated Scripting Environment

Because of PowerShell's popularity, Microsoft has introduced into Windows 7 a graphical interface for PowerShell that makes it very easy to learn the scripting language and use it in a color-coded, easy-to-read environment. Developing, debugging and running the scripts in this new environment is much easier than it was with the previous single-command-prompt method.

PowerShell Remoting

Also new to PowerShell is support for the WS-Management protocol that allows you to remotely run commands on client PCs. You can use this capability on a one-to-one basis, say for specific requests in response to help desk calls, or you can fan out with one-to-many remoting and run cmdlets on multiple PCs from within the Windows PowerShell Integrated Scripting Environment.


Source: Jonathan Hassell, Opinion: 10 best features in Windows 7 for IT professionals, Retrieved on 10/29/2008 from computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=NOSes+and+Server+Software&articleId=9118322&taxonomyId=156&pageNumber=2

We Don't Need No Stinking DNS Root Zone Signing

John Timmons at Ars Techinca wrote about the interorganizational wrangling beginning as .gov studies DNS fix. At issue: Who should implement and manage the root signing process rasises the question about who should hold the root keys to such a critical service. But my question is, why does the root zone need to be signed at all?

I hope plans to deploy DNSSec aren't slowed while ICANN, National Telecommunications and Information Administration (NTIA), and VeriSign hash out the details. As Timmons points out, there is a lot of wrangling going on that is important to address, but the root zone doesn't need to be signed for a successful global DNSSec deployment.

The trust in tree hierarchies like DNSSec and a public key infrastructure flows from a root to the leaves. Take a look at a hierarchy like VeriSign's, which has three PKI trees. The trust in each tree begins at the Class 1, 2, and 3 self-signed root certificate authorities. Those CAs are the trust anchors for each tree. All other public CAs have a similar structure where a self-signed root sits atop the tree and trust flows downward to the leaves. That flow of trust is the trust chain, which you can follow back to a trusted root. If you lookAmazon.com's digital certificate, it was issued by the VeriSign Class 3 Secure Sever CA, which was in turn signed by the VeriSign Class 3 Public Primary Certification Authority, which is the trust anchor.

The hierarchy in DNS is no different. There is a single root, the root zone, at the top of DNS that refers all queries to the top-level domain (TLD) servers. I recognize that DNS is a single tree where the plethora of public CAs are multiple trees, but that recognition simply demonstrates that a single trust anchor is unnecessary. The TLDs could be their own trust anchors, and the trust anchor signing keys could be distributed the same way thatCA certificates are distributed today, which is through software updates. Or a mechanism to update trust anchor signing keys could be distributed through DNS, making sure that keys don't expire before the new ones are distributed.

A singed root zone is a more elegant and potential efficient solution because there are fewer keys to update and can be managed through a single entity, but it's not necessary.

Source: informationweek.com/blog/main/archives/2008/10/we_dont_need_no.html

VeriSign wants to share (a small part of) the DNSSEC keys

VeriSign wants to share (a small part of) the DNSSEC keys

VeriSign, which operates two Domain Name System (DNS) root servers, is proposing that the operators of the 13 central root servers of the DNS should jointly control the master DNSSEC key to the root zone.

The DNS Security Extensions Protocol (DNSSEC) would use a public key process to detect fake responses to DNS queries. DNSSEC has been developed over decades as a countermeasure to IP address spoofing. For the last two years, a political dispute has been raging over who should hold the master key, the Key-Signing Key (KSK), for the signed root zone.

VeriSign's proposal picks up the idea – not new, but viewed positively by many technical experts – of sharing the KSK among a number of parties by giving part of the key to the twelve operators of the thirteen central root servers. New signatures for the root zone (the Zone Signing Key or ZSK) would have to be authorised by at least five of the twelve. If only three or four gave their approval, the new signing would fail. The ZSK would be valid for one year, the central KSK for several years.

VeriSign sees a great advantage in this distribution of authority. It would also address the fears of the international community, which has expressed strong reservations about the US Government wanting to keep hold of the master key. Brenden Kuerbis of the Internet Governance Project has already expressed doubts about the proposal. The group of Root Server Operators (RSOs), he points out, is not terribly international, given that nine of the twelve are based in the US. These include the US Army Research Lab, the US Defense Department's computing centres, and NASA's Ames Research Center. Under the present proposal by VeriSign, the US authorities would have direct or indirect access to the five keys required for a new signing. Kuerbis therefore calls for a rule to set a quota for international operators, to safeguard the international nature of the group.

According to VeriSign, key management would probably be exercised centrally. VeriSign's Data Center in Mountain View would generate not only keys and part-keys, but also the KSK and ZSK. VeriSign regards itself as the natural authority for the ZSK, since it manages the root zone. Nothing should change here, in VeriSign's view, and the US Department of Commerce (DoC) would continue to supervise the root zone. A takeover of KSK management would ensure greater security, argues VeriSign, since it would eliminate transfers of keys between different locations. A further argument put forward by VeriSign in favour of centralization at its data centre in Mountain View is that "no other operator is qualified with the same level of experience and secure facilities".

All the root server operators would have to physically attend the first "KSK signing ceremony", taking with them their PIN-protected green plastic part-keys. To prevent their having to return for the monthly ZSK renewals, a stock of ZSK keys would be created immediately. The vulnerability of the list to hacker attacks is just one of the questions left open.

The Department of Commerce only recently slapped the wrist of the Internet Corporation for Assigned Names and Numbers (ICANN) when it tried to take over the distribution of continuous root zone updates from VeriSign . When ICANN submitted its own proposal (PDF) for DNSSEC key management, the DoC prohibited its publication.



Source: heise-online.co.uk/security/VeriSign-wants-to-share-a-small-part-of-the-DNSSEC-keys--/news/111668