Risk calculator

Risk Calculator

Estimate the risk of a data breach in your organization. By providing some information specific to your organization you will get an immediate estimate of the risks you are facing.

Risk parameters

How many people are in your organization?
Number of employeesEnter the number of employees in your company. Or, more accurately, the number of people with access to internal company resources such as the network, email, and active directory.
Number of App usersEnter the number of employees who have access to applications with sensitive information. They don’t necessarily need access to the data but to the applications that contain it.
Number of DB usersEnter the number of employees with direct database access, including DBAs. Or, more accurately, the number of individuals whose database accounts will allow an attacker to steal data.
Personnel Risks
Risk of misuse1 in What’s the likelihood an employee will try to steal data? This question relates to human nature and the type of employees in your organization. It’s hard to provide reliable estimates, but statistically, 20% of data breaches are from internal threats. There are also estimates that every year, over 20% of companies experience incidents from intentional employee abuse of privilege. We estimate that 1 in 5,000 is a conservative number.
Risk from social1 in What’s the likelihood an employee will click on the wrong email and compromise their computer? This risk depends on the type of employees and the amount of training they receive. Companies that perform employee training claim to reduce this risk from 60% to 10%. We, therefore, believe that 1 in 10 (10%) is a conservative estimate.
Security Risks & Capabilities
Application Breach%What’s the likelihood that a hacker with access to an application account could steal data? That includes vulnerabilities like SQL injection and the risk the compromised user already has access to the data.
Detect database attacks%How likely are you to know when an individual uses a database account to steal data? You can estimate this based on the number of false positives you regularly get from your detective/alert systems. Not getting false positives means you are unlikely to know when an attack occurs.
Detect application attacks%How likely are you to know when an individual uses an application account to steal data or perform an attack? You can estimate this based on the number of false positives you regularly get from your detective/alert systems. Not getting false positives means you are unlikely to get an alert when an attack occurs.
Risk preview
Database risk
Preview of the total database risk. Click View Results for more details.
Application risk
Preview of the total application risk. Click View Results for more details.

What does it mean?

help

Risk results

Threat from employee misuse
The likelihood that an employee (not a DB or App user) will attempt to steal data.
Threat from employees from social
The likelihood that an employee (not a DB or App user) will fall prey to a social engineering attack.
Threat from user misuse
The likelihood that one of the application users will attempt to steal data.
Threat from users from social
The likelihood that one of the application users will fall prey to a social engineering attack.
Threat to DB from misuse
The likelihood that one of the database users will attempt to steal data.
Threat to DB from social
The likelihood that one of the database users will fall prey to a social engineering attack.
Perimeter breach
The likelihood that an individual inside the network (behind the perimeter) will attempt to steal data due to either misuse or social engineering. To intuitively understand this number, consider the number of employees and the social risk from each one.
Indirect risk
The risk from employees with no application or database access (through misuse or social engineering). This risk is harder to materialize because the attacker must also compromise an application or database account. It’s usually feasible once inside the perimeter but requires an additional step to get to a data breach.
Direct database risk
The likelihood that data will be stolen from the database directly (through misuse or social engineering). It shouldn’t be over 5-10%.
Direct application risk
The likelihood that data will be stolen through the application. (through misuse or social engineering). It shouldn’t be over 5-10%.

Enter your email for a report with customized recommendations:

Contact us with any questions or comments. We’d love to hear from you!

What does it mean?

help

Your database or application risk is over 50%. You’re an easy target waiting to fall prey. There’s a reasonable chance you’ll have a data breach this year or next year if you haven’t already had one you’re unaware of.

Your database or application risk is 20%-50%. There’s a reasonable chance you’ll have a data breach in the next five years because your exposure is statistically high. It’s a question of being targeted or unlucky to fall into the wrong spam campaign rather than your ability to defend.

Your database or application risk is 10%-20%. You have minimal defensive capabilities. There’s a 50/50 chance you’ll have a data breach in the next seven years. Your exposure is moderate, and you’re doing a good job, but you should improve it.

Congratulations! Your database and application risk is lower than 10%, which means you have defensive capabilities and can withstand an attack. If below 5%, you have strong defenses. It doesn’t mean you won’t have a breach, but it’s less likely. Whether from internal abuse or a successful spam campaign, attackers are likely be detected, and your security team can foil the attack.

Database security – self assessment

Database Security – Self Assessment

The following questionnaire will help you evaluate the strength of your database security. It takes about 5 minutes to complete it and at the end you’ll get a score along with an email containing the results with detailed explanations.

Do you know where is your sensitive information? Which database and what tables and columns contain it?
The most elementary requirement to protect sensitive data is to know where it is. Having the list of database that contain it and the tables and columns that require protection is essential.
Have you ensured users only have the minimal privileges they need (least privileged)?
An important best practice is to ensure least privileged – that users only have the permissions needed to perform their job. This is especially important for administrator privileges that are, unfortunately, often granted by mistake or without good justification.
Are you aware of changes in your database?
Change control is a simple way to demonstrate basic control over environments. Since administrators often neglect to document these changes, it is highly recommended to close the loop by monitoring for changes in the environment and approving them.
Do you review who connected to your database?
Knowing what users, programs, and machines connect to the database is the most minimal visibility to understand what’s going on. This information should be reviewed on a daily or weekly basis.
Do you review accesses to sensitive tables?
Special attention must be given to access to sensitive tables. It is important to know who’s performing such access, how much data is accessed, when that access is “unusual”, and more. Establishing effective reporting is essential so the reports are short, meaningful, and easy to review.
Do you monitor DBA activity?
Due to their elevated privileges, DBAs activity is considered a high-risk activity profile. This is both from as an internal threat of abuse of privilege, and in case their credentials are stolen or their machines hacked.
How much time, on average, do you spend on database security?
Effective monitoring can usually be done in less than 2 hours per week. Spending more time suggests your controls are not effective and that you are drowning in useless information. Not spending any time at all, suggests your controls are calibrated so low that you are unlikely to know if a real problem occurred.
Do you monitor for unusual database activity such as users connecting from different programs or from different machines?
Databases have a lot of connections and its easy to miss small changes such as a different IP address for a particular user, or a program that a user doesn’t normally use. Automation can help ensure you are aware of any changes in the connection profiles.
Do you monitor anomalous application activity such as SQL injection?
Applications perform massive amounts of SQLs that are impossible to review individually. This is one place where automation is the only solution. Anomaly analysis, for example, can analyze the activity profile and point out changes in the application behavior. These can be an indication of someone taking advantage of an application flaw to attack the database. SQL Injection is an example of an attack leveraging a common application bug.
How do you audit your database activity?
Auditing database activity requires the right technology. At small scale, home-grow scripts can be effective. However, when auditing more activity of larger databases the performance impact becomes very high and the required time investment – challenging. Using the right solution can help you monitor everything with negligible overhead and achieve effective reporting.
Do you have separation of duties that prevent, for example, DBAs from accessing sensitive data?
Database are designed to have administrator accounts with unlimited privileges. These accounts are a high-risk attack vector both for the internal abuse of privilege threat and in case they are compromised by credential theft or hacking into DBA machines. Reducing the access of these accounts and establishing separation of duties can significantly reduce the risk from DBA accounts.

You finished the self assessment!

Your database security maturity level is out of 10

10 Out of 10

If you’d like to receive a report with your self assessment results and more detailed explanations, please fill in your information:

First name
Last name
Company
Title
Email
Phone