Threat Modeling 3rd party purchases & tools

Look — I get it. It’s kinda crazy to build your own everything because there are people who’ve already done it. The prevalence of SaSS products, Open Source, or plugins are great at solving problems immediately with their flashy features. It could be something for your business like a chatbot, an immediate grammar checking tool, or marketing tracking pixel.

For the purposes of this blog, this is about evaluating purchases in a corporate environment, but they are incredibly applicable to our daily personal choices, or when we’re building software.

Show me the data

First questions I ask when evaluating a product is — what data does it want, and why?

Understanding the sensitivity of the data the product wants to hold will tell you how deep to look into it. Does it want Social Security numbers? Is it asking for a nickname and email? Is it offered in California or Europe, if so it likely complies with GDPR and CCPA which can give you additional help in removing your data after the fact.

Is it storing or transferring that data? What mechanism is doing this? Where is the data stored? Can you understand this process to the point you could talk someone else through it?

Is the data anonymized or is it attributable to an individual? Having an aggregate is not always possible, but sounds like being a part of a group can make it less pointed to you.

What is the scope of the data collection? Is it asking for more data than you think it needs to run? Is it a weightlifting workout tracker asking for your Social Security number?

What is the scope of the data retention? Does it cycle data out periodically, and if so, at what frequency? Having a more frequent cycle can help minimize risk.

What’s product/s scope

What exactly is being purchased? Knowing the full scope of the purchase helps determine what to examine. Be sure to ask about how they plan to use it, you maybe surprised at what comes up. The requesting party may unintentionally abstract something that’s not obvious upfront.

• Is it a piece of hardware, a software solution, or both?
• Are there secondary features that should be looked at, such as a web app and plugin?

For example, a metrics tool might have a visualization dashboard hosted at a different URL. The requester might not include the visualization dashboard in the request, but it might feature less strict authentication than the main tool, presenting a vulnerability.

Define product installation

How precisely is the software installed? Knowing the installation process helps us understand how the product works.

• Where is it installed — on a VM? Hosted by a vendor?
• Which systems will integrate with it? Do you know what data is on the systems? Or which teams use it & their use of it?

For tools that are JavaScript direct includes, pixels and iframe — see this post for details.

How’s the data transported

If we interact with a third party, how exactly do we send and receive data?

For example, the product might:

• Log in to a web interface and upload CSV files
• Make API calls to a third party service
• Upload files using FTP
• Email files

This gets back to understanding what the user is trying to solve. How do they envision using it? It could be a vague description, be sure to ask questions as if you were purchasing it yourself.

Be aware that vendors may claim to have cited security tests, certifications, or business practices. Claims by vendors should not be taken as absolute or even completely accurate. One vendor’s pentest is another’s cursory vulnerability scan.

Slack— browser plugins

Add-ons and plugins might ask for extensive permissions and gain access to more information than they require be sure to review the docs associated with the products to understand their scope.

The review process for Custom Apps is based on Slack’s own review process, found here: https://api.slack.com/security-review .

How can you tell if an app is overly permissive?

Perhaps your organization needs a slack tool for sharing funny memes — does that tool need read/write to all the slack channels in the organization? Probably not, it could be scoped to the one installed.

Does your chrome plugin need read/write to all the sites you visit and view your browser history? Be critical of what the task is and the access it’s requesting.

Tracking/identifier issues

Code that tracks information might use identifiers that are tied to individual user accounts, or a users’ email address. This might cause privacy breaches.

We will encourage the use of identifiers that do not tie back to confidential information. This of course depends on what your client is passing around!

Looking specifically for 3rd Party JavaScript info? Look here.

Summary

What does everything boil down to?

To get an accurate understanding of the product, you need to ask a lot of questions ranging from installation and specific use. Most important is following what’s valuable: what data could an attacker want and how is it handled?

Have questions? Feel free to tweet me @lovelydreamer. Opinions my own, not my employer!