Previous month:
September 2009
Next month:
November 2009

October 2009

Nine ways to mitigate malicious domains

In collaboration with antiphishing, security, CERT, and financial communities, ICANN has collected a proposed list of measures for new TLD applicants to implement to mitigate malicious conduct involving domain names.

Vetted registry operators. Recommended by APWG and security experts in the financial industry, this measure is intended to ensure that no criminal organization can own or influence a registry operator (e.g., through indirect shareholding or ownership).

Demonstrated plan for DNSSEC deployment. An applicants will be expected to publish a detailed plan and timeline for signing their zone file and for signing delegations (domain names registered in its TLD).

Prohibition of redirection by TLDs.Acting on the recommendation of ICANN’s SSAC, the ICANN Board of Directors has agreed that applicants must return negative responses when a DNS query is made to a non-existent domain and must not synthesize (redirect) queries for error resolution or advertising purposes.

Removal of orphan glue records. Orphaned glue records frequently point to name servers that host malicious domains. This measure requires applicants to explain the policy they will enforce to ensure that a name server record in a delegation will not persist in the TLD zone file when the parent domain name is deleted from the zone.

Requirement for thick Whois records. This measure requires applicants to provide Whois output that identifies the sponsoring registrar, the status of the registration, the creation and expiration dates of each registration, contact information for the registrant and designated administrative and technical contacts, plus name server information.

Centralization of zone file access. Today, organizations must individually contract with TLDs registries to obtain (FTP) access to zone files. This does not scale to the potentially large numbers of zone files the new TLD program may spawn. This measure provides for the implementation of a common access point for organizations that require access to TLD zone files. (Look for a future article explaining how centralization of zone file access will be implemented).

Documented registry level abuse contacts and procedures. This expands the ICANN SSAC recommendation that all registrars maintain an abuse handling process and publish contact information. Registries will similarly be asked to have public and easily accessible abuse handling agents.

Participation in the Expedited Registry Security Request process. A GTLD registry uses the ERSR process to request a contractual waiver for actions it might take or has taken to mitigate or eliminate a present or imminent security incident of global significance. This measure allows ICANN and registries to maintain operational security during an incident.

Draft Framework for High Security Zones Verification.The high security zones verification program establishes a set of operational and security control standards that collectively improve confidence in the ability to maintain security, availability, confidentiality, and privacy of systems and information assets supporting critical registry IT and business operations.

The publication of this explanatory memorandum and consideration of these measures for new GTLDs within the ICANN process is a landmark event. However, it's critical that all interested parties recognize that this is a discussion draft only. Simply put, this is not a "done deal." To ensure that any or all of these measures are incorporated into the new TLD application process, you must voice your support through the ICANN public comment process

Is office cleaning a proper analog for web security?

Nikolai Bezroukov offers an interesting view of Unix Security:

"The main problem with Unix security is that it is very similar to office cleaning services. It is a dull and unrewarding task that needs constant attention and often involves fighting against your own management."

This characterization may apply to Unix security, but it falls shy of being sufficient for web security in several respects:

It assumes that an office exists. Web applications span multiple servers, hosting sites and networks. Containing web applications to a particular domain of control may be a consideration during a design phase but this objective is often neglected during growth stages and ultimately abandoned.

It assumes that cleanliness is a design and operational objective. Web application cleanliness translates to keeping a web site clean of vulnerabilities. Few organizations put a premium on securing web applications over publishing content as quickly as humanly possible and considerable data are available to support this assertion (see Report: Nearly 6 Million Infected Web Pages Across 640K Compromised Sites).

It assumes a steady state of dull and unrewarding. WebSense reported that in 1H2009,  over three-quarters of web sites  with malicious code were found to be legitimate sites that had been compromised. That's not dull but dramatic and frightening. It's also rewarding but not for the legitimate web operators.

One aspect of Nikolai's characterization of Unix security that does apply is that web security is a task that needs constant attention. Specifically, every aspect of web application you host needs attention from design through deployment and continuing for as long as the application remains in a production environment.

Fighting with one's management is disputable. My experience is that management doesn't always fight against investing in securing web applications. The problem not whether management fights but when. Management rarely opposes investments in security in the aftermath of an incident involving a breach or defacement of a web site. Management needs to assess risk more carefully early and continuously during the lifetime of a web application and security staff need to help them by providing good data to assess that risk.