[RDS-WHOIS2-Safeguard] Request from Safeguard SG

Alan Greenberg alan.greenberg at mcgill.ca
Wed Jun 13 15:30:37 UTC 2018 

Thanks for the super-fast and detailed response.

I agree with most everything other than the 
recommendation. Although GDPR satisfied the 
requirement where it is in fact applicable law, 
that is not the case everywhere. So I would 
suggest going ahead with the recommendation. If 
it gets answered that it is already covered, so be it.

Alan

At 13/06/2018 11:03 AM, Volker Greimann wrote:

>Hi Alan,
>
>from my experience with IRon Mountain, I have no indication that their
>storage is in any way insecure. I do not know their internal practices
>of how they handle data that we upload to our secure upload locations
>and how exactly they store data, but in the end, that may be a good
>thing as the less a system is known by the outside, the fewer vectors
>for attack there are.
>
>Ultimately, they are contractually committed to safeguard the data from
>unauthorized access and we have no indication that this security has
>ever been compromised.
>
>I support the reporting recommendation in case of breach in principle,
>but a similar clause may already fulfil this requirement as section
>4.1.15 (DENIC RDE Agreement) specifies compliance with privacy and data
>protection regulations as a requirement, and under the GDPR the data
>processor is obliged to inform the data controller of any breach.
>
>There is also a clause in the liability section (10.2.2) that revolves
>around damages claimable in case of such a breach or unauthorized access.
>
>So while it may be preferable to spell it out, I could see the argument
>thrown back at us that this is already included.
>
>Volker
>
>
>Am 13.06.2018 um 16:44 schrieb Alan Greenberg:
> > Team,
> >
> > I have reviewed the Escrow agreement. I belive that it provides
> > adequate specifications for proper storage and transmission of data
> > (expressions such as "commercially reasonable efforts and industry
> > standard safeguards").
> >
> > One question I might want to ask is to what extent is stored data
> > accessible from outside their facility (ie is it well protected by
> > firewalls, or not physically connected). Not sure whether this is
> > really required though. I know traditionally organization such as the
> > US CIA had rules that highly confidential data not be stored on
> > machines with any external connection. I suspect the data we are
> > referring to is neither at that level of confidentialiity and besides,
> > network security has gotten somewhat better.
> >
> > It also includes requirements to separate escrow activities from other
> > domain-name activities, but the presence of such clauses implies that
> > theremay be the possibility of an internal breach, even if the data is
> > reasonably protected from external access.
> >
> > However, I see no requirement to notify ICANN or the
> > Registrar/Registry in the event of a breach and I believe that we
> > should recommend such a requirement.
> >
> > Please comment on whether you agree with such a recommendation and on
> > whether we need to talk to providers regarding physical connectivity.
> >
> > Alan
> >
> > At 11/06/2018 05:52 AM, Alice Jansen wrote:
> >> Dear Alan, Dear Safeguarding Registrant Data Subgroup,
> >>
> >> We have received the following information from subject matter
> >> experts in response to your request for information submitted on 06
> >> June:
> >>
> >> All of the existing registrar data escrow agreements, including Iron
> >> Mountain, can be found here:
> >> 
> <https://www.icann.org/resources/pages/registrar-data-escrow-2015-12-01-en>https://www.icann.org/resources/pages/registrar-data-escrow-2015-12-01-en
> >>
> >> Since data escrow is also a component in legacy gTLD Registry
> >> Agreements, we also recommended reviewing the base Registry Agreement
> >> (data escrow shows up in multiple sections):
> >> 
> <https://www.icann.org/resources/pages/registries/registries-agreements-en>https://www.icann.org/resources/pages/registries/registries-agreements-en 
>
> >>
> >>
> >> The data escrow template for new gTLD registries is published here:
> >> 
> <https://newgtlds.icann.org/en/applicants/data-escrow>https://newgtlds.icann.org/en/applicants/data-escrow
> >>
> >> Thank you,
> >> Best regards
> >> Alice
> >>
> >> On 06/06/18 22:02, "RDS-WHOIS2-Safeguard on behalf of Alan
> >> Greenberg" 
> <<https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>rds-whois2-safeguard-bounces 
> at icann.org on behalf of
> >> 
> <https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>alan.greenberg 
> at mcgill.ca> wrote:
> >>
> >>     Hi Alice and Jean-Baptiste,
> >>
> >>     As per our discussion in the Leadership meeting today, The SafeGuard
> >>     subgroup is requesting that ICANN Org provide us with the contract
> >>     signed with escrow providers so that we may understand what
> >>     processes, constraints or rules escrow providers are subject to
> >>     regarding safeguarding data while under their custody and in
> >> relation
> >>     to any data breaches that may be discovered.
> >>
> >>     If the contracts are all substantially identical, then the standard
> >>     boiler-plate contract will be sufficient. If the contracts are
> >>     significantly tailored, the we request copies of the actual
> >> contracts
> >>     for Iron Mountain and one other provider. If that requires a
> >>     non-disclosure agreement, we are willing to sign one.
> >>
> >>     If this request is still not sufficiently clear, since time is
> >>     running out, perhaps you can put me directly in touch with the
> >>     appropriate people within ICANN Org to more fully refine it.
> >>
> >>     Alan
> >>
> >>     _______________________________________________
> >>     RDS-WHOIS2-Safeguard mailing list
> >> 
> <https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>RDS-WHOIS2-Safeguard 
> at icann.org
> >>     https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard
> >>
> >>
> >> _______________________________________________ RDS-WHOIS2-Safeguard
> >> mailing list 
> <https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>RDS-WHOIS2-Safeguard 
> at icann.org
> >> https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard
> >
> > _______________________________________________
> > RDS-WHOIS2-Safeguard mailing list
> > 
> <https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>RDS-WHOIS2-Safeguard 
> at icann.org
> > https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard
>
>--
>Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
>Mit freundlichen Grüßen,
>
>Volker A. Greimann
>- Rechtsabteilung -
>
>Key-Systems GmbH
>Im Oberen Werk 1
>66386 St. Ingbert
>Tel.: +49 (0) 6894 - 9396 901
>Fax.: +49 (0) 6894 - 9396 851
>Email: 
><https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>vgreimann 
>at key-systems.net
>
>Web: www.key-systems.net / www.RRPproxy.net
>www.domaindiscount24.com / www.BrandShelter.com
>
>Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>www.facebook.com/KeySystems
>www.twitter.com/key_systems
>
>Geschäftsführer: Alexander Siffrin
>Handelsregister Nr.: HR B 18835 - Saarbruecken
>Umsatzsteuer ID.: DE211006534
>
>Member of the KEYDRIVE GROUP
>www.keydrive.lu
>
>Der Inhalt dieser Nachricht ist vertraulich und 
>nur für den angegebenen Empfänger bestimmt. Jede 
>Form der Kenntnisgabe, Veröffentlichung oder 
>Weitergabe an Dritte durch den Empfänger ist 
>unzulässig. Sollte diese Nachricht nicht für Sie 
>bestimmt sein, so bitten wir Sie, sich mit uns 
>per E-Mail oder telefonisch in Verbindung zu setzen.
>
>--------------------------------------------
>
>Should you have any further questions, please do not hesitate to contact us.
>
>Best regards,
>
>Volker A. Greimann
>- legal department -
>
>Key-Systems GmbH
>Im Oberen Werk 1
>66386 St. Ingbert
>Tel.: +49 (0) 6894 - 9396 901
>Fax.: +49 (0) 6894 - 9396 851
>Email: 
><https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard>vgreimann 
>at key-systems.net
>
>Web: www.key-systems.net / www.RRPproxy.net
>www.domaindiscount24.com / www.BrandShelter.com
>
>Follow us on Twitter or join our fan community on Facebook and stay updated:
>www.facebook.com/KeySystems
>www.twitter.com/key_systems
>
>CEO: Alexander Siffrin
>Registration No.: HR B 18835 - Saarbruecken
>V.A.T. ID.: DE211006534
>
>Member of the KEYDRIVE GROUP
>www.keydrive.lu
>
>This e-mail and its attachments is intended only 
>for the person to whom it is addressed. 
>Furthermore it is not permitted to publish any 
>content of this email. You must not use, 
>disclose, copy, print or rely on this e-mail. If 
>an addressing or transmission error has 
>misdirected this e-mail, kindly notify the 
>author by replying to this e-mail or contacting us by telephone.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rds-whois2-safeguard/attachments/20180613/cc835315/attachment-0001.html>

More information about the RDS-WHOIS2-Safeguard mailing list