I once spoke at a security roadshow on big data security. One security administrator in the audience was very clear that he understood nothing about databases. He was worried that his knowledge gap was too wide. This is not uncommon for us; when we talk to clients about big data security, they don’t always get it. The history of security is rooted in the network, and organizations don’t necessarily have database experts on their teams or in management roles.
Considering how much data is in databases — which may be accessible to anyone who gets the right passwords through a phishing attack or by accessing the database through a SQL injection attack — it really is critical that there is an understanding of the importance of database security and auditing throughout the organization.
Sure, you may need to learn a few new terms and understand some new roles, but the basic principles for the planning and deployment of a database security and auditing solution aren’t rocket science. I’m sure these considerations are familiar to everyone who works in security.
Because risk is strategically a factor in everything an organization does, you cannot look at single risk factors and build a plan. An evaluation of risk must bring the business and technical teams together to figure out the data assets most at risk based on their value to the enterprise and the subsequent damage to the business should there be a compliance violation and fine or, even worse, a data breach that goes public.
If you’re not sure where risky data lies (and who really is?), use automated discovery and classification tools to pinpoint databases and files that contain high-risk data such as personally identifiable information (PII) and financial data.
Data protection program providers are available if you need help brokering the discussion. Often, there can be a real disconnect in communication and vocabulary between people who understand data and its unique security requirements, those who are traditional security professionals who understand networks and firewalls and business owners.
Define the Objectives and Staging
Define the objectives and staging for your data security plan. Don’t boil the ocean in phase one; think agile and show interim successes. For example:
- Run database-specific vulnerability scanning to find and fix low-hanging fruit such as bad database configuration parameters, poor password policies or default passwords. This is a low-impact operation that creates actionable work items for the DBA teams that can reduce risk. You can also show management measurable results in the form of improved scores. In the meantime, be planning and implementing database activity monitoring (DAM).
- Deploy basic DAM and reporting of the most critical objects and/or those that require reporting for an imminent compliance deadline. This step will get you familiar with implementing DAM and reporting while helping you fine-tune security policies.
- At this point, you may find not only risky activity, but also issues that the application and database teams would like to know about, such as a high volume of SQL errors that are thrown because of a missing package or long execution times because of an accidentally dropped index. Look for such ways to show the value of DAM to your DBA and application teams. This paves the way for more cooperation moving forward.
- Add privileged user monitoring and reporting required for compliance and to help protect against insider threats.
- Implement real-time and threshold-based alerting for communication with the security operations center. It’s very easy to integrate real-time alerts with your SIEM system.
An aside here that bears stating explicitly even though it’s project management 101: Make sure your plan allows for hiccups. Even a project with small scope and lower complexity can be delayed for a variety of reasons such as database or OS upgrades, ports that need opening, change ticket approvals that take forever, vacations and more.
After Success, Expand the Scope
After the initial success with your project, expand the footprint by adding more data sources including file data, big data or tier-2 databases. Make sure you re-evaluate your reporting and alerting requirements. As you expand the DAM footprint, learn how to use the automation capabilities to make the workload easier via intelligent scheduling, automating the population of groups and workflow automation.
Consider having some team members investigate and implement deeper analytics to help your security analysts focus on the riskiest activity.