[RDS-WHOIS2-Safeguard] Request from Safeguard SG

Wed Jun 13 15:03:52 UTC 2018

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
>>
>> 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 
>>
>>
>> The data escrow template for new gTLD registries is published here: 
>> 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" <rds-whois2-safeguard-bounces at icann.org on behalf of 
>> 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
>>     RDS-WHOIS2-Safeguard at icann.org
>>     https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard
>>
>>
>> _______________________________________________ RDS-WHOIS2-Safeguard 
>> mailing list RDS-WHOIS2-Safeguard at icann.org 
>> https://mm.icann.org/mailman/listinfo/rds-whois2-safeguard
>
> _______________________________________________
> RDS-WHOIS2-Safeguard mailing list
> 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: 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: 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.