Re: [registrars] Proposed Agenda for Marina del Rey Constituencymeeting

["Paul M. Kane" <Paul.Kane@REACTO.com>]

Sure .. let me summarise parts of the BS 7799 in 10 bullets that may be
of use to Registrars and add a few bits of my own interpretations pertaining
to the Registrar industry and not intended to be "followed" to the letter....

The Standard is based on Common Sense......

Staff awareness, security level and access
i) Every firm should appoint a Security Manager /information officer as a point of contact to receive internal security reports and to disseminate incoming security related info to staff.
ii) Practice system/data recovery to make sure staff know the drill such that service can be recovered quickly.
iii) Many security "problems" arise from employees within an organisation, leaving back doors open for "quick" system access, poor password management, disgruntled employees leaving "time-bombs", deleting files, ....... to prevent breaches it is a good idea to have different access levels for staff, have source code written by one programmer checked by another, configure the O/S such that deleted files move to a "trash" bin and can only be erased or recovered from the trash by a different operator. Good documentation is a big help when staff rotate responsibilities.
 

Systems administration
iv) Keep regular back-ups of all data, systems and source code on off-line systems and periodically place copies in a remote secure location.  Have an "off-line" mirror of the live system (preferably in a different geographical location) standing by for "hot-swap" if live system needs to move to "ghost".
v) Use multiple ISPs that follow different cabling paths for internet access and have "live" servers on a variety of circuits a variety of O/S, and equipment manufacturers. Have scheduled replacement of hardware. Keep your primary DNS servers hidden and authoritative.  If you are running dynamic DNS have DES6 encrypted tunnels (where allowed by national law) to talk to remote DNS servers, where non-dynamic use encrypted FTP zone transfer with a checksum.
vi) Record and periodically check server activity in a manner that has meaning such that incidents may be "re-run" off-line tracking both the perpetrator and the effect of the security breach.
vii) Premises, hardware and cabling. Putting servers in a secure cage is great but futile if the terminals controlling those terminals are in an in-secure area or the cabling (e.g., mains electricity switch to the building, network cabling) is insecure. An easy to understand wiring diagram, network layout, colour coding wiring system and detailed plannng is a big help.

Practical measures
viii) If you don't have fully redundant systems in a different location, make sure your up-stream supplier has good back-up systems in place to keep you on the 'net and earning money!. Your company may have the best security in the world but if both your up-stream ISPs, use the same cabling path in the street to your premise, the same peering point gateway, the same phone company ..... you may be off the network when the excavator breaks the cable in the street!
ix) Server Room design and fire hazards - People are a company's most important asset - and it is usual to have a fire drill for the fast evacuation of people... but machines don't move but  data can move much faster than people! Having server room gas extinguishing systems is useful, but having a system "dump" at 100Mbs to remote servers (even at the other end of your office building) in the event of fire or flood is a simple and effective approach helping you to recover quickly.  It is not recommended to put your data centre on the top floor of an office tower put them in the basement.  Machines don't care about the view out of the window, and machine rooms can be designed to be small, airtight using air cooling system to keep the machine room cool and extinguishing any fire in seconds, without causing much damage to other servers.  In a 19inch rack keep at least 2U between servers such that a fire in one machine can't spread easily to another machines.
x) Access to Machine room/office building.  Check staff credentials before employing them, restrict access to vital rooms/systems to a few trusted (and monitored) staff....... and the usual firewall precautions, at an O/S level don't run any more systems daemons than are necessary to fulfil the purpose of the server (A standard installation of RedHat for example, executes loads of programs that a Registrar is unlikely to use .. so delete them before they are used to "crack" your machine).

Sure......, I'll even sign it next time we meet, <smile>

It was drafted by Committee (as they usually are) and is designed as a point of reference there are now loads of renditions of it on the 'net  available (in various languages) when BS 7799 (the standard I worked on as a member of the Committee ) was adopted as ISO 17799. PS I am not associated with the publishers of the evaluation copy accessible on page http://www.securityissues.ac but it is referenced as a useful and accessible rendition of the original standard.

Best

Paul

Rick H Wesson wrote:

Paul,

since you helped write it and it appears to be quite detailed, your
evaluation version is over 500 pages, could you give us some pointers on
which sections we should pay specific attention to? infact if you could
just distil the specific policy into an email I'm sure we would all
appreciate it.

are you attributed in the text? I'll buy it (110 pounds) if your name is
in it.

-rick

On Wed, 24 Oct 2001, Paul M. Kane wrote:

> In light of Dan's email focusing on security issues, it may be helpful to
> members of the Registrar Constituency to review ISO 17799 - a British Standard I
> was involved in writing a few years ago discussing Security Issues in the
> Digital Age.  see http://www.SecurityIssues.ac
>
> Best
>
> Paul
>
> Dan Halloran wrote:
>
> > Rick,
> >
> > Thanks for posting the proposed agenda for the registrars constituency
> > meeting on Monday, November 12.  I'm glad that we were able to arrange a
> > full day for the constituency meeting since there are a number of important
> > issues on the constituency's plate.  In response to several questions I've
> > received, I'd like to supplement your posting with some additional details
> > about the special focus on "Security and Stability of the Internet Naming
> > and Address Allocation Systems" that is planned for the remainder of the
> > week's meetings.
> >
> > A bit of background may help explain why the November meeting was re-focused
> > in the wake of 11 September.  As most of you already know, ICANN's primary
> > responsibility is ensuring the stability of the Internet's naming and
> > numbering systems.  The "White Paper"
> > <http://www.icann.org/general/white-paper-05jun98.htm>, based on which ICANN
> > was founded, lists the first guiding principle of the new DNS management
> > system as "1. Stability: The U.S. Government should end its role in the
> > Internet number and name address system in a manner that ensures the
> > stability of the Internet. The introduction of a new management system
> > should not disrupt current operations or create competing root systems.
> > During the transition and thereafter, the stability of the Internet should
> > be the first priority of any DNS management system. Security and reliability
> > of the DNS are important aspects of stability, and as a new DNS management
> > system is introduced, a comprehensive security strategy should be
> > developed."
> >
> > In light of this mandate, made urgent by the public's concern about
> > terrorism, ICANN is dedicating its November meeting to an in-depth
> > examination of security requirements related to the Internet's domain name
> > and address allocation systems, the extent to which these requirements are
> > currently being met, and what individual, organizational and/or collective
> > actions are needed to create a security environment for the domain name and
> > address allocation systems that reasonably assures their continued operation
> > under, and recovery from emergency conditions.  More specifically, the
> > meeting will seek to: (a) improve the knowledge base and heighten awareness
> > about DNS security by ICANN constituents and the broader public, (b) develop
> > and adopt suggestions for security improvements by all DNS service
> > providers, including registries, registrars, and nameserver operators, (c)
> > develop recommendations to the ICANN Board for any near-term actions by
> > ICANN that may be advisable, and (d) launch continuing efforts to assess and
> > improve security and readiness across the defined scope of ICANN's
> > activities and communities.  (Note that these goals are tightly focused on
> > the DNS and its component service providers -- the registries, registrars,
> > name server operators, etc.  General network security for the Internet is
> > outside the scope of ICANN's mandate.  Technical standards for security, for
> > example, are up to e.g. the IETF to develop.)
> >
> > ICANN Accredited Registrars are central to the stable operation of the
> > Internet's domain name system.  Although I'm reluctant to single any
> > particular companies out just because a particular incident received
> > publicity, I think it would be helpful for all registrars to review the
> > following news stories about registrars that have experienced DNS-related
> > security incidents:
> > <http://www.theregister.co.uk/content/archive/21689.html> and
> > <http://sa.internet.com/InternetNews/intarc/01/01/30.htm>.  Again, these are
> > just examples (and they don't necessarily represent the full breadth of
> > potential problems), but I think it's fair to say that these kinds of
> > incidents make it reasonable for people to ask whether the registrars as a
> > group are doing everything they can to protect the integrity of the DNS
> > within the scope of their operations.  While no registrar is a single point
> > of failure for the DNS (in fact that's one of the architectural strengths of
> > the Internet), each registrar is potentially a single point of failure for
> > its own customers.
> >
> > Please be sure to review the "Update" on the meeting that was just posted at
> > <http://www.icann.org/announcements/update-21oct01.htm>.  (**All attendees
> > will need to pre-register for this meeting, at
> > <http://register.icann.org/register.php>.**)  The Update also provides
> > information about the security/stability schedule and agenda.  For complete
> > details, please see <http://www.icann.org/mdr2001/schedule.htm>.  Here's a
> > brief overview of the schedule:
> >
> > 12 November 2001 (Monday)
> >    - Non-security-focused meetings of ICANN's
> >      various constituent organizations
> >    - Public forum on ICANN At Large
> >
> > 13 November 2001 (Tuesday)
> >    - Keynote speakers
> >    - Plenary panels
> >    - Break-out sessions for all attendees
> >
> > 14 November 2001 (Wednesday)
> >    - Parallel sessions
> >         - Tutorials
> >         - Workshops
> >    - Constituent-focused working meetings for
> >      registries, registrars, ISPs, etc.
> >
> > 15 November 2001 (Thursday)
> >    - ICANN Public Forum on DNS security/stability
> >         - Reporting session
> >         - Open Mike
> >         - ICANN Board meeting
> >    - Open Mike on all other matters
> >    - ICANN Board meeting on other matters
> >
> > An informal program committee <http://www.icann.org/mdr2001/program.htm> has
> > been set up to plan the meeting's schedule and agenda.  The registrars are
> > represented on the committee by Elliot Noss of Tucows.
> >
> > One important topic for registrar review and discussion will be Registrar
> > Data Escrow.  When operational, the escrow program will assure the stability
> > of gTLD registrations by preserving domain registration information and
> > continuing registrar services even in the case of total failure of a
> > registrar or its data storage systems -- thereby increasing consumer
> > confidence in the gTLD shared registry architecture.  ICANN and the
> > registrars need to finalize the terms of an agreement concerning the
> > potential uses, release conditions, and rights to the registration data to
> > be escrowed.  Also, ICANN needs to specify the schedule, terms and format
> > for registrar submission of this data.  The specification for the format of
> > the escrowed data was created by a committee that included technical experts
> > from the Registrars Constituency.  Very shortly ICANN will post for review
> > and comment a draft "Registrar Data Escrow Appendix" (to the Registrar
> > Accreditation Agreement.) This appendix will set forth the proposed deposit
> > contents and procedure, data security provisions, release conditions,
> > right-to-use terms, and the license for a new ICANN Data Escrow Program
> > logo.
> >
> > If you have any other suggestions for topics, speakers or panelists on DNS
> > security/stability, please forward them to Elliot Noss or
> > <meeting@icann.org>.
> >
> > Thank you very much for your attention.
> >
> > Best regards,
> > Dan Halloran
> > Chief Registrar Liaison
> > ICANN
> >
> > -----Original Message-----
> > From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> > Behalf Of Rick H Wesson
> > Sent: 23 October, 2001 10:43 AM
> > To: Registrars List
> > Subject: [registrars] Proposed Agenda for Marina del Rey Constituency
> > meeting
> >
> > Registrars:
> >
> > Below you will find the proposed agenda for the registrars meeting. If
> > there is an issue you wish to have put on the agenda please comment.
> >
> > Be prepared for a long day.
> >
> > Monday November 12th 2001
> > ==========================
> >
> >   0830 to 1200
> >     o intro and agenda bash
> >     o deletes
> >     o transfers / nc transfers task force
> >     o whois
> >     o below $6 pricing
> >     o annual report / budget
> >
> >   1200 to 1330
> >     o lunch
> >
> >   1330 to 1730
> >     o nc elections/nominations
> >     o nc reports
> >     o icann restructuring
> >     o epp
> >     o idn
> >     o Q1 registrars meeting
> >     o open mike
> >
> > -rick
>
>