In part one of this series, you learned about the challenges associated with accessing, and searching long-term retained database activity logs and identifying sensitive customer data to comply with stricter compliance regulations. In part two, you gained insight into how security professionals can mitigate database security risks when executive leadership orders the organization to migrate workloads into the cloud. In this final installment, you’ll get some tips on how to help your non-executive colleagues and teams develop a data-centric security mindset.
Take the time to explain data-centric security to your analytics teams in a way they can understand
The key to taking your analytics teams from a compliance to a data-centric mindset is ensuring that the data to which they have access makes sense and is actionable for them. One of the greatest challenges to empowering analytics teams is flooding them with false positives and unusable raw data. The default response from teams in those instances is to stop getting the data, which ensures that nothing gets done. One security architect commented, “For a while, our newly-formed analytics team was not understanding the data they were getting from our monitoring tools. They could not ascertain what data was sensitive and required attention. To solve this issue, we built a new workflow in which the sensitive data had already been classified in our database systems. We built the workflow to take notice when a specific individual user read data that they shouldn’t have seen based on their permissions settings and to trigger an alert if the user touched a sensitive object. When the workflow triggered an alert, the analytics teams responded with, ‘we’re not touching sensitive data’. In fact, they were touching sensitive data. The problem was they were not writing the queries well enough. Unintentionally, they accessed sensitive data, because they didn’t understand the workflow well enough. With coaching and experience they are mastering the process, and their queries are improving. When I first turned on the workflow for monitoring and to enable acting upon sensitive data access, it was triggering 50-60 alerts a day. A few months later, the workflow is triggering 5-6 alerts per week because the analysts triggering alerts are iteratively self-correcting their queries.
“At the same time, I explained that to deliver database security we need to know who has access to data, how it’s flowing into the organization, and where the reports are going. We need to know the different places data resides, particularly unstructured data which presents significant challenges to analytics teams. When I tell them something is a risk, I try to give them a business-centric illustration. I show them an example database and ask, ‘How many thousands of Social Security numbers (SSNs) are contained here? The average cost of a breach of one SSN is $X, multiply this by the number of SSNs in the database. This is a ballpark estimate of the cost you’ll incur if the database is breached.’ Next, I explain ‘these are the number of probes I see being made into our company that are being caught’. They think, ‘great, we have the firewall up, it’s doing its job.’ But what about an inside threat that the firewall cannot stop? We are slowly teaching them, and I recommend that all companies try to do this regularly to build awareness. We support moving forward with speed if the speed is secure because this is how you achieve real database security.
“With the easy access to long-term data I have, in a few minutes I can determine who is accessing data and when and tell you who did what for a three-year period. If a DBA approaches me and says, ‘one of my tables was dropped? Who did it?’ I can look for the table name and the commands and easily find the name of the individual, the IP, the name of the server they used, and the exact time and day they did it. That’s the benchmark. That shows people are watching. It’s not to create a ‘gotcha!’ moment. Rather, it fosters a sense of confidence among the DBAs and developers that you are watching out for them.
“We use a connection profiling tool that runs over our database activity monitoring (DAM) tool to help us decide which traffic to ignore. For example, if an IP is coming from an application and the database user account, the service it’s using, and the port are all correct – there are about seven parameters in all – I can instruct the DAM tool to ignore the data. By doing this connection profiling, I am eliminating the amount of data that we need to work through to see what people are doing when they interact with the database and this makes my system run smoother.
“We also use this connection profiling tool to help manage changes. For example, a server may change. If unexpected activity pops up, I will always capture it, but I also use the opportunity to see if a connection still needs to be kept. It’s good to set timeframes so you can periodically review activities and adjust as required. Internal auditors love it, they can see that I am taking all the right steps and documenting exactly why I am saying that certain connections be authorized. Auditors can also come in and double check the activity of any user account they want by running a command on the fly. We are taking a calculated approach to security. Some may find it deliberate or slow, but we must stop DBAs from having to manage a bunch of stuff they need to validate constantly. If we don’t, they may simply start ignoring it. We beat up and test these things, we do the validations to make sure our code is right and then I go to the DBAs and say, ‘this is what we are finding.’ And this is the way we fix things. Eventually, I will not have to do the code checking to make sure everything is right. Most of the security and the double-checking that proper steps are being taken is being automated. You only have so many people to develop and find problems, so you need to automate.
The security architect concludes, “When database technology took off and started to change the threat landscape so quickly, life came at security architects and my colleagues really fast and QA suffered. Important little things like maintaining a data dictionary were not happening anymore. Most people still know what data dictionaries are, but nobody puts them together anymore. If you are starting a data-centric security effort in your organization, start with the basics. Learn what systems you have and what’s contained in them. Work with your leadership team to make your security team a partner within your organization. Show everyone how you can improve security practices and help them rather than just being the group that gets the compliance box checked, or worse – the group that blocks innovation. You have far better results when you work together as peers than as rivals or even adversaries. I have worked in companies where the DBAs hated the security team. DBAs need to know that database security is their job, too. DBAs put all the company data in their system. Security teams set up the rules and build the different pieces. The security analyst’s job is to make sure the information is there when it’s needed and to make sure that data theft can be tracked and assigned properly. When there’s data theft, organizations first look at the people with the most access – the DBAs. Building tools together to get clear, concise insight into database activity should not be characterized as Big Brother spying and waiting for DBAs to mess up, but to protect them. When business units pressure DBAs to cut corners, it’s the security analyst’s job to push back, not the DBA’s. This productive relationship keeps communication flowing and enables DBAs and security teams to get in front of things using the data-centric approach.”
Do you want to talk through a data-centric security strategy?
Imperva has helped more than 6,500 companies ensure that enterprises large and small can protect their data and all paths to it. We can help you, too. Contact Imperva to find out more.
Try Imperva for Free
Protect your business for 30 days on Imperva.
