ArcGis Python Security Concerns

AndreasLundström · ‎01-07-2015

I’m working for a large organization which are using ArcGis Desktop on some (windows) clients. The security requirements for the system is very strict, and a part of that is prohibiting the users the ability to use compilers and interpreters. This pose an issue with ArcGis products since they rely heavily on Python scripting. We are looking into different ways of locking down python as much as possible without rendering ArcGis Desktop useless. The environment is Windows 2008 R2 servers with Windows clients. We would prefer to lock down python to only allow for execution of scripts in the ArcGis folder, and block other folders as well as the interactive prompt.

We have heard rumors that a solution for locking down Python in ArcGis has been presented at a user conference but we have not seen a description of how it was done. The ArcGis version we are using is 10.2 and we have experimented using both the “in process” bundled python as well as the external python installation in the system. Our first approach was looking into restricting python with group policies, but that is not easily done since Python is not “GPO aware”. Using software restriction policies are basically a block Python for all or allow Python for all. Since python scripts are run through the interpreter (python.exe), the GPO software restriction settings for executable locations only checks the python.exe and not the script location itself (the GPO system only sees the python script as a generic argument to the python.exe executable).

So my question is if anyone has have any experience in tightening the security concerning ArcGis and Python?

ThomasColson · ‎01-07-2015

This is not an answer but just me venting...

I'd have a serious chat with organization leadership about what its mission is and how they want to achieve those goals. As ESRI technology grows more and more complex and more reliant on "cloud" infrastructure and web-based data discovery, the disconnect between IT and GIS departments grows ever and ever wider. I blame ESRI for some of this: with most, if not all, of their newest desktop products requiring more and more local machine administrative access rights yet IT departments locking down more and more tasks that most GIS practitioners take for granted. Yes, as the representative for GIS, it's my job to educate IT (and leadership) on what the GIS program requirements are if the organization wants to achieve its mission. But I suspect you're coming from a large organization where institutional mentality and compartmentalization of work divisions results in a situation like our current Congress. It's real tough to convince leadership that users need to be able to use Python when they're handing out awards for protecting the network from the "Python Virus".

AndreasLundström · ‎01-09-2015

Unfortunately GIS is only one part of the output for the organization. Other parts are handling data classified by national law, meaning that security takes precedence over convenience. All of this is resulting in much more work for us trying to balance security with functionality. And I agree with you on the increasing access rights of ESRI products. It will soon reach a level where we might have to find other products due to the potential security concerns with local machine administrative rights. Luckily we don't have to fight the "Python Virus" misconception, it's a more general requirement that users don't have access to compilers and interpreters so that they could add programs and functionality to the system. Or in the case of python, use zero day exploit scripts commonly available as python scripts online.

We have one solution in place where we are limiting the client computers and users with access to ArcGis, but that solution does not scale very well and its a timely process to manage new and changed users and computers. Therefor I'm looking for some ideas on how to harden ArcGis and Python.