Why Your Database is Not Secure — A Prelude to the COLLABORATE 2019 Session

    By: Tim Boles on Mar 07, 2019

    Why Your Database is Not Secure.png

    By Tim Boles | Edited by April Sims

    "We're entering a new world in which data may be more important than software." —Tim O'Reilly, Founder, O'Reilly Media

    The cost of data breaches and data proliferation continues to grow year after year. As DBAs, it is our job to protect the data. A great place to learn more about data security and network with other DBAs is at COLLABORATE 2019, which has 18 sessions featuring database security topics. You can learn to use the features, functionality and applications available from Oracle to reduce the possibility of unauthorized access of data by hackers or internal users.

    This article provides a firm foundation of why you need to secure your database, as well as tips on how to get started. Think of this as a prelude to my COLLABORATE session, “Why Your Database is Not Secure,” which will help you learn how to leverage security information you gather to propose and implement changes to increase the security of your data.

    Current State of Database Security

    The goal of most of system breaches is to obtain data stored on the systems. Databases are high-profile targets for hackers because they often contain valuable and sensitive information. Cybercriminals can profit from retrieving and then using or selling data. Data like financial records, corporate records, personal user data, and governmental records can bring a windfall to the cybercriminals.

    There are numerous reports and whitepapers available on the internet that indicate an increasing chance the data we watch over will be compromised. According to the Identity Theft Resource Center (ITRC, 2019), the number of breaches reported was down by 23% in 2018, but the number of Personally Identifiable Information (PII) records exposed was up by 128% (see Table 1).

    These numbers give us an idea of a trend but do not truly show the state of breaches. The ITRC report is based on reported breaches and reported number of exposed records. Not all reported breaches contain exposed record counts and not everyone reports a breach.

    Table 1: ITRC Reported Breaches and Reported Records Exposed Statistics





    # of Breaches

    # of Exposed Records

    # of Breaches

    # of Records Exposed


























    Annual Totals





    Private sector companies often remain quiet about breaches. A report on the SamSam ransomware (Sophos, 2018), noted that the private sector suffered the most from the virus but reported these breaches less often than organizations in healthcare, education and government. A survey of 403 business executives found that more than half experienced a cyber-attack and 60% of those attacked lost data (Hartford Steam Boiler Inspection and Insurance Agency, 2017).

    According to statistics in Symantec’s 2018 Internet Security Threat Report, the number of attacks against small and large organizations was fairly balanced. Companies with 250 or fewer employees had the same percentage of email malware received as companies with more than 2,500 employees. Phishing rate by organization size was also similar with 1 in 3,111 for organizations with less than 250 employees and 1 in 3,019 for organizations with 2,500 or more employees (Symantec, 2018). Attacks are not only coming from the outside. Malicious insider activity accounted for nearly 36% of the records compromised in 2018. Additionally, 30 of 51 data breaches that involved Intellectual Property stemmed from inside the organization (Vijayan, 2018). These statistics do not include employee or individuals with insider access that mishandled assets.

    Securing the data is not just a moral or business decision. Governments are also taking a tougher stance on how companies maintain and protect data. In 2018, the General Data Protection Regulation (GDPR) was put into effect, with the purpose of imposing uniform data security laws on all EU members. In the United States, the number of individual states that have implemented data security laws has doubled since 2016. (National Conference of State Legislatures, 2019)

    It is important that organizations recognize the security of data should be everyone’s concern. As a data custodian, the DBA should champion efforts to secure data. The DBA is in the best position to understand where the risks are, how these risks can affect their organization, and should be the best equipped to deal with data security. There are three keys to a good security posture in an organization: training, communication and cooperation. For the DBA, the first steps down this path often starts with self-evaluation of attitude and then evaluation of the system.

    Why Are We Failing?

    The attitude of the DBA can have a tremendous impact on data security. One major issue is that DBAs are often complacent about security. A few examples of this type of thinking include:

    • No one is interested in our data. Many organizations believe hackers will not attack their systems because they are too small, not in an industry hackers care about, or do not store data hackers would want. If you look at reports in the last few years from ITRC, Verizon and Symantec, they all show similar information: Cyberattacks conducted against small to medium-size businesses are nearly as frequent and often more frequent than those against large businesses.
    • complex password is good enough. We would hope at this point all organizations have at least policies that force the usage of complex passwords. Yet that is not enough. Complex passwords can be circumvented. It’s often a mix of social engineering and complex malware attacks that allow hackers to gain the password to a system. This can become devastating when the same password is used across multiple systems. A breach on one system places data on other systems at risk as well.
    • We do not need database security assessments or tests. If you do not conduct assessments and penetration tests, you cannot understand where improvements can be made. Self-evaluations are a good start. There are many free tools and documented processes to help you evaluate database security. In addition to self-evaluations, third-party assessments are invaluable. Having an extra set of eyes and tests run will often show areas that need improvement that you might not have considered or just accepted as a standard.
    • One-and-done user creation. Staff often have access to the most sensitive data depending on their company role. You cannot just create a user, set privileges, roles and then forget about them. Data security needs to include policies and procedures that consider employees leaving a company, changing roles within the company or not actively using a system for an extended period of time.
    • We have a security department; they are responsible for data security. This is a very foolish way to look at data security. Not all organizations have experienced security staff. If they do, then the security staff is probably busy already managing and monitoring the network infrastructure and applications. Data is the DBAs domain and the DBA needs to champion data security. You should not go at it alone, but you should be a driving force behind gathering stakeholders and educating others on best practices for database security.
    • We wait 12 months before applying a patching to make sure all the bugs are out. Many organizations have complex environments that make it hard to keep up with published quarterly cycle patch updates provided by Oracle. Qualys is a leading provider of cloud-based security and compliance solutions. Their internal statistics show that between 2012 and 2016 the industry exposure to database vulnerabilities increased by more than 100%. John Holt, founder and chief technology officer at Waratek stated, “Oracle themselves claim that their average customer runs nearly a year beyond in applying critical patches,” (Waratek, 2018). What makes that terribly disturbing is the fact that attackers will often use automated scanners to identify and launch attacks against vulnerabilities within hours of disclosure.

    Security Evaluation

    Just as there is no way to have a 100% secure system, there is no way to have 100% data security. If data security were simple, everyone would do it. It is truly a stepwise progression. Here are a few ways you can create your own pathway to a more secure database system.

    Identifying Stakeholders

    Ideally, the pursuit of data security should be done as part of an overall data governance effort. If that is the case, then the data stakeholders have probably been identified. When you are considering the security of the data, you need to involve others. It would be difficult even within a small organization for an individual to have all the knowledge needed to secure everything appropriately. A deep understanding of data location, data governance policies and data usage is needed. You can define a data stakeholder as an individual or group that could affect or be affected by data under discussion.

    Groups often include:

    • Those who interact with the data.
    • Those who create or provide data.
    • Those who set or enforce the rules and requirements for data.
    • Those who provide the applications or tools that provide access to the data.
    • Those who control the technology used to store or access the data.

    The following table of possible data security stakeholders may help you in generating your own list.

    Table 2: Possible data security stakeholders


    Data Architects


    Backup & Recovery Team

    Legal Department

    Data Governance Board

    Chief Information Officer


    Data Analyst

    IT Security Group

    Application User

    Data Scientist

    Project Board

    Information Management Specialist

    Chief Technology Officer

    Business Analytics Dept.

    Getting Expert Help

    The purpose of creating a list of stakeholders is to identify people that can provide expert help, from assisting in developing data protection requirements to making sure everyone understands data protection concerns.

    Here are some basic questions and areas to investigate that you can use as a springboard.

    • What data needs protected?
      • Personally Identifiable Information (PII)
      • Supplier data
      • Intellectual property
      • Financial data
    • Where is the data located?
      • Live data
      • Archived data
      • Data backups
      • Non-production environments
    • Who should be able to access the data?
      • Are there specific roles defined for the users?
      • How roles assigned?
      • What happens when they change roles or leave the organization?
    • What regulations govern our industry?
    • What data protection laws pertain to our organization?

    These should give you a good foundation for creating your own questions. In researching for resources on data security policies and data governance below are some other resources that might be helpful.

    The requirements and decisions made by this group of stakeholders will probably cover areas outside the database administrator’s control. Yet, they give you a firm foundation to build on so you can justify changes to the environment, requests for resources and justification for performing assessments and testing. As you gather requirements and understand the entire picture of data security in your organization, you can begin the journey of securing your databases.

    Come to San Antonio, Texas, April 7-11 for COLLABORATE 2019. In my session alone you can learn how to perform basic security checks, implement low-impact security features of Oracle 12c, consider impacts of more invasive security features, and highlight when you might need additional Oracle security software.


    Hartford Steam Boiler Inspection and Insurance Agency. (2017). Half of U.S. Businesses Have Been Hacked. Retrieved January 17, 2019 from https://www.munichre.com/HSB/business-hacked-survey-2017/index.html 

    ITRC. (2019). End-of-Year Data Breach Report [White paper]. Retrieved February 2, 2019, from ITRC https://www.idtheftcenter.org/2018-end-of-year-data-breach-report/ 

    NCSL. (2019). Data Security Laws | Private Sector. Retrieved February 8, 2019, from http://www.ncsl.org/research/telecommunications-and-information-technology/data-security-laws.aspx 

    Sheridan, K. (2019). Exposed Consumer Data Skyrocketed 126% in 2018. Retrieved February 8, 2019, from https://www.darkreading.com/attacks-breaches/exposed-consumer-data-skyrocketed-126--in-2018/d/d-id/1333790 

    Sophos. (2018). SamSam: The [Almost] Six Million Dollar Ransomware [White paper].

    Retrieved February 1, 2019, from https://www.sophos.com/en-us/medialibrary/PDFs/technical-papers/SamSam-The-Almost-Six-Million-Dollar-Ransomware.pdf?la=en 

    Symantec. (2018). 2018 Internet Security Threat Report. Retrieved February 5, 2019, from https://www.symantec.com/security-center/threat-report 

    Vijayan, J. (2018). 2018 on Track to Be One of the Worst Ever for Data Breaches. Retrieved January 10, 2019, from https://www.darkreading.com/vulnerabilities---threats/2018-on-track-to-be-one-of-the-worst-ever-for-data-breaches/d/d-id/1333252 

    Waratek. (2018). Oracle: Apply Out-of-Band Patch for Database Flaw ASAP. Retrieved January 25, 2018, from https://www.waratek.com/oracle-database-server-flaw/


    Tim Boles
    is a Senior manager at Hitachi Consulting and a member of the IOUG SELECT editorial board. He is an educator, having taught high school students, college students and producing technical courses for Pluralsight. Boles is computer scientist and businessman, holding a Computer Science Master’s Degree from West Virginia University and an MBA from the University of Phoenix. You can contact Tim at tim2boles@gmail.com, follow him on twitter @timboles_dba or view his courses at www.pluralsight.com.

    Released: March 7, 2019, 10:17 am | Updated: March 7, 2019, 10:18 am
    Keywords: Feature | database | database security | dba | Security | SELECT | SELECT Journal | Tim Boles

    Copyright © 2019 Communication Center. All Rights Reserved
    All material, files, logos and trademarks within this site are properties of their respective organizations.
    Terms of Service - Privacy Policy - Contact

    Independent Oracle Users Group
    330 N. Wabash Ave., Suite 2000, Chicago, IL 60611
    phone: 312-245-1579 | email: ioug@ioug.org

    IOUG Logo

    Copyright © 1993-2019 by the Independent Oracle Users Group
    Terms of Use | Privacy Policy