Data plays a very important role in a typical organisational environment. Security is one of the biggest issues facing data storage; all companies should take measures to protect data from external and internal attacks via networks and operating systems. More recently, the focus of database security has shifted to highlight applications. Many organisations spend large amounts or resources adding firewalls, policies, operating system controls, IDS, IPS and access controls. By doing his, many organisations believe their databases are protected. But if the databases are left without direct control, they are left vulnerable to internal hacks where data can be accessed and transferred from the database. This will also be the case for any external attacks. For any attacker, a glitch in database security can a have a large and immediate financial payoff. For organisations, a database compromise can a have a huge negative financial impact.
What Is a Database?
A database can be defined as a collection of data that is saved on a computer system’s hard drive. Databases allow any user to access, enter and analyse data quickly and easily. It’s a collection of queries, tables and views. The data stored in the databases are usually organised to model aspects that support processes that require information storage and retrieval. The user interface for databases is called a database management system. DBMs is a software application that interacts with the authorised user, other applications and the database itself to capture and analyse data. Database management systems are designed to allow definition, querying, creation, update and administration of an organisation’s database. Popular database management systems include Microsoft SQL Server, MySQL, IBM DB2 and Sybase. A database is not portable across different database management systems, but different DBMs can interpolate by way of standards like SQL or JDBC to allow a single application to run with more than one database management system.
You can think of a database as a collection of lists of information. Everything that pertains to a specific person, process or an item are all stored in a database. Even sensitive information is stored in databases.
Why do Organisations and Enterprises Need Databases?
Databases allow enterprises and organisations to store and save any type of data needed. The speed and relatively affordable cost makes them a popular choice among many businesses with large customer bases. Companies that also have sensitive data and information needed for crucial decision making also take advantage of databases. Users can access company databases and bring up customer or user information in a shorter amount of time. It allows the business to avoid overwhelming costs, management and disposal of paper records. May companies also use databases because it can automate different procedures, saving resources and man hours. For example, instead of manually verifying transactions, users can rely on computer reports stored in the database. Instead of entering warehouse or retail stock information manually, handheld scanners can be used to save information in the database. A database can provide efficiency and speed in the modern workplace.
Databases are complex and many database security professionals simply do not posses the background to fully understand the involved risks and security issues related to different versions and brands of databases. This leaves security concern to Database Administrators who spend less than 5% of their time working on improving the security of the database. According to many IT experts and DBAs, many enterprise DBAs are not aware of which databases, tables and columns contain sensitive data because they are either handling legacy applications or there are no records or documentation of the data models. Even with full knowledge of the database assets, databases are harder to secure and protect because there are unique security implementations and procedures for the databases. This also applies to applications that interact with the databases. Experts also estimated that more than 90% of enterprises support more than one type of database. Modern day enterprises have to support hundreds or thousands of production databases with different business applications. Other business applications that interact with the databases can also pose serious risks as additional application layer vulnerabilities may be introduced into the system.
We can say that database security is the use of a wide range of data security controls to protect databases against any attacks (internal or external), against compromises of database confidentiality, integrity and availability. The security involves different types of controls like technical, administrative and physical controls.
In order to effectively protect the organisation’s data, database security should be a top priority. Without the support of management and some strategic direction, the security of the database will be overlooked. Database security must be part of the enterprise strategic plan because:
- In recent years, databases saw the largest percentage of compromised records per incident. It’s also one of the most highly attacked enterprise assets.
- The number of database attacks continues to increase.
- Management support is essential to the successful implementation of security controls.
- Security controls should be implemented as close to the data as possible to protect them from internal and external attacks.
- Many security professionals and departments do not understand or look at database security as closely as required.
The rapid growth of unstructured and structured data is opening a lot of security doors that are not getting enough attention in many organisations. Many businesses spend lots of money working on security systems, but databases are often left vulnerable to attacks. The dominant philosophy has been to create impenetrable perimeter defence (this includes putting up firewalls and intrusion detection systems) but the mindset has been changing over the years because the perimeter-only security strategy has proven to fail. Attackers can work their way around perimeter security devices and prey on gullible security personnel to give them have access to the system.
Convincing organisations to put more focus on database security is not easy, especially if these organisations have not previously been exposed to an attack. One way to call more attention to database security is to highlight the number of high-profile attacks and breaches where database security played a major role. Julian Assange’s Wikileaks and the Edward Snowden cases are good examples. Although these cases saw information about the covert operations of the US being released to the public, they are still some of the greatest database breaches recorded to this day. Another prime example is the Anthem attack where 80 million customer records were exposed. The database administrator discovered the attack when he noticed unauthorised access to the database. The hackers were able to compromise the credentials of 5 employees and used them to infiltrate company records.
These issues remain very critical especially when Big Data is involved. A recent survey by Dell Software found that structured data consists of at least ¾ of the whole data under management for many organisations. The survey also found that relational databases from different major vendors remain the dominant storage spaces for data and the volume of data continues to grow exponentially. With this continuing growth, there will be a need for more secured databases and improved security from any unauthorised access leading to the exposure of sensitive information.
Database Security Strategy and Considerations
As mentioned earlier, database security should be a priority and part of the overall security strategy.
1. Control to Database Access
Access controls protect against external and internal attackers, but it can also protect from the mistakes a user may introduce into the system. Access controls should be rolled out based on the principle of least privilege and it should be applied to 2 primary users – the administrators and the standard end users.
For the administrators, each database administrators should be limited to only the functions they need to do their job. Often times, default functionality (including default roles) gives many privileges as needed because it is designed for each use. In cases like these, default roles like “database administrator” should not be used, but specific administrative roles and activities should be designed and created in granting security privileges. Implement user login triggers which will monitor who the user is and where they are trying to access the information from. Knowing this information can be used to limit what this user is able to do and access when connecting to a database. By centrally managing these access controls it can reduce the chances of users improperly applying access controls to any user. Enforcing central password management policies and strict authorisation are essential to the overall database environment.
If you have seen movies where data hacking is one of the major plots, you will notice that many of the databases and the hackers themselves are using encryption. Using encryption is a response to regulatory compliance, but it’s also another fundamental layer of protection for your database. Encryption is a strong security control process when it is implemented correctly. Some enterprises think that implementing encryption will solve their security problems, however, while database security would not be complete without encryption, in reality you should understand the entire environment first and then protect your data in its 2 states – data at rest and data in transit.
Data in transit is the date travelling across the network. It’s logical that any data being sent out should be encrypted while traversing the network or at least make sure the network is rightfully segmented so that any inside attack will be prevented when a potential attacker is checking network traffic. End-to-end encryption is also a strong line of defence against any data leaks from an internal attack.
Data at rest on the other hand is data that is stored within the database. Data can be encrypted at different levels and as a part of an application, but this can be a challenge for system and key management updates. Encrypting data in the database itself, you’re centralising the encryption controls for the data at its source. The encryption can be applied to the entire table or per column. Plus, it’s also pretty useful that encryption should be applied to the data being stored for backup purposes.
3. Data and Database Auditing
How do you know if access and privilege are being abused or compromised? How does a database administrator know they are protected and not be accused of access abuse? How can they prove it?
You can prevent these things from happening by implementing and managing the audit trails within your database. Audits allow you to track and see the user activity including the administrative action. There are many options for audits, but the following should absolutely be audited to fulfil regulatory requirements:
- administrative activity
- use of the system privileges
- logon and logoff activity
- the use of all privileges
- critical object access
- any alterations to the structure of the database
Saving audit records on a secondary system and centralising is also important. By storing these records in the 2nd system, there will be less chances of any unauthorised activity recorded in the activity trail that an intruder can change. If the audit records are centralised on a single system, it will be easier to monitor and check as compared to checking individual databases.
4. Separating Environments
Separating environments is a best practice across the fields of data security, development and testing for many years and in fact, has been embedded in many regulatory requirements, industry standards and audit programs. Stored data should be separated because development environments and the developers are potential risks to the enterprise’s database. Ideally, developers should only have limited access to the development environment, unless troubleshooting is needed that cannot be duplicated in the development environment. If access is needed to be given to the developers, they should be supplied with read-only roles with minimal privileges and the actions taken should be audited.
Any production data should not be propagated to other database environments for testing or development purposes, but it can be manipulated in such a way that it will enable data transfer to other environments without leaving it open to attack. You can do data masking which can take any sensitive information and replace it with realistic but simulated values while maintaining integrity and the application will continue to work. These masked and functional databases are safe to move to any non-production environments whenever the enterprise requires it. If attackers get access to these environments, they will only access the decoy and not the true information.
5. Securing Database Configuration
Your organisation is the one responsible for protecting and securing the database. Therefore, to properly address any database security concerns, the right tools are needed to automate the entire secure configuration life cycle. This includes database discovery, configuration lock down, security scanning and automated remediation. The key areas that should be focused on when securing a database include:
- users and roles
- default accounts
- permissions and privileges
- parameter settings
- password management
- listener security
Once the database is properly protected and secured, any configuration weaknesses or vulnerabilities should be continuously monitored for any potential changes. It’s also important to monitor the configuration drift for security purposes and still follow regulatory requirements that require a system to be configured in a particular manner. If the database is monitored continuously for any changes, management and database administrators can be notified automatically if a base no longer meets the organisation’s security and regulatory requirements, thus necessary adjustments can be made.
2015 Top 10 Database Security Threats
Along with the advancements in database security, different types of security threats are also advancing. The reason databases are prime targets is quite simple – databases are the heart of an organisation, storing records and other confidential business information and data. Databases are vulnerable because business organisations are not protecting these assets well enough and less than 5% of the $27 billion spent on the security products directly address data centre security. However, the vast majority of these incidents – more than 97% – could have been prevented by implementing the best practices and the necessary internal/external controls. The top 10 database security threats below apply not only to traditional databases but also to Big Data technologies. Although Big Data’s NoSQL technology differs from SQL, they still have the same injection points. These injection points provide access for attackers to access Big Data components.
As mentioned earlier, threats are advancing even as databases become bigger and better. From 2013 to 2015 there have been changes in security threats and their intended targets. The top 10 database security threats in 2013 (in no particular order) included:
- Denial of service
- Unmanaged sensitive data
- Limited security expertise and education
- SQL injection
- Storage media exposure
- Unused and excessive privileges
- Privilege abuse
- Weak audit trail
- Exploitation of vulnerabilities and misconfigured databases
This year, we are still facing similar problems (in order of threat level):
- Excessive and unused privileges. Anyone granted with database privileges that exceed the requirements of their specific job functions can abuse those privileges. Another example is when someone changes their role within the enterprise or leaves the company, their right to access sensitive data does not change. If this personnel resigned or departed the company on bad terms, they can use their old privileges to steal information or attack high value data in the database.
- Privilege abuse. Disgruntled employees are not the only possible threats, anyone who has access privileges can turn rogue. Any user may abuse their legitimate privileges for unauthorised access. Say for example a company has an internal warehouse application used to view customer information via a web application or interface. The web application usually limits users to viewing an individual customer’s record like purchases or orders or any other business history. A rogue user may be able to go over the restrictions by connecting to the database using an alternative software like Microsoft Excel. The rogue user may be able to gain access, retrieve and save the records to their laptop and can be used for a wider variety of security breaches.
- Input injection. SQL injection and NoSQL injection are the 2 types of database injection attacks. SQL injection targets traditional databases and it involves injecting any malicious or unauthorised statements into the input fields of web applications. NoSQL injection targets Big Data platforms and usually involves injecting malicious statements in the Big Data components. In both instances, a successful injection can give the attacker or hacker unrestricted access to the entire database.
- Malware. State-sponsored hackers, spies and other cybercriminals have used multiple attacks to hack into databases. Spear phishing emails and malware are used to penetrate, gain access and steal vital information. Legitimate users may be unaware that their device is infected with malware and will become a clueless pawn in accessing this data.
- A weak audit trail. We have mentioned how important an audit trail is in securing the database but failing to collect detailed audit records of any database activity will pose a serious risk to the organisation on many levels. Any organisation with a weak or non-existent database trail audit will surely find themselves at odds with government and industry regulatory requirements. Most enterprises and organisation will go for the native database audit tools provided by the service providers or vendors or rely on manual ad-hoc solutions. These tools do not record details necessary in support of auditing, digital forensics or attack detection. Also, these native database audit tools are known to consume too much CPU and disk resources, thus many organisations are forced to scale down or totally remove auditing in their system. Many of these native audit mechanisms are not aware of the identity of the end user because all activities are linked to the web application account name. Any user with administrative access to the database can turn off native auditing to hide any scrupulous activity so auditing responsibilities and capabilities should be separate from the base admin and the database server platform to ensure the separation of functions and duties.
- Storage media exposure. Backup stores are usually not protected from internal/external attacks, thus many security breaches have involved database backup thefts. Add to that a failure to monitor and audit the activities of administrators who are given low-level access to sensitive data and the data is put at risk. Take the right measures in protecting your backup copies of any sensitive information and monitor your most highly privileged users for industry regulations.
- Exploiting vulnerable and misconfigured databases. Hackers know how to exploit any vulnerable and un-patched databases or find any databases that still have their default account settings and configuration parameters. The bad news is, many organisations often struggle to stay on top of maintaining their database configurations even when the patches are available. Common issues include complex requirements for patches, high workloads, mounting backlogs for the database administrators, challenges to find a maintenance window to take down and work on any business critical systems.
- Denial of service. This is an attack category where access to network applications or data are denied for the intended users. The most common method of doing this is to overload the server resources by flooding them with an excessive number of queries or with smaller volumes of queries that consume a disproportionate amount of system resources. The result will be the same, the resource-starved servers will become unresponsive and in some cases, will crash. The probable reason for this is to extort companies where a remote attacker will repeatedly crash the servers until the enterprise gives in to their demands.
- Unmanaged sensitive data. Any forgotten database may contain sensitive data and newer databases can be built. These sensitive data will be exposed to threats if the needed controls and permissions are not implemented.
- Limited security education and expertise. Any internal security controls that are not up to speed with the growth of data will be not equipped to handle most security breaches.
Business organisations should seriously consider database security as part of their overall security strategy. Everyone in the enterprise should do their part and understand their responsibilities in order to keep company data secured. Providing the overall security strategy will encourage different departments to work together to meet important database security requirements.