Osterman Research recently released a survey-based report on database security. The results don’t exactly instill confidence where username breaches are concerned: While more than 50 percent of respondents felt that a breach of the database would be a serious problem for their organization, 44 percent responded that it would take more than a day to detect compromised credentials and a breach of data. Considering that attackers are going to get in and get out as fast as possible, more than 24 hours is plenty of time for those compromised credentials to result in copies of tables making their way to the dark web. Some of our biggest hacks—Yahoo! springs to mind—take much, much longer to be detected.
There are tools available to monitor database logins and activity, from free (and sometimes onerous) logging for databases including MariaDB, MongoDB and MySQL to review and analysis through things such as Splunk plugins for most database systems. Once you are tracking logins and source IPs and possibly watching for spikes in query volumes, the power of DevOps can help you manage monitoring.
The key here is to collect the data, even if temporarily. A great first step is building a process that turns on login-attempt logging for a set period of time, then processes the resulting file to send the user a list of when they logged in and from where.
Next, capture summary information about number of queries and response sizes. That can show abuse of credentials, by either internal or external bad actors. The issue is not the availability of tools to do these jobs; the issue is making it a priority.
While not exposing your database to the internet is a good policy, monitoring database credentials provides in-depth defense against external attackers and a defense against internal attackers. Utilizing the tools available plus some work from DevOps (to automate the process, then to work out a way to add new application and user logins to the monitoring system) will improve your ability to detect credential issues, and the process—as so often happens when DevOps is involved—will force you to review which applications are hitting the database from where, possibly opening eyes to ideas for improvement in database usage and location.
These are the areas of security where DevOps really can help; it is rare for any one team to control security for logins/queries on the database. Is it the DBA’s responsibility? The security team? Operations (which generally creates the accounts)? Utilizing the tools available, and sitting down to discuss which makes the most sense for your organization, you can generate a simple report to be reviewed on a regular basis and settle the responsibility question. That means there is no huge loss of time pawing through logs and no waiting weeks to find out your database has been exfiltrated. It just makes sense, and it bridges the gap where security gets direct benefit out of DevOps, instead of the indirect benefit offered by standardized processes.