4

Our customer (a bank) needs to publish a web-service API for use by 3rd party applications. The security is going to involve OAuth2 and JWT (JSON Web Token). The problem is that the customer is afraid of misuse of the published APIs by the 3rd parties to whom they don't trust completely (please, don't comment on this). A basic scenario is like this:

The public API contains an operation IsOurCustomer() that returns true/false if the person has a product in the bank. The subsequent operation is CreateNewCustomer(), and is called when IsOurCustomer() returns false.

The bank is afraid that a 3rd party could scan their customer-base by checking who is/isn't their customer via calling IsOurCustomer() sequentially for all people taken from another source (say from a public state registry). (I can't tell whether the presumed damage is real, or whether it's a paranoia only.)

Is there a way how to prevent the possibility of data-scanning?

There are some partial solutions we came with, but none of them mitigates the problem completely:

  1. Throttling - It's hard to set the right limit which wouldn't restrict the legal work of the 3rd party company, but would prevent them to misuse the API at the same time. Especially, when the 3rd party has many employees and enough time. The 3rd party could issue thousands of (justified) customer-checks per day, which could allow them to scan 1 million of people per year.
  2. Legal threats - when API misuse is detected (which needs logging, monitoring).
  3. Payments per API call - above an agreed limit
  4. Heuristics - e.g. signal an alert when the ratio of calls to IsOurCustomer() and CreateNewCustomer() is too high.
  5. "Data Leak Prevention system" - I don't know of any usable DLP for our purpose.
  • 2
    The presumed damage can be very real. – Pieter B Nov 15 '16 at 17:24
  • 1
    What prevents data breach at the 3rd party after they have legitimately checked thousands of customers, assuming they cache that information? – Erik Eidt Nov 15 '16 at 18:36
  • Billing is hardly going to give you any guarantee. If benefits of exploiting the service outweight the costs, the solution become inefficient. I agreed with Ewan, tenantcy through API Management could mitigate the risk. – Laiv Nov 15 '16 at 18:53
  • @Pieter, Erik - Can you be more specific about the damage? What use can anyone make of the information alone that someone is a customer of a bank (true/false)? Of course, if there are names, addresses etc. involved, this really shall be a problem, but this is not the discussed case. On the other hand, you pointed to another problem - that there may be leak of information from the 3rd party about the customers to which the 3rd party is allowed to access. – xarx Nov 15 '16 at 19:54
  • @xarx it's a bank. Banks have competitors. Knowing which people in a geographic region are clients of your bank can be very very valuable information for a competitor, think about things like targeted advertising to all the clients of your bank. This is only one thing though, there are many more reasons, like scamming, but that goes too far for a comment. – Pieter B Nov 15 '16 at 23:26
3

It sounds like a legitimate concern to me.

You don't go into much detail about the purpose third parties are given use of the api for.

  • But if they are not supposed to be able to see who is a customer or not and they don't require that information then there is a simple solution:

  • Remove IsOurCustomer()

Have each 'tenant' of the api create their own customers and link them back to the banks customers privately if required for reporting.

Perhaps you have a more complex scenario though.

  • The third party NEEDS to know if the customer is already a customer or not, say as part of a sign up procedure, but the bank doesn't want to tell them

  • Require the third party to sign a contract stating that they will only use the information from the api for a particular purpose.

This would be fairly common in these days of data protection. The bank needs to recognise that this is a human problem rather than a technical one.

However, perhaps you have an even more delicate situation!!

  • The third party requires the information in order to be able to carry out the task the bank has specced. But when the legal dept looks at it they said that the bank could not legally tell the customer that information.

  • Here you are kinda screwed. However, perhaps you can get the third party to demonstrate that they already know the information you are divulging. For example: IsOurCustomer(string bankAccountNumber)

  • The 3rd party company are customer-hunters. I presume that the reason for an operation like IsOurCustomer() is in that different information needs to be provided for existing customers and for new customers, so that learning this information after call to CreateNewCustomer() is too late. However, the 3rd party is expected to use IsOurCustomer() only for the potential customers they are talking to at that moment, but not check who's a customer for people they have nothing to do with. Especially, not in a systematic manner. – xarx Nov 15 '16 at 20:14
  • In your second case: What if an outcome of breaking the contract is bigger than the fine, as Laiv mentions in a comment above? What else can be done to minimize the risk? – xarx Nov 15 '16 at 20:20
  • in the second case you move the risk to the bank. it stops being your problem – Ewan Nov 15 '16 at 22:20
  • the situation you describe sounds like a good match for the third case. force them to prove they have completed some steps before the IsOurCustomer function works. perhaps the customer has to log in and click something before the third party can proceed – Ewan Nov 15 '16 at 22:22
1

You might consider combining the two operations. Have CreateNewCustomer check for existing customers and return a message that says it was an existing customer and contains the existing customer id. That way you can't scan a large database without creating new customers, which presumably has some sort of email verification step or something else that would get noticed.

  • I know this would remove the problem. But it would also reduce the usability of the API at the same time. – xarx Nov 15 '16 at 20:39
  • Not from a consumer perspective. I can simply call 'create()' instead of 'if (exists()) { get(); } else { create(); }'. This makes you API simpler and removes your problem. – Bruno Schäpper Nov 16 '16 at 6:48
  • Please, see my comment to Marshall Tigerus. – xarx Nov 16 '16 at 7:58
1

This is a serious risk, I think, but there's a way around it that allows you to trust certain people.

I am assuming that a third party has a legitimate need to know if someone is your customer.

I would give each third party an identifier that they are responsible for that identifies them to the API. This identifier then links up to a denormalized table that references a unique id for a customer. If that denormalized combination isn't in the table, then for all intents and purposes, that third party doesn't know that customer exists.

So, you have Customer A who has a relationship with Third Party 1, but not Third Party 2. Naturally, you only want Third Party 1 to see this customer, so when Third Party 2 makes a call with Customer A's info, but their id, they get a response that this customer doesn't exist (or whatever error you want to give). Third Party 1, however, can safely call the same API, and get back information about the customer.

EDIT: I'm also assuming you are doing the appropriate securing of these endpoints so that only your trusted third parties can access them, and not some random guy off the street. Since this data is probably FINRA regulated, you are obligated to protect it.

  • If I understand you well, you are talking about that a 3rd party should have access only to data of their own customers. This is already handled by us. The problem is not with the current customers, but with persons that are not customers (yet). – xarx Nov 15 '16 at 22:10
  • Why would they need access to them? – Marshall Tigerus Nov 16 '16 at 3:14
  • They do not need access to them (there is no information to access), but they need to now whether this is the case. For instance, in order not to create duplicate customers in the customer database of the bank. Or, to avoid collecting information that is already available. – xarx Nov 16 '16 at 7:56
  • Handling duplicate data should be done on your end, unless you want to give access to all customers to the 3rd party (which seems to be your issue). – Marshall Tigerus Nov 16 '16 at 14:11
0

This feels like you are trying to solve a human problem with technical means. While technology can stifle human misuse, someone who is determined enough will find a way. The only way to stop that is to put so much technology in the way of using the API that it becomes impossible to use at all (both legitimately or otherwise). Barring making the API unusable, try solving a human problem with human solutions, which in this case is probably lawyers.

First, secure the API. Make it so that in order to use the API, every request requires a unique API key per 3rd party. (Optionally add encryption, possibly asymmetrical, if that is a concern.) Require 3rd parties to sign a legal agreement as to how the data is allowed to be used before issuing them an API key.

Second, log, a lot. Making someone sign an agreement not to misuse the data is kinda worthless if you have no way of detecting or proving misuse. Since everyone has a unique API key, it should be pretty easy to know who is making what requests and with what frequency. Then have something periodically analyze the logs and raise warnings if anything suspicious comes up. Then let a human make the final decision on whether or not the usage looks legit.

  • Exactly, It feels to me the same way. But our customer (the bank) asks for a solution that would completely mitigate the problem, for them it's go/no-go. Concerning of the rest of your answer, this is exactly what we are going to do. In particular, we are using secure API management, and logging, and logging, and logging :-). Thank you for your answer. – xarx Nov 15 '16 at 20:37
  • @xarx Sorry your bank client lives in a fantasy world where hackers don't exist and computers can detect lying and shady intentions. Good luck finding a solution with complete mitigation. – Becuzz Nov 15 '16 at 20:46
  • No, they live in a world where there is a solution for everything - only we need to find it. – xarx Nov 15 '16 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.