Share via

Tax Season... So Threat Model This...

  • Article

Tax Season! I came across a scenario that I wanted to share…

Scenario: You have some tax application that, let’s say, we’ll call OnlineTaxApp. You also have your online banking site where you manage your finances/investments/etc. called OnlineBankingSite. Then there is you looking to fill out your tax return. As part of the data you input into OnlineTaxApp, the application gives you an option to input your credentials from OnlineBankingSite with which the application can automatically import your interest/investment data, for example from the banking site. The same credentials that are used to manage your entire investment portfolio and banking data now being asked to provide to a third party who only wants access to a subset of information for read-only purposes! What do you do? Do you provide your credentials? What’s the risk here?

Well the risk is pretty straight forward. You just don’t know how the OnlineTaxApp is going to handle your credentials. What if OnlineTaxApp stores those credentials? What if the developer of this particular feature is harvesting the banking credentials in the backend from OnlineTaxApp? What if OnlineTaxApp is just inadvertently logging the credentials somewhere which are just waiting to get lost in the wrong hands in the future? What if…

Clearly lots of what if scenarios that we should be able to threat model and mitigate. The question really is who is accountable for the mitigation and how should this be mitigated?

The user? If I had to use this OnlineTaxApp, I would have two windows open. One window would be the OnlineTaxApp and the other window would be the OnlineBankingSite. Right after I imported the data into OnlineTaxApp, I would go to the other window and immediately change my credentials to OnlineBankingSite (no reason why the tax software would need my credentials ever again after it has imported the data!)

OnlineTaxApp? Clearly, as part of the threat model for this application, we would model the use case of the import feature where the banking credentials are used. In this use case, the spotlight would be on the question of retention for this piece of data. And the sensible thing here would be to ensure proper handling of this data as it’s being used but then followed by proper disposal (out of memory, out of storage, etc.).

OnlineBankingSite? This is where things get interesting. As you threat model this system you would see in your access control matrix that the role associated with the user credentials has access to not only read data but also update, create and delete other records. And yet for these APIs that this site must have exposed through which it can expose certain data to third party consuming applications, it is asking for the same credentials although it is only servicing read-only data: clearly a violation of principles of least privilege. So how could this have been designed a bit better… a bit more secure? Simple, you need a separate role with separate credentials that only allow read-only access to the data. You can setup a feature where you give the user of the site an option to create temporary export accounts, for example. It is this account’s credentials that you would then supply to a tax software where it can be ensured that the privilege of this account is aligned to the minimal set of functionality (i.e., read-only) that is exposed through the APIs.

None of this is really rocket science but in today’s world of complex, interconnected systems that we develop, it often gets difficult to assess, in a systematic fashion, the security consequences of features we develop. One more reason for threat modeling! Not only that, you see in this example, why it’s critical for line-of-business type applications such as banking and tax applications, to maintain an asset-centric view… just follow the data and the bad stuff will pop up. J

-Talhah

Comments