ICANN Brussels Security Strategic Initiatives Thursday, 24 June 2010 >> Good morning, everybody. We'll probably get started here in just a moment. >>GREG RATTRAY: Okay. I think we're probably ready to get going, so it's a very small crowd and a very big room. Starting at 8:00 in the morning after the gala is probably not the recipe for the most robustly attended session. We'll mention that the birds of a feather session on Tuesday evening was in a much smaller room, overflowing at the seams with about 60 people in it. So, anyways, what we plan to do this morning is really just review where we're at in the progress in the dialogue with the community on two strategic initiatives. The DNS CERT has been the one that has certainly received the most attention. But I want to review with everyone what we've done across both areas and, you know, what we would like to do with the community moving forward. And there are a few more people wandering in, including Dr. Crocker. So good morning. So as background -- and I put these slides together at the start. I wanted to actually use the exact slides that I had used in Nairobi, particularly this one. You know, the reason for ICANN putting together these two strategic initiatives stems from a lot of work we've done with the community over the past probably 18 months to a year, and in particular that we queued up these initiatives as part of the strategic planning process within ICANN last fall, and had been vetted through that process. I do want to note that the boldface on the slide, as early as the Nairobi meeting, you know, we had, you know, wanted to state clearly that organizational and research approaches to the initiatives had not been addressed, that these were really initiatives to begin a dialogue with the community about what needed to be done in these areas, you know, not predetermined answers. That certainly remains the case. And we certainly got a large amount of feedback about the need to work with the community as we flesh out particularly the CERT idea, as well as come up with organizational and resourcing constructs for that. So I do feel, continue to feel, as the person on staff that put together the initiatives, that, you know, we need to focus both on risk assessment as well as the notion of a DNS CERT. And I still think the DNS systemwide risk analysis is not -- has not received the attention that I had hoped it would receive within the community. And hopefully that will continue. In some ways, we've had a lot of interaction, less formal written comment, indicating that this is really the horse that should be in front of the cart, that we really should do more work on what are the risks to the DNS, you know, what -- seek community agreement about the prioritization of those risks, and then move on to things like contingency planning and the development of response capabilities to a CERT. So I'm hoping that we continue to work towards the creation of, you know, both the process for a communitywide risk assessment as well, again, as outlined in the initiative, the notion of some systemwide contingency planning for the key risks and potentially even working on exercise programs, both participating in exercises that involve the domain name system, and there's a growing number of international cyberexercise efforts where we have linkages both in the United States and Europe. You know, and this would be part of that exercise program. Again, we've received very little feedback on the notion, particularly on the contingency planning and exercise notion. So I would continue to encourage the community, if they have thoughts in that regard, to provide those to us. Then the initiative which has been the center of much more attention is the domain name system CERT or Computer Emergency Response Team. Again, this is really couched -- CERT's a label. We're really thinking about collaborative response capabilities to address systemic threats and risks. We've had examples of that. They're outlined in the DNS CERT business care. And Yurie Ito on my left, who's our staff lead for this effort, and going to talk about an operational requirements workshop that we had and some of the use cases that were involved in what we think are the types of situations that might involve efforts by systemwide response capability or CERT. You know, the key aspects of what we thought was necessary, again, are detailed in the business case, but full-time staff and global reach, you know, coordinate existing capabilities and reach to the less-well- resourced operators. Again, these are the slides that we used to explain these initiatives at the last meeting in Nairobi. So we're hoping that, you know, it's clear to the community that we are aware that there is a wide range of existing resources that work in this area, and we continue to work with those people. Again, Yurie's going to detail a little bit more the efforts we've had to reach out to existing organizations in the development of the concept for a DNS CERT. So in terms of moving forward into the last few months and coming up to the Brussels meeting, where we think that what I call the state of play or the activities that have gone on related particularly to the CERT initiative, we had planned, you know, back to the January/February time frame, when we were fleshing out these initiatives that we knew in the CERT initiative we needed to get down to a finer level of understanding of the requirements that such an organization might have, both in terms of, you know, what would it do, and then also in terms of what others are already doing, so it didn't try to replicate or duplicate those sorts of capabilities. So we've had that workshop. Yurie's going to talk to who was there and the outcomes of that workshop. That workshop report was posted, along with a summary of comments that we received on both strategic initiatives. And we also provided a detailed list of consultations that we had done on the DNS CERT, as there were some questions as to who we'd talked to as we put together that initiative. So that -- that long, detailed list is also available. All these things are publicly posted on the ICANN Web page. During this period, there's been an exchange of letters with the ccNSO, GNSO, and ALAC chairs between the CEO, Rod Beckstrom, and the chairs of those committees, about how to move forward with a communitywide look at the requirement here for a DNS CERT. My understanding is, you know, the -- the two supporting organizations, as well as potentially the ALAC -- and, Steve, I believe we've talked about the SSAC potentially supporting a communitywide working group. And my understanding is the GNSO yesterday approved drafting of a charter for that working group. So there is a supporting organization and advisory committee effort to begin a working group within the ICANN structure on the topic of a DNS CERT, as well as we know that there's discussion, you know, outside the ICANN staff and the formal ICANN communities, Paul Vixie has made a couple blog postings on this topic. And there was this birds of a feather session sponsored by Paul on Tuesday evening. That was a very robustly attended session, lasted for an hour and a half. Really, I think, was again the beginning of a dialogue with certain communities about, you know, what a DNS CERT -- CERT would be, and particularly the notion of potentially an organization that would pool resources from across the community that would oversee a functional operational organization. So the notion of a two-tier model for resourcing and then operating a response capability. So the next two slides really try to provide for everybody what we heard and what, you know, as staff, we think the next steps are, as well as we'll go into some detail on the -- the workshop itself. As I've mentioned, the initiative on risk assessment, contingency planning, and exercising was not a focus of much public comment at all. There were numerous comments that really started with, "You should work on a risk assessment. We, the DNS community, really need to understand what we think the risks are and what the priority are so that we don't, you know, create capabilities for things that aren't essential." But there was no concrete suggestions about how the community should actually put together a risk assessment. And I'm going to probably end this, to a degree, with we don't have a specific game plan at this point as to how a communitywide DNS risk assessment would occur. We did have a limited, you know, comment, a couple of government comments were supportive of the notion of, you know, a culture of preparedness. That quote comes from the U.K.'s comment on these initiatives, and the notion that contingency planning for key risks is something that is necessary, at least governments, you know, in a couple of cases pointed that out as a very useful thing to be working on. So moving again to the CERT, we got -- you know, in my three years in ICANN, one of the more robust sets of public comments on a given topic, certainly for the security team within ICANN, this has been a topic that's received the most attention. In our public comment, we had 30 or 40 different posted comments specifically related to DNS CERT. What you see on the slide is really the bullets that summarize that public comment. I think almost in every case -- I'm trying to think if there -- there was no case, having read the comments through a couple times, where anybody said, "The DNS CERT is an idea that's not worth discussing." So there's almost always a prefacory comment that we're all committed to security and resiliency, that we need to understand response capabilities. Now, that often was the prelude to some fairly pointed, you know, to be direct, negative comments on the specifics that were proposed on this -- on this topic in terms of there was a lot of notion that the analysis, anyways, needed a deeper understanding of threats and risks, again, that the response capabilities should be fine-tuned to what was specifically the most important systemic risks if it's going to be a system-wide capability. Something where we thought we had done a lot of due diligence, and we continue to do so, you know, but that an understanding of current response capabilities both within organizations in the domain name system, and then a lot of comment from both governments and some of the system operators that we needed to understand how this fit into the existing computer incident response and security team CERT structure,you know, needed to be deepened. I hope in some measure that that was really an oversight on our part. And part of the reason we had the set of consultations that we've done was because we've had a fairly robust dialogue with that community, as I'll mention in a second. You know, Yurie's on the steering committee of the global incident response FIRST organization, and we've been working with them for a year related to the notion of, you know, how does a domain name system play in the emergency responder community, including doing a workshop at the recent FIRST global meeting in Miami last week. So we understand that need. We are working hard in terms of the staff efforts to really make that liaison with other sorts of response capabilities. The other kind of capability that was much mentioned is an organization called DNS OARC, the operational analysis and response -- sorry, Operational Analysis and Research Center. And we've had constant contact with the members of that organization in all of the activities that we have done. And they are considering and put in support of notion for a DNS CERT and want to work through what their role may be in that regard. There was a little bit less comment, and some pointed and I thought useful comment from those in the less resource portions of the domain name system about the fact that they do have very limited security capabilities and do seek, potentially, the support from a more centralized CERT or response capability. That's really an overview of what we heard from the public comment. I'm going to just put this slide up and briefly talk about what we are currently doing and then I'm going to turn it over to Yurie to explain the outcomes from the workshop. We will work on threat and risk understanding. I think, in my personal opinion, you know, we need to get some sort of communitywide risk assessment process going. But I think that's still a work in progress in terms of the actual approach to doing so. As I've mentioned, we're going to continue to work with FIRST in the computer response community. One of the things that was initiated at the FIRST sponsors and national CERT meeting, which happened last weekend, actually, after the Miami FIRST meeting, we know they plan to work with us on issuing a survey to national CERTs about DNS security concerns and where a DNS CERT would fit in their ecosystem. So we look forward to working with Carnegie-Mellon CERTs on that. We do recognize very strongly the community's feedback that ICANN not operate a DNS CERT. So that's off the table. And the staff's focus is on working with others and facilitating the dialogue that has grown up now around a DNS CERT. And then we're going to briefly discuss here the workshop and Conficker reports that have come out since the Nairobi meeting. With that, I will introduce Yurie Ito, she works as a director of global security programs. I think it is relevant to mention, she was the technical director of a Japanese CERT for seven years before she joined the ICANN staff and is the longest-standing steering committee member in the FIRST organization. So a deeply experienced CERT response community operator. So with that, Yurie, I'd like you to explain the workshop. >>YURIE ITO: Thank you, Greg. I'm -- I will be introducing the outcomes from the DNS CERT operational requirements and (inaudible) analysis workshop. There was a group of operational security and DNS experts who participated in this workshop, representatives from ccTLD -- >>GREG RATTRAY: Sorry, I messed up. I didn't flip the slide. >>YURIE ITO: All right. Thank you. >>GREG RATTRAY: You had started talking, and I -- >>YURIE ITO: Okay. Thanks. So, yeah, it was this slide. Representatives from ccTLD, gTLD registries, registrars, ISPs, registrants, CSIRT, security response groups, small-size operators from Asia, Africa, and Caribbean region, all the representative from these are -- participated in this workshop to identify the requirements for responding to DNS security events, many of which are undermet or ignored by existing DNS security capabilities. And also, the workshop was trying to identify existing operational and capability gaps in how we presently respond to DNS security threats ducted use case-based analysis. Report. This workshop report was drafted by three participants from the community and reviewed by all the participants, and now it's uploaded on the ICANN Web site. The address is listed on the slide here. Next slide, please. Okay. So these are the list of requirements that workshop participants identified. One is a trusted communication channel for use during the event response that is usable by (inaudible) parties. And then standing incident coordination and response functions. Then incident status tracking through -- to completion of the response. And a trusted -- trust broker or introduction service across traditional (inaudible) boundaries, recognizing that the committee identifying threats to secure DNS operations is often disconnected from a DNS operation, operations, or a vendor community. Also a trusted voice for guidance on issues who has DNS security knowledge and expert experience that is responded by the community. Analysis capability. And institutional memory in forms of reports, recommendations, best practices which can inform and support a successful incident response. So these requirements -- next slide, please -- these are the listed requirements the participants identified, the requirements which is undermet or -- well, undermet currently. So to identify those requirements, participants use -- workshop used a scenario-based discussion on key risk areas for DNS, which is six areas we used is listed here, protocol and code vulnerabilities; registration infrastructure compromise; DNSSEC key compromise or failure; registration infrastructure failure; denial of service -- sorry, distributed denial of service attack; malicious use of DNS. These are the key areas we used for the discussion. Next slide, please. So workshop participants also discussed and identified in each requirement who are the existing players who's playing a role to fulfill these requirements or function. And these are the list of existing players who is playing in this role, in those roles or functions. DNS OARC is the group, that OPS Trust mailing list, NSP-SEC, Conficker Working Group, Forum of Internet Response Security Teams, FIRST, regional CSIRT frameworks, NX Domain -- these are the mailing list -- Digital Crime Consortium, ISC SIE is also community. Registry Internet Safety Group. SSAC and RSSAC mailing list. ICANN. NANOG and other regional ISP network and operators group, MAAWG, APWG. These are the groups and community participants -- the, sorry, workshop participants identified existing -- as existing players who's functioning. So that's the workshop output, and, again, the whole report from this workshop is uploaded on ICANN's Web site right now. >>GREG RATTRAY: Thank you, Yurie. Before I start the very brief synopsis of the summary and review on Conficker, where we see the workshop report at this point is grist for the mill or an input for the community dialogue on the notion of a DNS CERT. We did, I think, bring together a pretty strong group of people, and it made a good start at how to look at this problem, both a structural look at this problem as well as the output and thinking that came from that. At this point I want to make clear that we don't plan to initiate the development of a CERT based on that operational requirements, and that the ICANN staff again sees that as an input to a community-driven process on how to proceed on the CERT and hopefully plan, as I will mention in a moment, work with the ongoing efforts that started up at this point in time. On the Conficker summary and review, I just wanted to mention this. Our senior security technologist, Dave Piscitello, did what by most accounts is a very good synopsis of what ICANN's play was in the Conficker situation up until this spring. It's a situation that has not stopped, and there is still a Conficker working group ongoing that works on combating the spread of that malware. The DNS portion of that has declined. The report is posted. It was vetted by the Conficker working group after being drafted by Dave. I did want to mention, however, because both the report -- or the Conficker situation was one of the kind of catalytic elements that asked -- that caused us to consider the need for more structured community response capabilities, and again the report lays out that case about some of the things that we feel like, from an ICANN perspective, are necessary. And again, I do want to say this is a report focused on ICANN's look at the Conficker situation, not meant to be broader or overreaching in that regard. What we thought we need to do in that regard is formalize relationships between responders in those sorts of situations. Again, the CERT initiative being one of those ways that that might occur. That we put in place appropriate processes to rapidly respond to a situation, where in this case registries had to do a lot of things quickly. We put together something called the expedited registry security response process which allows for registries to quickly ask for permissions to do things that might be in question contractually in order to -- in, an expedited fashion, deal with security situations. So that process is already in place in terms of faster ways to work with the registries in responding. And then we needed to improve contact information with both the parties within the Domain Name System as well as those outside in the incident response community. And Yurie has led our efforts on our own internal incident response handling. The Web site for the Conficker review is listed on the slide. So in closure, both these things that really have been mentioned, in terms of the risk assessment in the first initiative, while there's been some comment and dialogue, there isn't a structured time-bounded effort currently existing within the community. As staff, we certainly, I think, continue to believe such a thing would be useful; want to support it. In terms of the DNS CERT, there's probably a couple of dialogues that have either started or are emerging. Again, the SO/AC working group we expect to happen, but that's not predetermined at this point. Again, my understanding is they're drafting a charter that will go on, as well as there's the BOF session that was held on Tuesday, and the commitment there was Paul Vixie would initiative a dialogue on the DNS ops mailing list to try to continue the energy that was started there about what would work in terms of a DNS CERT. And I believe the DNS OARC organization is also considering again what its role might be in the creation of such capabilities. So as staff, we plan to continue to be engaged and support all of these efforts. But really, at this point, that's our main look at going forward. So with that, I think that's probably a pretty robust status update. I would like to spend the next half hour answering questions or, hopefully, talking with you all about where we should proceed on these initiatives. Thank you. So the mic is open, the floor is open. The silence is deafening. >>ROBERT HUTCHINSON: Hi Greg. Bob Hutchinson from Dynamic Ventures. I was curious as to the DNS CERT concept, manual processes, seem to be the 20-year-old response to security threats. I'm wondering in these groups what was discussed about instrumenting DNSSEC or the entire DNS system, sorry, and building a more robust instrumentation for DNS so that we, as a community, can see the health of its operation in real time. >>GREG RATTRAY: It's a very interesting question, Bob, and I will give you probably both the staff answer and maybe a personal perspective as a cybersecurity person. Starting with the second, which is my own perspective, I do think the CERT community, and the dialogues that go on within it recognize that incidence response and manually chunking through ticketing system is increasingly not the most effective way. The amount of activity is just too much, the increased amount of automation and situational awareness are necessary. And there is some dialogue in our own DNS CERT discussions of how to operate a DNS CERT, though we haven't really got down into the level of how to create the right monitoring capabilities, or at least status update health checking, as you mention. From a staff perspective, the actual topic of our last annual symposium on security and resiliency was DNS health, and the specific notion was trying to get some baseline on what measurement capabilities are out there, what characteristics of DNS health would you want to try to measure, and what are the gaps in that regard. So I would point you to the symposium report. We did the symposium in Kyoto last year on DNS health measurement and way forward. That's the work we have done so far in answering that question. The two would definitely need to come together in my mind, that one of the things that a CERT could most productively provide is some situational awareness on the health of the DNS so that all the operators could initiate action on their own if that was appropriate. >>ROBERT HUTCHINSON: In the -- one of the workshops, it was mentioned that in -- I guess it was a DNSSEC workshop, by one of the panel members that, for example, key circulation issues in the U.S. government's implementations of DNSSEC in some cases have left broken keys in the system for up to a couple of months. And there is no current way to find the contact who owns the management of that stuff; okay? So there are hundreds of issues like this in DNS that, honestly, I think as a manual CERT, you're going to have a real difficult time dealing with. >>GREG RATTRAY: I don't think there's any concept for a manual, you know, or human-only kind of CERT. So what I think are very good points, I think both well instrumented understanding of a wide variety of things, whether it's status of DNSSEC, resolut- -- related issues, just routing issues related to, you know, how DNS queries are being routed because there have been issues around that, that good situational awareness will allow identification of potential quickly. There's a second portion of that thought that I am starting to lose. But that the CERT -- Oh that, the CERT will also be able to get in -- If people identify an issue, one of the roles, as Yurie outlined it, is that knowing who else is out there and being able to put parties in contact with each other I think is one of the most central roles. The security community doesn't know much about registry and registrar operations. We were in a room with over a hundred people, and we asked them how many people know what a -- of CERT people, and how many people know what a registrar is. And the number of hands that went up was less than ten. So the notion that the CERT community knows how to quickly reach in and contact people in the Domain Name System community at the operational level, there's just not that much awareness there, and we are trying to raise that awareness independent of a CERT, but there's a lot of connectivity to be provided. Yurie, do you have any thoughts in that regard? Maybe this is where the "less resource" piece comes in. Go ahead. Why don't you take that. >>YURIE ITO: So I mentioned about the list of existing players, and I call out a long list of existing players. But the more importantly, the key message of that players is they are all players there but not necessarily outreaching to resource constrained operators or not necessarily outreaching to Africa or Middle East, southeast Asia operators, from the key resource response community, in that box. >>GREG RATTRAY: Other questions? Comments? >>DOUG: Doug Mahn (phonetic). A couple of questions on the report. On page 11 on your report you outline scenarios 5.2, 6.1 and 6.2, but they are not included in the report. Do you have those documented somewhere? And at some point in time, those will be further discussed within the community? Or just mentioned and not captured anywhere? >>GREG RATTRAY: So, Doug, in the execution of the workshop, we had done a set of scenarios that we distributed to workshop participants. We ended up not getting through all the scenarios. So there's no -- It probably would be a useful thing to just post the kind of scenario basis that we used as just additional documentation. So I think we can take that on board and post that material. >> Doug: I think it would be useful, at least for those of us in the community to understand what other scenarios were you thinking about, even though you didn't get to talk about them. >>GREG RATTRAY: Yep, we can do that. >>DOUG: The second question I have has to do with the minority statement on the report. There are a number of items identified in the minority statement, and I am curious, have you responded to those items? Will you respond to those items? And how do you intend to deal with some of those items? >>GREG RATTRAY: So we promised all the participants, right, when we started the workshop that we were not going to -- either -- You can look at this two ways. We were not going to force a consensus. We also felt like we didn't have the ability to run a multi-month process to drive a consensus. You work on a complicated issue, you have over 20 smart participants. We knew going in that we may have people that wanted to express their opinions. So we always had left open the notion of providing alternative views. Two participants availed themselves of that opportunity, Greg Aaron of Afilias and Kathy Kleiman of PIR. Because the workshop report is really just information for the community, I see that as just another set of information; right? The drafters of the report, vetted by most of the participants, saw the output as in the main report. Other participants saw other things, another perspective from the workshop. It's really up to the kind of user to decide how to use that. We don't see the dissenting or alternative view as something that is something we need to respond to, especially since staff is not driving the settlement of concept of operations or anything at this point. Does that make sense? >>DOUG: Yeah, that's fine. The next item was one of the complaints in the minority statement, I think, has to deal with different activities in the community. I was wondering if you can say anything about what you view as the calendar for the next six months with respect to all of these things surrounding DNS CERT, DNS stability activities. A lot of these things, one of the complaints was the workshop was put together fairly quickly, limited number of people involved. And I am just curious if you guys have published, plan to publish, have thought about what is the calendar going forward in the next six months or so to try to drive some of these things to a resolution? >>GREG RATTRAY: So as staff, you know, it's based mostly on the community's feedback. We don't feel like we are in the driver's seat at this point. Where we think we are is strong supporters, both probably on process as well as hopefully some substance on the efforts that I think will begin within the SO/AC structure. So I imagine there will be a working group. My discussions with some of the chairs of the -- or the chairs of the ccNSO and the GNSO is they hope that initiates itself fairly quickly. That start something not a multi-month process; right? And that they will have a charter and they will have to plan out a work plan. So that will provide one set of -- you know, a feel for you as to what's going to happen when. My sense is that's going to be a fairly prolonged effort. Then, you know, the BOF really -- I think its path forward is not particularly clear, but Paul will initiate a dialogue that there may form enough of a critical mass around that. Again, we understand OARC is considering it potentially being -- advocating -- I don't want to put words in their mouth, but their role in progressing this idea. So I guess the basic answer is it's not particularly clear at this point, but there seems to be two or three separate initiatives that may continue forward with this work. >>DOUG: Okay. One final question. In your analysis on the DNS CERT, did you look at all at what is call the INOC DBA, the Internet Network Operations Center Dial by ASN? This is an organization of about 2200 network operations folks in the routing community, but they are all connected together for communication purposes to keep the net up. And it's fairly robustly funded and used by the operations people. If you haven't looked at that system, you might want to look at it. It's called INOC DBA. >>GREG RATTRAY: So the answer is no, and it did not come up much, although John.... John mentions to me for ICANN's own DNS operations, we're on that system. So, Doug, I think what this points to in a broader sense is we have got this recognition that the network operators and the routing piece of this is important. We probably artificially segmented the DNS piece to a degree from that. As the idea progresses, interface with that community would probably be a very useful part of how we did business, in my opinion. >>DOUG: The key thing is it's a virtual organization, it's not physical, which some people have issues when you use the phrase DNS CERT, they view it as a physical organization, but it's really information, coordination and sharing amongst over 2,000 net ops people. >>GREG RATTRAY: So you are saying as a model, it might be nice -- >>DOUG: It might be a model you guys you think about rather than a different model. >>GREG RATTRAY: Okay. Hi, Marilyn. >>MARILYN CADE: Hi Greg. My name is Marilyn Cade. I really appreciate following up on the previous speaker because he captured a couple of the things I wanted to say, but I will just make an observation about -- that may not be obvious to you, but it's obvious to me as I listen. We say that the staff is not leading, is not driving. But so far this morning, after -- the comments have primarily focused on DNS CERT and not on initiative one. So I would like to talk about initiative one for a minute, but first of all, I want to follow up on the comment you made. The network operators have a significant stake in what you are doing, but I think there is a significant gap in outreach to them. And my own view on that is, it would be good to bridge that gap now. They build and run the Internet, and while they certainly rely on resolution services and DNSSEC is important to they will, there are some other activities, I think, particularly in relation to sharing information, that might be helpful to begin the interaction now. I had a question about the ISPs who participated in your table-top exercise. Is that -- the information about who they are public? >>GREG RATTRAY: Yurie, the specifics on each participant are posted in the report, so, yeah. All the information we have about the participants is public in the sense that it's in the report. >>MARILYN CADE: And how many ISPs, if you remember? >>YURIE ITO: I don't have exact number, but there are a number of the people whose currently not ISP but used to be. For example, dot US -- EU? EUI? ISPs, and then now become another position, but had a long experience in ISPs. >>GREG RATTRAY: I think it's important on that workshop that was not -- people were not invited to represent organizations; right? This was really supposed to be an operational expertise. So people were actually invited based on their resums, not on their organizational positioning. So, yeah. So to say that we had ISP representatives may misrepresent the situation, because we weren't really taking organizational affiliations into account. >>MARILYN CADE: Yeah, I think that may also cause misunderstandings. And maybe we should all make a concerted effort, if we are going to focus on initiative one, to focus on initiative one, where I think that all the comments that I, too, read indicate that there's a strong interest in a dialogue. The second point on that I'd like to make is, I think it's really important -- and this is a complexity that it seems like a little thing, but words matter. You are actually talking to the councils, not to the GNSO. The GNSO is a much broader group. The GNSO has been restructured. It now has stakeholder groups. And so just a point for you and Yurie, because even the community of ourselves get confused about that. And it is the stakeholder groups that you want people from. The people you want are embedded into the stakeholder groups or back home and have a contact that works in the stakeholder group. So just a word for you about, you know, when people raise their hand, push a little hard and say, "Have you gone out to your full stakeholder group?" Because I think you'll get additional interest or different people in addition to the people you may get otherwise. >>GREG RATTRAY: Fair enough, Marilyn. Marilyn, I am ask you. One. Things that we need on initiative one is some sort of notion of how to proceed. Again, we're a little bit hesitant to launch that from the staff at this point, wanting to provide confidence in the community that these things are bottom-up sorts of initiatives. So I think we're reaching out to all the stakeholder groups and the community at large is give us a way forward on that that you think would actually be properly inclusive. Because I fundamentally believe that initiative one is the more important of the two initiatives. >>MARILYN CADE: So I will just reinforce, I think, something that I believe is coming forward from the message you're trying to give, and that is, community-wide. And community-wide means it's going to take some time. And in order for -- There are stages of creating awareness and understanding before you get to actual exchange of information. And I think maybe we should all be thinking about how do we go through those stages, and in some cases, we are going to have to do things in parallel. So I'm not sure I am giving you a very direct answer, but it's probably going to take a little longer than you might prefer. One thing I would say is, the next time that you can schedule this workshop, insist that they give you a better slot and do not let them schedule something against it. >>GREG RATTRAY: Thank you. Real quick, Patrick, we don't have anything in remote participation, apparently. Okay. >>STEVE METALITZ: Thank you. Steve Metalitz here on behalf of the coalition for online accountability. I want to thank you for the rundown that you have given on some of the activities that you are doing in this very important area. I have a couple of questions, and I'm not sure this is the appropriate forum for it. Perhaps it's the next one. But let me ask them anyway and you can tell me if I should ask them elsewhere. One of our concerns in the time of unusual fiscal austerity for ICANN is that the security, stability, and resiliency security, stability, and resiliency operations function is slated for just about the largest increase in its budget in fiscal year '11 of any other group. And in fact, if this budget is approved, it will be the largest single activity that ICANN engages in among the 15 organizational activities in terms of the dollars committed to it. And in going over both the original budget framework and the budget that will be approved by the board or voted on by the board tomorrow, there's not very much detail about what this $7.1 million would be spent on. And I notice that there's almost no overlap between what's listed in the budget document and what you have talked about this morning. The budget document talks about the labor cost for DNSSEC implementation, security program certifications, external audits of ICANN security, hardening of ICANN's infrastructure, and other important activities highlighted in the strategic plan. Focus of efforts is particularly on internal security efforts. Now, it may be that it's not appropriate really to discuss all this in a public forum, but I think there should be somewhere that there's a little more explanation. Since these two initiatives are only mentioned in this budget document in the final sentence where it says, "Operational costs to operate DNS CERT are not included in this draft of ICANN's operating plan and budget." So most of what you have talked about today is not even could have had by this largest budget item. Is there a place or a time when there would be more discussion about what ICANN is spending, getting for its $7.1 million in this budget item? >>GREG RATTRAY: Steve, I think you're right, this is probably not the right forum but I am going to respond in a degree. These initiatives are not funded. So to the extent we are trying to explain the 7 million in the FY '11 budget, just be clear to everyone, there's no dedicated resources to either one of these initiatives. To be direct, there's staff time that will be committed to continuing forward with the community on these initiatives. There's some cost to that. On process, where I think you should look for more explanation is either make a call saying the security -- you know, the security lead should explain to the community the constituent pieces of 7 million, which I am going to do briefly in a second, or this is an operating budget sort of thing, drive it into the dialogue about the FY ops plan, and why is this funded at this level. I think the key -- the limited amount of explanation does hit to the key aspects. I run a small staff, you know, of five people; right? And that has a 2 million budget, most of which is focused on internal corporate security and risk management, continuity sorts of activities. Obviously there is a gap between 2 and 7. A large portion of other activities, particularly the fairly robust efforts going into DNSSEC implementation, a portion of the DNS operations budget, including the operation of L-root, a significant portion of the ICANN's I.T. budget that has to do with backup facilities, all of which are internal operations of the corporation, are in that $7 million figure. Working with Kevin, we could break that out in some granularity, if there's a call for that. But as you mention, really it's a fairly large figure. Most of it has to do with fairly solid infrastructural sorts of things we are either doing internal to ICANN or, again, the DNSSEC and L-root sorts of operations. >>STEVE METALITZ: Thank you, that's helpful. I would point out that DNS operations is a separate budget item, separate from the one I just looked at. It's slated for 82% increase. So it's clearly -- I think this problem crosses over. It's never been that clear to me in terms of DNSSEC, which I agree is a very important initiative, what's covered where. So I will take it up in the budget discussion. I appreciate the response you have given. >>GREG RATTRAY: Okay. Looks like we have potentially Leigh with a question. >>LEIGH WILLIAMS: I'm not sure it's as much a question as a comment. I think -- This is Leigh Williams from the financial community. I would say we agree with many of the things that you have heard in the workshop and this morning. We think that it's important that existing capabilities be reviewed as we think about DNS CERT. It's important that we engage the community on security, as Marilyn has said. It's important, as Steve has said, that we think very explicitly about how resources are dedicated to security. All of those disciplines are absolutely critical. That said, it's also very important to us as a community, I think, that we actively engage on all of this. Security is absolutely a priority. So we see it as very positive that this discussion on DNS CERT is taking place, that sometimes we have to be maybe just a little bit more ambitious than people might comfortably have been had we not raised this question. We think that it's very important that members of the GNS council and the GNSO generally and the business constituency and all the constituencies actively weigh in on security, and if it takes a little bit of effort on the part of the staff to make that happen or a little bit of effort on the part of the community to get that kind of enlistment, we think that's worthwhile. And while it might not be comfortable to all of us and it's important to have the discipline that Steve and others encourage us to have, we also think it's enough of a priority that if sometimes it's a little bit difficult to get this as high on the list as it needs to be, we from the financial community would support doing whatever it takes to get that on people's radar. >>GREG RATTRAY: Thank you, Lee. The timing is pretty good. We are a couple minutes to 8:00 -- sorry, 9:00. Any other comments in the room? Patrick, nothing out there on remote participation, I assume? All right. I thank everybody for coming in early on Thursday morning, again, after the gala. I thought this was a very good discussion. Again, we will continue both to engage with the community efforts, be as outwardly facing and transparent as we can while working on these issues. So thank you very much. [ Applause ]