The End of the All-Powerful DBA

The Ashley Madison security breach has again turned IT security (and the lack thereof) into front page news. Nobody in IT should be surprised that hacker attacks like this one is possible – after all, the Ashley Madison CTO managed to easily hack into a competitor’s website.

The problem all unsecure sites share is the all-powerful DBA, and that role needs to be reconsidered. You can take two different approaches:

  • Enforcement
  • Trust but verify

Both of these approaches need to involve an IT security officer whose job is security and only that. The security officer should be a person not involved in database or system administration and should not share an office with the DBAs. The security officer belongs in your compliance organization and is more akin to an auditor.

If your data is truly sensitive, you should decide to enforce security (and accept a cost in lost productivity). With this approach, you place hard restrictions on what users can do. This includes securing that the DBA can’t read sensitive data and can’t grant access. Only the security officer can grant access and you ensure that nobody has both DBA and security officer roles.

If you focus more on productivity than absolute security, you can decide to trust but verify. You don’t place hard restrictions on your data, but monitor who accesses data. In this approach, the DBA can still read data, but not change the logging level or delete logs, and the security officer read these logs.

The problem is that most organizations follow a trust paradigm without the verify, and that is the way to Edward Snowden, the U.S.Office of Personnel Management and Ashley Madison. If you want to be secure, the all-powerful DBA has to go.