Securitybot is an open-source implementation of a distributed alerting chat bot, as described in Ryan Huber's blog post. Distributed alerting improves the monitoring efficiency of your security team and can help you catch security incidents faster and more efficiently. We've tried to remove all Dropbox-isms from this code so that setting up your own instance should be fairly painless. It should be relatively easy to install the listed requirements in a virtualenv/Docker container and simply have the bot do its thing. We also provide a simple front end to dive through the database, receive API calls, and create custom alerts for the bot to reach out to people as desired.
This guide runs through setting up a Securitybot instance as quickly as possible with no frills.
We'll be connecting it to Slack, SQL, and Duo.
Once we're done, we'll have a file that looks something like
You'll need a database called
securitybot on some MySQL server somewhere.
We've provided a function called
init_sql located in
securitybot/sql.py that will initialize SQL.
Currently it's set up to use the host
localhost with user
root and no password.
You'll need to change this because of course that's not how your database is set up.
You'll need a token to be able to integrate with Slack.
The best thing to do would be to create a bot user and use that token for Securitybot.
You'll also want to set up a channel to which the bot will report when users specify that they haven't performed an action.
Find the unique ID for that channel (it'll look similar to
C123456) and be sure to invite the bot user into that channel, otherwise it won't be able to send messages.
For Duo, you'll want to create an Auth API instances, name it something clever, and keep track of the integration key, secret key, and auth API endpoint URI.
Take a look at the provided
main.py in the root directory for an example on how to use all of these.
Replace all of the global variables with whatever you found above.
If the following were all generated successfully, Securitybot should be up and running.
To test it, message the bot user it's assigned to and say
To test the process of dealing with an alert, message
test to test the bot.
Securitybot was designed to be as modular as possible. This means that it's possible to easily swap out chat systems, 2FA providers, and alerting data sources. The only system that is tightly integrated with the bot is SQL, but adding support for other databases shouldn't be difficult. Having a database allows alerts to be persistent and means that the bot doesn't lose (too much) state if there's some transient failure.
The bot itself performs a small set of functions:
Messaging, 2FA, and alert management are provided by configurable modules, and added to the bot upon initialization.
The bot handles incoming messages as commands.
Command parsing and handling is done in the
Securitybot class and the commands themselves are provided in two places.
The functions for the commands are defined in
commands.py and their structure is defined in
commands.yaml under the
Securitybot is designed to be compatible with a wide variety of messaging systems.
We currently provide bindings for Slack, but feel free to contribute any other plugins, like for Gitter or Zulip, upstream.
Messaging is made possible by
securitybot/chat/chat.py which provides a small number of functions for querying users in a messaging group, messaging those users, and sending messages to a specific channel/room.
To add bindings for a new messaging system, subclass
2FA support is provided by
auth/auth.py, which wraps async 2FA in a few functions that enable checking for 2FA capability, starting a 2FA session, and polling the state of the 2FA session.
We provide support for Duo Push via the Duo Auth API, but adding support for a different product or some in-house 2FA solution is as easy as creating a subclass of
Task management is provided by
tasker/tasker.py and the
Since alerts are logged in an SQL database, the provided Tasker is
This provides support for grabbing new tasks and updating them via individual
Blacklists are handled by the SQL database, provided in
blacklist/blacklist.py and the subclass
User object provides support for handling user state.
We keep track of whatever information a messaging system gives to us, but really only ever use a user's unique ID and username in order to contact them.
Alerts are uniquely identified by a SHA-256 hash which comes from some hash of the event that generated them. We assume that a SHA-256 hash is sufficiently random for there to be no collisions. If you encounter a SHA-256 collision, please contact someone at your nearest University and enjoy the fame and fortune it brings upon you.
Please ask us things
Contributors must abide by the Dropbox Contributor License Agreement.
Copyright 2016 Dropbox, Inc.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.