The Report on "Securing Cyberspace for the 44th Presidency"

A report "Securing Cyberspace for the 44^th Presidency” has just been released.

Synopsis:
The CSIS Commission on Cybersecurity for the 44th Presidency has released its final report, "Securing Cyberspace for the 44th Presidency." The Commission’s three major findings are:

1. Cybersecurity is now one of the major national security problems facing the United States;
2. Decisions and actions must respect American values related to privacy and civil liberties; and
3. Only a comprehensive national security strategy that embraces both the domestic and international aspects of cybersecurity will improve the situation.

Source: Securing Cyberspace for the 44th Presidency, Retrieved on 12/17/2008 from sis.org/media/csis/pubs/081208_securingcyberspace_44.pdf

"The discussion of using Federal market powers to "remedy the lack of demand for secure protocols" is too terse, perhaps by intent. As I read that section (p. 58), it is calling for BGP and DNS security. These are indeed important, and were called out by name in the 2002 National Strategy to Secure Cyberspace. However, I fear that simply saying that the Federal government should only buy Internet services from ISPs that support these will do too little. DNSSEC to protect .gov and .mil does not require ISP involvement; in fact, the process is already underway within the government itself."

Read more...

Steven Bellovin, The Report on "Securing Cyberspace for the 44th Presidency", Retreived from circleid.com/posts/20081215_securing_cyberspace_44th_presidency on Dec 15, 2008

Identify and Mitigate Windows DNS Threats

Two weeks ago we took a look at what you need to do to prepare for a Windows DNS deployment, and how to blend Unix-based DNS with your Active Directory (AD) structure. This week we're back to consider several threats you need to be aware of, and steps you need to take to protect your Windows-based DNS servers and network.

Footprinting, for instance, is a case where an attacker obtains information about your DNS zones and your network via zone transfer.

Zone transfers are preventable at the firewall and routers on the perimeter of your network. DNS client queries are transmitted on UDP port 53, and TCP port 53 is used for zone transfers. Zone transfers outside of the protected network (outside your firewall) via TCP port 53 should be avoided.

Continue reading...

DNSSEC News: VeriSign, NeuStar and others team on DNS security

Momentum continues to build for rapid deployment of DNS encryption mechanisms.

Seven leading domain name vendors -- representing more than 112 million domain names or 65% of all registered domain names -- have formed an industry coalition to work together to adopt DNS Security Extensions, known as DNSSEC. Members of the DNSSEC Industry Coalition include: VeriSign, which operates the .com and .net registries; NeuStar, which operates the .biz and .us registries; .info operator Afilias Limited; .edu operator EDUCAUSE; and The Public Interest Registry, which operates the .org registry.

DNSSEC prevents hackers from hijacking Web traffic and redirecting it to bogus sites. The Internet standard prevents spoofing attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption.

The coalition is "a really good and public statement by all of the members that we believe that DNSSEC is vital to securing the stability and trust of the Internet, and we will do everything we can as members to get the technology in place and get our zones signed," says Rodney Joffe, senior vice president and senior technologist for NeuStar.
DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered this summer. It's because of threats such as these that the U.S. government is rolling out DNSSEC across its .gov and .mil domains.

Source: VeriSign, NeuStar and others team on DNS security, Carolyn Duffy Marsan, Network World , 12/09/2008, Retreived from networkworld.com/news/2008/120908-dns-security.html on 12/10/2008

DNSSEC Gets Its Own Coalition

"The new coalition will aim to identify and overcome the challenges and make DNSSEC deployment a global reality. One of the key players in the new DNSSEC coalition is VeriSign, the vendor that controls the Internet's root domain servers for the .com and .net domains.

"We firmly believe that DNSSEC is a technology that requires implementation and it solves a specific problem that nothing else solves," Pat Kane, vice president of naming services at VeriSign told InternetNews.com.

The specific problem in Kane's view is man in the middle cache poisoning attacks like the one discovered by Kaminsky. The basic idea behind the attack is that DNS server responses can be tampered with to redirect end users to different sites, so a user could type in "Google.com" and be taken to a phishing site instead. With encryption signed DNS information from DNSSEC, a domain name would be validated to ensure authenticity.

For the ISC's Vixie the real barriers to adoption for DNSSEC involve a number of items. For one he stresses the need to get the root zone signed including .com for DNSSEC to function as it was intended. Getting the tools together to improve the usability of DNSSEC's tools and implementation is also key. That involves DNS servers like BIND as well as many other Internet ecosystem vendors.

"We need Apple, Red Hat, Microsoft, Ubuntu and all major wireless and wireline ISP's to support DNSSEC validation in their recursive name servers and clients," Vixie said. "And we need the DNS registrars and registries to fully support DNSSEC for all their domain holders, meaning that if a domain holder signs their zones they ought to be able to upload their public keys someplace."


Full article: DNSSEC Gets Its Own Coalition, Sean Michael Kerner, retrieved from http://www.enterprisenetworkingplanet.com/netsp/article.php/3789356 on December 5, 2008

You don’t have to wait to deploy DNSSEC

Overview of DNSSEC

DNSSEC (Domain Name System Security Extensions) is a suite of specifications which implement record signing to ensure the integrity of certain types of transactions. It uses both asymmetric and symmetric cryptography for RR (Resource Record) or zone transfer transactions, respectively. To ensure the authenticity of information received by a resolver, DNSSEC provides the following (Wikipedia.org):

• Origin authentication of DNS data

• Data integrity

• Authenticated denial of existence

These capabilities are added to the existing DNS framework by using a new set of resource record (RR) types, including (nominet.org.uk):

• DNSKEY contains the public key used to sign the data in a secure zone.

• NSEC shows the interval between names in the zone. These are used in DNSSEC for ‘authenticated denial of existence’ of an address.

• RRSIG contains the signature of other RR types in the zone, including DNSKEY and NSEC. For each set of RRs for which the zone is authoritative, there exists a corresponding RRSIG RR. (An RR set, or RRSet, consists of RRs with the same name, type, and class values. All records in an RRSet are signed with the same signature.)

• DS (Designated Signer) RRs contain hashes of the keys of child zones. They’re used to build the chain of trust central to DNSSEC integrity protection.

Figure 1 shows a DNS host RR with its associated signature. When a resolver using DNSSEC receives this information in response to a name resolution query, it uses information contained in the RRSIG RR (contents of Key Tag and Signer’s Name fields) and the sender’s public key to validate the signature.

Figure 1
(nominet.org.uk)

Securing DNS with DNSSEC begins with establishing a chain of trust. Resolvers use ‘anchor keys’ to verify parent domains, beginning with the trust anchor. The trust anchor is the foundation of any chain of trust.

The public key (of the Trust Anchor) is used to verify digital signatures and the associated data. Furthermore, the public key is used to constrain the types of information for which the Trust Anchor is authoritative.

A relying party uses Trust Anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor’s public key, and by enforcing the constraints expressed in the associated data for the trust anchor. (Wikipedia.org)

In an ideal world, the DNS trust anchor for the Internet consists of the root name servers. However, there are issues.

DNSSEC Challenges

There are two categories of challenges when trying to design and implement global DNSSEC security. The first consists of technical and security issues, including (Wikipedia.org & ISC):

• There is a problem with DNSSEC’s reporting of names not present in a signed zone via the NSEC RR. It allows enumeration of zone contents. However, NSEC3 is expected to resolve this issue.

• An effective method of dealing with trust anchor key rollover has not been defined.

• Earlier versions of DNSSEC had issues. This adversely affected confidence in the ability of DNSSEC to improve DNS integrity without introducing other, potentially worse, problems.

• DNSSEC will increase DNS traffic with more requests and larger responses. Domains with high volume traffic should prepare for increased bandwidth needs.

• DNSSEC is more sensitive to time issues than standard DNS. System clocks must be reasonably accurate.

Although these five problems are important, they are minor when compared to the second set of challenges, challenges related to political posturing and mistrust, including (Wikipedia.org):

• The U.S. wants to control the trust anchor keys for the root name servers. Other countries are concerned this would give the U.S. too much control over the Internet. Centralized control by any one country is probably not acceptable to many nations.

• It’s unclear how ICANN would handle delegation of names to TLDs managed by entities with which it has no formal agreement, such as .ca.

• Some governments are encryption averse. Will they try to ban DNSSEC-backed encryption key distribution?

Some security and Internet professionals are using these challenges as a reason to not implement DNSSEC. The assumption is that it can’t be used without global acceptance. But global acceptance is not necessary to begin making DNS more reliable.

Islands of trust

Even without global implementation, DNSSEC implementation can incrementally improve DNS transaction integrity through the use of islands of trust. See Figure 2.

Figure 2
(nominet.org.uk)

Instead of the trust anchor being a root name server, it is the uk-DNSSEC domain. This could represent something as restricted as a corporate domain with internal child domains. As other levels in the DNS hierarchy transition to DNSSEC, these islands can easily establish a trust relationship with them by exchanging keys, as shown in Figure 3.

Figure 3
(SP800-81, NIST)

Note that in this example, the .com TLD does not have a trust relationship with root. However, this would not prevent all domains under .com from building chains of trust up to the .com trust anchor.

The final word

DNSSEC is not a DNS panacea, and it doesn’t encrypt data. It only signs RRs. However, it promises to establish a level of authenticity in DNS transactions. Overcoming challenges preventing global acceptance might take years. However, several country TLDs already support DNSSEC, making national islands of trust possible. Incremental steps like these will help make DNS, and the Internet, safer. They should not be ignored.

DNSSEC is a complex topic. See the following documents for detailed analysis, design and deployment:

• Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81
• DNSSEC: The Protocol, Deployment, and a Bit of Development (Cisco)
• The Case Against DNSSEC
• Resource Records for the DNS Security Extensions (IETF, RFC 4034)
• A Illustrated Guide to the Kaminsky DNS Vulnerability
• Verisign and ICANN Square off Over the DNS Root
• DNSSEC Introduction and Resources (ISC)

Source: Tom Olzak, You don’t have to wait to deploy DNSSEC, Retreived from http://blogs.techrepublic.com.com/security/?p=663 on November 19th, 2008

Proposal for Signing the DNSSEC Root

The U.S. National Telecommunications and Information Administration (NTIA) is soliciting comments on signing the DNSSEC root. Ignore the caption on the page: this is not about DNSSEC deployment, which is already happening just fine. It's about who gets to sign the root zone.

A handful of us DNSSEC dweebs wrote a response that emphasizes the technical need to start signing sooner rather than later, and strongly supports signing by either of the parties who are already trusted to put information into the root—IANA or the root zone operators. My name is on the 'From:' line simply because I was the one to email it to the NTIA. I wrote the first draft of the document, but other signers did some serious editing before we turned it in.

We hope that this will help NTIA feel more at ease about moving forwards quickly without agonizing about all the different people who want to hold the keys.

Source:circleid.com/posts/20081113_proposal_signing_dnssec_root_zone

Internaut | Antidote to DNS cache poisoning

Commentary: To protect against Domain Name System poisoning, consider these strategies

Chances are your agency is in the middle of locking down all its Domain Name System servers. Security vulnerabilities discovered this summer have caused government agencies to rush to implement the appropriately named DNS Security Extensions (DNSSEC). But keep in mind that there are a range of DNS vulnerabilities that could threaten the government's business continuity.

So let's examine DNS and the security problems a bit more closely.

As you might know, the Internet DNS is the international system for translating domain names into numeric locations. It also provides the official hierarchical naming system for all connected networks.

Many descriptions of DNS start with the world's top-level domains, including .gov, .mil, .org, .com, .edu and more. But sometimes it's easier to comprehend DNS from the bottom up. Taking that view is also a good way to understand why a government DNS server that lacks the new — and now required — DNSSEC can be vulnerable to fraud or spoofing.

So let's start the journey from an end user's computer.

When people need to reach your government agency via the Internet, they probably type www.YourAgencyName.gov into their Web browsers. Their computers, in turn, must find a way to translate that name into a numeric IP address. That's how the Internet finds your server.

Most Internet service providers maintain at least one DNS server. In fact, a local DNS server connection is part of each computer's TCP/IP properties when it is set up for Internet connectivity. The ISP's local DNS server is usually the first place the Web surfer's computer goes to look for the address translation.

If you work in a big organization, you probably have a local DNS server right in your building.

Traditionally, the local DNS server first tries to use its cache of resource record information to answer queries. Because those types of servers remember previous lookups in a cache, they are sometimes called caching name servers or caching resolvers. If the end user is trying to connect to a popular domain name, chances are it's already in the local DNS server's memory. That is called a recursive query.

But if there is no local record for the requested domain name, the DNS server can query other DNS servers on the network and send an answer back to the client. That is called an iterative query.

Somewhere between a recursive query and an iterative query, things can be spoofed or "poisoned." An attacker can send fake DNS information in response to a query. This fools the local DNS server into accepting the wrong information for a domain name. This is called cache poisoning because the server remembers the incorrect information in its cache. It will continue to provide the wrong information in future lookups.

Think of the Internet DNS as a distributed database system. Top-level domains and subdomains have to maintain one or more authoritative DNS servers that store records about domain names and the names of devices within that domain.

The DNS server at the top of the domain serves as the root. It is the ultimate authority, with the latest domain name information updated daily or even more often.

An iterative DNS lookup might need to reach all the way back upstream to the authoritative DNS root when it looks up domain names.

The good news is that authoritative name servers at the top of the DNS pyramid are not vulnerable to cache-poisoning attacks unless those servers are configured as both authoritative and recursive name servers.

The bad news is that depending on how high up in the DNS food chain a cache is poisoned, the bad data can trickle down to many other servers as domain names are looked up.

DNSSEC was created to better protect local DNS servers. That's why the federal government is hustling to install the solution on all DNS servers. But there are other things that can be done.

To protect against DNS poisoning, consider the following strategies:

* The authoritative name server on a government network should never be configured to also serve as a recursive name server.
* Install the official DNSSEC on your DNS server. Those extensions add data-origin authentication and data-integrity assurances.
* Look for patches for your server that randomly select a source port for DNS queries. Cache poisoning is more difficult if the port is not known.
* If possible, set your local DNS servers to greatly reduce the number of recursive lookups they perform.
* Fixing the government's servers is one thing. But cache poisoning can occur elsewhere on the Internet. That means a government employee connecting to a government network from an external ISP (from home or while on the road) could be vulnerable to DNS issues when trying to reach a government domain. Thus, managers should educate employees in how to spot spoofed Web pages, and they should consult ISPs to make sure they are working to address DNS security issues.

For a quick test, go to recursive.iana.org and point the test server at your home domain. That will tell you if your DNS servers are configured in a risky way.

Source: www.gcn.com/online/vol1_no1/47490-1.html

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

Secure64 Names Thomas Chalk as SVP of Sales and Marketing

Secure64 Software Corporation has hired Thomas Chalk as its Senior Vice President of Sales and Marketing. Chalk was previously with Symantec Corporation, where he was Director of Global Strategic Sales. At Secure64, Chalk will be responsible for directing all sales and marketing activities for the company as it expands those efforts to support the release of its latest product, Secure64 DNS Signer™, which enables organizations to deploy DNSSEC simply and securely. Without DNSSEC, Internet users cannot know with certainty that their Internet-based communications such as web site visits and email correspondence actually connect to the parties they intend to reach.

Chalk was a top performer at Symantec, driving rapid revenue growth within Symantec’s top tier global accounts. Prior to Symantec, Chalk held senior sales and marketing positions at Level 8 Systems, Compuware Corporation, Platinum Technology, and NCR Corporation. Chalk earned his B.S. from Oral Roberts University.

“Tom has an outstanding track record driving sales, and his skills and relationships will be an important asset for Secure64 as we tap into the European, service provider, and government markets for our DNS product line,” said Steve Goodbarn, CEO of Secure64. “Tom joins us at the perfect time with the recent unveiling of our Secure64 DNS Signer product and the recently completed round of funding to build out our sales and marketing program. After being ignored for far too long, DNS security vulnerabilities are finally getting the attention they deserve and we offer a must-have solution for any company tackling DNS security and implementing DNSSEC protocols. Tom understands that value proposition and will do a great job communicating it to customers.”

Source: businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20080916005492&newsLang=en

.ORG Applauds US Government on DNSSEC

.ORG applauds the US Government's decision last week to require all users of the .GOV domain to implement DNSSEC, and even more importantly, to sign the .GOV root.

.ORG is the first generic Top Level Domain authorized by ICANN to implement DNSSEC, and we are hard at work putting together a comprehensive plan to roll it out.

We have said it before, and we'll say it again—DNSSEC is just part of the security program. Together with DNSSEC, signing the root is critical to addressing the problem discovered by Dan Kaminsky, "cache poisoning" or "man-in-the-middle" attacks. Attackers can impersonate legitimate websites so that the user has no way of knowing that he or she is being redirected.

We have urged ICANN and government officials to take whatever steps are needed to sign all the zones in the root, and we are pleased to see that the government understands the need for its very own domain.

Source: http://www.circleid.com/posts/88291_org_government_dnssec

Welcome to The Official, Unofficial, DNS Security Extensions (DNSSEC) Blog

Welcome to The Official, Unofficial, DNS Security Extensions (DNSSEC) Blog. This blog explores ways to improve communication and information sharing about DNSSEC project. Here you will find the latest news, DNSSEC feeds, videos, training resources and other related information. Please join, comment and share your stories.