So what’s the root of the problem? Despite the increase in security vendors and investment in new perimeter security defenses, companies are still failing to develop effective IT security solutions that mitigate the increase of database breaches. The fact is that the database holds some of the most valuable data being targeted and is ultimately the final destination of any attack. At the most basic level, it really doesn’t matter where your database is hosted or what type you are using; if you want to safeguard your company’s most sensitive data, you need to shift your mindset and adjust your strategy to incorporate database security.
Know your challenges, map the risks
Your data is the most critical part of the business foundation for all of your applications, be they financial, human resources, customer service interfaces, or public-facing web sites.
Although perimeter security defenses have proven ineffective time and time again, they remain the primary breach defense employed by most organizations. There are many reasons why perimeter security is ill-equipped to protect your data from a breach, but the key issues are that your PCs are vulnerable to new and unknown cyber threats, the ‘insider risk’ is not mitigated in the least, and high privilege user accounts are able to connect to third party applications with no understanding of the potential risks. If you have more than one database type, your situation is even worse.
What is a good security strategy?
In order to establish an effective database security strategy, you should start with four basic steps: Assessment, Classification, Mapping, and Course of Action.
You don’t need to avoid the cloud when you have the right database security strategy. With the right strategy, you can reduce risk and develop ways to mitigate different types of attacks, thus rendering even the cloud a safe space for your database.
Assess your organization for databases
The endless procession of new applications inside an organization creates a significant need for additional databases, and as multiple teams add more databases to your infrastructure, you need to know them – each and every database has to be accounted for.
Over time, many applications automatically install additional databases, some of which are used to store sensitive information. Therefore, you must run frequent site surveys as well as database discovery tasks, to ensure that you know about every database being used inside your infrastructure.
Classify your information
Vast amounts of information are stored inside your databases, so once you have uncovered all of the databases inside your organization, the next task will be to classify the information.
Information classification should be done according to the use case of your databases. Besides scanning each database for general sensitive information such as Personally Identifiable Information (PII), specific databases require an additional scan for specific types of sensitive information.
Many times, regulations compliance dictates the type of classification required for each database. Each organization must comply with different or multiple regulations such as HIPAA, SOX, and PCI DSS. Since each one has a different definition of what is considered “sensitive information,” you must make sure to classify the information accordingly.
Map your database usage, exposure and severity
As database administrators (DBAs) and developers still represent the front-line personnel for data management in most enterprises, you must make sure that these sources (users, IP addresses and applications) are provisioned accordingly, and when you define the type of access you grant them, make sure it’s set to the usage type.
Each database has multiple types of information that need to be accessed, with requests and queries coming from specific applications, groups of people, and sometimes group systems. Preventing unauthorized access to the database reduces unnecessary exposure and dramatically increases your security.
Mapping the usage and exposure of your databases should also help you define an appropriate mitigation plan for each threat. For example, if your database is used by a web application that’s exposed publicly to the internet, make sure you map it as ‘high severity exposure’ and include additional layers of security as part of your next task.
Define action items for each violation
The final step is to create a task list and define the action items for each database.
This should include:
- type of segregation of duties required
- actions to be blocked
- information to be dynamically masked
- actions that trigger an alert
- databases to be separated from your general database segment (if you have one)
It’s clear today that employing the right security solution will decrease your organization’s susceptibility to breach damages, protect your data, and allow you to invest your IT security budget more effectively.