Just about a year ago a case management software vendor announced they would begin using Octopus Deploy to stream upgrades to client systems. While this is an excellent solution for orchestrating environments, and it can elevate the customer experience, the convenience gained from this approach pales when compared to the security risks it presents. This is a plea to any law firm being asked to install Octopus Deploy tentacles on your on-premise servers: reject the use of Octopus Deploy until you fully understand the risks associated with this choice.
The reasoning for my position is presented below, but if there is one take-away in all of this, it is that all risks associated with usage of Octopus Deploy are transferred to the customer via the consent form. In it, you will find the following terms:
The Software includes a third-party deployment tool through which the Company can automatically deploy Software updates. While the Company endeavors to select high-quality third-party tools, the Company cannot and does not warrant the quality of such third-party tools and disclaims any and all liability related to the installation and use of such tool. By clicking this box you acknowledge your continued obligations under the License Agreement and Terms and Conditions, including the above modification.*
Automated and streamed upgrades are common today and expected in most cases. While it may seem like a good idea to have easier and simpler automated upgrades, Octopus Deploy is the wrong tool for the job. When the upgrade system is architected into the software solution, it benefits from a closed system that is purpose driven and limited. Even when third-party tools are used in the pipeline, a DevOps architected design carries the spirit of the deployment from the developer to the end-user. Taking any piece of that pipe-line and attaching it to an existing system ad-hock is akin to nailing another piece of wood to a stump and calling it art.
What is Octopus Deploy?
As far as your law firm is concerned, Octopus Deploy is the means to upgrade case management software without having to pay additional fees. It enables the software developer and vendor to push upgrades to the software through an automation system. That system consists of a core set of server instances connected to agents, also known as tentacles, that can control your environment.
Octopus Deploy is designed to orchestrate installations, reduce downtime, and eliminate human errors but it thrives on one key factor: root access to your critical systems. Although it is intended to be used by the upgrade process, Octopus Deploy can be instructed to execute other operations. It is a tool with unfeathered power, remotely controlled by another organization, that exposes a pandora’s box of risks including third-party compromise, credential compromise, malicious code injection, packet poisoning, etc.
This use case fits with the Octopus Deploy intended capabilities. To be certain, I reached out to Bob Walker, VP of Customer Success at Octopus Deploy, and asked him questions that contradicted my own perceptions of what their tool was designed to do. My initial concern was whether the intended use covered a case where the tentacles were installed on non-owned (3rd party) customer servers.
We want our software to help everyone deploy their applications better. We are not concerned with if the agent is installed on company-owned or non-owned computers. We have lots of customers who install those agents on their client’s computers. For example, Guestline recently posted an article on how they use Octopus Deploy to deploy to 1000s of hotels around the US. They don’t own those computers they are deploying to.
While that showed this was part of a normal use case, Bob Walker went a step further and referenced another vendor, Guestline, that was practicing this scenario. I reached out to Guestline to learn more about their deployment and discovered that the nature of their environment the systems were, in fact, owned by them. Matthew Ford, from Guestline, shared this with us:
…we’re deploying to tills, servers and usually a dedicated back office PC. These are usually hardware supplied by us, but sometimes it’s pre-existing. Either way these machines are dedicated to the EPOS problem and so there is no encroachment by any other process or purpose.
I continued to search for cases closer to the one here, and to this point found none. After a number of exchanges on multiple DevOps communities the consensus was that this use-case presented too many risks. None of the persons we consulted with backed this scenario.
How does this use case present a security risk?
On face-value this use case is not a security risk, it all depends on the implementation. Going back to my exchange with Bob Walker, they were fairly blunt about security concerns with Octopus Deploy:
The flexibility of Octopus Deploy is a bit of a double-edged sword. Some of the configurations we support can be used to make the overall CI/CD pipeline more secure. However, that same configuration can be used to make it less secure. For example, you can configure the agent to run as a restricted AD service account. However, it is possible to have the agent run as a domain controller admin user account. We can’t stop anyone from doing that.
As with all software, the the power is transferred to those who administer or use it, and Octopus Deploy is no exception. There are no controls available to ensure that the deployment is done in a manner that is safe, but you don’t have to take myword for it, Mr. Walker said it for us:
At that point it the user’s responsibility to have the appropriate procedures, policies, and auditing in place to not allow that to happen (or if it does, alert to the bad configuration). We offer recommendations and suggestions and do our best to stop people from making poor decisions, but being COTS software, bad configurations are possible.
Putting it all together.
Octopus Deploy is a clever solution for managing complex deployments. In software development, clever fixes to large problems are rarely sustainable. The best example of this is the time inventor of the Python programming language, Guido van Rossum, spent at DropBox. Van Rossum called clever fixes “cowboy coding culture” and is credited with changing the organizational attitudes that supported it. The root problem here is the lack of an integrated update engine within the software while the solution is complicated and costly —it is my fundamental belief that a solution that is clever is not a sufficient answer to a complex problem.
As a consequence, business process owners bear the final responsibility for the information technology as deployed within the confines of their business process. — Control Objectives for Information and Related Technologies (COBIT) Framework 5, ISACA.
