Technical Risks of third-parties

A third party would be defined as any contractor, business associate, business partner, vendor or even volunteer who works within your organization.  When you work with a third party it will instantly create an additional risk for your organization. However, that level of risk will depend upon the third party, as not all third parties are created equal. A third-party security services firm with a positive reputation will most likely introduce less risk than a contractor hired to do marketing.  

Third Party Risk Management has quickly been recognized as a vital task, which must be taken seriously. As companies look to adopt newer technologies and become more agile it is only reasonable to think that third parties will be utilized more frequently in the future for more and more services and tasks. Without assessing, and managing third party relationships how can you be sure that your third party is taking your security seriously? 

From a technical perspective a third-party connection could come in various forms for example a web API (web hook) pulling data from one source into another system which could inadvertently share information through web services. A more traditional third-party connection could be a remote user with VPN access or direct connections through an application such as Citrix. Another possibility of a third-party connection could be a Site-to-Site VPN between corporate networks, which is always, open and connected which could potentially lead to the most risk.  Additionally, a third party may have access to a secure file transfer protocol (SFTP), which could be used to transfer and/or exchange information between companies. Each method described details differing levels of access and with that third-party access it introduces potential risks.

A Web API could be utilized to transfer PHI or other data through HTTP(s).  This method is similar to a user accessing a web application to view a medical record, but instead of a user it’s an automated process which pulls the medical record or other information requested and returns results to be incorporated or displayed to the initial program, which made the request. An example of this would be if I created a web site dedicated to the price of gold. One of my main objectives of this website is to display the current price of gold.  However, I don’t want to edit the website continuously to keep updating the price of gold as it changes in real-time.  Instead I could create an API which will pull the price of gold from another site of my choosing which would then be displayed on my website.  This API would be updated in real-time and would not require me to consistently update the gold price on my web site.   

A remote VPN is pretty straight forward it would be a single user accessing a VPN to obtain network access to utilize the agreed upon asset.  Similarly, a direct access connection through a Citrix or VMware application environment can utilize a native ability to limit the contractor or third parties’ access to only the required resources. While a site to site VPN is a consistent open connection between your organizations network and the third parties’ networks.  Site-to-Site VPNs should be avoided, as the trust of the third party can never truly be known without extensive audits. If a Site-to-Site VPN must be used it is important to utilize a strict deny all rule and allow only the specifically needed traffic through the VPN tunnel.

An SFTP connection is a common way to allow the exchange of information.  A third party can be provided unique credentials and provide the source of their IP address to allow for the source validation of the incoming IP addresses to allow only the known third parties to upload data to your file upload service.  Validating the source IP address along with a unique username/password to authentication over a SFTP is a secure method.  Ideally, the third parties would only have permissions to view data or folders associated with their company and have the ability to only upload data.

Additionally, a third party may actually host all of your data. With the strong adoption of cloud hosting it is becoming more common for companies to offload their sensitive information to the cloud. If sensitive information is stored in the cloud it should be detailed in a third-party risk tracker. Additionally, the vetting and continued assessing of any hosted provider should be considered as the wrong choice could have costly consequences.

All of these different methods have many similarities when it comes to managing third party access. The use of third-parties will only continue to increase with newer technologies and advancing skill gaps between workers. If an organization follows the proper vetting, management and continued auditing of their associated third-parties then an organization can effectively limit and document the risks involved. We have some steps below that all organizations should follow to keep their relationships productive and secure.

The first step is to include, review and update contract language in BAAs addressing third party security requirements, obligations and best practices. This is especially true for any service which hosts PHI.

Second is to track which contractors or third parties have access to what data or systems.  A detailed tracker will go a long way to document and understand who has access and what level of access they possess. Additionally, for APIs, SFTP, VPNs, hosted data and other connections should include the IP addresses of a connection; ports, protocols and all characteristics of the connections possible. 

Additionally, the technical aspects of third-party management should spin-off different tasks, which should be performed regularly to add a layer of defense.  These audits can catch mistakes, anomalies, things falling through the cracks and any other things overlooked regularly. 

      Verify unique IDs are in place for all users

      Verify the appropriate level of privileges is set for all users

      Test the monitoring in place to ensure it is in place and working properly especially for third party users

     Verify secure protocols are implemented for all transmitting of sensitive information

 Verify that any PHI stored is encrypted while at rest

      Review connection agreements are matching the agreed requirements

When it comes to securing your third-party relationship, it should follow the same principles as the rest of your security practices. Do the basic things track the third-party users or connections, detail the level of access, implement strong access controls, and verify your monitoring is working properly. Also, make sure only secure protocols are used for any data exchanges and always audit and review. Finally, strongly assessing and reviewing your third party can help ensure the continued security of your sensitive infrastructure. It is better to discover the possible can of worms now before you find yourself making a headline for the wrong reasons.