Today we have a guest editorial as Steve is out of the office. Join the discussion here.
Think about what you have in place right now for security and auditing and all the things that go with it, from the load balancer all the way down to permissions on stored procedures. You’ve probably done the easy stuff and some of the hard stuff, and as far as you know, it’s working - your customer data hasn’t been posted for all the world to see.
Now imagine you get an email from your security team stating that they have reason to be believe your company is being targeted and that all precautions should be taken. What do you do next?
To invoke Speed, what do you do?
Part of me says that if there were gaps to be filled it should have been done by now; it’s a little late to require SSL for all traffic or encrypt every laptop (please tell me both are already done!). But practically speaking you can’t just ignore the warning, so what do you do? It’s worth building that list now, before you need it, both of things to do just in case and things that need to be done but haven’t been done yet to time or money constraints (maybe now those will get approved).
As a DBA you might:
- Review the list of everyone that is a sysadmin or local admin and remove anyone you can.
- Change the SA password and require password changes for all Windows accounts that have SQL access.
- Change all the SQL Service account passwords.
- Review the logs and make sure whatever auditing you use is working (it captured the password change events for example) and that the logs are being shipped off to a read only repository.
- Run a full vulnerability scan and fix all the high severity issues, look for recently added ones that might indicate a breach has already happened.
- Run a virus scan (excluding the MDF/NDF/LDF of course).
- Test that the monitoring and alerting works by causing multiple failed logins from a temporary account (and then remove it).
- Review your list of actions to take if errors or other traffic overwhelm your ability to sync to a DR site or exhaust the connection pool.
Then you wait and watch, hoping that you’ve done enough to both stop the attack and to let you see that it was stopped.
This is different than responding to an attack. When you can see the attack you can take immediate steps to fight the problem - blocking an IP range for example. It’s harder when the threat hasn’t materialized yet and you’re trying to be ready for anything.
Have you practiced for an attack? What would you add or remove from the list above?
