How a Database Risk Assessment Reduces the Risk of a Cyberattack

Database security often, and to an organization's detriment, falls between the cracks as security and IT teams scramble to stay on top of daily cyber hygiene tasks and deal with the never-ending problems of running their network.

The danger of overlooking their database, or to put it in, say, banking terms – the vault – is this is likely a threat actor's primary target. An organization's database is where IP, credentials, and financial information are stored. 

These should be enough reasons to conduct periodic database risk assessments to ensure the vault is closed and locked.

Why Databases are Often Overlooked

While it is accepted that database security is often not prioritized, it's important to know the underlying logic for this decision.

Often, the mindset, particularly a leadership's thought process, is that the database resides "in our house," so it must be safe. After all, the thinking goes that if the data is within our walls and our people protect those walls, then the data is safe.

But this is a logical fallacy, and one security teams must face. These security people understand that if a breach happens, the hunt will start at the database level. 

Trusting staff is great, but that is not what cybersecurity is about. It's about eliminating the possibility of risk. The reality is we need to shut down the avenues bad guys can take to cause damage, and that is where a database risk assessment comes in.

Looking Under the Couch Cushions

The reality is once a security team conducts a database assessment a variety of problems are generally uncovered.

And finding these issues should be considered a positive, not a negative.

It's healthy to peek behind the curtain and look under the covers. Finding and addressing a problem is better than simply hoping nothing bad happens. Don't be afraid of what is found, it's the first step toward being more secure. 

After rooting around in a database, one of the more common issues found is unpatched software. 

When was the patching process last completed? Sometimes three months, a year, and we have seen three years, which leaves the client incredibly vulnerable.

Trustwave's assessments also commonly comes across these issues:

• Access/permissions granted to the public
• Xp cmdshell not disabled
• Easily guessed passwords (Hope you’re not using Password123!)
• Default accounts with default passwords
• SA account with a blank password
• No encryption enabled
• SQL Injection signatures.

One reason all of the above is so dangerous is that databases are inherently easily accessible. Still, organizations compound this problem by not deleting old accounts, using default passwords or in some cases we, find highly privileged users with easily guessed passwords.

In the past, there was also a bit of a separation of responsibilities between the database developers and the security team, which proved problematic. The database guys would say to security, "I created the database, I made it powerful, I gave people access, and now the rest is your problem."

And while this mindset is mostly gone, I still hear it in some parts of the world, so it's one more thing to keep in mind.

The Good Enough Principle

Many tools are on the market now, but before an organization either takes the plunge and acquires one or hires a company that uses one, a little background check is necessary.

I had a conversation with one company and was told that it uses (name redacted) with the explanation that it's good enough. To which I said, "well, good enough is no longer good enough."

He kind of agreeingly laughed, and I quickly followed up, noting that while his tool is probably doing a decent job, the reality is I've got a lot of really big clients who have just gone through some really big breaches, and they all use these type of tools.

Those that are just “good enough” and look where it got them.

Using the Right Tools for the Job

One can't use a screwdriver to chop down a tree. At least not easily. The same holds true for conducting a database risk assessment.

An axe is needed to chop down a tree, and a tool designed, built, and updated to test databases is needed for an assessment.

Such a tool is Trustwave's AppDetectivePRO. 

The preferred tool for security practitioners is a database security audit and assessment scanner that can be downloaded and installed on a workstation in minutes. 

Trustwave's AppDetectivePRO was the first database scanner introduced into the industry more than 25 years ago and is geared toward clients with a small footprint. It can scan a database and understand your risk by uncovering configuration issues, vulnerabilities, elevated data access, or any combination of settings that could potentially compromise the integrity of the database.

The tool is intuitive and used by internal security teams and external auditors. 

The internal audit capabilities enable companies to help defend themselves by finding problems and also prepare them for compliance audits, essentially allowing an organization to know the answers to the test before it takes the test.

The Trustwave SpiderLabs team uses AppDetectivePRO when clients purchase managed vulnerability scanning reports accessed via the Trustwave Fusion dashboard.

Trustwave's step-up product for enterprises is DbProtect. DbProtect is a visual database security and risk management platform that helps organizations secure their enterprise databases – on-premises or in public, private, or hybrid clouds.

Enterprises, government organizations, and small and medium-sized businesses use DbProtect to automate two labor-intensive best practices: continuously assessing for database risk and continuously monitoring database activity.

The final word on why to have a database risk assessment is simple.

Security.

An organization won’t know its weaknesses without an assessment and it’s important to not be afraid of the findings. Even if the test results are sub-optimal, at least a starting point has been found and you can immediately start on a safer path.