IT staff are often working in reaction to high-priority events using tools and methods not necessarily aligned with security priorities. This article describes some typical challenges and resulting risks, then proposes a solution that combines the best of many worlds.
You can't work in IT without open source tools. Whether you like them, love them, or hate them, one thing is for sure - if you take them away, you destroy progress. Open source tools have transformed IT efficiency many times over, on many fronts.
But tools built for a specific purpose often get misused. Because they are so good at certain things, they are put into play despite, "a few minor details". Unfortunately, time has a way of making big issues of minor details.
In this article, we will provide a couple examples of tools that have become de facto standards however provide a great deal of risk because of how they get used. We will then offer a solution that enable teams to continue using these but retain the security required, even in the most aggressively secured networks.
How do you manage an IT Data Center with 500 servers all using different authentication schemes for user login? You have one set of servers using RADIUS, another on a new Active Directory Windows network, and then collections of servers semi-run by product teams and IT in tandem, all using their own login methods. For IT teams that use a rotating assignment plan for resource sharing, collecting similar passwords into a Password Manager and sharing that with authorized IT staff can be an efficient way of working with these realities.
But in truth, what starts as a way of managing a handful of people quickly explodes out of control. The idea of changing credentials for 500 servers is not one anyone wants to face, but this becomes the requirement that falls out of mismanaging content and distribution of these credential files. In almost every situation, the files are shared with someone that shouldn't have them and credentials are added that aren't aligned with the ones that exist. There isn't any separation of policy, and eventually you have a master file with all systems shared by a small group of people. It's only a matter of time before a midnight emergency, responded to by resources partially managed by a product team and partially managed by rotating IT staff, decides that the situation justifies deviation from sound policy. In probably 2/3 of all cases, this leads to the sharing of credentials with third parties.
Secure Shell Keys
The use of SSH isn't much different. Key files are stored in both Linux and Windows files for a handful of servers that serve as hops to sensitive IT gear. In fact, keys are often shared inside Password Managers. As is the case with Password Managers, SSH keys end up being given to people who shouldn't have them - because, of course, just this one time we didn't have a viable choice. SSH keys also tend to end up in the hands of those outside the company, more often than not as a result of someone leaving for another position elsewhere. Without strong controls for distributing keys, and without systems that enforce well-defined policies, it's almost impossible to even know who has them, much less decide when to go "get them back" or generate new keys. 500 servers? You're going to need more than a couple dozen SSH keys to manage all the different dynamics. Tracking credential access is quickly out of the question.
Cloud Storage Browsing
When Azure launched cloud storage, a number of developers set out to create a browser that would let users enumerate and manage cloud storage items much like you do with Windows Explorer. One such application, Azure Storage Explorer 6, entertained some 180,000+ downloads.
The software allowed you to create connections to existing storage resources then browse content, add/remove files, and change security permissions. If you shutdown Store Explorer, it saved your credentials so you could come back without re-entering long key strings each time.
The problem with this application is in how those keys get stored. Within 10m we were able to find the file used to store the credentials, immediately recognize the key was being encrypted in the file, and work back through the Open Source code to find the hardcoded decryption key. Of the 180,000+ users that downloaded the software, we truly wonder how many have given up significantly sensitive cloud-based data as a result: It's trivial to exploit this setup.
This particular software item is no longer being actively maintained, and Microsoft has replaced it with a more credible solution. It was however actively used for quite some time, and it serves as an excellent example of how problems arise. When you start understanding how often this occurs, you stop wondering why we see so many high-profile data breaches and start asking how many more take place each day we never heard about.
How would you react if, on the first day of your new job, you came to discover that this was in fact the very state of affairs you inherited? How, then, would you address the problem? First, you have absolutely no choice but to change every single credential ever managed by any of these resources. It will take time, and you can put together a priority scheme based on risk and accessibility. But once you do that, what is it about procedural operations you change?
What if I told you that you didn't have to change anything? Human nature says people revert back to known and comfortable behaviors, so rather than try and enforce change, why not use tools that allow teams to continue in this fashion yet retain significant data protection in the process? SSProtect can provide this for you. Deploying it will:
- ...protect against existing threats and compromised hosts; SSProtect only permits the authorized user's application to access plaintext
- ...inhibit access except to the default application assigned to the resource, i.e. only putty can read SSH .ppk files, others cannot
- ...control end-user access by adding/removing user permissions, which go into effect almost instantly
- ...retain the ability to see who accesses data, from where, for how long, using what software (Audit logs are generated/ stored elsewhere)
- ...restore protected backups of every protected asset, at the touch of a button
SSProtect wasn't designed for any one of these specific applications, it was designed for the collective whole of all. This means use of these sensitive materials only requires that you a) deploy the software, which can be done in minutes for a single user or 10s of minute for many, and b) that you enable two-factor authentication and use USB tokens for access. Though not required, we highly recommend it due to the exceptional value it provides.
Once the software is deployed, most everything else remains the same - share SSH keyfiles using Box or Dropbox, Egnyte or OneDrive...use a network file server - or email, or a thumb drive...to share password manager files. Rename files. move them around, even delete them (see below). These things don't have any impact, and shared access with Organization peers is automatic (zero-config :Collaborate). Third parties can be given authorized access with a few clicks.
By applying SSProtect, you are able to easily and non-intrusively apply strong protections to existing assets while allowing your team to work in a way that would never have been possible before. Not only do you gain protective measures, you benefit from host-specific details otherwise unavailable. By adding :Recover, you get completely seamless backup and restore - with very little impact. Restore any version of any protected file at any time. Lose SSH keys to Ransomware? Not with :Recover you won't.
Seeing is Believing
For a short demonstration of these concepts, see the Insights article, Protecting In-Use SSH Keys With In-Place Encryption. Because we recognize these claims may be difficult to embrace, we invite you to email firstname.lastname@example.org and setup a time for a hands on demonstration - only we won't be driving, you will. Download the latest version of the software and try for yourself, or let us walk you through it. Either way, you'll be well on your way to discovering how simple it is to gain protective capabilities without changing other things. Surely that's worth 15m of your time, isn't it?
This article was published June 10th, 2016