Database Security - Coursework Example

Database Security Database Security Introduction A database can be described as a compilation of logically consistent data that bears inherent meaning. Data bases are designed and populated with data that relates to a specific purpose and an interaction with the events of the real world and active audiences interested in the contents (Shekhar & Chawla, 2003). They are designed to operate large amounts of information by capturing, storing, managing and retrieving that information. Computerized databases are created and maintained by database management systems (DBMS) or a collection of application programs specifically written for that purpose. The DBMSs provide an interface that that enables users to interact with the database itself, other applications for capturing and analyzing data (Oppel, 2004). Database security is concerned with aspects aimed at protecting the contents of the database, users and owners. The protection ranges from system protection against software and hardware malfunction to intentional and unauthorized use of the database and unintentional access by entities not authorized. Databases may be exposed to threats in the form of loss of integrity, confidentiality, authenticity and availability. Most large databases face security challenges related to survivability, intellectual property rights and data quality. According to a report by the American firm Verizon, databases are at the core of any organization as they store confidential data and customer records, yet they are the most breached business assets (Kroenke & Auer, 2007). Data must be available at every necessary time, and it must only be available to appropriately authorized users (Elmasri & Navathe, 2010). It is also of critical importance to track users who access data and the data they access. Data authenticity ensures that data is edited by authorized sources and confirms that users accessing it are actually who they claim to be. Authenticity also verifies that outbound data is being delivered to the expected recipient. Through data integrity, external data is verified as having the correct format and the necessary metadata. Data integrity is also concerned with the accuracy and verifiability of input data as well as ensuring that data follows the correct rules of workflow for the organization (Kroenke & Auer, 2007). All changes to data and their authors must be reported as a compliance requirement for data integrity. Through data confidentiality, it is ensured that only correctly authorized users have access to confidential data. This ensures that the entire database is protected from internal and external system breaches by reporting who gained access to data and the operations they applied. Legally sensitive and mission-critical data are specifically given more confidentiality attention as they bear more risk of exposing an organization to loss of business and litigation. That is organizations must have mechanisms that limit exposure to internal data losses, external hacking, and securing data in the event that hardware is stolen and unauthorized administrator access (Elmasri & Navathe, 2010). All organizations need a place to store data and institutional knowledge. Such data often contain proprietary knowledge that includes financial data, employee human resource data and personally identifiable information. Therefore, the confidentiality and security of the data is of critical significance to organizations. It is the significance of the data that makes it vulnerable to unauthorized access for malicious purposes, and especially by insiders. The vulnerability of databases to breaches may partly be blamed on poor security measures by organizations. As the Internet and email make the distribution and sharing of corporate information much easier, so does the risk of injurious access and use of information increase (Shekhar & Chawla, 2003). When malicious insiders and hackers access sensitive data, they affect business operations by inflicting damage and extracting value. Apart from reputation damage or financial loss, breaches often lead to regulatory violations, legal fees and fines. Internal controls and best practices can be put in place to control unused and excessive privileges, privilege abuse, malware and a weak audit trail. Database integrity is concerned with the requirement that information should be secured from improper alteration (Elmasri & Navathe, 2010). Loss of integrity may be occasioned by deletion, updating, insertion or creation of data, which could be either accidental or intentional. Organizations can use several categories of solutions that align with their security and compliance objectives. The four key control measures are access control, flow control, inference control and data encryption (Kroenke & Auer, 2007). Other further general measures include discovery and assessment which can locate where critical data reside and database vulnerabilities; user rights management which identifies excessive rights of access to data that is over sensitive; blocking and monitoring which protects databases from attacks and data theft; auditing which helps to demonstrate compliance with regulations of the industry; and non-technical security measures that encourage and emphasize a culture of security preparedness and awareness. The commonest security concern and problem to most computer systems is the need to prevent unauthorized users from gaining access to the system itself to either make malicious alterations or obtain information. In that sense, a DBMS’s security mechanism must feature access control methods that limit access to the whole database system by creation of user accounts and passwords which control the process of logging in. The core authority for the management of a database system is the database administrator (DBA). The DBA will usually have an account in the DBMS, referred to as a DBA account or, alternatively, a superuser account that gives them authoritative capabilities which are not available to regular users and database accounts (Silberschatz, Korth & Sudarshan, 2006). A DBA is responsible for creating accounts, and classifying and granting users privileges to use the system in accordance with the organization’s policies. Further, they have privileged commands that can revoke or grant privileges to individual users, accounts and user groups. The account creation function creates new accounts and passwords for users or groups of users to facilitate their accessing of the DBMS, while privilege revocation permits the cancellation of certain privileges previously allowed to some accounts. The security level assignment entails assigning user accounts to appropriate levels of security clearance. When users or groups of users need to access the database system, they must first apply to be given user accounts. If there exists a legitimate requirement to access the database, the DBA will create an account number plus a password for the new users. By users logging in through entering the account number followed by the password, the DBMS checks the validity of the credentials keyed in and either permits or denies users access to the database (Silberschatz, Korth & Sudarshan, 2006). The DBMS can also consider application programs to be users and require them to log in so as to be granted access to the database. An encrypted table that is maintained by the DBMS and contains two fields, one including account numbers and the other passwords, is used to keep record of database uses, their accounts and passwords. Each time the DBA creates a new account, fresh statistics are introduced to the table and when one is deleted, a corresponding record is also erased from the table. The database system tracks all the operations applied by certain users on the database throughout their login sessions, consisting of the sequence of interactions with the database from the time they log in up to the time they log out. Immediately an individual checks into the system, the DBMS records their account number and associates it with the device the user logged in from and attributes all the operations they apply to their respective accounts until they log out. Of particular importance, the DBMS keeps track of update operations applied by users to the database, which enables the DBA to identify users that temper with the database. The system log is modified in order to maintain a record of the applied updates as well as each user who applies an update. The system log records each entry applied that may be need in the event of recovery from a system crash of transaction failure. As organizations strive to trim down vulnerabilities by adapting new technologies that detect and prevent threats, attackers also create innovative means to achieve their malicious objectives. Consequently, the threat landscape shifts constantly as weaknesses are identified and exploited by the attackers. According to a study conducted by Symantec, it was established that the security threat landscape is characterized by some predominant attacker operations (Silberschatz, Korth & Sudarshan, 2006). First, malicious activities are primarily web-based, and then attackers target end users rather than computers. Thirdly, Underground economies consolidate and mature the quick adaptability of attackers and their activities. The study also revealed that cyber criminals are moving beyond the mass-distribution phishing styles of scams to localizing and personalizing their attacks for easier and more consequential penetrations. When users are permitted database privileges exceeding the needs of the functions of their jobs, the privileges are often abused. For example, employees of a bank may be required by their job functions to only modify contact information of account holders by they may abuse excessive privileges granted to them and increase a colleague’s account balance. Then, when employees leave their employment, their rights of access to sensitive data are not changed immediately and incase they departed on bad terms, they can abuse such privileges and inflict damage or steal data of high value (Beaulieu, 2009). Mechanisms of privilege control that are not defined and controlled effectively can be blamed for cases where users end up with unwarranted privileges and the abuse of legitimate privileges for purposes that are not authorized. For instance, healthcare applications can allow the viewing of individual records of patients through customized Web interfaces. However, the applications usually limit the users to only view a patient’s history and disallow simultaneous viewing of multiple records or making electronic copies, but rogue users can circumvent such restrictions. The attackers can connect to the database by using alternative clients like MS-Excel. When an attacker uses their legitimate credentials to log in with MS-Excel, they can retrieve and store patient records on their laptops and as soon as the records are on a client’s machine, it is vulnerable to a wide scope of possible breach situations. Structured Query Language (SQL) injection can also give attackers unrestricted and unauthorized access to the entire database (Beaulieu, 2009). SQL is typically a special purpose programming language which is designed to manage data stored in a relational DBMS. When SQL is successfully injected, malicious and unauthorized statements are inserted into vulnerable data channels such as stored procedures or Web applications. When the database executes the injected statements, critical stores of data can be viewed, altered or copied. Associated risks of SQL injection include database finger printing, denial of service and bypassing authentication. Database fingerprinting is where attackers are able to determine what database type is used in the backend and then use attacks specific to the database that correspond to particular weaknesses in the DBMS. Denial of service is where attackers flood a server with requests, resulting in the denial of service to authorized users. By bypassing authentication, attackers gain access as though they are valid users of the database and are able to use data they are not authorized to (Beaulieu, 2009). Middleware sitting between users and data also bring forth another category of security issues. When users are only required to provide a single sign during authentication, they are granted access to the entire system by only one password, but the risk is that when the password is stolen, all systems are endangered (Voorhees & Harman, 2005). Because most organizations own several types of databases, they hire the services of third party vendors of databases security who implement database activity monitoring solutions. However, third party vendors have both advantages and disadvantages. When data masking and scrambling is used as a security measure, scrambled and fake data are set up by design, but they can be rather expensive. Data encryption also allows data that is personally identifiable to be scrambled when intruded, but it also adds potential performance issues and overheads (Voorhees & Harman, 2005). Prevention of database intrusion and extrusion looks for odd outbound data, bad access commands and SQL injections, but require very specific set up criteria and are prone to cause performance issues. Third parties also provide solutions that prevent data leakage, catching any data heading out of the system. Protection to data that is actually stored in the data warehouse is not guaranteed. Other than third parties, some systems also have inbuilt solutions that are provided by vendors such as Microsoft, IBM and Oracle. The inbuilt solutions include security logging, password controls, internet protocol (IP) restrictions for out of site access, data access that is based on profiles and roles and auditing capabilities of whoever runs reports. For strong passwords, users need a complex combination of letters, numerals and signs and it is recommended that they change them frequently. This makes them harder to crack or guess by attackers, but users often write them down probably somewhere close to their computers (Voorhees & Harman, 2005). External and internal facing databases also need to be kept separately, which is a feature of inbuilt solutions. That makes it difficult to hack one and then proceed to the other. However, it compromises functionality by restricting internal flow of data. By restricting unwanted connections, organizations make it difficult for attackers to worm through the system, but that also gets into the way of integration by reducing user acceptance (Date, 2003). On top of the security categories and general issues, the number of users of a database and their activities can compound the complexity dimension and security focus. The higher the number of users, networks, applications and databases, the higher the complexity of the interactions one may find within the system (Shasha & Bonnet, 2002). In the same sense, the risks also grow exponentially, which calls for more refined management tasks in order to maintain efficiency and security. For example, when 10 users access any five databases, there are potentially 50 interactions. When the number increases by, say, 45 databases and 90 users, then 100 users will access any out of the 50 databases, which grows the potential interaction up to 5,000. When other networks and applications are added to this example, an apparent complexity which directly proportional to the security risks will be seen. A single security breach from any point within the network will threaten the entire database’s security, users and any other network connected to it (Shasha & Bonnet, 2002). Such a complex example requires flexibility and speed in revoking and granting users to users. When administrative processes and their implementation are delayed, it means legitimate access is wrongly delayed or access that could otherwise be denied is granted. Therefore, when users who had accounts on numerous databases or access to many applications are no longer working for an organization, their access to those accounts and applications must be instantly stopped. But when administrative responsibility and control are distributed across the network and also among different groups and administrators, blocking access instantly may not be possible. This issue can be sorted by having in place an intelligent and central repository which controls data in aspects of authorization, authentication, accounts and identity (Shasha & Bonnet, 2002). The repository then communicates rapidly any information needed to any application or node. It then makes one or more changes in one place that alters all the privileges and rights of access previously granted to a user who is no longer a worker of the institution. As an identity management initiative, the vital depository is based on the hypothesis that the intelligence fed to it and its software addresses such connections and all its considerations. This grants the system greater security since a single control point is inherently more responsive than multiple ones and simpler to secure. It is also more efficient because of it attribute of eliminating inherent delays and duplications automatically in a system that dispersed administrative functions require multiple actions to be applied on the same account. Organizations need to make use of secure application roles in the verification of IP addresses. Roles should also be enabled or disabled promptly, while privileges should be encapsulated in stored procedures (Shasha & Bonnet, 2002). Administrators must use role passwords that users do not know. Conclusion In conclusion, database security needs stem from the requirement to protect data. Data can be seen to be under threat of corruption and accidental loss as well as unauthorized deliberate efforts to access and alter them. Other concerns may arise from the need to protect data against unwarranted delays in accessing and using data or interference to the point of service being denied (Connolly & Carolyn, 2002). Advances in technology and some practices provide dynamic arenas for unapproved exploitation and also new ways for intentional or accidental misuse that are injurious even to stable environments and products. Therefore, specific measures can be recommended for specific security concerns. Organizations need to establish and maintain security measures that address application-level concerns. That can be achieved by attaching roles and privileges to each application and ensuring that users do not abuse the privileges and roles when not working with the application. The use of roles should be based on user-defined criteria. That could mean users being able to connect only from certain IP addresses or middle tier (Date, 2003). Attributes and privileges, which include users, objects and the system, must be managed. Only specific users may be allowed to access and given rights to process and alter data, which includes that right to execute particular SQL statement types or access objects belonging to other users (Beaulieu, 2009). Varying limitations may be applied to different users’ access and action to objects like rows, tables and schemas, This concept of limitation can also be applied to resources like time, and that may be broken down to idle times, connect or the central processing unit (CPU). Another effective measure is to create, control and manage roles associated with the database and enterprise. This can be through creating named privilege groups that will facilitate how members are granted privileges. Establishing granularity of the desired access control entails setting up secure, session-based attributes. An example would be storing user attributes such as employee number and user name that can be retrieved later during a session to enable an access control that is finely grained. Further security dimensions may address physical, personnel, procedural and technical aspects (Lightstone, Teorey & Nadeau, 2007). Computers and devices should be made as physically inaccessible as possible to unauthorized persons by keeping them in environments that are physically secure. Then, personnel charged with the responsibility of the data security, system administration and physical security must be reliable, which can be ensured by conducting background checks on them. The policies and procedures used in operating the system must be capable of assuring reliable data. A good measure is to separate the functional roles of users in data management (Beynon-Davies, 2004). For example, one person may be given the responsibility for backing up the database, and their only role will be ensuring the database is always up and running. Then, another person can be made responsible for the generation of application reports that involve sales data or the payroll. Finally, from the technical aspect, access, transmission, manipulation and storage of data must be guarded through technology which enhances the particular type of information management policies employed by an organization. References Beaulieu, A. (2009). Learning SQL (2nd ed.). California: OReilly. Beynon-Davies, P. (2004). Database systems. Basingstoke: Palgrave. Connolly, T., & Carolyn, B. (2002). Database systems. New York: Harlow. Date, C. (2003). An introduction to database systems. New York: Addison Wesley. Elmasri, R.., & Navathe, S. B. (2010). Fundamentals of database systems (6th ed.) New York: Pearson Addison-Wesley. Kroenke, M., & Auer, D. (2007). Database concepts (3rd ed.). New York: Prentice. Lightstone, S., Teorey, T., & Nadeau, T. (2007). Physical database design: The database professionals guide to exploiting indexes, views, storage, and more. Oregon: Morgan Kaufmann Press. Oppel, A. (2004). Databases demystified. California: McGraw. Shasha, D., & Bonnet, P. (2002). Database tuning: Principles, experiments, and troubleshooting Techniques. Oregon: Morgan Kaufmann Press. Shekhar, S., & Chawla, S. (2003). Spatial databases: A tour. New York: Prentice. Silberschatz, A., Korth, H., & Sudarshan, S. (2006). Database system concepts. California: McGraw-Hill Voorhees, E., & Harman, D. (2005). TREC Experiment and Evaluation in Information Retrieval. New York: MIT Press. Read More