Securing SQL Anywhere Server 10


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Securing SQL Anywhere Server 10

  1. 1. Securing SQL Anywhere Server 10 A whitepaper from iAnywhere Solutions, Inc., a subsidiary of Sybase, Inc.
  2. 2. Copyright © 2006 iAnywhere Solutions, Inc. Contents Introduction 3 Why bother with security? 4 Pre-installation security procedures 5 Securing the physical machine . . . . . . . . . . . . . . . . . . . . . . . . 5 Network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Securing the operating system . . . . . . . . . . . . . . . . . . . . . . . . 5 Securing mobile devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 IT policies and procedures regarding mobile devices . . . . . . . . . . . . 8 Database access and permissions 9 User accounts and permissions . . . . . . . . . . . . . . . . . . . . . . . . 9 Integrated logins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Kerberos authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Directory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 User password policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Using a custom login procedure . . . . . . . . . . . . . . . . . . . . . . . 12 Disabling database features . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Securing access to SQL Anywhere utilities . . . . . . . . . . . . . . . . . 14 Debugging database activity . . . . . . . . . . . . . . . . . . . . . . . . . 16 Securing SQL Anywhere configuration files . . . . . . . . . . . . . . . . . 17 Database auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Securing backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Securing web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Data protection with encryption 21 Encryption types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Communication encryption 27 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Digital certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Enabling communications encryption . . . . . . . . . . . . . . . . . . . . . 30 Performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 SQL injections 32 Preventing SQL injections . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Injections in the URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Conclusion 34 Appendix A: SQL Anywhere security checklist 35 Appendix B: Guidelines for strong passwords 36 Appendix C: Social engineering 38 Appendix D: Sample password verification function 39 1
  3. 3. Copyright © 2006 iAnywhere Solutions, Inc. Legal Notice 45 Contact Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2
  4. 4. Copyright © 2006 iAnywhere Solutions, Inc. Introduction In today’s IT world, where computers and computer-enabled devices are a crucial part of any business, it has become a necessity to ensure that proper information security practices are implemented. With businesses storing more and more data about their daily activities in electronic form, failing to enforce proper security procedures can lead to unwanted problems and expose a business to unnecessary danger. When it comes to information security, it is crucial to pay attention the component of IT infrastructure that actually stores and transmits information—the database server. Failing to secure a database server can make it the weak link that an unauthorized person can exploit to obtain crucial business data. Also, data communications into and out of the database server have to be properly secured to prevent instances of eavesdropping and intentional data corruption. The biggest security breaches to receive national media attention in recent months have all involved the loss or theft of sensitive, personal data. Examples include the U.S. Health and Human Services department, where Social Security numbers and other personal information for nearly 17000 Medicare beneficiaries could have been compromised when an insurance company employee called up the data through a hotel computer and then failed to delete the file. Such incidents not only tarnish the name and reputation of the organization involved, but also pose a very real danger of identity and financial theft. This whitepaper first discusses the security infrastructure that is required to prevent unauthorized access to business data, and then focuses on the steps needed to secure a SQL Anywhere 10 database server installation properly. SQL Anywhere 10 is a leading database in the small to medium enterprise database market, as well as a leading database offering for mobile devices. With its strong mobile solutions, it is important to pay attention to securing the database server itself, as well as the communication transmissions between the database server and mobile databases. Not all of the techniques and methods described in this paper lend themselves to both a mobile and a server environment. For example, physical security of hardware is a much more difficult problem with mobile devices than it is with server or desktop hardware. There are four general areas that must be addressed in order to secure a SQL Anywhere 10 database: ♦ Pre-installation security This encompasses the physical and network security of the server running the database, as well as the security of the underlying operating system. ♦ Database access and permissions You should pay the most attention to this area because securing a database largely involves securing access to it. This includes user accounts and permissions, authentication methods, password policies, backup security, and so on. ♦ Database encryption For maximum security, a database should always be encrypted with a strong encryption key. 3
  5. 5. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Communication encryption No matter how secure a database file is, once it starts sending data over a network, that data becomes susceptible to interception and abuse. It is recommended that you use the built-in transport-layer security in SQL Anywhere to encrypt communication and secure traveling data. Why bother with security? With the rise of the Internet and corporate computer networks, information has become a key commodity for businesses. The loss of information can, in some cases, result in incredible difficulties for a business. As a result, most enterprises are at least aware of (or have in place) security procedures and preventative measures to deal with the very real threat of data theft and/or loss. This raises the question of how much a security-conscious organization should spend. The answer to this question is not simple, because in addition to the primary, tangible results of information security spending, there exist secondary, invisible costs. Although the primary costs associated with information security are not small in most cases, it is the secondary costs that should be considered far more carefully. It is the secondary costs that determine the size of the primary ones. Primary security costs include the quantifiable charges a business will incur while increasing its preventative measures. These can include security personnel, administrative personnel, cost of facilities, cost of computer equipment, security consultant costs, physical security measures, and so on. It is estimated that businesses spend approximately 30% of their IT budgets on security. The total amount of primary costs can run into the millions of dollars for large enterprises. Secondary costs are future, worst-case-scenario costs. Because of their more intangible nature, these costs can never be measured perfectly. They are the costs that the business may incur in the case of data loss or theft. These vary greatly with the amount and type of data stored, but are never zero, and could potentially lead to the death of the business. These costs include the following: ♦ Time No matter what type of data is lost/stolen, the amount of time to get that data is always a cost. This includes public stores of data that are widely available because you still have to make sure that the integrity of the data has not been compromised. ♦ Legal costs A business may be legally obligated for the customer data it stores (depending on country or state law). In the case of a lawsuit due to data loss, the costs to a business could be massive. Besides a possibly large settlement, there are also extensive legal fees involved in any court case. ♦ Lost opportunity costs Data loss usually results in downtime. Even if downtime is minimized because proper backups are made on a regular basis, in today’s information and Internet-driven world, downtime is equivalent to loss of productivity in terms of time or sales, both of which are non-recoverable. ♦ Lost credibility A breach in security can cause stakeholders (such as 4
  6. 6. Copyright © 2006 iAnywhere Solutions, Inc. employees, customers, or partners) to lose trust, and regaining that trust can be a difficult and time-consuming process. In the end, it is up to the business to determine the amount that should be spent on primary security costs. To do this properly, the worst-case scenario secondary costs have to be kept in mind. When it comes to information security, prevention is not only better than the cure, but it can mean the difference between survival and bankruptcy for the enterprise. Pre-installation security procedures This section outlines steps that are taken outside of SQL Anywhere that help increase the security of the database server. These steps deal with general server precautions, operating system security, and so on. Securing the physical machine Securing any server setup has to begin with the physical nature of the server. No matter how protected the server software is, most software security measures are ineffective if an unauthorized person has physical access to a machine. Besides hardware theft, a number of software tools are available for gaining administrator privileges on a server, which can subsequently be used to perform various malicious activities. Therefore, it is imperative that any database server is stored in a physically protected location, such as a secure server room, which requires specific entry credentials. Also, the server room should ideally have flood detection, as well as fire detection and fire suppression systems. Network security After the server is physically safe, the issue of securing network access to the server needs to be addressed. First of all, the database server should not be directly exposed to the Internet. Data should always be accessed through middleware software systems, so that the connection mechanisms to the database are never exposed. For example, when SQL Anywhere MobiLink database synchronization is used, the mobile devices themselves are by default unable to talk to the database directly, and instead have to communicate with a MobiLink server, which then talks to the backend database server. Most businesses are aware of the need for proper firewalling. It is imperative that firewall policies be as conservative as possible, only allowing communication with an internal network computer. Holes should not be punched in the firewall (such as exposing the default SQL Anywhere connection port 2638) without careful consideration. Securing the operating system The operating system running the database server should be dedicated solely for 5
  7. 7. Copyright © 2006 iAnywhere Solutions, Inc. that purpose. Disable all unnecessary services and daemons (FTP, Telnet, and so on) to eliminate the possibility of unauthorized access to the database because of a security flaw in another piece of software. Finally, all relevant security updates for the operating system need to be downloaded and installed on a regular basis. Also, care should be taken with respect to operating system user accounts. Only users with administrator privileges should be allowed to have access to the database executables and data files. Moreover, if network authentication is used, the database server should not be started using a local (non-network) user account. Permissions to start and stop processes should also be tightly controlled to prevent users from intentionally or accidentally stopping the database server. Securing mobile devices Using mobile devices can pose a significant security danger for a business if you do not take proper security precautions. This danger increases significantly if a mobile device is able to access data remotely that is contained in a business’s database. To avoid the possible problems that mobile devices can present, while reaping the numerous benefits that they provide, such devices have to be secured in the following three areas. Access to the device Because of their small size, mobile devices are easily lost or stolen. According to experts, when it comes to security threats against data on mobile devices, malware, viruses, and worms still don’t come close to loss and theft. Therefore, it is imperative that proper preventative measures are taken to ensure that in the event of an unauthorized user gaining access to a mobile device, they are unable to use that device in any malicious way. In this area, the primary focus falls on implementing strong and conservative authentication procedures to protect a mobile device against unauthorized access: ♦ Operating system power-on passwords This is a feature that is available in most mobile operating systems today. This is the most basic form of mobile device security, but it is also one of the most effective. Contemporary operating systems also have built-in punishment features if a system password is entered incorrectly, such as Windows Mobile increasing the delay between successive password entries, or Blackberries erasing all data on the device after 10 such unsuccessful attempts. ♦ Remote device management This refers to the ability of network administrators to change the security options on mobile devices remotely without user intervention. Not implementing this feature could result in some mobile devices having less stringent security policies than the rest of the organization. ♦ Application-level security Although a mobile device should have a system, power-on password, it is highly recommended that execution of all crucial applications be password protected as well (if such an option is available). 6
  8. 8. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Certificates Mobile devices today usually support the storage of certificates for authentication purposes. This can be extremely useful when you are adding and removing the login privileges of a certain user or group of users remotely. ♦ Non-traditional authentication In recent years a number of non-text-password options have surfaced, particularly because of the growing mobile sector and the more realistic appreciation of the dangers facing mobile authentication. These methods can either replace or work in tandem with traditional password practices to increase the security quotient of a mobile device. They include: signature authentication, picture-based passwords, fingerprint authentication, and Smart Card/SecurID Card authentication. Access to the data stored on the device Although securing device accessibility is an important step to preventing unauthorized access, the use of removable media such as flash or USB drives makes it vitally important to protect the data contained on the device itself. This becomes the only defense if the authentication protection of the device itself is circumvented (via password cracking or stealing) or is non-existent. Securing access to data primarily involves data encryption. SQL Anywhere includes strong encryption capabilities to protect the data it stores. In general, however, it is also recommended that you encrypt other files on the mobile device for increased protection. This includes encrypting the data on storage mediums, as well as data stored in RAM during normal operation to prevent data snooping. Access to the company network Having strong security policies for network access is also an important consideration. This area has two facets: securing access to the corporate network and securing communication with the corporate network. Any corporate network should have security features in place to ensure that only devices that are deemed friendly are allowed to connect to it. This prevents employees from connecting their personal devices to the network and also decreases the chance of corporate espionage (for example, someone hiding a mobile device that can connect to the network and gather data automatically). You can restrict access to the company network through such measures as dial-up passwords, network authentication protocols for secure web sites, and VPN authentication. It is also vital that, after successful network authentication, all traffic between the device and the network be encrypted. SQL Anywhere provides transport-layer security (TLS) by encrypting communications using approved industry standard algorithms that are extremely difficult and time consuming to decrypt given existing technology. Although the business data communication between mobile and consolidated deployments of SQL Anywhere can be considered secure, network and system administrators have to make sure that all other communication with a mobile device is also protected. Therefore, all critical applications should support native encryption of communication data. If the 7
  9. 9. Copyright © 2006 iAnywhere Solutions, Inc. mobile device is able to connect to a VPN, all communication should be encrypted with industry-standard, proven encryption techniques. iAnywhere Afaria When considering mobile device security, iAnywhere Afaria can help resolve many of the abovementioned issues. Afaria is the industry leading total mobile device management solution that covers all of the security areas discussed above, from patch management and security management, to remote control and network security. Afaria assists the enterprise in the following areas of mobile IT management: ♦ Security Afaria provides the following features to increase device security: • Patch management Afaria provides precise control over which patches are deployed and where they are deployed. Patch distribution is automatic and exact logs are kept. • Security management Afaria provides full disk encryption combined with the ability to set power-on passwords, automatic certificate rollout, secure full system data deletion, remote reset capabilities, and so on. • Data backup Afaria provides automatic backup and restoration of data, profiles, and configurations for remote devices. ♦ Process automation Afaria automates and schedules processes, such as file transfers and hard disk checks. ♦ Data and content management Afaria allows for easy and secure document distribution and control, as well as synchronizing to and from various document formats. ♦ Systems management extensions Afaria lets you control the software settings on all mobile devices from company headquarters, using a single console. ♦ Software and inventory management Afaria provides comprehensive capabilities for managing software installations, licensing, updates, rollbacks, and remote control. IT policies and procedures regarding mobile devices Besides securing access rights to mobile devices and their data, an IT department should have a solid set of policies and procedures in place to manage their mobile inventory, and to make sure that all users are educated on their responsibilities with regard to hardware assigned to them. Implementing policies and procedures like the following ultimately benefits the security of the organization as a whole: ♦ Maintain an inventory of all company mobile devices and who currently has possession of them. ♦ Implement remote patch management procedures. This will allow you to patch devices in groups, reducing the risk that a device is left without the necessary security bug fixes. 8
  10. 10. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Establish procedures to disable the remote access rights of any mobile device that is lost or stolen. These should also include measures to erase all user authentication information that the device contained (such as passwords). ♦ Erase all data from mobile devices that are not in use or when such devices change ownership, or are lost or stolen. This minimizes the amount of data that could be compromised if the device is stolen. ♦ Use the services of third-party companies that specialize in the retrieval of lost mobile devices. ♦ Standardize the software applications installed on company mobile devices and restrict the user’s ability to install additional software. Database access and permissions This section outlines how database accounts should be configured for secure database operations. User accounts and permissions User IDs should be created for every unique user (given a small number of users) or role (if a large number of people are connecting to the database). This allows the DBA to fine tune the permissions that each user ID has in order to restrict what that user can do in the database. Having unique user IDs also simplifies the process of determining which user was responsible for a certain action. See “Database auditing” on page 18. In order to secure a SQL Anywhere database server, the following issues must be addressed: ♦ Restrict DBA authority Users with DBA authority have the power to do anything on a database server. DBA authority is generally not needed for normal user activity and poses a security threat if it is assigned carelessly. Also, the DBA login credentials should be kept very safe, known to only a handful of people who have legal obligation not to divulge such information. ♦ Starting databases By default, any user can start a database on a running database server. Use the -gd option to set the permissions required to start and stop databases. For more information, see the -gd server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-gd-database-dbengine.html. ♦ Creating databases By default, any user can create a database with the CREATE DATABASE statement. Use the -gu option to set permissions required to create databases. For more information, see the -gu server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-gu-database-dbengine.html. 9
  11. 11. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Stopping the database server By default, any user can use the dbstop utility to shut down a database server. Use the -gk option set the permissions required to stop the database server. For more information, see the -gk server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-gk-database-dbengine.html. ♦ Loading and unloading data The LOAD TABLE, UNLOAD TABLE, and UNLOAD statements all access the underlying file system of the server. This could potentially be a security issue, and it is recommended that access to the above statements is restricted using the -gl command. For more information, see the -gl server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-gl-database-dbengine.html . ♦ Revoke all non-crucial permissions Using the GRANT and REVOKE statements, do not give users and groups permissions which they do not need for their normal day-to-day work. For more information, see GRANT statement and REVOKE statement in SQL Anywhere Server - SQL Reference, or html/dbrfen10/rf-grant-statement.html. Integrated logins Integrated logins allow users to use a single login name and password to log on to both your Windows operating system and onto a database. An external login name (or user group) is associated with a database user ID. Integrated user IDs can bring a number of security advantages. First, if a user ID is integrated into SQL Anywhere, that user does not need remember a database user ID and password. Besides the obvious ease-of-use for the user, the user never knows an ID and password combination that can be used to compromise the database (intentionally or accidentally). This also allows the DBA to grant or remove a user’s database access permissions very quickly. Moreover, since a whole group of Windows users could be configured to log in with a single database user ID and password, user account administration becomes easier for the DBA. You need to take some precautions when using integrated logins to minimize security problems in Microsoft Windows. First, the Guest user account in Windows should be disabled. The Guest user account has no password, and if the integrated logins are not configured properly, a malicious user could gain database administrator access rights to the database server. Also, if the Windows operating system is compromised and user login information is stolen, a malicious user could gain unrestricted access to a database. For more information about integrated logins, see “Using Integrated Logins” in SQL Anywhere Server - Database Administration, or 10
  12. 12. Copyright © 2006 iAnywhere Solutions, Inc. html/dbdaen10/da-using-an-integrated-login.html. Kerberos authentication SQL Anywhere supports Kerberos authentication. Kerberos is a network authentication protocol that provides strong authentication and encryption using secret-key cryptography. SQL Anywhere can use Kerberos for authentication in a manner similar to Windows integrated logins. Users who have already logged in to Kerberos can connect to a database without providing a user ID or password. Kerberos logins offer the convenience of a single security system, but there are important security implications that database administrators should be familiar with (such as a single point of failure and clock synchronization). For more information about Kerberos authentication logins, see “Using Kerberos Authentication” in SQL Anywhere Server - Database Administration, or html/dbdaen10/da-connect-s-5294913.html. Directory services SQL Anywhere has built-in LDAP support, allowing the querying of LDAP directory services to find database servers. Client databases can use the Server Location utility (dblocate) to query a directory service to find a consolidated database without knowing its exact network address. For example: dblocate customerDatabaseServer One reason directory services with LDAP access have become commonplace in today’s enterprises is because of the increased security they provide. Directory services allow for easier user, resource, and security policy management, as well as the ability to effectively hide the network IP information of a database server. Although finding databases with the dblocate utility has a number of advantages from a management perspective, sometimes it is preferable to hide a database server from being discovered by the utility. For this, use the -sb option when starting the database server. For more information, see the -sb server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-sb-database-dbserver.html. User password policies Weak passwords are often referred to as the Achilles heel of many computer systems. When it comes to the passwords used to access a database server, the place containing vital data for the survival of a business, a password that is easy to guess could bring about disastrous consequences. The following techniques can help improve password security: 11
  13. 13. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Minimum password lengths The longer a password is, the more difficult it becomes to crack it using computer-based password guessing programs because of the increasing number of possible character combinations. You can set the minimum password size using the min_password_length option. For example, the following sets the minimum password length to 8 characters: SET OPTION PUBLIC.min_password_length = 8 ♦ Enforce password management policies All users should be made aware of a company’s acceptable password policies (such as complexity and randomness) and such policies should be strictly enforced. You can use the password verification option verify_password_function to make sure that user passwords conform to safe standards. For more information about choosing secure password guidelines, see “Appendix B: Guidelines for strong passwords” on page 36. For a sample password verification function, see “Appendix D: Sample password verification function” on page 39. ♦ User password expiration You can also use the verify_password_function option to specify a time period after which a password becomes invalid. This increases database security in the event that an old password, already automatically disabled, is compromised. For an example of such an implementation, see “Appendix D: Sample password verification function” on page 39. ♦ Change the default DBA password The default password for the database DBA (administrator) account is sql. This should be changed immediately after database creation, and before a database server is set up to accept connections over the network. To maximize security, a new user ID should be created with DBA permissions (and a sufficiently strong password), and the built-in DBA account should be disabled. ♦ Do not include passwords in ODBC data sources When you create an ODBC data source, you are given the option to store the data source password. Avoid storing such passwords to achieve greater security. ♦ Limit the number of failed login attempts You can leverage features such as login procedures to limit the number of unsuccessful login attempts for a user. Once that number is reached, the user account should be locked out and an administrator contacted to address the problem. Using a custom login procedure To develop more detailed control over login permissions to the database server, you can create a stored procedure that is called automatically whenever a user attempts to log in. This is done using the login_procedure option and can help further secure a SQL Anywhere database server. For more information about setting up a custom login stored procedure, see the login_procedure option in SQL Anywhere Server - Database Administration, 12
  14. 14. Copyright © 2006 iAnywhere Solutions, Inc. or go to sqlanywhere/1000/en/html/dbdaen10/da-login-procedure.html. The following SQL example shows how you can disallow a connection by signaling an INVALID_LOGON error: CREATE PROCEDURE DBA.login_check() BEGIN DECLARE INVALID_LOGON EXCEPTION FOR SQLSTATE ’28000’; // Allow a maximum of 3 concurrent connections IF( DB_PROPERTY(’ConnCount’) 3 ) THEN SIGNAL INVALID_LOGON; ELSE CALL sp_login_environment; END IF; END go GRANT EXECUTE ON DBA.login_check TO PUBLIC go SET OPTION PUBLIC.login_procedure=’DBA.login_check’ go Disabling database features If certain features are not needed in the database server in your environment, use the -sf server option to disable them. Once disabled, these features are not available to client applications, stored procedures, triggers, or database events. These features can be enabled again at runtime if the -sk option is used to start the server. You can disable specific features, or groups of features, as described in the documentation. For maximum security, it is recommended that you consider disabling the following groups of features using the -sk option when starting the server: ♦ local_call Disables all features that provide the ability to execute code that is not directly part of the database server and is not controlled by the database server. This set consists of the cmdshell, external_procedure, and Java features. ♦ local_db Disables all features related to database files. This set consists of the backup, restore, database, and dbspace features. In this case, backups could be performed when the database is offline. ♦ local_io Disables all features that allow direct access to files and their contents. This set consists of the xp_read_file, xp_write_file, directory, load_table, and unload features. ♦ local_log Disables all logging features that result in creating or writing data directly to a file on disk. This set consists of the request_log and log_file features. When disabling features with the -sf option, be sure to use the -sk option to specify a key to enable some of these features later on if needed. 13
  15. 15. Copyright © 2006 iAnywhere Solutions, Inc. For more information and the complete list of detailed features and groups of features that can be disabled, see the -sf server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-dbserver-s-3752812.html. Securing access to SQL Anywhere utilities The SQL Anywhere utilities are downloadable, and so must be considered available to any user who wants them. It is important to consider the potential effects these utilities can have in relation to the security of your database. The following utilities require a database connection with elevated permissions. By restricting user permissions, you can limit the potential security problems you could have with them. Utility Security concern dbbackup The Backup utility could allow a malicious user to create a backup copy of the database, which could allow them to crack the encryption key at their leisure. dbinfo The Information utility shows information about a database. This information could aid an attacker in breaking the security measures that have been put in place. dbinit The Initialization utility could allow a malicious user to create a database, which could potentially be loaded on a running server and result in increased resource usage and less disk space. dbstop The Stop Database utility could allow a malicious user to stop a database, resulting in unnecessary downtime. dbunload The Unload utility allows one to save database schema and data in comma-delimited (.csv ) format. This could expose important data to a malicious user. dbconsole The SQL Anywhere Console utility could provide an attacker with information about database connections and properties. Such information could be used to compromise a database server. dbisql The Interactive SQL utility (GUI or command line) could allow a potential attacker to execute arbitrary SQL statements against the database with negative consequences. Sybase Central Sybase Central is a GUI management tool that allows access to all aspects of a database, including wizards designed to provide the same functionality of the abovementioned utilities. A user who gains access to login credentials could use this tool to view and alter any part of the database. 14
  16. 16. Copyright © 2006 iAnywhere Solutions, Inc. The following utilities require no database permissions. Access to the database file is all that is required to use them. In a server environment, securing the physical server and database file is the best way to prevent compromising your data. In a mobile environment, different considerations must be made. For example, dbtran is a key utility that does not require a user ID or password to access it. Using this utility, a user can translate to SQL all statements contained within that transaction log file. There are some options that can be used (possibly in combination) to prevent this: ♦ Encrypt the database file An encrypted database file requires the to user know the encryption key to translate the transaction log file. ♦ Use frequent backups Design your backup procedure to back up and truncate the transaction log frequently. This keeps the transaction log files in a separate directory and limits the size of the live transaction log file. The backup directory should be encrypted using file system encryption to further protect them from dbtran. ♦ Truncate the log at checkpoint Use the -m option on the database server. This truncates the transaction log when a checkpoint occurs, limiting the amount of data in the log file. This option limits recoverability, and it is not recommended. ♦ Manage your mobile devices Use IT policies and procedures to manage remote data. For example, tools like iAnywhere Afaria can be used to remove data remotely to limit what a malicious user can do. Utility Security concern dbdsn The Data Source utility could allow a malicious user to locate other SQL Anywhere databases on the network easily. Such a user could also modify or delete existing data sources, thus creating problems in the application layer. dberase The Erase Database utility could allow a malicious user to delete vital database files, which can result in data loss. dblog The Transaction Log utility could be used to change the name of the transaction log file associated with a database or disable the transaction log altogether. This could lead to data loss and/or performance degradation. dbtran The Log Translation utility could allow a malicious user to generate SQL statements to recreate a database, based on a transaction log file of the database. This is especially dangerous if the transaction log files are not encrypted. The following utilities do not require access to the database file at all. All they require is network connectivity to run. Malicious use of these utilities simply involves finding and identifying potential targets for attack. 15
  17. 17. Copyright © 2006 iAnywhere Solutions, Inc. Utility Security concern dblocate The Server Enumeration utility could allow a malicious user to find other database servers in the immediate network. dbns10 The DBNS Broadcast Repeater utility could give a potential attacker information about additional database servers present on the same and different subnets. For more information on these tools, see “Administration utilities overview” in SQL Anywhere Server - Database Administration, or html/dbdaen10/da-sql-anywhere-components-overview.html. Debugging database activity SQL Anywhere provides a number of features for debugging database activity. These can be useful in determining the status of the database server and what SQL statements were passed to it. Although providing useful functionality, you have to be careful with these features because they could be exploited to gain access to important information. Database request log The SQL Anywhere request log records all requests made to the database server. Logged information includes such things as timestamps, connection IDs, and request type. For queries, it also includes isolation level, number of rows fetched, and cursor type. For INSERT, UPDATE, and DELETE statements, it includes the number of rows affected and the number of triggers fired. Sensitive information, such as login data, is not logged in the request level log. DBA authority on a database running on the server is required to turn on request logging on a running server, but any user can start a new database server with request logging enabled. The request log should only be used when trying to diagnose a database-related problem because it cannot be encrypted and records all information in plain text. This could allow a potential intruder to determine the exact calls an application makes to a database, and they could then exploit this information to gain unauthorized access. When the request log is in use, the following recommendations should be followed: ♦ Delete all request logs as soon as they are no longer needed. ♦ Specify a maximum size for the request log to minimize the amount of data compromised in the event of a security breach. The size of the request log file is limited using the -zs option. For more information, see the -zs server option in SQL Anywhere Server - Database Administration, or go to html/dbdaen10/da-zs-database-dbengine.html. 16
  18. 18. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Take advantage of application profiling, which allows you to store request log output in a different, tracing database. This is a new feature in SQL Anywhere 10 and provides additional security by allowing the tracing database data to be encrypted (whereas if request log information is saved to a file, that file is not encrypted). For more information, see “Tracing session data” in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbugen10/ug-perform-s-3238494.html. Server Messages window The Server Messages window displays status information about a SQL Anywhere database server. On Windows computers, the icon in the system tray is the only visible indication that the database server is running. For maximum security, you should disable the Server Messages window when starting the database server by specifying the -qw option. Then, there is no visible indication that the database server is running, which might fool a potential attacker. For more information, see the -qw server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-dbserver-s-6270173.html. Securing SQL Anywhere configuration files The security of the database server’s configuration files should also be considered. If a malicious user is able to get a copy of these files, they could determine a weakness that could later be used to exploit the server. With SQL Anywhere, configuration files can be used to simplify database server startup by saving all required options and parameters in a file that is later passed to the database server with the @data option. This can simplify server startup (especially when multiple parameters are needed) and store important information. Since you can store sensitive information in configuration files, it is 17
  19. 19. Copyright © 2006 iAnywhere Solutions, Inc. important to use the File Obfuscation utility (dbfhide) to disguise the contents of such configuration files. Using dbfhide uses simple encryption methods to make it more difficult to understand what information is stored in the file. Simple encryption is an internally developed encryption method that is equivalent to obfuscation. It is not as secure as industry standard strong encryption algorithms such as AES. You should not store sensitive information (such as encryption keys) in configuration files, even if dbfhide is used. Access to configuration files should also be secured via operating system user permissions to administrator users only. Database auditing Auditing is a way of keeping track of the activity performed on a database. The record of activities stays in the transaction log. The SQL Anywhere database server keeps a transaction log for each database, which records all transactions which modify the database. This is used to ensure data integrity and recoverability. When database auditing is enabled, the server adds security-related information to the transaction log, which can be examined at any time. Auditing information can help identify malicious behavior by logging information about when a user attempted unauthorized access to the database. In the case where the user (or user group) did not actually attempt the unauthorized access, this could signify a breach of database credentials and should be addressed immediately. By turning auditing on, the database increases the amount of data saved in the transaction log to include the following: ♦ All login attempts (successful and failed), including their IP addresses. ♦ Accurate timestamps of all events (to a resolution of milliseconds). ♦ All permissions checks (successful and failed), including the object on which the permission was checked (if applicable). ♦ All actions that require DBA authority. Auditing is off by default, and has to be turned on explicitly by issuing the following command: SET OPTION PUBLIC.auditing = ’On’ After this, auditing remains on until it is turned off. You can retrieve database audit information by using the Log Translation utility (dbtran) that comes with SQL Anywhere. It can be used to extract audit information while the database server is operational or from a specific transaction log. If the log file is not encrypted, a malicious user could use it to generate all the SQL statements needed to create a complete copy of the database. See “Securing access to SQL Anywhere utilities” on page 14 for information about protecting your data from unauthorized access by the SQL Anywhere utilities. 18
  20. 20. Copyright © 2006 iAnywhere Solutions, Inc. Performance analysis of database auditing Enabling database auditing impacts performance because it can cause extra logging information to be generated whenever the user accesses the database. When comparing the performance of databases with and without auditing enabled, the following was found: During insertion of data, databases with auditing disabled performed about 14% faster than databases with logging enabled. This test was based on an insertion simulation where 200000 rows were inserted into a single table on a Pentium 4 2.4 GHz system with 1024 MB RAM. During retrieval of data, databases with auditing disabled performed about 14% faster than databases with logging enabled. This is based on a retrieval simulation where 200000 rows were retrieved from a single table on a Pentium 4 2.4 GHz system with 1024 MB RAM. Securing backups The security of database backups is often overlooked, with most security efforts channeled towards the live database. Backups, however, are just as crucial since they contain most, if not all, of the same data as the production database. If backup security is overlooked, a malicious individual can bypass the expensive security measures that might be in place to protect the live database by just obtaining a copy of a backup. This section outlines a number of backup security issues that need to be considered. Physical protection When it comes to the physical security of a backup system or backup records (such as tapes), the same level of care should be in place as with the production database system. Moreover, if an off-site backup location is used, that location should be protected 24 hours a day, 7 days a week by professional security personnel. If the data is transported manually (that is, not over a network), the transport method should be secured proportionally to the value of the data being transported. For crucial enterprise data, it is recommended that a security service be brought in to provide industry-grade transport vehicles and professionally-trained personnel. Network backup procedures Network backups can made by a simple copy of the database files, the dbbackup utility, the dbbackup API, or the BACKUP DATABASE SQL statement. Using the provided backup utilities provides a key benefit with regards to security. The backup utilities are executed over a standard database connection, and so TLS (transport layer security) can be used to protect the data in transit over the network. Moving backup copies of the database files over the network requires a different set of precautions. Ideally, if the data is strongly encrypted in SQL Anywhere 19
  21. 21. Copyright © 2006 iAnywhere Solutions, Inc. (which is recommended), it should first be decrypted and then extracted from the database. It should then be compressed (for faster transport) and re-encrypted for the duration of the data movement. Upon arrival at the backup system, the data must then be decrypted and encrypted again using the backup encryption key (which should be different from the live database encryption key) before finally being saved to the backup storage medium. Backup encryption The stored backup copies should be kept in an encrypted state, with a special backup encryption key that is used for that purpose only. Given the rare (when compared to a live database) usage of backed up data, the backup copies could be encrypted with more complex algorithms and longer and more complex encryption keys. The data could further be doubly-encrypted, (which is impractical for production systems), but is appropriate in this situation. Securing web services SQL Anywhere includes a built-in HTTP server that can be used by client applications to access web services stored in the database. This simplifies user requests for data, as a standard HTTP call returns the necessary information, while also removing the need for a direct connection with the database (such as an ODBC connection). Access to data via web services needs to be secured, otherwise, anyone can to connect to a web service and see the data it returns. The following things are important to consider if you are using web services in the database: ♦ Authentication When accessing a web service over HTTP, users should not be required to supply database login information, because this information is sent in the clear. For example, the following HTTP URL would log in the user with user ID DBA and password sql into service serviceName: http://DBA:sql@localhost:8080/serviceName Any malicious user listening would see the user ID and password in the clear in the URL when it is sent and database security would be compromised. If user authentication is required for access to the web service, HTTPS should be used in place of HTTP to ensure all of the URL information is encrypted. SQL Anywhere gives you the option to run all service queries as a specified user after a user logs in (regardless of the actual user access permissions). Care should be taken when using this feature, as it may result in additional data loss if a user account is compromised. ♦ Use secure connections SQL Anywhere web services support both HTTP and secure HTTPS connections. For maximum security, especially when data is sent over the Internet, it is highly recommended that your web services use HTTPS connections. ♦ Parameters SQL Anywhere allows you to pass parameters to your web services to provide additional information necessary for the execution of the 20
  22. 22. Copyright © 2006 iAnywhere Solutions, Inc. SQL query associated with the service. Proper security measures have to be in place to avoid possible malicious attacks. See “SQL injections” on page 32 for more details. To avoid these attacks, all parameters have to be strongly typed and all parameter values should be checked for correctness before being used in SQL queries against the database server. Data protection with encryption SQL Anywhere allows the data contained within its databases to be encrypted to prevent unauthorized users from viewing that data by using external tools (such as hex editors). While it is recommended that you encrypt any non-trivial data within the database, it is up to the DBA to determine if encryption is required, and the degree to which data is encrypted. Performance overhead of encryption can vary (as described below), and a balance should be achieved between security and operational performance. Encryption types SQL Anywhere supports two types of data encryption: simple encryption and strong encryption. Simple encryption secures the data by applying an obfuscating algorithm to it. Although not as secure as strong encryption, simple encryption will prevent someone who is using a disk utility from easily deciphering the data in the database. Simple encryption has one advantage over strong encryption—performance. Simple encryption adds minimal overhead to unencrypted data retrieval and insertion. Strong encryption within SQL Anywhere is based on the Advanced Encryption Standard (AES) algorithm for block ciphers chosen by the National Institute of Standards and Technology (NIST). It uses a user-specified key to encrypt the data in the database and transaction log such that if the original key is not provided, the data cannot be decrypted. Strong encryption in SQL Anywhere is also available on some platforms using a Federal Information Processing Standards (FIPS) approved implementation of the AES algorithm. In order to encrypt databases with AES_FIPS, a separately licensed component must be obtained. For more information, see Keeping Your Data Secure in SQL Anywhere Server - Database Administration, or html/dbdaen10/da-encrypting-security-database.html. Strong encryption keys and algorithms When it comes to choosing secure encryption keys, the same principles apply as with selecting secure passwords (see “Appendix B: Guidelines for strong passwords” on page 36). Once a key is chosen, a copy of it should be kept in a physically-protected location because if it is lost, the data in the database, the 21
  23. 23. Copyright © 2006 iAnywhere Solutions, Inc. database log files, and the database mirror files (if available) are completely inaccessible. Starting an encrypted database requires the entry of the encryption key, so it is recommended that only one person (the DBA) is able to start the database. This avoids multiple people having knowledge of the encryption key and decreases the chance of a security breach (for example, due to social engineering methods). In addition, the encryption key should not be specified on the database server command line. Most operating systems provide ways of viewing the command line of running processes, and so your key could easily be compromised. Instead, start the database server and connect to the utility database, and then use the start database command to start your database, specifying the key in the start database command. For embedded applications, if you do not want to share the encryption key with your users, there are a few options that you can consider for hiding the key: ♦ Store the key embedded in the application somewhere This is not usually recommended due to the ease of finding the key, but it is very easy to implement and would prevent an average user from finding it. ♦ Come up with an algorithm that can be used to derive the key at runtime The key does not have to be stored on the machine, but the key generation algorithm must be protected. The algorithm should generate a different key for each machine, user, database, and so on, where the database is kept ♦ Hide the key in INI files or the registry on Windows This also isn’t recommended since it is easy to snoop these values with operating system utilities. However, it is easy to set up and can be effective for deterring average users. ♦ Use a web service to retrieve the key If the application requires Internet access, or if Internet access is always available, an HTTPS web service could be written that the application could call to retrieve the key before starting the database. ♦ Use a built-in encryption API On Windows, consider using the built-in encryption APIs like CryptProtectData and CryptUnProtectData to store an encrypted form of the database key. For more information about social engineering, see “Appendix C: Social engineering” on page 38. Encryption options for creating databases The following command line options are used to enable database and table encryption when creating your database using the Initialization utility (dbinit): ♦ -e This option is used to create a database with simple encryption (obfuscation). ♦ -ek key This option is used at database creation time to specify that full database encryption will be used, and is followed by the encryption key. This parameter is also used to specify the database encryption key when starting an encrypted database. 22
  24. 24. Copyright © 2006 iAnywhere Solutions, Inc. ♦ -ep This option is used at database creation time to specify that full database encryption will be used, and that the user should be prompted with a dialog box for the encryption key. The user can be prompted for the encryption key both at database creation and at database server start-up. ♦ -et This option is used at database creation time to enable individual table encryption within the database. If used alone it specifies simple encryption. If followed by -ek or -ep, strong encryption is used on the encrypted tables. For more information, see “Creating databases (SQL)” in SQL Anywhere Server - SQL Usage, or sqlanywhere/1000/en/html/dbugen10/ug-creatingdbs-sql.html. Full database encryption Databases that are fully encrypted (meaning all database tables and the database transaction log are encrypted) are recommended from a security standpoint. Databases can be encrypted using either simple or strong encryption. Simple encryption Encrypted databases can be created using dbinit, the CREATE DATABASE SQL statement, or the Sybase Central Create Database wizard. For example, a database with simple encryption can be created from a command prompt by executing the following: dbinit -e database-file Strong encryption Strongly encrypted databases can be created via the command line utilities, with SQL statements, or by using Sybase Central. When using SQL statements, you must include the ENCRYPTED ON KEY clause in the CREATE DATABASE statement. For more information, see “Creating databases (SQL)” in SQL Anywhere Server - SQL Usage, or sqlanywhere/1000/en/html/dbugen10/ug-creatingdbs-sql.html. On the command line, use the dbinit utility with the -ek (encryption key specified on command line) or -ep (user prompted for encryption key via a dialog) parameter. The -ep parameter is recommended because using the dialog masks the key instead of having the user enter it in plain text on the command line. For more information, see -ep server option in SQL Anywhere Server - Database Administration, or manuals/sqlanywhere/1000/en/html/dbdaen10/da-ep-option.html. 23
  25. 25. Copyright © 2006 iAnywhere Solutions, Inc. To encrypt a database after it has already been created, use the CREATE ENCRYPTED FILE statement. The CREATE ENCRYPTED FILE statement can also be used to change the encryption key of a database. For more information, see CREATE ENCRYPTED FILE in SQL Anywhere Server - SQL Reference, or html/dbrfen10/rf-create-encrypted-file-statement.html. Table encryption Table encryption is similar to database encryption in that tables are fully encrypted with either simple or strong encryption, but the difference is that for table encryption, only specified tables are encrypted. This method allows you to encrypt tables with sensitive data, but avoids the possible performance impact associated with encrypting the entire database. If database encryption is enabled, you cannot encrypt individual tables. Simple encryption ♦ SQL The following SQL statement creates a database with simple table encryption: CREATE DATABASE database-file-name ENCRYPTED TABLE ♦ Command prompt The following command uses the dbinit utility to create a database with simple table encryption: dbinit database-file-name -et Strong encryption ♦ SQL The following SQL statement creates a database with strong table encryption, using the key abc and the AES encryption algorithm: CREATE DATABASE database-file-name ENCRYPTED TABLE KEY ’abc’ ALGORITHM AES ♦ Command prompt The following command creates the same database as the above SQL statement, but using the dbinit utility: dbinit database-file-name -et -ek abc -ea AES 24
  26. 26. Copyright © 2006 iAnywhere Solutions, Inc. It is recommended that instead of having users enter the encryption key on the command line, that they be prompted to enter the key in a dialog (where it is masked and not displayed in plain text). This is done as follows: dbinit database-file-name -et -ep -ea AES After a database with table level encryption has been created, you can create encrypted tables by adding the ENCRYPTED clause to the CREATE TABLE statement. For example: CREATE TABLE Customers( MemberID CHAR( 40 ), CardNumber VARCHAR( 30 ) ) ENCRYPTED; Encrypting individual values in a table In SQL Anywhere, you can encrypt any data within a table by using the ENCRYPT function. This requires no special parameters at database creation, but the drawback is that the encryption key must be entered for every INSERT or SELECT. Using the ENCRYPT function uses strong AES encryption. Using the ENCRYPT function, one can encrypt a single column (such as a password column), but not any other data in the table. In this situation, it is useful to create triggers to encrypt inserts automatically, and to create a hidden view to decrypt the column automatically for SELECT statements. For more information, see “Encrypting portions of a database” in SQL Anywhere Server - Database Administration, or html/dbdaen10/da-security-s-4649816.html. Mobile data encryption policies Mobile devices running SQL Anywhere support the same data encryption functionality available on desktop computers. When using a mobile installation of SQL Anywhere, it is also recommended that you encrypt the data. 25
  27. 27. Copyright © 2006 iAnywhere Solutions, Inc. To reduce the chance of security threats, if a consolidated database in a SQL Anywhere database network is encrypted using a key X, before data is sent to mobile devices it is first decrypted using that key. This allows the database on the mobile device to be encrypted only if desired. If data in the mobile databases is encrypted (using key Y), key Y should under no circumstances be the same as key X. This prevents the chance of unauthorized access to all company data if the encryption key on a single mobile device is compromised. Moreover, a database management procedure should be in place that regularly invalidates the keys used to encrypt mobile database instances (forcing data to be re-encrypted with a new key), so that even if the encryption on a mobile device is compromised, the key will not be useful to the malicious user. Performance analysis Performance is only slightly impacted when data is encrypted because SQL Anywhere is very efficient in encrypting/decrypting data. In lab tests, when databases are encrypted with AES or AES_FIPS, the performance decrease is between 2-3% on data retrievals and as much as 5% on data insertion. These results are based on the insertion/retrieval of 2.5 million rows to and from a single table on a Pentium 4 2.4 GHz system with 1024 MB RAM. 26
  28. 28. Copyright © 2006 iAnywhere Solutions, Inc. Communication encryption SQL Anywhere is a market leader in the development of front line databases, designed to provide crucial business information regardless of where the user is located. Sending business data outside of the enterprise can become a security issue if no care is taken to encrypt and protect that data from malicious individuals. SQL Anywhere comes with built-in security mechanisms to allow for maximum protection, while allowing employees in the field to perform their work with ease. Although SQL Anywhere does support unencrypted communications between databases (requiring only a user ID and password for the database), this section focuses on transport-layer security. Introduction Communication encryption in SQL Anywhere is done using transport-layer security (TLS). TLS, the successor to SSL, is a cryptographic protocol designed to provide communication encryption over TCP/IP. TLS is an Internet Engineering Task Force (IETF) standard protocol, which secures client/server communications using digital certificates and public-key cryptography. SQL Anywhere supports server authentication, where the database server creates public and identity certificates and a client application can use those certificates to verify the identity of the central database server. Note that regardless of whether or not communications encryption is in use, the login packet that the client application sends to connect to the database server is always encrypted. The TLS protocol uses a combination of public-key and symmetric key encryption to improve communication performance. Public-key encryption provides better authentication techniques, but is computationally intensive. Once a secure connection is established, the client and server use a highly-efficient symmetric cipher with 128-bit key size for the rest of their communication. Digital certificates Transport-layer security is based on the exchange of digital certificates amongst interested parties. Before communication begins, each party generates an identity certificate, which is created by concatenating a public certificate with a private key. 27
  29. 29. Copyright © 2006 iAnywhere Solutions, Inc. Public certificate Identity certificate public information and public key public information and digital signature public key digital signature private key private key A server or client identity certificate is created by concatenating a public Private key certificate and the matching private key. An important feature of the public certificate is the digital signature. Digital signatures are used to maintain data integrity during transmission and to detect tampering. Digital signatures are generated by creating a unique hash value based on a certificate, and signing or encrypting that hash value with a signature private key. It is very important to protect the signature private key because if it is compromised, a malicious user can mask a dangerous data transmission as legitimate and fool the database server. There are three ways in which the signing of certificates can be approached: ♦ Self-signed certificates Self-signed server or client certificates can be used for simple setups (one central database server and few remote databases). In this scenario, the private key used to sign public certificates is stored in the central database server (for server authentication) or with the remote databases (client authentication). For more information, see “Self-signed root certificates” in SQL Anywhere Server - Database Administration, or html/dbdaen10/da-ml-tls-s-3595952.html. 28
  30. 30. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Enterprise root certificates This approach helps improve data integrity and extensibility in a multi-server and/or multi-client deployment. A specific server is designated as the certificate authority and contains a private key used to sign all the certificates needed in the database system. This has the advantage of extensibility, as additional servers can be added without the need to reconfigure clients, and vice versa. For more information, see “Enterprise root certificates” in SQL Anywhere Server - Database Administration, or go to html/dbdaen10/da-ml-tls-s-3393696.html. 29
  31. 31. Copyright © 2006 iAnywhere Solutions, Inc. ♦ Commercial (global) certificate authorities When a commercial certificate authority is used (such as VeriSign), the certification procedures are very similar to the enterprise root certificates approach, except that the private signature key is never stored locally. This has a number of advantages over the other approaches. First, commercial authorities specialize in the signing of certificates and have first-class systems to handle such requests. This includes elaborate physical and virtual security implementations. Global certificate authorities are also useful when two different organizations want to exchange data. Trusting certificates signed by the same third party can greatly speed up such a process. When using globally-signed certificates, each client or server must verify the certificate values (such as Organization, Common name, and so on) to avoid trusting certificates that the certificate authority has signed for others. For more information, see “Globally-signed certificates” in SQL Anywhere Server - Database Administration or html/dbdaen10/da-ml-tls-s-4135725.html. Enabling communications encryption In order to enable communications encryption, first you need to decide which encryption method you want to use: ECC or RSA. If you require a FIPS compliant application, you must use RSA_FIPS security. Once you have chosen, you need to do the following to enable communications encryption between the client and server. ♦ Create digital certificates The identity certificate needs to be created and should be stored securely on the server. The client certificate should be generated and distributed to client applications. SQL Anywhere ships a utility called gencert.exe to aid in the generation and signing of RSA or ECC 30
  32. 32. Copyright © 2006 iAnywhere Solutions, Inc. certificates. In addition, a utility called readcert.exe is provided to read certificates. The following example uses the gencert -r option to generate an RSA self-signed server certificate. gencert -r Certificate Generation Tool Choose certificate type ((R)SA or (E)CC): R Enter key length (512-2048): 1024 Generating key pair... Country: CA State/Province: ON Locality: Waterloo Organization: Sybase, Inc. Organizational Unit: IAS Common Name: MobiLink Serial Number: 123 Certificate valid for how many years: 12 Enter password to protect private key: mypwd123 Enter file path to save certificate: public_cert.crt Enter file path to save private key: server_key.pri Enter file path to save server identity: server_cert.crt ♦ Start database Server Start the server with encryption enabled by using the -ec option. This option allows you to specify the type of security and the server certificate information. The following example uses the -ec server option to specify ECC security, the server certificate, and the password protecting the server’s private key: dbsrv10 -ec tls(tls_type=ecc;certificate=c:testserv1_ ecc.crt; certificate_password=mypwd) -x tcpip c: testsecure.db ♦ Configure client applications To set up client applications to use transport-layer security, deploy the certificates generated above with your application. Then use the Encryption [ENC] connection parameter in your connection string. The following example connection string uses the trusted_certificates encryption connection parameter to specify the public certificate, public_cert.crt. UID=DBA;PWD=sql;ENG=myeng;LINKS=tcpip; ENC=tls(tls_type=ecc;trusted_certificates=public_cert.crt) For more information on setting up communications encryption, see “Transport-Layer Security” in SQL Anywhere Server - Database Administration or html/dbdaen10/da-ml-tls.html. Performance analysis Communication encryption has a significant impact on the performance of database communications, due to the overhead involved in encrypting all outgoing and decrypting all incoming communications traffic. In general, RSA is 31
  33. 33. Copyright © 2006 iAnywhere Solutions, Inc. faster than ECC, and ECC is faster than RSA_FIPS. All tests were performed on standard off-the-shelf hardware with no modifications. Database fetch When fetching data over an encrypted communication channel, RSA encrypted communication is 50% slower than unencrypted communication. These results are based on a retrieval test of 2.5 million rows on a Pentium 4 2.4 GHz system with 1024 MB RAM.. Database insert When data is inserted, encrypted communications again perform slower than unencrypted ones, but the difference is not as pronounced as with the database fetch results. When inserting data, the performance difference between RSA and unencrypted inserts is 40%. These results are based on an insert test of 2.5 million rows on a Pentium 4 2.4 GHz system with 1024 MB RAM. SQL injections SQL injections are security vulnerabilities that can occur when dynamically-generated SQL statements are passed for processing to a database server from the application layer. These vulnerabilities occur when, during dynamic SQL statement generation, the user-provided values are not escaped properly, thus making it possible for the user to gain access to unauthorized data by entering his/her own SQL code. Because of the growth of the Internet, the most common targets of SQL injection attacks have become commercial web sites, as those can be exploited to retrieve large amounts of sensitive information. Because of their simple nature, SQL injections are often overlooked and dismissed as a security threat, and prevention efforts are focused on other areas of the enterprise. Examples The following code generates a SQL statement that, when passed to the database, authenticates a user login (if the return data set is empty, the login was incorrect): String statement = SELECT * FROM users WHERE userId = ’ + _userId + ’ AND password = ’ + _password + ’; ; What would happen if the user, instead of entering a proper password, types anyUser into the username form box, and the following into the password box? password’ OR ’’=’ The dynamically-generated SQL statement would look like this: SELECT * FROM USERS WHERE uid = ’anyUser’ AND password = ’password’ OR ’’=’’; The result of executing this statement is unintended. The database would return all users, which might result in the malicious user gaining unauthorized access rights to the system. If the malicious user wants to specifically damage the data in the database, they 32
  34. 34. Copyright © 2006 iAnywhere Solutions, Inc. could have entered the following in the password field: password’; DROP TABLE accounts; SELECT * FROM users WHERE uid = ’admin This would result in the deletion of the accounts table, which might have disastrous consequences. Preventing SQL injections Because SQL injections look completely legitimate to a database server, most of the preventative measures for this problem are related to the application layer and how the application invokes SQL execution from the database. Preventing SQL injections in the application layer Modifying an application to secure it from being vulnerable to SQL injection attacks has been simplified in recent years because most programming languages and data access APIs include tools designed to combat such attacks. Escape characters Some languages provide specific functions (such as Perl DBI::quote) that accept a string value and check it to see if it contains special escape characters. Although such methods do not detect SQL code, they can remove escape characters (such as ones that terminate a string), causing the database server to return a SQL syntax error, so it does not execute the statement. Value placeholders A better way to prevent injection attacks is to use value placeholders when building a query. This technique is more useful for detecting SQL code in values that should have none (such as a password variable). The following is a C# code sample: string commandText = SELECT * FROM Customers WHERE Country=@CountryName; SqlCommand cmd = new SqlCommand(commandText, conn); cmd.Parameters.Add(@CountryName,countryName); In this case, because ADO.NET provides strong type checking, C# flags an error if countryName contains anything more than just a character or numeric value. Placeholder availability depends on the provision of such features from the DBMS itself or from the data access API used (such as ADO.NET in the above example). You can also make use of host variables instead of building SQL queries dynamically. Stored procedures The most effective method for combating injection attacks is by using database stored procedures. The stored procedure method is similar to the value placeholders method, but has a number of key differences. First, stored procedures are contained within the database and are only invoked by the 33
  35. 35. Copyright © 2006 iAnywhere Solutions, Inc. application code with the necessary parameters passed in. With proper database security settings (see “Prevention in the database layer” on page 34), the application is informed that the stored procedure failed, without exposing any of the internal workings of the procedure itself. Secondly, stored procedures enforce type checking. If a stored procedure expects an INTEGER variable, anything but a valid integer causes a server error. Also if the procedure takes in a VARCHAR variable of size 10, it is difficult to inject any code into it without causing database server errors. Stored procedures, when implemented properly, can be of great help in eliminating the chance of SQL injections. You have to keep in mind, though, that variable values should still be checked for possible injection code on the application side, as this provides additional protection. Prevention in the database layer Although SQL injection attacks are legitimate SQL statements and it is impossible for the database server to identify malicious code, it is possible to tighten the security of the database to limit the danger of such code. In a normal production deployment, there should always be a separate user account that is used strictly by the application. To prevent a malicious user from using statements such as DROP TABLE, the application user’s permissions should be limited to: ♦ Only the SQL functions that it would need during normal operations. ♦ Only the tables that contain necessary information. ♦ If stored procedures are used, the application user should only be given permissions to execute the ones it needs. Auditing can also help identify instances of successful SQL injection attacks and reverse the possible damage done to the system. Injections in the URL It is important to be aware of URL stuffing when talking about SQL injections. This refers to an exploit that is possible when the web site exposes SQL statements in the URLs for its web pages (for example when building up a SQL statement over the course of a number of pages). This practice should be avoided. Exposing SQL code, or the parameters used to build up an SQL statement, in the URL should be considered an unacceptable breach of security. Even a novice user with basic SQL knowledge could exploit the system and cause damage. Conclusion In today’s world, the value of information is continually increasing in organizations, and database security is a critical issue. Every organization should take database security as seriously as they do their end of year financial statements. If a 34
  36. 36. Copyright © 2006 iAnywhere Solutions, Inc. company’s data is compromised, the costs incurred can be prohibitive, both from a financial and a public relations perspective. SQL Anywhere 10 provides an organization with the tools needed to make sure that its data is secure. This document has outlined the key areas of concern and provided the steps necessary to ensure that your company’s data is safe and secure while it is stored in a SQL Anywhere database and wherever it is sent to over the network. Appendix A: SQL Anywhere security checklist ♦ Database server machine is in a secure environment with adequate protection ♦ The necessary network security measures have been put in place ♦ All unnecessary operating system services and daemons have been disabled ♦ Stringent operating system user account policies have been implemented, with few users able to login to the database server machine ♦ When using integrated logins, the Windows guest user account is disabled, and all other user logins have strong passwords ♦ Mobile device security measures are in place ♦ Access to device is secured with passwords, certificates or non-traditional authentication methods ♦ Application-level security is in place • Remote device and patch management is available • Data on the mobile device is encrypted using strong encryption • Communication of mobile devices with the corporate network is secure • Only company-owned devices are allowed to connect to the corporate network • Proper IT policies and procedures are in place, as discussed earlier ♦ DBA authority is restricted to as fewer users as possible ♦ Permissions to start, stop, create, load and unload databases are restricted to DBA users ♦ Security measures are in place regarding database user passwords: • A custom login procedure has been implemented • Passwords have a minimum length • Passwords must meet a minimum level of complexity • The default DBA account password (“sql”) has been changed, or preferably, the DBA account is disabled and replaced with another account with DBA privileges 35
  37. 37. Copyright © 2006 iAnywhere Solutions, Inc. • Passwords are not included in ODBC data sources • The number of unsuccessful login attempts is limited ♦ Unnecessary SQL Anywhere utilities are not present on the server, and measures have been taken to prevent the utilities from compromising security ♦ The database request log is not enabled by default and when needed it is deleted immediately after use ♦ The database server message window is disabled ♦ Database auditing is enabled and access to the dbtran utility is restricted ♦ All backups and backup procedures are properly secured ♦ All database web services are secured using HTTPS and require user authentication ♦ Strong database or table encryption is used ♦ Encryption keys are strong ♦ Users are prompted to enter the database encryption key using a dialog box upon starting the database ♦ Communication with mobile/consolidated databases is secured using transport-layer security ♦ When possible, stored procedures with strong type checking are used to prevent unauthorized execution of code and SQL injections ♦ Adequate security training and information is made available to employees to familiarize them with proper information security procedures and practices Appendix B: Guidelines for strong passwords Passwords are the standard way of securing computer systems today. This includes anything from a desktop workstation to a critical database that stores customer credit information. Regardless of the purpose a specific password has, it is imperative that such a password is secure avoid weak links in an organization’s network. Weak passwords remain one of the biggest problems facing security systems today. This is because people often, unless specifically forced not to, choose passwords that are easy to remember—their names, names of objects, important dates, and so on. Such passwords are easily broken using techniques such as dictionary attacks, where an attacker uses a very large number of common words to guess a user’s password. This is done by either making continuous login attempts, or by obtaining the encrypted version of the password storing file and comparing its values to millions of pre-encrypted dictionary words. This process 36
  38. 38. Copyright © 2006 iAnywhere Solutions, Inc. can be extremely fast—two dual-processor workstations can break hundreds of passwords in just a few minutes using a 100000 word dictionary file. Qualities of a strong password ♦ it is at least eight (8) characters long ♦ it has at least one number ♦ it has at least one lowercase letter ♦ it has at least one uppercase letter ♦ it has at least one symbol (!,@,#,$,^) The following should never be used as passwords: ♦ user name ♦ employee numbers ♦ given names ♦ names of family members, friends, or co-workers ♦ nicknames ♦ social security or social insurance numbers ♦ driver’s license numbers ♦ birthdays ♦ license plate numbers ♦ addresses or street names ♦ phone numbers ♦ names of towns, cities, countries ♦ names of companies, departments, or divisions ♦ computer terms, commands, web sites, hardware items, or software names ♦ common terms and acronyms ♦ words and number patterns (aaddoo22, a1s2d3f4, and so on) ♦ makes and models of vehicles, planes, or boats ♦ slang words and phrases ♦ obscenities ♦ school names, school mascot names ♦ favorite foods, sports, TV channels, beverages, and so on ♦ dictionary words 37
  39. 39. Copyright © 2006 iAnywhere Solutions, Inc. ♦ any of the above, but in reverse ♦ passwords used on public web sites ♦ often used passwords Appendix C: Social engineering All computer security systems are different with respect to what they are securing and how their respective security measures are implemented. Nonetheless, all security systems share a common weak link that can easily be exploited to bring them down entirely—the human factor. No matter how secure a system is, a malicious user can gain access to it by carefully manipulating the people that interact with such a system on a daily basis. The practice of obtaining confidential information by social means in order to gain unauthorized access to a computer system is referred to as social engineering. Social engineering with respect to computer systems relies on the trust that most people naturally show towards any other person. A social engineer manipulates such trust to gain access to privileged information, which in most cases refers to learning the user IDs/passwords of people who have access to restricted data. A common example of such a use includes calling company employees pretending to be a system administrator. Given the high likelihood that employees are not familiar with most of the personnel in IT, if they are asked for their password in order to reset a system, there is a high chance that they will give out that password. Social engineering work is most commonly done over the phone, e-mail, or instant messaging, and sometimes in person. There are a number of procedures that can help an organization decrease its vulnerability to social engineering attacks: ♦ Schedule security training sessions and explain to all employees what social engineering is, what methods social engineers use to gain access to information and what preventative measures could be taken to prevent such attacks. One of the biggest reasons why social engineering works is that the general workforce is not aware the problem even exists. Therefore, training sessions will decrease the susceptibility of employees to such attacks. The following topics should be addressed: • What a social engineer is and how they attempts to earn a victim’s trust. • List a number of common warning signs that could indicate that a caller is a social engineer. • Employees should know what information has value with respect to the company’s business and should be protected at all costs. • Password policy should be explained. It should also be reinforced that passwords are personal and they should not be given out to anyone. • The necessity to protect company lingo, names and positions of personnel, server names, and so on, as all of these could be used to plan a successful social engineering attack on a different employee. 38