[SecurityRatty] tag: agreements

Interop NY Keynotes: Novell

Wed, 17 Sep 2008 10:40:03 +0000

Novell President and Chief Executive Officer Rob Hovsepian learned what interoperability meant when he had a large retailer client who wanted all his businesses to connect and close-out at the same time.

Making IT work as One

How does my company stay efficient while we’re using technologies around interoperability? How can innovation help my business?

Top business needs:

Reduce cost
Manage complexity
Mitigate risk

Mixed IT environments are a reality for almost all organizations. Different environments, architectural strategies, desktop profiles, etc. There are benefits to having mixed source environments, although homogenous environments are ideal. On average 46,000 hours in an organization are spent on Sarbanes-Oxley standards.

Some considerations to make IT work as one:

Strategy
Solutions
Ecosystem

Strategy

Actionable strategy is key. The emergence of three silos (applications, systems and infrastructure, and operations) are now moved into one. There is a lot of pressure to make these pieces come together.

Solutions

You need focused solutions to solve problems today while keeping an eye to the future. There are three main needs: the data center, end-user computing, and identity and security. This is also what is the most important to the market right now. The end goal is the agility of the data center.

Data Center Challenges

Create an agile IT infrastructure
Address power and space constraints
Deliver performance, security and availability
Manage hardware, software and labor costs
Meet service level agreements

Data Center Solutions

Workload management - green IT and server efficiency, unified physical and virtual environment
Virtualization and Consolidation - business continuity and disaster recovery
Enterprise Servers

End-User Computing Solutions

Collaboration
Enterprise desktops - Novell uses Linux and Open Office, interesting to note
Endpoint management

Identity and Security Challenges

Minimize risk, uncertainty and policy violations
Provide timely and secure access to information
Ensure, document and prove information security
Reduce the cost of proving compliance
Reduce the cost and complexity of governance

Identity and Security Solutions

Identity and Access Management - user provisioning, role management, access management
Compliance Management - Audit, Governance, Risk Management and Compliance (GRC), IT controls automation, Security, Information and Event Management (SIEM)

Ecosystem

The ecosystem is powerful. Companies should challenge partners for innovation and interoperability.

Community Innovation - open source and open standards

IT Landscape - Mixed IT Environments

Consulting, systems integration vendors
Application vendors
Systems software vendors (Novell)
Hardware, network vendors

How does your ecosystem help your company? How do your partners help? What is their role in the industry to help you? How are all the vendors in the industry helping you?

If a tree falls in someone else's silo...

Mon, 08 Sep 2008 08:29:57 +0000

Must read post by Iang:

In the case of phishing, it is relatively clear. The developers believe the PKI book. The PKI people believe in the efficacy of digital signatures to prove stuff. The cryptographers believe in the perfection of mathematics, and the security world believes in the completeness of their own learning. They are all wrong, but only at the large level of generalisations, not at the detailed level of particular claims. Any one of the claims, in isolation can be shown to be true. But, generalising these brittle claims to be solid building blocks is a completely different question. Few of the claims are strong enough to partake in a general model without severe support; the general model of secure browsing is the best evidence of how it is secure in name only.

How then is it built? By accident or by design, a series of claims meet together in a holy ring of righteous architecture. Each of the proponents claim loudly that their part is strong, but the ring has no strength. Eventually, one of the claims in the links is broken. For phishing, the browsers never did have the potential to show authenticity; not only did they not have the security strength to do it (c.f., Skype v. CSRF), they didn't even do it in practice (recall the lost padlock?), and their recent efforts to show authenticity (c.f. colour debate) reveal how far they are from understanding even the goal, let alone the implementation. Once that link was broken, and money was made, all the others revealed their weaknesses, as crooks systematically worked to breach the lot.

If we look at the wider financial collapse, now underscored by the nationalisation of the worlds biggest financiers of mortgages ($ 5.3 trillion.... or is it $ 5.4 ?), we see the same pattern. The bankers believed in their product. The originators believed in their origination, the securitizers believed in their free market and accurate price, and the holders believed in the assets. The CDO, the subprime, the other 100 special names, each was a contract. Each was clear in and of itself. But, when placed end-to-end, in a line, with a bunch of other agreements, the claims that were good in isolation were not strong enough to participate in the super-claim made of the overall edifice.
The financial system was built like a bridge; each piece rested on the previous one. And then, the clever architects bent the bridge around ... and around again, until the first piece met the last. The elegant keystone of finance was to finally lift up the first one to rest on the last.

Thus, the banks themselves invested their capital in their own product.

Maybe computer security failures won't ever result in $6 trillion worth of failures, but every day we bet more and more of our economy on networked computer systems. And those architectures are built on the precise mindsets that Iang portrays.

Banks are apt to comply with their auditor's request to run scans their resources, but what they do not do is build systems with architectural integrity. Why do you log in with a username and password? Why are the messaging systems not locked down? Where are the strong identity tokens and claims? Do banks know that they are not on a mainframe any more?

Sadly, they don't - they build a web silo and then they hook it up the legacy silo and put a wide open messaging system in between. There is no end to end security design, just silos. The banks build distributed systems, they operate distributed systems, but they don't design distributed systems.

It is too bad, its never been a core competency of banks to design systems, but it never mattered before because IBM just drew up the plan and the banks followed it. Now everyone has their own plan, but the security architecture reflects an auditor's checklist and manager's golf games not risk management decisions or security architecture.

If a tree falls in someone else's silo, your system doesn't hear until their silo knocks yours over...

Black Hat Talks Pulled After Industry Pressure

Wed, 06 Aug 2008 08:39:16 +0000

A few Apple-related talks scheduled for next week’s Black Hat conference have been cut from the line-up, presumably because they would reveal too much insider information about vulnerabilities.

Brian Krebs has the details–

Charles Edge, a researcher from Georgia, had been slated to discuss his research on a weakness that could be used to defeat FileVault encryption on the Mac. But sometime last week, Black Hat organizers pulled his name and presentation listing from its schedule of talks.

Contacted via cell phone, Edge said he signed confidentiality agreements with Apple, which prevents him from speaking on the topic and from discussing the matter further.

Almost every year, much of the drama leading up to and during Black Hat seems to revolve around talks that are canceled or censored at the last minute for various legal reasons.

Read the full article here.

Summarizing July's Threatscape

Fri, 01 Aug 2008 12:08:24 +0000

July's threatscape -- consider going through June's summary as well -- once again demonstrated that nothing is impossible, the impossible just takes a little longer where the incentive would be the ultimate monetization of the process.

Russian hacktivists attacking Lithuania and Georgia, several Storm Worm campaigns, a couple of new malware tools, Neosploit team abandoning support for their web malware exploitation kit, CAPTCHA for several of the most popular free email providers getting efficiently attacked in order to resell the bogus accounts registered in the process, several copycat SQL injects next to the evasion techniques applied by the copycats, botnets continuing to commit click fraud and generate revenue for those who own or have rented them, an infamous money mule recruitment service taking advantage of the fast-fluxed network provided by the ASProx botnet - pretty interesting month indeed.

01. Decrypting and Restoring GPcode Encrypted Files -
The GPcode authors read the news too, and are catching up with the major weaknesses pointed out in their previous release in order to come with a virtually unbreakable algorithm. And since more evidence of who's behind the GPcode ransomware was gathered, vendors and independent researchers realized that the latest release is also susceptible to a plain simple flaw, namely the encrypted files were basically getting deleting and not securely erased making them fairly easy to recover.

02. Chinese Bloggers Bypassing Censorship by Blogging Backward -
When you know how it works, you can either improve, abuse or destroy it in that very particular order. Chinese bloggers are always very adaptive in respect to spreading their message by obfuscating their messages in a way that common keywords filtering software wouldn't be able to pick them.

03. Gmail, Yahoo and Hotmail’s CAPTCHA Broken -
This has been an urban legend for a while, but with more services starting to offer hundreds of thousands of pre-registered accounts at these providers, it's surprising that spam and phishing emails coming from legitimate email providers is increasing. The "vendors" behind these propositions are naturally starting to "vertically integrate" by offering value-added services for extra payments, namely, scripts to automatically abuse the pre-registered accounts for automatic registration of splogs and anything else malicious or blackhat SEO related.

04. The Antivirus Industry in 2008 -
If it were anyone else but a security vendor to come up with such a realistic cartoon aiming to stimulate innovation by emphasizing on how prolific and sophisticated malware groups have become, it would have been a biased cartoon. However, this one is courtesy of a security vendor, and it's pretty objective.

05. Lithuania Attacked by Russian Hacktivists, 300 Sites Defaced -
This attack is a good example of a decent PSYOPS operation. Of course they have already build the capabilities to deface and even execute DDoS attacks against Lithuania, so why not put them in a "stay tuned" mode, by speculating on the upcoming attack and then executing it making it look like they delived what they've promised? This a lone gunman mass defacement given that the sites were all hosted on a single ISP, with no indication of any kind of coordination whatsoever. The same for the Georgia President’s web site which was under DDoS attack from Russian hackers later this month. Despite that the hacktivists behind it dedicated a separate C&C for the attack, one that hasn't been used in any type of previous attacks so far, they did a minor mistake by using a secondary command and control location that's known to have been connected with a particular "botnet on demand" service in the past. The second attack once again proves that you don't need to build capacity when you can basically outsource the process to someone else.

06. The ICANN Responds to the DNS Hijacking, Its Blog Under Attack -
The ICANN finally issued a statement concerning the DNS hijacking of some of their domains, which is in fact what Comcast.net and Photobucket.com should have done as well, next to stating it was a "glitch". The ICANN also took advantage of the moment and also pointed out that their blog has also been under attack during the month. There's no better example of how the combination of tactics can result in the hijacking of the domains of the organizations implementing procedures aiming to protect against these very same attacks. And while Photobucket.com remained silent during the entire incident, the hosting provider that was used by the Netdevilz team in the two attacks, since they were also responsible for the ICANN and IANA DNS hijackings, technological and social engineeringissued a statement.

07. The Risks of Outdated Situational Awareness -
Security vendors are often in a "catch-up mode" and if I were an average Internet user not knowing that real-time situational awareness speaks for the degree to which my vendor knows what going on online, I'd be pretty excited. However, I'm not. Prevx were catching up with a service which I covered approximately two months ago, I even had the chance to constructively confront with one of the affected sites on how despite their security measures in place, this attack was still possible. Recently Prevx have once again demonstrated an outdated situational awareness by coming across a banking malware in July 2008, whereas the malware has been around since July 2007, and earlier depending on which version you're referring to.

08. Fake Porn Sites Serving Malware - Part Two -
Yet another domain portfolio of fake porn sites serving rogue codecs and live exploit URLs, just the tip of the iceberg as usual, however their centralization is greatly assisting in tracking them down.

09. Storm Worm's U.S Invasion of Iran Campaign -
Stormy Wormy is once again making the headlines with their ability to actually make up the headlines on their own.

10. Mobile Malware Scam iSexPlayer Wants Your Money -
The best scams are the ones to which you've personally agreed to be scammed with without even knowing it. Like this one, which was tracked down and analyzed a couple of hours once a uset tipped on it.

11. The Template-ization of Malware Serving Sites -
The increase of fake porn and celebrity sites is due to the overall template-ization of these, with the people behind them basically implementing several malicious doorways to ensure that the domains get rotated on the fly. Despite that they all look the same, they all sever different type of malware, and zero porn of celebrity content at all except the thumbnails.

12. Violating OPSEC for Increasing the Probability of Malware Infection -
No better way to expose your affiliations and several unknown bad netblocks so far, by adding the netblocks and the malicious domains as trusted sites upon infecting a PC with the malware. Of course, the usual suspects lead the "trusted netblocks".

13. Monetizing Compromised Web Sites -
Several years ago, a script kiddie would install Apache on a mail server, they claim that they defaced it. Today, these amusing situations are replaced by monetization of the compromised sites, by reselling the access to them to blackhat SEO-ers, malware authors, phishers, or personally starting to manage a scammy infrastructure on them, by earning money on an affiliate based model, like this particular attack.

14. Malware and Office Documents Joining Forces -
A recent DIY malware kit, sold as a proprietary tool basically crunching out malware infected office documents, whose built-in obfuscation makes them harder to detect. It will sooner or later leak out, turning into a commodity tool, a process that's been pretty evident for web malware exploitation kits as well.

15. Are Stolen Credit Card Details Getting Cheaper? -
Depends on who you're buying them from, and whether or not they offer discounts on a volume basis, namely the more you buy the cheaper the price of a card is supposed to get. With the current oversupply of stolen credit card details, what used to be an exclusive good once where they could enjoy a higher profit-margin, is today's commodity good.

16. The Neosploit Malware Kit Updated with Snapshot ActiveX Exploit -
Since alll the web malware exploitation kits are open source, and leaked in the wild at large, their modularity allows everyone to easily embed any type of exploit that they want to, resulting in Neosploit's single most beneficial feature, the fact that certain versions include all the publicly available exploits targeting Internet Explorer, Firefox and Opera. Moreover, the open source nature of the kit is resulting in a countless number of modified versions yet to be detected and analyzed, therefore keeping track of the exploits included in a malware kit can only be realistic if you take into considered the exploits that come with the default installation.

17. Obfuscating Fast-fluxed SQL Injected Domains -
Now that's a very good example of different tactics combined to attack, ensure survivability, and apply a certain degree of evasion in between.

18. The Unbreakable CAPTCHA -
There's never been a shortage of ideas, there's always been an issue of usability.

19. The Ayyildiz Turkish Hacking Group VS Everyone -
That's a pretty inspiring mission if you are to ensure your future in the next couple of years, by targeting everyone, everywhere that has ever publicly stated their disagreement with the Turkish foreign policy.

20. Money Mule Recruiters use ASProx's Fast Fluxing Services -
A true multitasking in action with a botnet that's been crunching out phishing emails, SQL injecting and now hosting a well known money mule recruitment service.

21. SQL Injecting Malicious Doorways to Serve Malware -
Constantly switching tactics and combining different ones to achive an objective that used to be accomplished by plain simple techniques, is only starting to take place. In this case, instead of a hard coded SQL injected domain, we have the typical malicious doorways the result of the converging traffic management tools with web malware exploitation kits.

22. Impersonating StopBadware.org to Serve Fake Security Warnings -
Typosquatting popular security vendors and services is nothing new, by having HostFresh providing the hosting for the parked domains promoting the rogue security software, is a privilege and flattery for the success of the Stopbadware initiative.

23. Coding Spyware and Malware for Hire -
Customerization -- not customization -- has been taking place for a while, that's the process of tailoring your upcoming products to the needs of your future customers, compared to the product concept myopia where the malware coder would code something that he believes would be valuable to the potential customers. End user agreements, issuing licenses for the malware tool, as well as forbidding the reverse engineering of the malware so that no remotely exploitable flaws could be, are among the requirements the coder assists on.

24. Lazy Summer Days at UkrTeleGroup Ltd -
Taking a random snapshot of the current malicious activity at a well known provider of hosting services for rogue security applications, live exploit URLs and botnet command&control locations, always provides an insight into what are their customers up to. In this case, centralization of their scammy ecosystem, and parking a countless number of rogue domains on the same server.

25. Email Hacking Going Commercial -
Cybercrime is in fact getting easier to outsource, and while the number of scammers trying to offer non-existent services, or at least services where they cannot deliver the goods, the business model of this service that is that you only pay once they show you a proof that they've managed to hack the email address you game them. How are they doing it? Social engineering and enticing the user to click on live exploit URL from where they'll infect the PC and obtain the email password, of course, next to definitely abusing it for many other purposes in the process.

26. Vulnerabilities in Antivirus Software - Conflict of Interest -
You can easily twist the number of vulnerabilities found in your antivirus solution, but not recognizing them as vulnerabilities at the first place. It's all a matter of what you define as a vulnerability, or perhaps what you admit as a serious vulnerability - remote code execution through a security software, or a flaw that's allowing malware to bypass the security solution itself.

27. Counting the Bullets on the (Malware) Front -
Emphasizing on the number of malware/threats/viruses/worms/slugs your solution detects may be marketable in the short-term, but is damaging the end user's understanding of the threatscape in the long-term. So, by the time he catches up with what exactly is going on, he'll recall the moment in time where he was using the number of threats his solution was detecting as the main benchmark for its usefulness. In reality through, the number is irrelevant from a pro-active point of view, with zero day malware like the one coded for hire undermining the signatures based scanning model.

28. Smells Like a Copycat SQL Injection In the Wild -
It was pretty obvious that copycats seeing the success of SQL injections the the huge number of sites susceptible to exploitation, would also starting taking advantage of the practice. Some are, however, targeting local communities and trying to avoid detection by using targeted SQL injections.

29. Click Fraud, Botnets and Parked Domains - All Inclusive -
The scheme is nothing new, what's new is that the botnet masters are trying to limit the revenues that used to go out to affiliate networks they were participating in, and are trying to own or rent the entire infrastructure on their own.

30. Over 80 percent of Storm Worm Spam Sent by Pharmaceutical Spam Kings -
With access to Storm Worm sold and resold, and new malware introduced on Storm Worm infected hosts used as foundation for the propagation of the new malware in this case, it's questionable whether or not the Storm Worm-ers themselves are sending out the junk emails, or are they people who've rented access to the botnet doing it.

31. Neosploit Team Leaving the IT Underground -
Pretty surprising at the first place, but in reality it clearly demonstrates that when you cannot enforce the end user agreement on your crimeware kit, but continue seeing it used in a very profitable malware operations, you basically shut down the support for the public version. The team is not going to stop innovating for their own purposes, and in the long-term they may in fact re-appear with an updated malware kit that's converging different services next to the product itself.

32. Dissecting a Managed Spamming Service -
Managed spamming services using botnets as the foundation for the campaigns are starting to introduce improved metrics for the delivery, as well as experienced customer support ensuring the spam messages make it through spam filters, or at least increase the probability of making the happen. This is an example of a random service emphasizing on the improved metrics they're capable of delivering.

33. Storm Worm's Lazy Summer Campaigns -
Looks like a "cybercrime intern" launched this campaign, lacking any of the usual Storm Worm evasive practices, no exploitation of client side vulnerabilities, as well as no survivability offered by their usual fast-flux nodes.

US Government Won't Cede Control Over DNS Root Zone

Fri, 01 Aug 2008 06:54:13 +0000

In a letter to ICANN Board chairman Peter Dengate-Thrush Meredith A. Baker, Acting Assistant Secretary for Communications and Information in the Commerce Department's NTIA (National Telecommunications and Information Administration) has declared that the US government has no plans to yield the control it now has over changes to the Internet's DNS root zone file. ICANN manages the DNS root zone, but according to terms of an agreement between it and the NTIA. The distribution of changes in the zone file to the various root servers across the world is performed by VeriSign. ICANN's authority to administer various aspects of the Internet DNS derives from agreements with the Commerce Department. The current agreement for that authority, the JPA or Joint Project Agreement, is set to expire in September 2009. ICANN has been gearing up for what comes next with preparations for taking more complete control. The Baker letter pulls the rug out from under some of those plans. I'm not surprised at the letter and it wouldn't surprise me if even an Obama administration were to retain such control, but observers in Europe and Asia will probably be disappointed.

U.S. Government Won't Cede Control Over DNS Root Zone

Fri, 01 Aug 2008 06:54:13 +0000

In a letter to ICANN Board Chairman Peter Dengate Thrush, Meredith A. Baker, acting assistant secretary for communications and information in the Commerce Department's National Telecommunications and Information Administration, has declared that the U.S. government has no plans to yield the control it now has over changes to the Internet's DNS root zone file. ICANN manages the DNS root zone, but according to terms of an agreement between it and the NTIA. The distribution of changes in the zone file to the various root servers around the world is performed by VeriSign. The authority of the Internet Corporation for Assigned Names and Numbers to administer various aspects of the Internet Domain Name System derives from agreements with the Commerce Department. The current agreement for that authority, the Joint Project Agreement, is set to expire in September 2009. ICANN has been gearing up for what comes next with preparations for taking more complete control. The Baker letter pulls the rug out from under some of those plans. I'm not surprised at the letter, and it wouldn't surprise me if even an Obama administration were to retain such control, but observers in Europe and Asia will probably be disappointed.

ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars

Tue, 08 Jul 2008 11:42:32 +0000

The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, such as this one, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April. The incomplete information caused some confused analysis such as this from CADNA (the Coalition Against Domain Name Abuse). I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in a column on eWEEK.

Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars

Tue, 08 Jul 2008 11:42:32 +0000

Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars

Tue, 08 Jul 2008 11:42:32 +0000

Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

Virtualization Needs vs. Cool Features

Tue, 01 Jul 2008 17:00:08 +0000

Regardless of the size of your virtualization project you will probably ask two of the most common questions before you even start:

What product(s) & version(s) should I use?
How much should I plan to spend?

The simplest answer of course is “it depends”. I’ve seen implementations range from a thousand bucks to over several million. Ideally, your virtualization project needs & goals should drive your product selection. The bells & whistles you chose will determine your spending.

10 Basic questions that will help you determine product & cost:

Will your Virtual Infrastructure (VI) host production Virtual Machines (VM)?
What servers do you already have that can be used as hosts (32bit, 64bit, Mem, Disk, Network)?
Do you have a need for High Availability (HA)?
Do you have the need to manage SLA’s on your VMs?
What will a typical VM in your VI look like (OS, Disk, Mem, Network, CPU)?
What other IT resources do you have that can be used (SAN, NAS, Switches, etc…)?
What level of comfort does your existing staff have with the various IT resources?
Do you have existing hardware/software support agreements with Vendors you could leverage?
What tools do you already own that are “virtualization aware” and what new tools will you need?
How many VM’s do you plan to scale to?

Please, please, please, don’t make the mistake of implementing features that you don’t need and over-engineering just because the product lets you do so.

If you plan it right your product & cost, questions will be answered with no unpleasant surprises.

ShareThis