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

Wed Apr 29 15:18:10 UTC 2020

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

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>
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>;
> 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>
> *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> 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
> 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/20200429/e1a21d5d/attachment-0001.html>