Overview
The security level of a computerized system is as good as the security level of its weakest links. If one part is secure and tightened properly and other parts are compromised, then your whole system is compromised, and the compromised ones become your weakest links. The weakest link fits well with attackers? mindset which always looks for the least resistant path to their goal. Third parties in computers present an intrinsic security risk for CISOs, and in general, to any person responsible for the overall security of a system. A security risk is one that is overlooked due to a lack of understanding and is not taken into account in an overall risk assessment, except for the mere mention of it. To clarify, third-party refers to all other entities that are integrated into yours, which can be hardware and software, as well as people who have access to your system and are not under your control.
A simple real-life example can make it less theoretical: Let?s say you are building a simple piece of software running on Linux. You use the system C library, and in this case, play the 3rd party role. If the C library has vulnerabilities?then your software has vulnerabilities. And, even if you make your software bulletproof, it still won?t remove the risks associated with the C library which becomes your software weakest link.
Zooming out on our imaginary piece of software then, you probably already understand that the problem of the 3rd party is much bigger than what was previously mentioned, as your software also relies on the operating system and other installed 3rd party libraries, and the hardware itself, and the networking services, and the list goes on and on. I am not trying to be pessimistic, but this is how it works.
In this post, I will focus on application integration-driven weakest links for the sake of simplicity, and not on other 3rd parties such as reusable code, non-employees, and others.
Application Integration as a Baseline for 3rd Parties
Application integration has been one of the greatest trends ever in the software industry, enabling the buildup of complex systems based on existing systems and products. Such integration takes many forms depending on the specific context in which it is implemented.
Mobile World
In the mobile world, for example, integration serves mainly the purpose of ease of use where the apps are integrated into one other by means of sharing or delegation of duty, such as integrating the camera into an image editing app?iOS has come a long way in this direction with native FB and Twitter integration, as well as native sharing capabilities. Android was built from the ground up for such integration with its activity-driven architecture.
Enterprise Systems
In the context of enterprise systems, integration is the lifeblood of business processes where there are two main forms of integration: one-to-one such as software X ?talking? to software Y via software or network API. The second form is many-to-many, such as in the case of software applications ?talking? to a middleware where later the middleware ?talks? to other software applications.
Personal Computers
In the context of a specific computer system, there is also the local integration scenario which is based on OS native capabilities such as ActiveX/OLE or dynamic linking to other libraries ? such integration usually serves code reuse, ease of use, and information sharing.
Web Services
In the context of disparate web-based services, the one-to-one API integration paradigm is the main path for building great services fast.
All In All
Of course, the world is not homogeneous as is depicted above. Within the mentioned contexts you can find different forms of integration which usually depend on the software vendors and existing platforms.
Integration Semantics
Each integration is based on specific semantics. These semantics are imposed by the interfaces each party exposes to the other party. REST APIs, for example, provides a rather straightforward approach to understanding the semantics where the interfaces are highly descriptive. The semantics usually dictate the range of actions that can be taken by each party in the integration tango and the protocol itself enforces that semantics. Native forms of integration between applications are a bit messier than network-based APIs where there is less capability to enforce the semantics allowing exploits such as in the case with ActiveX integration on Windows which has been a basis for quite a few attacks. The semantics of integration also includes the phase of establishing the trust between the integrated parties, and again, this varies quite a bit regarding implementation within each context. It varies from a zero-trust case with fully public APIs such as consuming an RSS feed or running a search on Google with an Incognito browser up to a full authentication chain with embedded session tokens.
In the mobile world where the aim of integration is to increase ease of use, the trust level is quite low: the mobile trust scheme is based mainly on the fact that both integrated applications reside on the same device such as in the case of sharing, where any app can ask for sharing via other apps and gets an on-the-fly integration into the sharing apps. The second prominent use case in mobile for establishing trust is based on a permission request mechanism. For example, when an app tries to connect to your Facebook app on the phone, the permission request mechanism verifies the request independently from within the FB app, and once approved, the trusted relationship remains constant by use of a persisted security token. Based on some guidelines, some apps do expire those security tokens, but they last for an extended period. With mobile, the balance shift remains between maintaining security and annoying the user with many too many permission questions.
Attack Vectors In Application Integration
Abuse of My Interfaces
Behind every integration interface, there is a piece of software that implements the exposed capabilities, and as in every software, it is safe to assume that there are vulnerabilities just waiting to be discovered and exploited. So the mere existence of opening integration interfaces from your software poses a risk.
Man In The Middle
Every communication among two integrated parties can be attacked using a man in the middle (MitM). MitM can first intercept the communications, but also alter them to either disrupt the communications or exploit a vulnerability on either side of the integration. Of course, there are security protocols such as SSL which can reduce that risk but not eliminate it.
Malicious Party
Since we don?t have control of the integrated party, then it is very difficult to assume that it has not been taken over by a malicious actor which now can do all kind of things: exploit my vulnerabilities, exploit the data channel by sending harmful or destructive data, or cause a disruption of my service with denials of service attacks. The other risk of a malicious or under attack party is about availability, and many times with tight integration your availability strongly depends on the integrated parties’ availability. The risk posed by a malicious party is amplified due to the fact trust is already established, and many times a trusted party receives wider access to resources and functionality than a non-trusted party, so the potential for abuse is higher.
Guidelines for Mitigation
There are two challenges for mitigating 3rd party risks: the first one is the visibility that is easier to achieve, and the second is what to do about each risk identified since we don?t have full control over the supply chain. The first step is to gain an understanding of which 3rd parties your software is reliant upon. This is not easy as you may have visibility only over the first level of integrated parties?in a way this is a recursive problem, but still, the majority of the integrations can be listed out. For each integration point, it is interesting to understand the interfaces and the method of integration (i.e. over the network, ActiveX), and finally, trust establishing a method. Once you have this list, then you should create a table with four columns:
- CONTROL – How much control you have over the 3rd party implementation.
- CONFIDENCE – Confidence in 3rd party security measures.
- IMPACT – Risk level associated with potential abuse of my interfaces.
- TRUST ? The trust level required to be established between the integrated parties before communicating with each other.
These four parameters serve as a basis for creating an overall risk score where the weights for each parameter should be assigned at your discretion and based on your judgment. Once you have such a list, and you?ve got your overall risk calculated for each 3rd party, then simply sort it out based on risk score, and there you’ve got a list of priorities for taming the weakest links.
Once you know your priorities, then there are things you can do, and there are actions that only the owners of the 3rd party components can do so you need some cooperation. Everything that is in your control, which is the security of your end in the integration and the trust level imposed between the parties (assuming you have control of the trust chain and you are not the consumer party in the integration), should be tightened up. For example, reducing the impact of your interfaces towards your system is one thing in your control as well as the patching level of dependent software components. MITM risk can be reduced dramatically with the establishment of a good trust mechanism and implementation of secure communications, but not completely mitigated. And lastly, taking care of problems within an uncontrolled 3rd party is a matter of specifics that can?t be elaborated upon theoretically.
Summary
The topic of 3rd party security risks is a large one to be covered by a single post, and as seen within each specific context, the implications vary dramatically. In a way, it is a problem which cannot be solved 100%, due to lack of full control over the 3rd parties, and lack of visibility into the full implementation chain of the 3rd party systems. To make it even more complicated, consider that you are only aware of your 3rd parties, and your 3rd parties also have 3rd parties?which in turn also have 3rd parties?and on and on?so you can not be fully secure! Still, there is a lot to do even if there is no clear path to 100% security, and we all know that the more we make it hard for attackers, the costlier it is for them, which does wonders to weaken their motivation.
Stay safe!