A chat-driven DevOps environment enabled by ChatOps can help development teams collaborate more efficiently across your organization, and give you greater visibility and auditability of deployment activity.
The challenge for organizations, though, is to enable ChatOps in a secure fashion so as to protect restricted enterprise systems and data from being improperly accessed or exposed to security threats.
Here are the key security concerns when it comes to scaling ChatOps in the enterprise.
Cutting through layers adds to risk
With ChatOps, you are basically punching a hole through all of your data layers and allowing your DevOps and sprint teams to get at data that would have otherwise been restricted. Without proper controls, there’s a big risk that you could expose sensitive data, including personally identifiable, credit card, and other confidential information to people who are not authorized to see it, says Asaf Yigal, co-founder and vice president of product at log management firm Logz .io. “You are basically creating a script that can access whatever data that the person who wrote the script can access,” he says.
Excessive exposure
Minus the right controls, ChatOps can also allow members of a team to either inadvertently or maliciously shut down a service or an entire system from a desktop or mobile device, with few of the checks and balances that would otherwise be required.
For example, a developer could potentially access a cloud API via the chat client on a mobile device to restart or restore a service that might be having problems, without any of the typical authentication needed for the task. Without proper controls, anyone can go into a service using a chat command and bypass whatever security mechanisms might exist, Yigal notes.
Ensuring that individuals taking action in a ChatOps environment are, in fact, permitted to take those actions should be a high priority, says Jason Hand, DevOps evangelist with VictorOps and author of ChatOps for Dummies.
The chatbot challenge
Chatbots are designed to interact with multiple tools and services. Often, these services are tied together in long scripts, Hand says. “For example, users can ask a bot to ‘push to prod,’” he says.
This triggers a script that may begin with the code being committed to a version-control repository, QA tests being automatically run and eventually the original code being deployed to production.
Typically, multiple individuals and teams might be involved in managing the code through this process. “But with a ChatOps approach and leveraging a chatbot, anyone with authorization can ‘deploy to prod,’” Hand says.
Despite the risks this poses, for many organizations, the automatic system of record that is created by a group chat is often all the accountability they require in a ChatOps environment, he says.
Bots need credentials like the rest of us
To be secure, organizations using ChatOps should tie their LDAP or other access control list (ACL) to the bot. This ensures that each command that users attempt via chat is vetted against their user credentials to ensure they are authorized to issue the command, Hand says.
A chat log merely provides a timeline of what happened, how, and by whom. It cannot prevent mistakes from happening the same way that tying an ACL to a chatbot would. “Allowing users to have access to chatbots means they can trigger actions that, under normal circumstances, they may not be able to execute,” Hand says.
Enforcing two-factor authentication, especially for critical commands, such as one that might cause a system to restart or one that queries for sensitive logs, is another way to bolster ChatOps security, says Jen Andre, co-founder and CEO of Komand, a security automation and orchestration platform company.
“Make sure you are using a chat platform that supports two-factor authentication when you log in,” Andre says. “A lot of security teams are using it because it adds another confirmation method” for a user’s identity and level of access. It really is a very smart way to mitigate the risks of a user’s credentials being misused in a chat environment to execute dangerous commands, she says.
Equally important is the need to control access to specific chat rooms and to ensure that certain commands can only be issued in specific rooms as well, Andre said. For example, if you are using Spinnaker for releasing software changes, it is a good idea to ensure that Spinnaker commands can only be issued from specific chat rooms. It is also important to ensure that only people authorized to make the changes are allowed into the chat room, she says.
Platforms and methods
The security implications of ChatOps depend to an extent on the platform you choose and the methods you employ to ensure proper separation of duties and role-based access control, says Dmitri Zimine, senior director of automation of integration at Brocade.
Authentication complexity, for instance, varies by chat provider, he says. “If you got ActiveDirectory, HipChat integrates with it easily. But for Slack, some custom user mapping may be needed,” he says as one example.
Similarly, the effectiveness of your access controls depends on how you architect ChatOps in the enterprise, Zimine says. The foundation for ChatOps at StackStorm, for instance, is an “action library” with role-based access control around it.
Only a subset of the automated deployment actions in the library is exposed to chat. From the chat, users only see what is exposed to chat. Role-based access controls dictate the actions to which specific users have access.
“Because chat is the least common denominator between the widest set of teams, only a small set of widely used actions usually is exposed” via chat, Zimine says. DevOps and SRE teams expose to developers the actions needed to easily deploy and operate apps.
In turn, super users have access to create actions and decide what to expose to SRE and developers, Zimine says. “Admins and SREs have direct access to the action library.
“Developers have access to a small, most relevant subset of actions via ChatOps,” he says.
Chat servers need security
Chat server security can be another stumbling block for organizations. Popular chat clients like Slack, HipChat, and Flowdock don't afford the kind of direct control that many organizations want over their chat environment.
“For those of us using Slack, we only have the promise that Slack makes to us about the security of our data both in transit and at rest,” Hand says. But for many organizations ,that might not be enough, he concedes. “Encryption is in place, but for many companies, not hosting their own chat server and data is a compromise to collaboration and automation that they aren't willing to make.”
But there are some options they can consider. For instance, HipChat has a locally hosted option that might work for an organization that absolutely wants an on-premises chat capability, he says.
Boiling down to security basics
Ultimately, ChatOps security boils down to restriction and monitoring, Yigal says. Because ChatOps enables access to data and functions that would not normally be available to a developer, it is crucial to restrict access tightly based on roles and operations and to monitor everything that is going on in the chat environment.
“You really, really need to tie it down. Restriction is key.”
Image credit: Flickr
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
