The increasing sophistication of threats and the on-going evolution of database technology has made database security one of the most elusive tasks to do well.
Traditional database security implementations (called Database Security 1.0) are overrun with high costs, delays and recurring questions as to the value of these investments. This has spawned a new generation of database security projects – often called “Database Security 2.0” or “Database Security Re-boot”.
The key difference is that rather than focus on “plumbing”, Database Security 2.0 focuses on use cases and answers and minimizes the causes that generate “implementation fatigue” and lack of value. Database Security 2.0 means:
- Having a unified security solution for on-prem enterprise and cloud databases - rather than multiple disparate projects.
- Delivering a comprehensive database security solution as a SaaS offering that focuses on allowing the security team to stop being administrators of the solution and instead becoming users of the solution.
- Using machine learning and AI instead of rule-based alerts and manual processes to immediately produce value and to avoid the need to have a team of people define policies, manage white lists etc.
The simplest way to understand how DBSec 2.0 differs from the older DBSec 1.0 implementations is to follow a scenario/use case (one of many that make up a database security program). In this scenario you are being asked to:
- Monitor access and activities to your database environment that include on-prem enterprise databases as well as Azure SQL and AWS RDS MySQL servers.
- From a security perspective you need to identify and stop misuse of privileged access. For example, you need to ensure that a disgruntled DBA that is about to leave the company does not steal data or do harm to the systems.
- From a compliance perspective you need to keep an audit trail of activities for 13 months or for three3 years if you are also doing business in the State of NY.
Now let’s look at a few key examples that contrast DBSec 1.0 with DBSec 2.0:
Database Activity Monitoring
DBSec 1.0: You used a Database Activity Monitoring product to cover your on-prem databases, deploy agents and appliances and implement using a tool such as IBM Guardium or Imperva SecureSphere. Then, you learned out how to use the APIs and facilities in AWS and, separately, how to use the APIs and facilities in Azure. You ended up with three implementations each using separate methods and tooling, each in a different place.
DBSec 2.0: You subscribe to a service, plug in feeds from your on-prem systems, attach your accounts on AWS and Azure and manage everything (as a user) from one place, using a single set of policies and definitions. The DBSec 2.0 service “translates” this to what needs to happen in each specific environment, adjusts the policies on your enterprise system and retains the feeds from on-prem systems while also connecting with AWS CloudWatch and Azure Event Hubs.
Database Policies and Alerts
DBSec 1.0: You define policies and alerts that tell you when “bad behavior” happens. But Wwhat is bad behavior? It turns out that, almost without exception, all DBsec 1.0 implementations fail badly in this area and produce so many meaningless alerts that the SIEMs are flooded and everything is ignored.
DBsec 2.0: You utilize built-in UEBA methods (using machine-learning models and AI) designed to identifying events such as excessive data extrusion, account takeover, service account abuse and more. This is the most fundamental difference between DBSec 1.0 and 2.0 – In 1.0 it’s up to you to “ask the right questions”; in 2.0 you just get the right answers.
Database Infrastructure and Implementation
DBSec 1.0: You need to provision servers and storage and ensure that you can maintain data based on your retention needs. If you archive data you need to make sure you can restore it fast enough and check its integrity.
DBSec 2.0: You get a service that gives you an SLA for retention. The service usually uses Ccloud storage services to keep the cost very low – but that’s all transparent to you – you just tell the service how long to keep each class of data from and the rest is done for you. All data is live and available for reporting as well as for analytics.
The difference in effort, overhead, cost and relieved headaches is staggering. The scenario above is only one of at least ten separate work streams that comprise every database security program – so take the simplification of even this simple scenario, multiply it by 10 or 20 in terms of increased value and reduced effort and it is clear why in the past two years many of the world’s most advanced and security-minded financial services and healthcare organizations have adopted Database Security 2.0.