<<<
Chronological Index
>>>
Thread Index
>>>
Comments on FY 14 Security, Stability and Resiliency Framework
- To: comments-ssr-fy14-06mar13@xxxxxxxxx
- Subject: Comments on FY 14 Security, Stability and Resiliency Framework
- From: Andrew Sullivan <asullivan@xxxxxxx>
- Date: Thu, 11 Apr 2013 00:10:19 -0400
Dynamic Network Services ("Dyn") is pleased to provide some remarks on
the FY 14 Security, Stability and Resiliency Framework ("the
framework") that ICANN published for comment on 6 March.
By and large, we believe the document is a good basis for future
developments. We nevertheless have a few comments.
First and perhaps most importantly, we support the aim that ICANN
security staff continue to be engaged both across the organization
and, at least as important, with other actors on the Internet. That
continued role is in our view critical to ICANN's success, and in fact
we think it should be strengthened.
We are extremely happy to see a plan for security staff to be
distributed across ICANN as the organization changes. We are slightly
worried (on the basis of this document) how that plan is going to
work. The framework discusses how SSR fits into ICANN, but its
description of the function of the security staff is a little thin on
details of how the five views of SSR are to be realized by a group of
staff embedded within other functions. Historically, security staff
members seem to be pulled in multiple directions, and we worry that
ICANN's organizational change will exacerbate that problem. We
suspect that achieving the valuable goals in the framework will
require additional staff.
It is a simple consequence of agile methodologies that, in order to
achieve the benefits of greater flexibility and regular delivery of
small pieces of value, one sacrifices staff efficiency. The framework
(p 25) touches on the need for additional staff, but it is not clear
from the framework what the existing strengths and weaknesses are;
neither is it clear what the needs of the initiatives are from the
point of view of security. Moreover, since the staff members are to
be embedded across the organization, presumably security staff will
need to be involved not only the FY14 activities explicitly called out
in the framework, but also any other initiatives from anywhere else in
the organization. It seems to us that, if this is supposed to be a
framework for ICANN SSR activities in FY14, it will be necessary to
have some more information the scope of and limits to engagement by
ICANN security staff. We think this is the area in which the
framework could do with the greatest improvement.
This is especially important given the (in our view true) claim on p 9
that the "Internet is an ecosystem […]." Even small
portions of ecosystems are notoriously difficult to manage, and if the
Internet is an ecosystem then ICANN's remit and responsibilities are
even more difficult than one might have supposed. So, because the
Internet is an ecosystem, and because ICANN's SSR responsibility is
wisely thought of in terms of the health of the DNS, it is necessary
to ensure that there is adequate ICANN security staff involvement in
overall Internet security activities.
Turning to some details in the document, we note that there are
several diagrams throughout the document that are presented instead
of, rather than as a complement to, text. The diagrams do not always
make the point as clearly as one might like. For example, Figure 7 on
p 16 is interesting, but it looks like it distills a number of
processes that could usefully be documented (perhaps for inclusion in
the framework by reference, but not directly). Similarly, the import
of Figure 4 on p 12 is not clear. Are these categories of root labels
significant for SSR? Why?
Finally, a nit. Given the definition of "security" in the framework,
it is not clear that, "Misuse of and attacks against the DNS and
global networks challenge overall unique identifier security," (p 7)
is true in any interesting way. Security is here defined entirely in
terms of protecting and preventing misuse. So either the sentence is
trivially true (since instances of misuse are by definition a
challenge to security), or else the nature of the challenges needs to
be unpacked.
Respectfully submitted,
--
Andrew Sullivan
Dyn
asullivan@xxxxxxx
<<<
Chronological Index
>>>
Thread Index
>>>
|