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

Mark Svancarek (CELA) marksv at microsoft.com
Wed Apr 29 17:25:01 UTC 2020


I’d like to remind everyone that we’ve already negotiated this and the report sent out for public comment already declared that non-LEA could use urgent priority.  I am just trying to keep the language already in the draft report, which presumably you previously agreed to!

We already work very closely with LEA. We do research and share the results with them. This is a system which is beneficial to them. But as described below, there is a category of urgent requests that we would take directly to the infrastructure owner, and it would not be helpful to delay our engagement with them while hunting for an interested government agency to sponsor an urgent request.

As for “We should move away from trying to defend our employers particular interests and focus on the bigger picture”, I would of course say the same thing to CPs who I hoped would be my partners.

/marksv




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

Maybe I know to little about the MDCU and I am sure they do excellent work but ultimately they cannot be compared to public authorities or critical national infrastructure providers, can they?

If you get in, what is to stop smaller two-person internet crime fighter outfits from demanding the same?

Maybe the solution is that you work closer with law enforcement so you provide the data they need to them and they take it from there?

We should move away from trying to defend our employers particular interests and focus on the bigger picture.

On Wed 29. Apr 2020 at 18:41, Mark Svancarek (CELA) <marksv at microsoft.com<mailto:marksv at microsoft.com>> wrote:
I cannot accept a policy which does not include a path for Microsoft DCU to ultimately receive authority to make urgent priority requests.

Perhaps I am still misunderstanding your proposal. Please clarify.

Does
“others may also have access to the urgent queue, but would be more restricted in its use"
Mean
“there will be a practical way for Microsoft Digital Crimes Unit to be accredited to make occasional urgent priority requests”?

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

I would assume others may also have access to the urgent queue, but would be more restricted in its use. Operators of critical national infrastructure could be included. Private crime fighters such as the unit you describe would probably not be considered as such though.
--
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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787097362&sdata=v0VTJE%2Fi1snLx21crjQl87LFAbibEkca%2Bw08ohc%2Fon8%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 Wed, Apr 29, 2020 at 6:13 PM Mark Svancarek (CELA) <marksv at microsoft.com<mailto:marksv at microsoft.com>> wrote:
A), as written below, still implies that only government entities may receive authority to make urgent requests.  It is possible that I am misinterpreting this.

Please clarify – how would Microsoft Digital Crime Unit receive authorization to make urgent priority requests?  Is this a special type of accreditation?

B) and C) are already required in our draft policy, so there should be no controversy here.


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

Hi,

to expand upon my previous mail on the subject I would see the following basic requirements for any framework for urgent requests:

a) Requestor is authorised to send urgent request
b) Request is made in relation to subject matters where urgent requests are permitted
c) Requestor demonstrates urgency is required in this case

For a), we will need to define who should have the authority to even be allowed to enter the portal to urgent requests. If you are not a bearer of the special pass, thou shalt not enter these hallowed halls. Basic concepts required for this pass should be special authority, dependability and potentially others. Authority would flow from specific legal powers, such as law enforcement of appropriate jurisdictions. Others may be possible but should still have comparable authority that can be shown in evidence. Dependability would be measured as a track record of previously confirmed urgent requests, e.g. how dependable is the requestor in only using this fast lane for cases where it is actually required.

b) Obviously, if you are an operator of a facility that has been granted access to make urgent requests to act quickly in case your site is attacked, you should not be using the queue to request data of someone violating your trade mark. So we will probably down the line have to define what matters can make use of this speed lane. This should probably be an open-ended refinement process as otherwise we will surely forget something or someone. For starters, the content of the draft Rec 9 should be sufficient, but will need some more defining. For example, critical infrastructure could be equated by what is defined by many national laws as critical national infrastructure but the problem here is that such laws do not exist in every country and may be wildly different in scope. Our approach should work across the board.

c) Every request with urgency should be accompanied with a statement of why an urgent response is needed and how your request is related to your authority. Fail to make that case and to the back of the regular queue you go.


--
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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787097362&sdata=v0VTJE%2Fi1snLx21crjQl87LFAbibEkca%2Bw08ohc%2Fon8%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 Wed, Apr 29, 2020 at 4:21 PM Mark Svancarek (CELA) <marksv at microsoft.com<mailto:marksv at microsoft.com>> wrote:
Everyone, we will be discussing this topic in plenary soon.  Given the business of meetings, it will be good if we can discuss this topic in advance of the meeting. If you have any additional feedback which may be helpful before we meet, please add it here.

Thx.
/marksv

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

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

From: Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>
Sent: Thursday, April 23, 2020 1:37 AM
To: Mark Svancarek (CELA) <marksv at microsoft.com<mailto:marksv at microsoft.com>>
Cc: gnso-epdp-team at icann.org<mailto: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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787107357&sdata=8c6mxjccVfG7r5%2BugQAKb1v1jeQIlMGS4FeL55mX7z4%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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787117349&sdata=wirIDU68dbd8SeVDFhCIFKetJYigbURDUfGo9xScBIo%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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787117349&sdata=RWGWGlqrpyHPJp9mk6BM0UkMbmu85LP%2FPH4L6KYrIDM%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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787127346&sdata=souBmYlHPgaUaL0z%2FrDrAuzHAzTYsaVap%2B1xv1aHhfs%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.
--
--
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%7Ccef9407b0f1d4fbe1e1508d7ec5fa134%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237767787127346&sdata=5PLj4KlPgPzR0NatYnVwxzJXdO4JPOT6SdQXNySQB1o%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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200429/f4240eff/attachment-0001.html>


More information about the Gnso-epdp-team mailing list