In the world of interconnectivity, we find third-party applications can be extremely helpful in integrating business solutions. For example, a Quickbooks plug-in may make our CRM software much more seamless; a marketing platform might plug in to our CRM data to enhance its value.
Yet these types of third-party applications require an opening in our IT infrastructure’s security, which in turn increases cybersecurity risks. While these risks can be mitigated to acceptable levels, a business must remain vigilant in the methods and manners in which a third-party application is given access.
In his article “Third-Party App Access Is the New Executable File”, Co-Founder and CEO of Adaptive Shield Maor Bin compares this access to malware in the damage that can occur should the integration’s relationship become malicious.
Much of this new integration that allows third-party applications access to a larger infrastructure is due to OAuth 2.0. Short for “open authorization”, OAuth 2.0 is the second version of the open authorization standard. (It replaced OAuth 1.0 in 2012.) While we will not get into a deep dive on how OAuth 2.0 works, the basic principle uses shared tokens between client and server. More information can be found at the OAuth homepage.
Once a third-party application is authorized, there often is a “checklist” of required access the application needs. For example, a marketing tool will almost certainly need access to the contact list of a CRM, for example, to leverage prospects and suspects lists for communications. Similarly, the Quickbooks plugin cited previously may need access to finance records and transactions to remain current. Care should be taken by a proficient security team that any particular third-party application is granted only the minimum access required. This is called principle of least privilege and can be applied to software just as it might be applied to an staff role.
One way to think about this is the way that a mobile application asks for various permissions on your phone. A fast food app may want location access, financial information (for easy payment), camera, and other permissions. Each individual user should consider what permissions are needed for any given application. What would the repercussions be if that application were hacked?
Considerations for allowing Third-Party Applications sensitive access
With these types of decisions, a security expert must balance risk and utility. However, here are some tips on how to successfully navigate third-party applications and integrations:
- Consult your I.T. security team
- The first step in a new integration should be your IT team. He, she, or they can assess the best methods of integration and how much risk is acceptable in his/her/their opinion. It is not recommended to assume on the IT team’s behalf—there may be security pieces that you could be unaware of, even as a decision-maker in a business.
- Always use known vendors. This isn’t a perfect solution—by any stretch—but allowing access to vendors or developers you are unfamiliar with should be an immediate red flag.
- Share with your team the risks involved in third-party applications. While we do not want to stop progress or movement toward helpful integration, there is a limit that makes practical sense. Trying integration after integration, for example in trying new tools, only further opens possibilities of security holes. Informing end users that they may be limited to trying a certain (reasonable) number of tools will help set expectations.
- Principle of Least Privilege
- We touched on this earlier and linked this post explaining the concept. Essentially, we just want to limit access for third-party applications to permissions it will need to correctly execute its function.
- Make an informed decision on ease of use and value versus security risk
- For each of these third-party applications, a security-minded decision maker should weigh the benefits against the security cost of each solution. As with many IT security based questions, how much risk are you/your cyberinsurance policies/your compliance requirements willing to live with?
- Set up periodic third-party applications audit
- Security managers should conduct periodic audits of third-party applications and their permissions. This will help keep a handle on possible exposures and show where overlapping exposures may be occurring.
If you need help with your integrations of third-party applications, CONTACT US and our security experts can help you out!