You are on page 1of 15

Database Security Security in a database involves mechanisms to protect the data and ensure that it is not accessed, altered,

or deleted without proper authorization. In other words, Database Security is the mechanism that protects the database against intentional or accidental threats. Why need for Database Security? In case of shared data, multiple users try to access the data at the same time. In order to maintain the consistency of the data in the database, database security is needed. Due to advancement of internet, data are accessed through World Wide Web, to protect the data against hackers, database security is needed. The plastic money is more popular. The money transaction has to be safe. More specialized software both to enter the system illegally, extract data is available.

Why is Database Security important? Databases often store data which is sensitive in nature Incorrect data or loss of data could negatively affect business operations Databases can be used as bases to attack other systems from

Security risks to database systems include, for example:


Unauthorized or unintended activity or misuse by authorized database users, database administrators, or network/systems managers, or by unauthorized users or hackers (e.g. inappropriate access to sensitive data, metadata or functions within databases, or inappropriate changes to the database programs, structures or security configurations); Malware infections causing incidents such as unauthorized access, leakage or disclosure of personal or proprietary data, deletion of or damage to the data or programs, interruption or denial of authorized access to the database, attacks on other systems and the unanticipated failure of database services; Overloads, performance constraints and capacity issues resulting in the inability of authorized users to use databases as intended; Physical damage to database servers caused by computer room fires or floods, overheating, lightning, accidental liquid spills, static discharge, electronic breakdowns/equipment failures and obsolescence; Design flaws and programming bugs in databases and the associated programs and systems, creating various security vulnerabilities (e.g. unauthorized privilege escalation), data loss/corruption, performance degradation etc.; Data corruption and/or loss caused by the entry of invalid data or commands, mistakes in database or system administration processes, sabotage/criminal damage etc.

OUR ENVIRONMENT

DBA A Database Administrator responsible for the design, implementation, maintenance and repair of an organizations database. 1. Maintaining database and ensuring its availability to users 2. Controlling privileges& permissions to database users 3. Monitoring database performance 4. Database backup and Recovery 5. Database security

We consider database security in relation to the following situations:

Theft and Fraud Loss of confidentiality Loss of privacy Loss of integrity Loss of availability

Database security concerns the use of a broad range of information security controls to protect databases (potentially including the data, the database applications or stored functions, the database systems, the database servers and the associated network links) against compromises of their confidentiality, integrity and availability. It involves various types or categories of controls, such as technical, procedural/administrative and physical. Database security is a specialist topic within the broader realms of computer security, information security and risk management. Many layers and types of information security control are appropriate to databases, including: Application security Access control Auditing Authentication Encryption Integrity controls Backups

Traditionally databases have been largely secured against hackers through network security measures such as firewalls, and network-based intrusion detection systems. While network security controls remain valuable in this regard, securing the database systems themselves, and the programs/functions and data within them, has arguably become more critical as networks are increasingly opened to wider access, in particular access from the Internet. Furthermore, system, program, function and data access controls, along with the associated user identification, authentication and rights management functions, have always been important to limit and in some cases log the activities of authorized users and administrators. In other words, these are complementary approaches to database security, working from both the outsidein and the inside-out as it were. Many organizations develop their own "baseline" security standards and designs detailing basic security control measures for their database systems. These may reflect general information security requirements or obligations imposed by corporate information security policies and applicable laws and regulations (e.g. concerning privacy, financial management and reporting systems), along with generally-accepted good database security practices (such as appropriate hardening of the underlying systems) and perhaps security recommendations from the relevant database system and software vendors. The security designs for specific database systems typically specify further security administration and management functions (such as administration and reporting of user access rights, log management and analysis, database replication/synchronization and backups) along with various business-driven information security controls within the database programs and functions (e.g. data entry validation and audit trails). Furthermore, various security-related activities (manual controls) are normally incorporated into the procedures, guidelines etc. relating to the design, development, configuration, use, management and maintenance of databases.

Vulnerability Assessments and Compliance One technique for evaluating database security involves performing vulnerability assessments or penetration tests against the database. Testers attempt to find security vulnerabilities that could be used to defeat or bypass security controls, break into the database, compromise the system etc. Database administrators or information security administrators may for example use automated vulnerability scans to search out misconfiguration of controls within the layers mentioned above along with known vulnerabilities within the database software. The results of such scans are used to harden the database (improve the security controls) and close off the specific vulnerabilities identified, but unfortunately other vulnerabilities typically remain unrecognized and unaddressed.

Vulnerability Severity Code Definitions

A program of continual monitoring for compliance with database security standards is another important task for mission critical database environments. Two crucial aspects of database security compliance include patch management and the review and management of permissions (especially public) granted to objects within the database. Database objects may include table or other objects listed in the Table link. The permissions granted for SQL language commands on objects are considered in this process. One should note that compliance monitoring is similar to vulnerability assessment with the key difference that the results of vulnerability assessments generally drive the security standards that lead to the continuous monitoring program. Essentially, vulnerability assessment is a preliminary procedure to determine risk where a compliance program is the process of on-going risk assessment. The compliance program should take into consideration any dependencies at the application software level as changes at the database level may have effects on the application software or the application server. In direct relation to this topic is that of application security.

HARDENING DATABASES
Hardening databases general strategies and tactics Principle of Least Privilege! Stay up-to-date on patches Remove/disable unneeded default accounts Firewalling/Access Control Running Database processes under dedicated non-privileged account. Password Security Disable unneeded components Stored Procedures and Triggers

Hardening databases firewall/access control Throttling connections make it harder for the bad guys to brute-force or guess passwords Use firewall software like IP Tables Xinetd may be useful for throttling Its possible that throttling could deny access to applications which make a large amount of connections legitimately. Reducing the surface area of attack with firewall rules Dont let the world connect to your database server.

Hardening databases password security Strong passwords are a must o Constant brute-force attacks are happening across campus. Esp. against SQL Server Default passwords are a problem MySQL: root@localhost:<blank> SQL Server: sa:<blank> (Old, but still seen sometimes) Oracle: Built in password policy control seems rare o How can we enforce password policy?

Hardening databases stored procedures, triggers Stored Procedures and Triggers can lead to privilege escalation and compromise. Be sure to be thinking about security implications when allowing the creation of, and creating these.

Hardening databases disable unneeded components

Just like disabling unneeded services for an operating system is a good idea disabling unneeded components for databases is a good idea. o XML FTP (Oracle) o Named Pipes access (SQL Server)

HARDING ORACLE
TNS Listener The TNS Listener is the hub of all communications in Oracle. [] When a client wishes to access the database server, the client connects first to the Listener. [] In versions of Oracle prior to 10g, the TNS Listener could be administered remotely what makes this particularly dangerous is the fact that by default the Listener is installed without a password []
The Database Hackers Handbook

Set a password for TNS Listener Administration o listener.ora file PASSWORDS_listenername = somepass o Use the lsnrctl utility LSNRCTL> change_password

Default Accounts Decent amount of default accounts o Be aware what they are o Ensure the passwords do in fact get changed appropriately 10g forces admin to set passwords for many default accounts on install and may lock or expire them.

HARDENING SQL SERVER


Local Admins Removing Local Builtin\Administrators group from sysadmins o If they are an administrator on a system running SQL Server they can get to anything in any database. Authentication If configured to use Windows Authentication password policy can be enforced! XP_CMDSHELL Do not enable this on install of SQL Server2k5 unless absolutely necessary

HARDING MYSQL
Disabling network access If your Database is only for being accessed by someone/something on the same machine o disable network-based access with the --skip-networking option o Firewall off the port MySQL is listening on(typically port 3306) Account Types

Identity is determined by username AND the location connected from - Coolness Scope Identities appropriately o Allow bob to login from any uiowa.edu hostname GRANT [] ON somedb.sometable TOBOB@%.uiowa.edu; o Allow bob to login from any campus IP address GRANT [] ON somedb.sometable TOBOB@128.255.0.0/255.255.0.0 Encrypting Traffic MySQL supports encrypting traffic with SSL o Consider using GRANT REQUIRE SSL or similar for an account Useful for accounts that may be accessing sensitive data and/or data that is required to be encrypted by some requirement.

PRINCIPLE OF LEAST PRIVILEGE If X service doesnt need access to all tables in Y database then dont give it access to all tables. o Example: A web application that reads a list of people from a database and lists them on a website. The database also contains sensitive information about those people. The account used by the web application should not be allowed to read the table that contains sensitive non-public information. Do not give accounts privileges that arent needed o Unneeded privileges to accounts allow more opportunity for privilege escalation attacks.

Database activity monitoring (DAM) Another security layer of a more sophisticated nature includes real-time database activity monitoring, either by analyzing protocol traffic (SQL) over the network, or by observing local database activity on each server using software agents, or both. Use of agents or native logging is required to capture activities executed on the database server, which typically include the activities of the database administrator. Agents allow this information to be captured in a fashion that cannot be disabled by the database administrator, who has the ability to disable or modify native audit logs. Analysis can be performed to identify known exploits or policy breaches, or baselines can be captured over time to build a normal pattern used for detection of anomalous activity that could be indicative of intrusion. These systems can provide a comprehensive Database audit trail in addition to the intrusion detection mechanisms, and some systems can also provide protection by terminating user sessions and/or quarantining users demonstrating suspicious behavior. Some systems are designed to support separation of duties (SOD), which is a typical requirement of auditors. SOD requires that the database administrators who are typically monitored as part of the DAM, not be able to disable or alter the DAM functionality. This requires the DAM audit trail to be securely stored in a separate system not administered by the database administration group.

Abstraction Application level authentication and authorization mechanisms should be considered as an effective means of providing abstraction from the database layer. The primary benefit of abstraction is that of a single sign-on capability across multiple databases and database platforms. A Single sign-on system should store the database user's credentials (login id and password), and authenticate to the database on behalf of the user. Native Audit In addition to using external tools for monitoring or auditing, native database audit capabilities are also available for many database platforms. The native audit trails are extracted on a regular basis and transferred to a designated security system where the database administrators do not have access. This ensures a certain level of segregation of duties that may provide evidence the native audit trails were not modified by authenticated administrators. Turning on native impacts the performance of the server. Generally, the native audit trails of databases do not provide sufficient controls to enforce separation of duties; therefore, the network and/or kernel module level host based monitoring capabilities provides a higher degree of confidence for forsenics and preservation of evidence. Process and Procedures A database security program should include the regular review of permissions granted to individually owned accounts and accounts used by automated processes. The accounts used by automated processes should have appropriate controls around password storage such as sufficient encryption and access controls to reduce the risk of compromise. For individual accounts, a two-factor authentication system should be considered in a database environment where the risk is commensurate with the expenditure for such an authentication system. In conjunction with a sound database security program, an appropriate disaster recovery program should exist to ensure that service is not interrupted during a security incident or any other incident that results in an outage of the primary database environment. An example is that of replication for the primary databases to sites located in different geographical regions. After an incident occurs, the usage of database forensics should be employed to determine the scope of the breach, and to identify appropriate changes to systems and/or processes to prevent similar incidents in the future.

Introduction to Database Security Issues Types of Security Legal and ethical issues: Some information is considered private and thus cannot be accessed by unauthorized users. In many countries there are laws regarding privacy. Policy issues: Government, institutions or corporate have their own policies regarding the privacy of information. They decide what information should be made available to the public and what information must be protected. System-related issues This is concerned with deciding the level at which the security should be implemented. The security can be implemented at the system level or at the Operating system level or at the database level The need to identify multiple security levels : This is concerned with deciding the different security levels like Top-secret, secret, confidential and unclassified

Threats to databases - Loss of integrity: the database must be protected from improper modification. Modification includes insertion, modification and deletion of data. Integrity is lost if unauthorized changes are made to the database - Loss of availability: Availability is concerned with making the database objects available to the authorized users. - Loss of confidentiality: Confidentiality means protecting the unauthorized disclosure of data. Unauthorized disclosure could result in loss of public confidence,, embarrassment and legal action against the organization. Control Measures To protect databases against these types of threats four security measures can be implemented : access control, inference control, flow control, and encryption .Access Control:

:The security mechanism of a DBMS must include provisions for restricting access to the database as a whole. This access control is handled by creating user accounts and passwords. Inference Control Statistical databases are used mainly to produce statistics on various populations. The database may contain confidential data on individuals, which should be protected from user access. Users are permitted to retrieve statistical information on the populations, such as averages, sums, counts, maximums, minimums, and standard deviations. The statistical database provide statistical information or summaries of values based on various criteria. To protect the statistical database inference control measures should be provided.

Flow Control Flow control regulates the distribution or flow of information among objects. A flow between object X and object Y occurs when a program reads values from X and writes values into Y. Flow controls check that information contained in some objects does not flow explicitly or implicitly into less protected objects. A flow policy specifies the channels along which information is allowed to move. The simplest flow policy specifies just two classes confidential (C) and non-confidential (N), and allows all flows except those from class C to class N. A covert channel allows information to pass from a higher classification level to a lower classification level through improper means.

Encryption Data encryption , is used to protect sensitive data(such as credit card numbers) that is transmitted via some type communication network. The data is encoded using some coding algorithm. An unauthorized user who access encoded data will have difficulty decoding it, but authorized users are given decoding or decrypting algorithms(or keys) to decode data. Encryption consists of applying an encryption algorithm to data using some encryption key the resulting data has to be decrypted using a decryption key to recover the original data.

1.2 Database Security and the DBA The database administrator (DBA) is the central authority for managing a database system. The DBAs responsibilities include granting privileges to users who need to use the system and classifying users and data in accordance with the policy of the organization. The DBA has a DBA account in the DBMS, sometimes called a system or superuser account , which provides powerful capabilities : The DBA is responsible for the overall security of the database system. This includes 1. Account creation 2. Privilege granting 3.Privilege revocation 4.Security level assignment

1.3 Access Protection, User Accounts, and Database Audits Whenever a person or group of persons need to access a database system, the individual or group must first apply for a user account. The DBA will then create a new account number and password for the user if there is a legitimate need to access the database. The user must log in to the DBMS by entering account number and password whenever database access is needed.

Discretionary Access Control Based on Granting and Revoking Privileges There are two types of database security mechanisms: Discretionary security mechanisms Mandatory security mechanisms The method of enforcing discretionary access control in a database system is based on the granting and revoking privileges .

2.1Types of Discretionary Privileges The account level : At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database. The relation (or table level):At this level, the DBA can control the privilege to access each individual relation or view in the database.

2.1Types of Discretionary Privileges(5) In SQL the following types of privileges can be granted on each individual relation R: SELECT (retrieval or read) privilege on R: Gives the account retrieval privilege. In SQL this gives the account the privilege to use the SELECT statement to retrieve tuples from R. MODIFY privileges on R: This gives the account the capability to modify tuples of R. In SQL this privilege is further divided into UPDATE, DELETE, and INSERT privileges to apply the corresponding SQL command to R. In addition, both the INSERT and UPDATE privileges can specify that only certain attributes can be updated by the account. REFERENCES privilege on R: This gives the account the capability to reference relation R at the time of specifying integrity constraints. Data Control Language Grant &Revoke To control the granting and revoking of relation privileges, Each relation R in a database is assigned an owner account . The person who creates an object is considered as the owner of that object. The owner of a relation is given all privileges on that relation. In SQL2, the DBA can assign an owner to a whole schema using the CREATE SCHEMA command. The owner account holder can pass privileges on any of the owned relation to other users by granting privileges to their accounts. 2.2 View and Security The mechanism of views is an important discretionary authorization mechanism in its own right. For example, if the owner A of a relation R wants another account B to be able to retrieve only some fields of R, then A can create a view V of R that includes only those attributes and then grant SELECT on V to B. The same applies to limiting B to retrieving only certain tuples of R; a view V can be created by defining the view by means of a query that selects only those tuples from R that A wants to allow B to access. 2.4 Propagation of Privileges using the GRANT OPTION Whenever the owner A of a relation R grants a privilege on R to another account B, privilege can be given to B with or without the GRANT OPTION. If the GRANT OPTION is given, this means that B can also grant that privilege on R to other accounts. Suppose that B is given the GRANT OPTION by A and that B then grants the privilege on R to a third account C, also with GRANTOPTION. In this way, privileges on R can propagate to other accounts without the knowledge of the owner of R. If the owner account A now revokes the privilege granted to B, all the privileges that B propagated based on that privilege should automatically be revoked by the system. 2.5 An Example

Suppose that the DBA creates four accounts --A1, A2, A3, and A4-- and wants only A1 to be able to create base relations; then the DBA must issue the following GRANT command in SQL:GRANT CREATETAB TO A1;User account A1 can create tables under the schema called EXAMPLE. Suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT; A1 is then owner of these two relations and hence all the relation privileges on each of them. Suppose that A1 wants to grant A2 the privilege to insert and delete tuples in both of these relations, but A1 does not want A2 to be able to propagate these privileges to additional accounts: GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2; 2.5 An Example(7) Finally, suppose that A1 wants to allow A4 to update only the SALARY attribute of EMPLOYEE;A1 can issue: GRANT UPDATE ON EMPLOYEE (SALARY) TO A4;(The UPDATE or INSERT privilege can specify particular attributes that may be updated or inserted in a relation. Other privileges (SELECT, DELETE) are not attribute specific.)

2.3 Revoking Privileges In some cases it is desirable to grant a privilege to a user temporarily. For example, the owner of a relation may want to grant the SELECT privilege to a user for a specific task and then revoke that privilege once the task is completed. Hence, there is need for revoking privileges. In SQL, a REVOKE command is included for the purpose of canceling privileges. 2.5 An Example(5) Suppose that A1 decides to revoke the SELECT privilege on the EMPLOYEE relation from A3; A1 can issue: REVOKE SELECT ON EMPLOYEE FROM A3;(The DBMS must now automatically revoke the SELECT privilege on EMPLOYEE from A4, too, because A3granted that privilege to A4 and A3 does not have the privilege any more.)

Mandatory Access Control for Multilevel Security Security classes are top secret (TS), secret (S), confidential(C), and unclassified (U), where TS is the highest level and U the lowest: TS S C U Two restrictions are enforced on data access based on the subject/object classifications: 1.A subject S is not allowed read access to an object O unless class(S) class(O). This is known as the simple security property . 2.A subject S is not allowed to write an object O unless class(S) class(O). This known as the star property (or* property).

Mandatory Access Control To incorporate multilevel security It is necessary to consider attribute values and tuples as data objects. Hence, each attribute A is has a classification attribute C in the schema. In addition, in some models, a tuple classification TC is added to the relation attributes to provide a classification for the whole tuple. Hence, a multilevel relation schema R with n attributes would be represented as R(A1,C1,A2,C2, , An,Cn,TC) where each Ci represents the classification attribute associated with attribute Ai.

3.1 Comparing Discretionary Access Control and Mandatory Access Control Discretionary Access Control (DAC) policies are characterized by a high degree of flexibility, which makes them suitable for a large variety of application domains. The main drawback of DAC models is their vulnerability to malicious attacks, such as Trojan horses embedded in application programs. By contrast, mandatory policies ensure a high degree of protection in a way, they prevent any illegal flow of information. Mandatory policies have the drawback of being too rigid and they are only applicable in limited environments. In many practical situations, discretionary policies are preferred because they offer a better trade-off between security and applicability. 3.2 Role-Based Access Control Role-based access control (RBAC) has emerged rapidly in the recent years for managing and enforcing security in large-scale enterprises. Here permissions are associated with roles, and users are assigned to appropriate roles. Roles can be created using the CREATE ROLE and DESTROY ROLE commands. The GRANT and REVOKE commands discussed under DAC can then be used to assign and revoke privileges from roles. 3.2 Role-Based Access Control(2) RBAC appears to be a viable alternative to traditional discretionary and mandatory access controls; it ensures that only authorized users are given access to certain data or resources. Many DBMSs have allowed the concept of roles, where privileges can be assigned to roles. Role hierarchy in RBAC is a natural way of organizing roles to reflect the organizations lines of authority and responsibility.

You might also like