dinsdag 27 januari 2009

Public key infrastructure

By Anon on Mon, 01/12/2009 - 12:33pm.

Can you explain me the public key infrastructure in detail or reference any book with detailed explanation over PKI.
Answer by Ron Nutter

Expert's answer
I found this explanation on Wikipedia that should help get you started:
In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA) . For each user, the user identity, the public key, their binding, validity conditions and other attributes are made unforgeable in public key certificates issued by the CA.
I checked Sourceforge and found an open source book on PKI that would also be a good reference to review. I went to Amazon's website and found several books on PKI that should also be good sources of information on this subject as well.

zondag 28 september 2008

SAS70

Nu ook AZL Services volledig SAS-gecertificeerd!

Op 31 januari jl. heeft –na AZL Vermogensbeheer– ook Services de SAS type II verklaring ontvangen. Pensioen- en vermogensbeheer van AZL voldoen daarmee aan de hoogste normen die internationaal aan proces- en risicobeheersing worden gesteld. Dit is een belangrijke stap in een markt waar transparantie en vertrouwen in de dienstverleningsrelatie van groot belang zijn.
Wet betekent SAS?SAS70 (Statement on Auditing Standards number 70. Service Organisations) is ontwikkeld door het American Institute of Certified Public Accountants (AICPA), de Amerikaanse beroepsorganisatie van accountants. Het is een internationaal erkende auditing standaard en wordt steeds meer beschouwd als een kwaliteitskeurmerk. In het SAS70 rapport staat beschreven hoe de interne beheersingsmaatregelen van een dienstverlenende organisatie zijn opgezet alsmede hoe geaudit wordt om de toereikendheid van de maatregelen te beoordelen en om de feitelijke werking vast te stellen.
Twee soorten SAS70 verklaringen, type-I en type-IIDe SAS70 type-I-verklaring beschrijft de interne controles van de dienstverlenende organisatie. Een externe accountant toetst of de controles daadwerkelijk bestaan en worden nageleefd teneinde de kwaliteit van de dienstverlening te waarborgen. De SAS70 type-II-verklaring geeft een oordeel over de effectieve en langdurige werking van de interne controle maatregelen. Er wordt gedurende tenminste zes maanden gecontroleerd of alle processen en controles conform de voorschriften worden uitgevoerd. Daarbij wordt niet alleen de aandacht gericht op de administratieve organisatie, maar ook de ondersteunende geautomatiseerde systemen zijn een belangrijk onderdeel.Wanneer een dienstverlener in bezit is van een SAS70-verklaring heeft de opdrachtgever de best denkbare garantie dat de service van de hoogste kwaliteit is en de vereiste transparantie bezit. AZL heeft dat belang al in een vroeg stadium onderkend en is op eigen initiatief gestart om voor onze klanten in de pensioensector SAS-verklaringen op te stellen. Inmiddels heeft ook De Nederlandsche Bank (DNB) de relatie gelegd tussen de richtlijnen van uitbesteding en de SAS70-verklaringen.

Vermogensbeheer en PensioenenAangezien het karakter van de activiteiten van vermogensbeheer en pensioenbeheer erg verschillend van aard zijn, zijn twee SAS verklaringen opgesteld. De proces- en risicobeheersing van AZL Vermogensbeheer is in 2005 nauwgezet getoetst, wat uitmondde in de SAS- verklaringen. Nu heeft ook Pensioenen (AZL Services) heeft de SAS type-II-verklaring op 31 januari jl. ontvangen.

Een SAS-verklaring gaat verder dan een Service Level Agreement. Ze maakt de kwaliteit van de uitbestede processen namelijk inzichtelijk, zodat pensioenfondsen erop kunnen vertrouwen dat de serviceorganisatie de uitbestede activiteit goed beheerst en controleert.

Een SAS70-rapportage is ook veel transparanter dan een ISO-certificering omdat het een uitgebreide rapportage omvat inclusief de bevindingen van de externe accountant.
Lagere accountantskosten voor pensioenfondsen?Een SAS70-rapport kan ook uitermate nuttig zijn voor de externe accountant van de uitbestedende organisatie bij de controle van de jaarrekening. In het rapport heeft AZL de processen beschreven die uiteindelijk leiden tot een bepaalde balanspost, de daarmee gepaard gaande risico’s, alsmede de daarbij passende controlemaatregelen. Een algemene toetsing van deze processen kan in het kader van de jaarrekeningcontrole van het pensioenfonds achterwege blijven omdat de accountant kan steunen op de dossiers die in het kader van SAS zijn opgesteld en die door de externe accountant van AZL zijn beoordeeld. De accountant van het pensioenfonds is zodoende in staat de dossiers en controles gemakkelijker te beoordelen en er in hun jaarrekeningcontrole gebruik van maken. AZL raadt haar pensioenfondscliĆ«nten aan dit aspect mee te nemen in de onderhandelingen met hun externe accountants, zodat de accountantscontrole sneller en goedkoper kan verlopen
26-3-2007

SAS70

Nu ook AZL Services volledig SAS-gecertificeerd!
Op 31 januari jl. heeft –na AZL Vermogensbeheer– ook Services de SAS type II verklaring ontvangen. Pensioen- en vermogensbeheer van AZL voldoen daarmee aan de hoogste normen die internationaal aan proces- en risicobeheersing worden gesteld. Dit is een belangrijke stap in een markt waar transparantie en vertrouwen in de dienstverleningsrelatie van groot belang zijn.
Wet betekent SAS?SAS70 (Statement on Auditing Standards number 70. Service Organisations) is ontwikkeld door het American Institute of Certified Public Accountants (AICPA), de Amerikaanse beroepsorganisatie van accountants. Het is een internationaal erkende auditing standaard en wordt steeds meer beschouwd als een kwaliteitskeurmerk. In het SAS70 rapport staat beschreven hoe de interne beheersingsmaatregelen van een dienstverlenende organisatie zijn opgezet alsmede hoe geaudit wordt om de toereikendheid van de maatregelen te beoordelen en om de feitelijke werking vast te stellen.
Twee soorten SAS70 verklaringen, type-I en type-IIDe SAS70 type-I-verklaring beschrijft de interne controles van de dienstverlenende organisatie. Een externe accountant toetst of de controles daadwerkelijk bestaan en worden nageleefd teneinde de kwaliteit van de dienstverlening te waarborgen. De SAS70 type-II-verklaring geeft een oordeel over de effectieve en langdurige werking van de interne controle maatregelen. Er wordt gedurende tenminste zes maanden gecontroleerd of alle processen en controles conform de voorschriften worden uitgevoerd. Daarbij wordt niet alleen de aandacht gericht op de administratieve organisatie, maar ook de ondersteunende geautomatiseerde systemen zijn een belangrijk onderdeel.Wanneer een dienstverlener in bezit is van een SAS70-verklaring heeft de opdrachtgever de best denkbare garantie dat de service van de hoogste kwaliteit is en de vereiste transparantie bezit. AZL heeft dat belang al in een vroeg stadium onderkend en is op eigen initiatief gestart om voor onze klanten in de pensioensector SAS-verklaringen op te stellen. Inmiddels heeft ook De Nederlandsche Bank (DNB) de relatie gelegd tussen de richtlijnen van uitbesteding en de SAS70-verklaringen.

Vermogensbeheer en PensioenenAangezien het karakter van de activiteiten van vermogensbeheer en pensioenbeheer erg verschillend van aard zijn, zijn twee SAS verklaringen opgesteld. De proces- en risicobeheersing van AZL Vermogensbeheer is in 2005 nauwgezet getoetst, wat uitmondde in de SAS- verklaringen. Nu heeft ook Pensioenen (AZL Services) heeft de SAS type-II-verklaring op 31 januari jl. ontvangen.

Een SAS-verklaring gaat verder dan een Service Level Agreement. Ze maakt de kwaliteit van de uitbestede processen namelijk inzichtelijk, zodat pensioenfondsen erop kunnen vertrouwen dat de serviceorganisatie de uitbestede activiteit goed beheerst en controleert.

Een SAS70-rapportage is ook veel transparanter dan een ISO-certificering omdat het een uitgebreide rapportage omvat inclusief de bevindingen van de externe accountant.
Lagere accountantskosten voor pensioenfondsen?Een SAS70-rapport kan ook uitermate nuttig zijn voor de externe accountant van de uitbestedende organisatie bij de controle van de jaarrekening. In het rapport heeft AZL de processen beschreven die uiteindelijk leiden tot een bepaalde balanspost, de daarmee gepaard gaande risico’s, alsmede de daarbij passende controlemaatregelen. Een algemene toetsing van deze processen kan in het kader van de jaarrekeningcontrole van het pensioenfonds achterwege blijven omdat de accountant kan steunen op de dossiers die in het kader van SAS zijn opgesteld en die door de externe accountant van AZL zijn beoordeeld. De accountant van het pensioenfonds is zodoende in staat de dossiers en controles gemakkelijker te beoordelen en er in hun jaarrekeningcontrole gebruik van maken. AZL raadt haar pensioenfondscliĆ«nten aan dit aspect mee te nemen in de onderhandelingen met hun externe accountants, zodat de accountantscontrole sneller en goedkoper kan verlopen
26-3-2007

maandag 22 september 2008

vv

Privacy breaches related to electronic medical records seem to appear in the news regularly. The Walter Reed Army Medical Center started to notify 1,000 patients of a privacy breach in June. A few days earlier, the University of California San Francisco (UCSF) disclosed that it had to notify more than 3,000 patients of a privacy breach in the Department of Pathology.These news stories bring to mind a Markle Foundation study released at the end of 2007. Though a majority of Americans believed electronic data can improve care, 80 percent were very concerned about the risk of access without their authorization, including access related to marketing, identity theft and fraud. The Association of American Physicians and Surgeons published a similar study earlier in 2007 that found 70 percent of patients asked doctors to suppress information due to privacy concerns, and 50 percent believed control of their records was already lost.The pressure to move records to an electronic format is stronger than ever, but at the same time the risk and awareness of privacy violations are on the rise. In tandem to the shift in opinion are more frequent HIPAA prosecutions by the Department of Justice. The FBI, for example, published a clear warning on April 15, 2008, after a nurse pleaded guilty to unlawful access to patient information:“What every HIPAA-covered entity needs to realize and reinforce to its employees is that the privacy provisions of HIPAA are serious and have significant consequences if they are violated,” (Jane W.) Duke (United States Attorney for the Eastern District of Arkansas) stated. […] “We are committed to providing real meaning to HIPAA. We intend to accomplish this through vigorous enforcement of HIPAA's right-to-privacy protections and swift prosecution of those who violate HIPAA for economic or personal gain or malicious harm.” The rapid adoption and evolution of computer-based processes across dispersed and complex health care environments made the confidentiality, integrity and availability of patient data issues of public policy. Privacy of information in health care is a long-standing tenet of medical ethics, of course, but the move to portable electronic formats brought forward a new generation of security and interoperability challenges.Log management for HIPAAPatients, as well as practitioners, want to view and modify medical records more freely, but with electronic records, it is not immediately clear who else might be looking. Preserving established levels of privacy depends on efforts to better report who should or should not, and who did and did not, have access to electronic patient medical records. In other words, effective logging practices can meet the need for electronic personal health information (EPHI) protection and access management. The U.S .National Institute of Standards and Technology (NIST) Special Publication (SP) 800-66 includes the following question about HIPAA integrity (§164.312(c)(1): “Are current audit, logging, and access control techniques sufficient to address the integrity of the information?”Effective log management for HIPAA can be described in five steps. It first should automate the collection and consolidation of log data. Secondly, it also should automate analysis of the data and generate reports related to EPHI control and access. These two automation goals will save considerable time for operations alone and add considerable value to a security team. With data being collected consistently and analyzed regularly, log management should enable better event management, such as monitoring for unauthorized software, login attempts or other suspicious behavior and discrepancies. Finally, log management should be used to identify and respond to incidents.A covered entity that intends to maintain the integrity of its EPHI must maintain sufficient security controls to know what happens to EPHI, when it happens, and who (or what) acted on it. Capturing this information is easy; pull together the logs of all the systems that touch EPHI. Unfortunately, this log data usually comes from many large and growing sources that have inconsistent content, time stamps, and formats. Covered entities therefore need top-level commitment to a log management solution if they are to effectively store patient data and review its access, change and movement patterns.The success of log management depends on several factors:
Senior management support
Clear statements of objectives and procedures
Security training for log administrators and users Log management requires not only a reasonable amount of data to be collected (which can be archived for future review) but also the ability to detect in real time symptoms of abuse or violations. If Walter Reed and UCSF had had effective log management systems, their IT departments could have immediately alerted management to the presence of file-sharing software or of file traffic going across the network to unauthorized external locations. This is an example of how the use of logs would help satisfy HIPAA's “Protection from Malicious Software, §164.308(a)(5)(ii)(B)”. Even if logs revealed file-sharing software in a system not known to keep EPHI, a management system could pinpoint systems with malicious software and thus lead to a more timely investigation. This use of logs would help satisfy “Security Incident Procedures, §164.308(a)(6)(ii).”The electronic format of data is a double-edged sword. It brings easier access, which makes it popular, but new barriers and controls against attack need to be evolved for the electronic medium. The shift to computers has dramatically increased the need for better information security and access controls, such as robust log management, to preserve even the status quo for privacy in health care.

On the tracks of medical data: Electronic records pressure

On the tracks of medical data: Electronic records pressure

Privacy breaches related to electronic medical records seem to appear in the news regularly. The Walter Reed Army Medical Center started to notify 1,000 patients of a privacy breach in June. A few days earlier, the University of California San Francisco (UCSF) disclosed that it had to notify more than 3,000 patients of a privacy breach in the Department of Pathology.These news stories bring to mind a Markle Foundation study released at the end of 2007. Though a majority of Americans believed electronic data can improve care, 80 percent were very concerned about the risk of access without their authorization, including access related to marketing, identity theft and fraud. The Association of American Physicians and Surgeons published a similar study earlier in 2007 that found 70 percent of patients asked doctors to suppress information due to privacy concerns, and 50 percent believed control of their records was already lost.The pressure to move records to an electronic format is stronger than ever, but at the same time the risk and awareness of privacy violations are on the rise. In tandem to the shift in opinion are more frequent HIPAA prosecutions by the Department of Justice. The FBI, for example, published a clear warning on April 15, 2008, after a nurse pleaded guilty to unlawful access to patient information:“What every HIPAA-covered entity needs to realize and reinforce to its employees is that the privacy provisions of HIPAA are serious and have significant consequences if they are violated,” (Jane W.) Duke (United States Attorney for the Eastern District of Arkansas) stated. […] “We are committed to providing real meaning to HIPAA. We intend to accomplish this through vigorous enforcement of HIPAA's right-to-privacy protections and swift prosecution of those who violate HIPAA for economic or personal gain or malicious harm.” The rapid adoption and evolution of computer-based processes across dispersed and complex health care environments made the confidentiality, integrity and availability of patient data issues of public policy. Privacy of information in health care is a long-standing tenet of medical ethics, of course, but the move to portable electronic formats brought forward a new generation of security and interoperability challenges.Log management for HIPAAPatients, as well as practitioners, want to view and modify medical records more freely, but with electronic records, it is not immediately clear who else might be looking. Preserving established levels of privacy depends on efforts to better report who should or should not, and who did and did not, have access to electronic patient medical records. In other words, effective logging practices can meet the need for electronic personal health information (EPHI) protection and access management. The U.S .National Institute of Standards and Technology (NIST) Special Publication (SP) 800-66 includes the following question about HIPAA integrity (§164.312(c)(1): “Are current audit, logging, and access control techniques sufficient to address the integrity of the information?”Effective log management for HIPAA can be described in five steps. It first should automate the collection and consolidation of log data. Secondly, it also should automate analysis of the data and generate reports related to EPHI control and access. These two automation goals will save considerable time for operations alone and add considerable value to a security team. With data being collected consistently and analyzed regularly, log management should enable better event management, such as monitoring for unauthorized software, login attempts or other suspicious behavior and discrepancies. Finally, log management should be used to identify and respond to incidents.A covered entity that intends to maintain the integrity of its EPHI must maintain sufficient security controls to know what happens to EPHI, when it happens, and who (or what) acted on it. Capturing this information is easy; pull together the logs of all the systems that touch EPHI. Unfortunately, this log data usually comes from many large and growing sources that have inconsistent content, time stamps, and formats. Covered entities therefore need top-level commitment to a log management solution if they are to effectively store patient data and review its access, change and movement patterns.The success of log management depends on several factors:
Senior management support
Clear statements of objectives and procedures
Security training for log administrators and users Log management requires not only a reasonable amount of data to be collected (which can be archived for future review) but also the ability to detect in real time symptoms of abuse or violations. If Walter Reed and UCSF had had effective log management systems, their IT departments could have immediately alerted management to the presence of file-sharing software or of file traffic going across the network to unauthorized external locations. This is an example of how the use of logs would help satisfy HIPAA's “Protection from Malicious Software, §164.308(a)(5)(ii)(B)”. Even if logs revealed file-sharing software in a system not known to keep EPHI, a management system could pinpoint systems with malicious software and thus lead to a more timely investigation. This use of logs would help satisfy “Security Incident Procedures, §164.308(a)(6)(ii).”The electronic format of data is a double-edged sword. It brings easier access, which makes it popular, but new barriers and controls against attack need to be evolved for the electronic medium. The shift to computers has dramatically increased the need for better information security and access controls, such as robust log management, to preserve even the status quo for privacy in health care.

Feds Tighten security on .gov

When you file your taxes online, you want to be sure that the Web site you visit -- http://www.irs.gov/ -- is operated by the Internal Revenue Service and not a scam artist. By the end of next year, you can be confident that every U.S. government Web page is being served up by the appropriate agency.
That’s because the feds have launched the largest-ever rollout of a new authentication mechanism for the Internet’s DNS. All federal agencies are deploying DNS Security Extensions (DNSSEC) on the .gov top-level domain, and some expect that once that rollout is complete, banks and other businesses might be encouraged to follow suit for their sites.

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.
With DNSSEC deployed, federal Web sites “are less prone to be hacked into, and it means they can offer their services with greater assurances to the public,’’ says Leslie Daigle, Chief Internet Technology Officer for the Internet Society. "DNSSEC means more confidence in government online services.’’

The U.S.’s government DNSSEC mandate is "significant,’’ says Olaf Kolkman, a DNSSEC expert and director of NLnet Labs, a nonprofit R&D foundation in the Netherlands. "First, the tool developers will jump in because there is the U.S. government as a market….Second, there is suddenly a significant infrastructure to validate against.’’

The White House DNSSEC mandate comes just weeks after the July disclosure of one of the most serious DNS bugs ever found. The Kaminsky bug -- named after security researcher Dan Kaminsky who discovered it -- allows for cache poisoning attacks, where a hacker redirects traffic from a legitimate Web site to a fake Web one without the user knowing.
White House officials said their DNSSEC mandate has been in the works since February 2003, when the Bush Administration released its National Strategy to Secure Cyberspace. The cybersecurity strategy, which was prompted by the Sept. 11, 2001, terrorist attacks, included the goal of securing the DNS.
Under a separate, but related, cybersecurity program called the Trusted Internet Connection initiative, the U.S. government is reducing the number of external Internet connections it operates from more than 8,000 to less than 100.

The DNSSEC mandate "was issued as a consequence of agencies having completed the initial consolidation of external network connectivity [through the Trusted Internet Connection initiative],’’ said Karen Evans, administrator for the Office of E-Government and Information Technology at the Office of Management and Budget (OMB), in a statement. "The Kaminsky DNS bug was not a factor.’’

DNS hardware and software vendors that are scrambling to add DNSSEC capabilities to their products predict the one-two punch of the Kaminsky bug followed by the White House mandate will drive DNSSEC deployment across the Internet.
"The timing couldn’t be better right now, with Dan Kaminsky’s vulnerability and the huge spotlight that focused on DNS security,’’ says Mark Beckett, vice president of marketing for Secure64, a DNS vendor that began shipping an automated system for deploying DNSSEC in September. "Even though we have a patch out there for the Kaminsky bug…the only long-term solution to this problem is DNSSEC.’’
The OMB mandate is "significant, but it’s the tip of the iceberg,’’ says Rodney Joffe, senior vice president and senior technologist for NeuStar, which sells the UltraDNS managed services suite and operates several top-level domains (TLDs) including .us and .biz. "All the other TLDs are now scrambling to work on DNSSEC. It’s a sea change. There is no question that 2009 will be the year of DNSSEC.’’

The OMB issued a mandate in August that requires all federal agencies to support DNSSEC.
The memo states that .gov must be cryptographically signed at the top level by January 2009, and that all subdomains under .gov, such as www.irs.gov, must be signed by December 2009.
While the memo focuses on the .gov domain, the U.S. Defense Information Systems Agency says it intends to meet OMB's DNSSEC requirements on the .mil domain, too.
OMB is working with agencies to finalize their plans for deploying DNSSEC on their domains and subdomains, and these plans are expected to be finalized by mid-October.
"The federal government has been working with many organizations regarding DNSSEC and is preparing for deployment,’’ Evans says. "One of the resources available, the Secure Naming Infrastructure Pilot (SNIP), is a testbed available to all government agencies so they can test their DNSSEC operations prior to deployment.’’

To meet the mandate, federal agencies must upgrade their DNS servers to support the new protocol, buy network management tools to support DNSSEC, and provide training to their network management staff.

"The real impact is that you are changing the way the DNS is managed within the .gov domain,’’ says Scott Rose, a computer science with the National Institute for Standards and Technology (NIST) Information Technology Laboratory. "The largest cost in DNSSEC deployment is setting up procedures and software for key management.’’Agencies will pay for DNSSEC out of their existing IT infrastructure budgets, Evans says.
"People who want to enable their domain names, say those of their Web sites, to be validated with DNSSEC have to do some investing. They have to update their infrastructure, and they have to go through a learning curve,’’ says Kolkman, who called the OMB deadline of December 2009 “ambitious.’’
"We think it’s doable,’’ Rose says of the .gov DNSSEC deadline. "We think it sends a strong signal that the U.S. government is committed to DNSSEC and to improving Internet security within the .gov domain.’’
By rolling out DNSSEC on .gov, the federal government is doing what it can to improve the security of the communications it has over the Internet with citizens and contractors.
The U.S. government is "standing up and saying that for all the right reasons, DNSSEC is the path to pursue,’’ Daigle says. "It’s a good move because it’s proactive. They’re trying to address the security of their DNS resources before there is the kind of critical security disaster that many people have posited is needed before DNSSEC would be deployed.’’
Experts say the OMB mandate may encourage ISPs to support DNSSEC, too, as their customers are heavy users of .gov Web sites.
"By the end of the year, a large number of ISPs will all have DNSSEC deployed,’’ Joffe predicts. "There will no longer be an excuse for ISPs not to implement DNSSEC knowing they have customers that go to government Web sites.’’
The U.S. federal government will be among the first organizations in the world to deploy security enhancements to the top-level domain it operates, which is .gov.
Countries that have deployed DNSSEC in their top-level domains include Sweden, Puerto Rico, Bulgaria and Brazil.

DNS vendors hope the federal DNSSEC mandate will lead to broader adoption of the standard across the Internet.
"We’ve seen a fair amount of interest in DNSSEC outside the U.S….but we haven’t had a whole lot of momentum inside the U.S.,’’ says Cricket Liu, vice president of architecture at InfoBlox. "My hope is that this is the beginning of getting the ball rolling in the U.S.’’
What about the root and .com?
While significant, the OMB mandate is missing a few key components that are necessary to drive DNSSEC deployment across the Internet.
First, the OMB memo says nothing about when the Internet’s root servers will support DNSSEC.
Second, the memo doesn’t address whether the U.S. government will require VeriSign, which operates the popular .com and .net top-level domains, to support DNSSEC.
The National Telecommunications and Information Administration (NTIA), the arm of the U.S. government that oversees the Internet’s DNS infrastructure, has not set a deadline for DNSSEC deployment for the root servers, .com or .net.
"NTIA recognizes the potential benefits of a DNSSEC signed root zone file and is actively examining various implementation models in coordination with other U.S. government agencies as well as all the other relevant stakeholders, including [The Internet Corporation for Assigned Names and Numbers] and VeriSign, with whom the Department has existing relevant legal relationships,’’ according to an NTIA statement.
NTIA’s statement said the agency will not take any action that would affect the operational stability or efficiency of the DNS.
"A DNSSEC signed root zone would represent one of the most significant changes to the DNS infrastructure since it was created; therefore any changes cannot be taken lightly considering that the Internet DNS is a global infrastructure on which the global economy relies,’’ the statement said.
VeriSign has been running DNSSEC pilot projects for several years, and it offers free DNSSEC tools on its Web site for developers.
VeriSign operates two of the Internet’s 13 root servers. In March 2008, VeriSign created a DNSSEC testbed for all the root zone operators to use.
"The testbed is going well,’’ says Ken Silva, CTO for VeriSign. "We’ve gathered a lot of data ….This is all part of the process to be ready if and when the full Internet is ready to deploy DNSSEC.’’

VeriSign hasn’t committed to supporting DNSSEC in .com and .net. As of June 2008, .com and .net supported 87.3 million domain names, a figure that is up 20% from the previous year, according to VeriSign.

Silva says .com and .net will not be upgraded with DNSSEC until after the root.
"This is not something that is going to happen overnight,’’ says Silva, who predicts it will be another three years until the root servers support DNSSEC. "For full DNSSEC deployment Internet-wide, you could be talking decades.’’
Experts say full-scale deployment of DNSSEC won’t happen until the root., .com and .net are authenticated with digital signatures.
"Having the root signed is fairly important,’’ Kolkman says. "Obviously, .com is the 300-pound gorilla in the room. If .com were signed, that would pull a lot of people into DNSSEC, but having the root signed gives a more global signal.’’
Chicken-and-egg dilemma
Internet engineers developed DNSSEC in 1997, but the technology hasn’t been widely deployed because it suffers from the classic chicken-and-egg dilemma.
DNSSEC doesn’t protect against spoofing attacks unless it’s widely deployed across the Internet’s DNS infrastructure. Web site operators don’t benefit much from DNSSEC unless it’s deployed at the top-level domain. The top-level domains haven’t supported DNSSEC because there hasn’t been demand from Web site operators.
With the OMB mandate, it appears the egg is cracking. Other top-level domains interested in rolling out DNSSEC include the Pubic Interest Registry’s .org. http://blog.internetgovernance.org/blog/_archives/2008/4/25/3659794.html and Poland’s country code, .pl
One reason DNSSEC has been slow to catch on is that it is difficult to deploy. Network managers will need tools that help them generate and store cryptographic keys in a secure manner, plus they will have to update those keys on a regular basis in order to support DNSSEC.
"It has been a complicated and time-consuming exercise for people to deploy DNSSEC,’’ Beckett says. That’s one reason Secure64 received a $1 million grant from the Department of Homeland Security earlier this year to develop an automated DNSSEC signing solution that became the just-released Secure64 DNS Signer product.
"DHS wanted to prime the pump to get commercial products out there to remove that complexity and to make it possibility to deploy DNSSEC in a matter of days or weeks, rather than the months and months it might take them today,’’ Beckett adds.

OMB says enough commercial DNSSEC products are available to warrant deployment across .gov.
"The U.S. enjoys a robust and dynamic commercial marketplace that will continue to meet our needs,’’ Evans says. "The Department of Homeland Security Science and Technology Directorate has been leading the research and development associated with this initiative. The National Institute for Standards and Technology is responsible for developing DNSSEC standards, and the General Services Administration is ensuring service-based solutions are available.’’
DNSSEC experts are encouraging corporate network managers to view the federal mandate as a sign that DNSSEC is real.
"What I think you should take away from this as corporate IT managers is that DNSSEC is coming. DNNSSEC is real, and it’s out of the experimental stage,’’ Daigle says. "It’s OK to buy products and equipment to support it.’’
Network managers also should take a good look at DNSSEC because of the Kaminsky bug, experts say. This is especially true of industries such as banking and e-commerce that battle phishing attacks.
The Kaminsky bug "is a verifiable and credible business case for actually deploying DNSSEC, not just in the government but in private industry,’’ Joffe says. "The only solution we know of that is 100% correct in solving the problem of DNS cache poisoning is DNSSEC.’’