[Gnso-epdp-team] [EXTERNAL] Re: Regarding Urgent Priority requests by non-LEA

Mark Svancarek (CELA) marksv at microsoft.com
Thu Apr 23 13:58:40 UTC 2020


Thanks, Volker!  My comments are inline below.
/marksv

From: Volker Greimann <vgreimann at key-systems.net>
Sent: Thursday, April 23, 2020 1:37 AM
To: Mark Svancarek (CELA) <marksv at microsoft.com>
Cc: gnso-epdp-team at icann.org
Subject: [EXTERNAL] Re: [Gnso-epdp-team] Regarding Urgent Priority requests by non-LEA

Thank you Mark, you explanation highlights one of the key issues of this debate:

What is an urgent issue for one party may not be the same for another.
[Mark Svancarek] Correct.  That’s why more than one category of requestor should be allowed to use the system. This is also why a centralized decider would have been nice, to get some consistency.  C’est la vie.

Ultimately we will need an objective standard to measure urgency. The ones I believe we had already agreed to was life and death situations and imminent terrorist attacks. Another issue is trust in the reporter.
[Mark Svancarek] Correction: The latest draft of Rec 9 says, “imminent threat to life, serious bodily injury, critical infrastructure (online and offline) or child exploitation.“  It doesn’t matter who the attacker is – that may not be know at the time – only what is being attacked.  Note that “critical infrastructure” is likely a defined term in a jurisdiction.

Again, this is something that is easier to attribute to law enforcement of appropriate jurisdiction than to other reporters from the private sector as the latter have no checks and balances and may be motivated by other influences. Handling a request with urgency reduces our ability to verify the accusations made in the request. Many of the issues you describe are not verifiable by contracted parties and need to be believed or taken at face value. So trust is an issue.
[Mark Svancarek] Trust is an important aspect throughout SSAD.  Reputation can serve as a vehicle for trust.  An entity can develop a favorable reputation by being accredited or certified, by having a history of good requests, and by taking extra steps to become a trusted notifier.  Favorable reputations shall be lost by having a history of policy-defined bad requests, by failing audits, or by making spurious escalations when denied.  Over time these can be factored into the learning system and recommendations of the CG, as in many other systems.

All in all, I am open to considering other matters for urgency, but these will have to be carefully considered and weighed against the risks.
[Mark Svancarek] Thanks!

We also need to consider that these requests will not end the threats you describe. Is it really that urgent to get the registration data for a domain when a private enterprise like a bank is under attack by a ransomware operation? Do the security folks not have more important things to deal with at such times, like stopping the attacks or the domains from resolving? Will knowing the data that the registrant provided at the time of registration really end the attack? It may help, but is it really that urgent to know?
[Mark Svancarek] We may have multiple tools in our toolbox.  When a domain name record is the tool we need for a specific job, we should be allowed to use it.  If not, we would use our other tools. As you say, reputation is important.

Finally, if you open the gates too much, the special queue may become useless.
[Mark Svancarek] I would rephrase that as “if you open the gates too much, the special queue will be less effective and non-urgent requesters will be impacted".  I suspect that no threshold of urgent requests will be deemed acceptable to certain CPs, another reason why I prefer a central decider.  But over time we will develop a sense how much volume is to be expected.  Until then we risk urgent requestors might negatively impacting non-urgent requestors. I don’t think that reality disqualifies the concept, it’s just one more thing to discuss in Rec 9 or wherever else the issue pops up.
I do not subscribe to the opinion of the Texan Lt. Gov that there are more important things than living. Life is the most important to protect. Everything else comes later.
[Mark Svancarek] Hopefully there is no confusion that attacks on life are more serious than attacks on banks.  But there are definitions of critical infrastructure for a reason, and we should consider that, too.
[Mark Svancarek] PS: In USA there are many states. Illinois has a history of electing governors whom they subsequently send to prison.  Texas has a recent history of electing governors who say really stupid things.

--
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net%2F&data=02%7C01%7Cmarksv%40microsoft.com%7C12b918fd6cf74596df0a08d7e7619447%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232278599461227&sdata=tF6MxY76gQ7O0MYiCu1Id9KAlEdGOEKryjJrx8EeP2s%3D&reserved=0>

Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835
CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.


On Thu, Apr 23, 2020 at 7:22 AM Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>> wrote:
Although we’ve always discussed urgent priority requests as being available to both LEA and non-LEA, we are regularly asked why non-LEA should be allowed to use this type of request.  We’ve seen this again in the public comments, with new suggestions that a non-LEA requestor must route urgent requests through a government agency rather than making such a request themselves.

To clarify why it’s not sufficient to limit these requests to law enforcement and government agents, I asked my Digital Crime Unit and state actor cyberdefense teams for details. Here’s what they said.


  *   Law enforcement (LE) and Microsoft priorities do not always overlap such that what we consider an emergency, where this information could be necessary to protect our customers ( such as a threat to our infrastructure or our customer’s infrastructure), is the same as an emergency for LE.
  *   The threshold for what is important to protect our customers is often different or  lower than the threshold for a LE emergency as outlined below – but nonetheless just as important.
  *   When a customer or partner is under attack, we would not necessarily engage LE. We would only notify/contact the customer directly since the impact is on their tenant. LE engagement is then at their discretion.
  *   Here are some scenarios where we would likely make urgent data requests separate from LE engagement:

     *   a large banking establishment or school district under ransomware attack
     *   a nation state actor targeting multiple human rights organizations with persistent spear phishing attacks
     *   a nation state actor using a malicious domain to compromise and steal information from members of the United Nations
     *   a nation state actor purchasing large swaths of domains to target multiple organizations in the oil and gas industry, then using them in a large-scale intrusion campaign

Remember that abuse of the Urgent Priority request mechanism is already defined as an activity which may lead to loss of accreditation, even for LEA.  That safeguard would be certainly be invoked quickly if the privilege were abused by a non-LEA requester.

I look forward to discussing this topic soon.

/marksv

_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7C12b918fd6cf74596df0a08d7e7619447%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232278599466215&sdata=rD2DxzdO4KVB7WDu3I9EqVTqMsvFKNG9bN8mxRD%2Bg7o%3D&reserved=0>
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7C12b918fd6cf74596df0a08d7e7619447%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232278599471208&sdata=AR26Voqbiiu1ps1BQV4WzqlfHFFVsk8%2BCnM4Dy7QEf8%3D&reserved=0>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7C12b918fd6cf74596df0a08d7e7619447%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232278599476198&sdata=j%2FncZuLrhlh%2Bb81bMoEzb0UwYzeXGvt%2B%2FYDlnqJWLR0%3D&reserved=0>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200423/215de107/attachment-0001.html>


More information about the Gnso-epdp-team mailing list