With all this talk and reporting about security concerns, lets change the channel for a moment and assess the potential security benefits of Cloud Computing.

In my view, there are some strong technical security arguments in favour of Cloud Computing - assuming we can find ways to manage the risks.

With this new paradigm come challenges and opportunities.  The challenges are getting plenty of attention - I’m regularly afforded the opportunity to comment on them, plus obviously I cover them on this blog.  However, lets not lose sight of the potential upside.

In this post, I walk through seven technical security benefits.  Some are immediate, others may arise over time and have conditions attached (some unstated for the sake of brevity).  However, I’m including the longer-range benefits now to raise awareness.  Some of the outcomes listed are available today without the Cloud, but they are either complex and slow to implement (and thus less likely to happen) or prohibitive for capital cost reasons.  I don’t claim this is a definitive list - it reflects where my thinking is today.

Some benefits depend on the Cloud service used and therefore do not apply across the board.  For example; I see no solid forensic benefits with SaaS.  Also, for space reasons, I’m purposely not including the ‘flip side’ to these benefits, however if you read this blog regularly you should recognise some.

On a sidenote, I believe the Cloud offers Small and Medium Businesses major potential security benefits.  Frequently SMBs struggle with limited or non-existent in-house INFOSEC resources and budgets.  The caveat is that the Cloud market is still very new - security offerings are somewhat foggy - making selection tricky.  Clearly, not all Cloud providers will offer the same security.

Seven Technical Security Benefits of the Cloud

1. Centralised Data

• Reduced Data Leakage: this is the benefit I hear most from Cloud providers - and in my view they are right.  How many laptops do we need to lose before we get this?  How many backup tapes?  The data “landmines” of today could be greatly reduced by the Cloud as thin client technology becomes prevalent.  Small, temporary caches on handheld devices or Netbook computers pose less risk than transporting data buckets in the form of laptops.  Ask the CISO of any large company if all laptops have company ‘mandated’ controls consistently applied; e.g. full disk encryption.  You’ll see the answer by looking at the whites of their eyes.  Despite best efforts around asset management and endpoint security we continue to see embarrassing and disturbing misses.  And what about SMBs?  How many use encryption for sensitive data, or even have a data classification policy in place?
• Monitoring benefits: central storage is easier to control and monitor.  The flipside is the nightmare scenario of comprehensive data theft.  However, I would rather spend my time as a security professional figuring out smart ways to protect and monitor access to data stored in one place (with the benefit of situational advantage) than trying to figure out all the places where the company data resides across a myriad of thick clients!  You can get the benefits of Thin Clients today but Cloud Storage provides a way to centralise the data faster and potentially cheaper.  The logistical challenge today is getting Terabytes of data to the Cloud in the first place.

2. Incident Response / Forensics

• Forensic readiness: with Infrastructure as a Service (IaaS) providers, I can build a dedicated forensic server in the same Cloud as my company and place it offline, ready for use when needed.  I would only need pay for storage until an incident happens and I need to bring it online.  I don’t need to call someone to bring it online or install some kind of remote boot software - I just click a button in the Cloud Providers web interface.  If I have multiple incident responders, I can give them a copy of the VM so we can distribute the forensic workload based on the job at hand or as new sources of evidence arise and need analysis.  To fully realise this benefit, commercial forensic software vendors would need to move away from archaic, physical dongle based licensing schemes to a network licensing model.
• Decrease evidence acquisition time: if a server in the Cloud gets compromised (i.e. broken into), I can now clone that server at the click of a mouse and make the cloned disks instantly available to my Cloud Forensics server.  I didn’t need to “find” storage or have it “ready, waiting and unused” - its just there.
• Eliminate or reduce service downtime: Note that in the above scenario I didn’t have to go tell the COO that the system needs to be taken offline for hours whilst I dig around in the RAID Array hoping that my physical acqusition toolkit is compatible (and that the version of RAID firmware isn’t supported by my forensic software).  Abstracting the hardware removes a barrier to even doing forensics in some situations.
• Decrease evidence transfer time: In the same Cloud, bit fot bit copies are super fast - made faster by that replicated, distributed filesystem my Cloud provider engineered for me.  From a network traffic perspective, it may even be free to make the copy in the same Cloud.  Without the Cloud, I would have to a lot of time consuming and expensive provisioning of physical devices.  I only pay for the storage as long as I need the evidence.
• Eliminate forensic image verification time: Some Cloud Storage implementations expose a cryptographic checksum or hash.  For example, Amazon S3 generates an MD5 hash automagically when you store an object.  In theory you no longer need to generate time-consuming MD5 checksums using external tools - its already there.
• Decrease time to access protected documents: Immense CPU power opens some doors.  Did the suspect password protect a document that is relevant to the investigation?  You can now test a wider range of candidate passwords in less time to speed investigations.

3. Password assurance testing (aka cracking)

• Decrease password cracking time: if your organisation regularly tests password strength by running password crackers you can use Cloud Compute to decrease crack time and you only pay for what you use.  Ironically, your cracking costs go up as people choose better passwords ;-).
• Keep cracking activities to dedicated machines: if today you use a distributed password cracker to spread the load across non-production machines, you can now put those agents in dedicated Compute instances - and thus stop mixing sensitive credentials with other workloads.

4. Logging

• “Unlimited”, pay per drink storage: logging is often an afterthought, consequently insufficient disk space is allocated and logging is either non-existant or minimal.  Cloud Storage changes all this - no more ‘guessing’ how much storage you need for standard logs.
• Improve log indexing and search: with your logs in the Cloud you can leverage Cloud Compute to index those logs in real-time and get the benefit of instant search results. What is different here?  The Compute instances can be plumbed in and scale as needed based on the logging load - meaning a true real-time view.
• Getting compliant with Extended logging: most modern operating systems offer extended logging in the form of a C2 audit trail.  This is rarely enabled for fear of performance degradation and log size.  Now you can ‘opt-in’ easily - if you are willing to pay for the enhanced logging, you can do so.  Granular logging makes compliance and investigations easier.

5. Improve the state of security software (performance)

• Drive vendors to create more efficient security software: Billable CPU cycles get noticed.  More attention will be paid to inefficient processes; e.g. poorly tuned security agents.  Process accounting will make a comeback as customers target ‘expensive’ processes.  Security vendors that understand how to squeeze the most performance from their software will win.

6. Secure builds

• Pre-hardened, change control builds: this is primarily a benefit of virtualization based Cloud Computing.  Now you get a chance to start ’secure’ (by your own definition) - you create your Gold Image VM and clone away.  There are ways to do this today with bare-metal OS installs but frequently these require additional 3rd party tools, are time consuming to clone or add yet another agent to each endpoint.
• Reduce exposure through patching offline: Gold images can be kept up securely kept up to date.  Offline VMs can be conveniently patched “off” the network.
• Easier to test impact of security changes: this is a big one.  Spin up a copy of your production environment, implement a security change and test the impact at low cost, with minimal startup time.  This is a big deal and removes a major barrier to ‘doing’ security in production environments.

7. Security Testing

• Reduce cost of testing security: a SaaS provider only passes on a portion of their security testing costs.  By sharing the same application as a service, you don’t foot the expensive security code review and/or penetration test.  Even with Platform as a Service (PaaS) where your developers get to write code, there are potential cost economies of scale (particularly around use of code scanning tools that sweep source code for security weaknesses).

Your Thoughts?

What benefits do you see that I haven’t included in the above list?  Where do you agree/disagree and importantly, why?

ScienceLogic: What is “BSM Lite” and how is it different from “heavy” BSM?

Doug McClure: I think the concepts that Peter Sevcik from Net Forecast initially outlined in his blog post sum up what “BSM Lite” is all about: a simpler, less expensive, more responsive way of achieving the goals and objectives of Business Service Management (BSM).  He’s contrasted this nicely against what he termed “BSM Heavy” being the larger investments in time and resources to deploy domain specific tools and solutions each providing a view into the business service delivery with some aggregation and consolidation to tie up all of the disparate tool’s information into a concise end-to-end business service management story.

I’m pleased that he leveraged some of my thinking around a better working definition of what BSM really is from the BSM Defined page on my blog. Of course, these definitions are going to vary depending on whom you talk with and how they see the overall BSM Maturity Model.  I’ve created a BSM Maturity Model that aligns with the famous Gartner IT maturity model.  I’d like to think that a “BSM Lite” solution is one attacking the low hanging fruit, enabling one to achieve value quicker, and in a more tactical manner.  The “BSM Heavy” solutions are capable of the same, but span all along the BSM Maturity Model by adding additional point solutions, products and technologies from their broader portfolio. 

ScienceLogic: Does “BSM Lite” just refer to the tools, or can it refer to the process and methodology as well?

Doug McClure: I think that BSM is as much a philosophy as it is technology, process, people and methodology.  If we can get people to think, operate and respond differently than they do today with a focus on the business, customers, quality, revenue, or whatever else is most important to their business goals and objectives, than that is Business Service Management and could be “BSM Lite” if you will. 

Being that I work for IBM Tivoli, one of my personal objectives is to identify ways to use our key BSM enabling products in a more efficient, effective and BSM centric way. This was a huge driver for trying to hold DevCampTivoli focused on “Collaborative Development of End-to-End BSM Solutions”. 

In my opinion, we don’t make things very easy for our clients and the answer can’t be to “buy this product, module or widget” to fill in the gaps.  In my opinion, we must establish a BSM overlay within IBM Tivoli’s development and product management organization that ensures that we have clearly thought about how to enable BSM with the hundreds or products that we sell.  In my opinion, every product release must incorporate the fundamentals of enabling BSM in addition to the core domain specific functionality intended. I hope to keep this spirit alive and get our smartest IBMers and clients thinking about the best way to take a “BSM Heavy” solution and make it “lighter”. I hope to share more about my plans here and guidance for the industry in general soon.

That said, I am always interested in consulting with clients and collaborate with peers in the industry to figure out how to get the focus on the people, process and technology as key components of their BSM strategies.  I am absolutely convinced that without a documented BSM strategy, roadmap and top level sponsorship within the business and IT, the chances of BSM success greatly diminish.

ScienceLogic: Given the complexities involved in implementing a BSM strategy and dealing with the people and processes components of any business, how does “BSM Lite” really work? Should the expectations and outcomes be “lite” as well?

Doug McClure: Time will tell if “BSM Lite” will work.  I’m seeing emerging companies that are already breaking down some of the barriers to BSM success.  I do not expect that those choosing to begin with a “BSM Lite” approach should expect “lite” outcomes. 

The outcomes are the same regardless of the approach IF you’ve got a documented BSM strategy, roadmap and top level sponsorship in place before you begin. New features, capabilities and technologies will be needed as the needs of the business change and companies mature in BSM and fundamental IT management. This will likely force companies to move in more “BSM Heavy” directions to fill those gaps. 

In my opinion, this is the ideal scenario now as it gives “BSM Lite” vendors opportunities to grow their products and solutions. It also GREATLY improves the chances for success with a “BSM Heavy” solution because the organization would have already had matured enough to approach a “BSM Heavy” solution than if they hadn’t done a “BSM Lite” solution in the past.

ScienceLogic: Is “BSM Lite” more appropriate for a small or midsized organization, or does it apply equally to large companies? Is there an ideal profile for a company that can successfully implement a BSM strategy? Is there a different profile for “BSM Lite”?

Doug McClure: From an economic perspective, the concepts of “BSM Lite” are appropriate for all companies.  Remember, with “BSM Lite” we’re focused on identifying ways to make the goals and objectives of BSM easier to implement and in a more cost effective way.  Any company concerned about their IT cost overhead should care about this, especially when the risks of starting out with a “BSM Heavy” type deployment are much greater and the time to value generally much longer.

The “ideal” profile for any company is one where the BSM initiative begins by establishing top level buy in through creation of a formal BSM strategy for the company. This BSM strategy personalizes how the company defines what BSM is, what value the company expects from it, and how it will use BSM as a competitive differentiator for delivery of its business and IT services, products, etc.

The organizational “profile” I’ve seen most successful is when implementing a BSM strategy originates from within or actively includes a group that many companies have now that serves as a liaison or relationship management role between the various lines of business and IT. Sometimes this group is often seen as the gatekeeper to filter (and hinder) business driven requirements into the IT organization. In the ideal scenario, this group works very closely with the business and IT (usually staffed by business people and not IT people) to understand both the business side and IT side of complex business services and applications. 

Apart from the traditional IT components, what this group can do is help IT really understand the business perspective.  Analysis of the impact on the business in business terms is only possible by collaborating with a group such as this.  True value oriented BSM becomes attainable when we get to this level of IT and business alignment, cooperation, collaboration and communication.

If BSM is an IT only initiative, this will likely result in an IT centric perspective severely lacking in the necessary business perspective.  In these cases where IT doesn’t invest their BSM efforts with the business as an equal partner, the implementation ultimately becomes a “CYA” tool for IT and not achieve the desired value oriented expected.

To some degree “BSM Lite” may have an entirely different profile. If we see the price points, complexity and time to value change significantly we may see these types of deployments originate exclusively within the Line of Business. The possibility may exist where large enterprises operating in a shared IT services or IT outsourcing type model that the Line of Business brings in a “BSM Lite” solution to gain the visibility, checks and balances needed to ensure that the LoB’s needs are being met from the internal/external provider. I’d envision that “BSM Lite” may even be capable of operating within a “SaaS” model or other managed service type offering where the price points are below the signing levels triggering broader IT involvement and review.

To Be Continued…

ShareThis

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.

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.

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.