ptg 364 CHAPTER 13 Security and Compliance The Open Web Application Security Project (OWASP; www.owasp.org) lists its recent top 10 application vulnerabilities as follows: . SQL Injection . Cross-Site Scripting . Broken Authentication and Session Management . Insecure Direct Object References . Cross-Site Request Forgery . Security Misconfiguration . Failure to Restrict URLs . Unvalidated Redirects and Forwards . Insecure Cryptographic Storage . Insufficient Transport Layer Protection Identity Access Management Components One of the key areas identified in the security big picture (as you can see looking back at Figure 13.3) is identity management. It is key in the sense that well-managed identities are essential to well-managed security. There is a quite a bit to consider when talking about identities. Figure 13.4 shows a common “identity universe” for a company that has both internal- and external-facing applications. In other words, identities are both customers that interact with the business and internal identities such as employees and other work- force identities (contractors, temps, partners, and so on). Both sets of identities must be managed well, and often there are overlapping identities that require accesses (and iden- tity management) in both areas (internal and external). Often, companies use one internal-facing LDAP directory such as Microsoft’s Active Directory for managing their internal identities and then another LDAP directory such as Sun One LDAP for managing all external-facing identities (for forums, eStore, and so on). Then they create triggers or synchronization jobs that do a “search before create” type of processing when new identities are created within either LDAP directory. Because overlap is rare, not much extra “create” overhead occurs, but when they do overlap, only one identity (such as a partner identity that might be in that company’s internal and external LDAP directories) gets created. This is effectively “mastering” the user identities. It is recommended that you consider both sources of identities at all times. You should also establish strict access roles for all identities with the least rights going to anonymous identities. More and more companies are also now moving to concepts such as Open ID, where a company can utilize the authentication and identification established by third-party Open ID providers and grant trust to these identities with very high confidence. The industry is moving this way fast. Figure 13.5 shows the logical components of identity access management. Download from www.wowebook.com ptg 365 Identity Access Management Components 13 Company Identities Internally-Facing Identities Externally-Facing Identities Employees Temps Others Partners (and their Contacts) Forums Customers (Registered/Subscription/Anonymous) Prospects Leads Opportunities Touch/Use Internal Applications/Data Sell/Service/Buy/Use Products, Services, Data Mergers and Acquisitions Social Networking App Store… Identity Universe Mergers and Acquisitions Mergers and Acquisitions FIGURE 13.4 Identity universes (internal and external-facing applications). Logical Components of Identity Access Management Applications/Access Points Access ManagementIdentity Life-Cycle Management Directory Services - User Management - Credential Management - Entitlement Management - Identity Integration - Provisioning/De-provisioning - Authentication & SSO - Trust & Federation - Entitlements & Authorization - Security Auditing/Compliance - Identity Propagation - Impersonation & Delegation - Users - Attributes - Groups - Roles - Credentials - Policies Applications/Access Points FIGURE 13.5 Logical components of identity access management. Download from www.wowebook.com ptg 366 CHAPTER 13 Security and Compliance This figure shows that you must carefully address full identity life-cycle management, which includes user ID management, credential management, entitlement management, identity integration (between multiple LDAPs), and provisioning and deprovisioning iden- tities. Access management is all about authentication, single sign-on, authorization, and impersonation and delegation rules. And, the directory services themselves define the users, groups, all attributes (or elements) of a user or group, roles, policies to enforce, and credentials to be used. All applications and access points must be plugged in to this iden- tity access management framework. All risk is minimized by a sound identity access management foundation. Compliance and SQL Server On the global level, hundreds of compliance laws are in place that affect almost every aspect of data access, data protection, data movement, and even data storage. Countries such as Germany now have some of the most severe data compliance rules on the planet, such as strict control of how certain personal data is stored and what personal data can be stored; these rules even prohibit personal data from being transmitted (or moved) across German borders. If you are planning to create applications and databases that will span countries or contain sensitive or private data, you must “design in” the rules and enforce- ments from the beginning (as we have been stressing throughout this chapter). Let’s address the most common “sensitive” data: Personal Identifiable Information (or PII for short). PII data is at the center of most global data privacy laws and regulations. As you can see from a subset of the PII data model in Figure 13.6, PII data is any personal information that identifies an individual, such as name; address; driver’s license number; other government-issued identification (such as passport number); and even gender, ethnicity, and age. If you have any databases or applications that have this type of data in it, you are bound by local and/or regional laws and regulations whether you like it or not. It is the law. You must then protect this data in accordance with those regulations and laws; otherwise, you become liable for fines, lawsuits, or worse (risk exposure of that data could put you out of business). As you can also see in Figure 13.6, there are different sensitivity levels around PII data. Something like a person’s name is considered low sensitivity, whereas an employee ID is considered medium sensitivity. And marital status, gender, Social Security number, bank account number, driver’s license number, and passport number are consid- ered high sensitivity and often must be treated with special care and feeding with capabili- ties such as encryption in transit and at rest (while stored in a table). Following is a list of some of the many laws and regulations that have been put into effect and that you will likely have to address in your application: . The Health Insurance Portability and Accountability Act (also known as HIPAA) was introduced in 1996 to protect critical health and patient information. HIPAA forces companies to strictly control data identified under its jurisdiction. Download from www.wowebook.com ptg 367 Compliance and SQL Server 13 Billing Profile No n - K "Card Number" "Card Type" PIN "Security Code" Bank "Bank Account Number" "Bank Routing Number" Customer Physical Address No n - K "Street Address" City State "Postal Code" Personnel Demographic No n - K BirthDate Gender "Marital Status" Children Government Identification No n - Ke "Social Security Number" "Passport Number" "Drivers License Number" "Other Government ID" Purchases No n - K Product "Purchase Date" "Purchase Amount" "Renewal Date" Personnel Name No n - K "First Name" "Middle Name" "Last Name" Internal Contact Information No n - K "Office Phone Number" "Job Title" "Site Location" Consumer Customer Name No n - Ke "First Name" "Last Name" Customer Contact Points Personnel No n - K "Employee ID" Sales Entity Enterprise/SMB Customer Consumer Customer Customer Electronic Address Low Sensitivity Medium Sensitivity High Sensitivity characterized by Referenced by Provided Known by Made Made Made Specifies Installed provided Installed Identified via has provided Known by Specifies FIGURE 13.6 Personally Identifiable Information (PII). . The Sarbanes-Oxley Act (known as SOX), put into place in 2002, requires auditors to assess and report on the effectiveness of a company’s internal controls on informa- tion and extend into the authorization of access and updates to data. . The Gramm-Leach-Bliley Act (GLBA) of 1999 further defines steps that must be taken by financial institutions to protect, secure, and prevent access of core financial data. . California’s Information Practices Act of 2005 details strict controls around PII data, what needs to be encrypted, and laws surrounding breaches of controlled data. . The Children’s Online Privacy Protection Act, passed in 1998, focuses on the proce- dures to protect the confidentiality, security, and integrity of personal information collected from children. Other industry-oriented laws and regulations have emerged, such as the Payment Card Industry data security standard (PCI standard). It is focused on what must be done to ensure credit card information is secure from the moment a customer makes a purchase until the merchant disposes of the credit card transactions. Two great books on security and compliance are Cryptography in the Database by Kevin Kenan (2006, Addison-Wesley) and The Executive Guide to Information Security by Mark Egan (2005, Addison-Wesley). These books will make great focused additions to your tech- nology library. Download from www.wowebook.com ptg 368 CHAPTER 13 Security and Compliance SQL Server Auditing Introduced with SQL Server 2008 is the SQL Server Audit feature. This long-overdue feature now adds a great native auditing functionality into the SQL Server Database Engine. NOTE The SQL Server Audit feature is available only in the SQL Server 2008 Enterprise and Developer Editions. An audit is the combination of several elements into a single package for a specific group of server actions or database actions. The components of SQL Server Audit combine to produce an output that is called an audit. The SQL Server Audit feature in SQL Server 2008 is intended to replace SQL Trace as the preferred auditing solution. SQL Server Audit is meant to provide full auditing capabilities, and only auditing capabilities, unlike SQL Trace, which also serves for performance debug- ging. The SQL Server Audit feature is built on top of Extended Events, a new high-perfor- mance eventing infrastructure introduced in SQL Server 2008. SQL Server Audit leverages the performance benefits of Extended Events, which provides both asynchronous and synchronous write capabilities (by default, SQL Server Audit uses the asynchronous event- ing model). NOTE By default, the audit events are written to the audit target in an asynchronous fashion for performance reasons. When tighter guarantees of audit records being written to the audit log are required, you can select synchronous write, with the understanding that some amount of performance degradation should be expected. The choice of asynchro- nous or synchronous is controlled by the QUEUE_DELAY option of the CREATE AUDIT DDL. SQL Server Audit is also tightly integrated with the Windows operating systems and can push (write) its audits to the Windows Application or Security Event Log. With SQL Server Auditing, you can set up auditing of just about any event or execution within SQL Server, and it can be as granular as you need (right down to a table and operation level). This capability is important because not only can you track all these events, but you can use this auditing capability to fulfill application and database audit compliance and look for patterns of misuse, or even specific “hot” objects that contain the most sensitive data in your database. As you can see in Figure 13.7, a branch under each database called Security contains several of the common security-related nodes that you’ve seen before (Users, Roles, Schemas, and so on). But now, there is a Database Audit Specifications branch from which you can set up and view the database audit specifications you have defined. You Download from www.wowebook.com ptg 369 SQL Server Auditing 13 FIGURE 13.7 The new Database Audit Specifications item in the SQL Server Management Studio (SSMS) Object Explorer. can have as many specifications as you want, and again, they can be at varying levels of granularity. Before you can set up a Database Audit Specification, however, you must first set up a SQL Server Audit object. To do this, you must use a couple of new entries in the Object Explorer under the Security folder at the SQL Server instance level: Audits and Server Audit Specifications. Essentially, three main objects describe audits in SQL Server 2008: . The Server Audit object—Used to describe the target for audit data, plus some top- level configuration settings. This destination can be a file, the Windows Application log, or the Windows Security log. The Server Audit object contains no information about what is being audited—just where the audit data is going. Multiple Server Audit objects can be defined with each object independent from one another (that is, they can each specify a different destination). . The Server Audit Specification object—Used to describe what to audit at a server instance-wide level. A server audit specification must be associated with a Server Audit object to define where the audit data is written. There is a one-to-one relation- ship between the Server Audit Specification object and the Server Audit object. . The Database Audit Specification—Used to describe what to audit at a specific database level. Where the audit data is written is determined by the Server Audit object it is associated with. Each database audit specification can be associated with Download from www.wowebook.com ptg 370 CHAPTER 13 Security and Compliance FIGURE 13.8 Creating a new Server Audit object in Object Explorer at the Server instance level. only one server audit. A server audit can be associated with audit specifications for multiple databases, but only one database audit specification per database. To create a new Server Audit object, right-click on the Audits item in Object Explorer and select New Audit (see Figure 13.8). When you set up a Server Audit object, you specify where the audit information will be written to. In Figure 13.9, you can see that we are creating a server audit named NEW_SQL_Server_Audit and are defining it to use the Application log at the Windows oper- ating system level as the audit destination. You can also choose to write to the Windows Security log or to a text file. Events written to the Application or Security Event log can be accessed with Event Viewer or with specialized Event log management software, such as Microsoft Systems Center Operations Manager. NOTE Depending on the volume of audit targets being monitored, better performance may be achieved by using a file as the audit target rather than the Windows Event log. Also, when written to a file, the audit data is accessible through a built-in table-valued func- tion (fn_get_audit_file), which allows the use of regular SELECT syntax to query the audit trail. NOTE You can also configu re the Audit object to shut do wn the SQL Ser ver insta nce if, for whatever reason, SQL Server Audit is unable to write its audit events to the audit tar- get. Although shutting down the server instance may seem drastic, doing so may be necessary for certain scenarios, to ensure that the server cannot operate without its activity being audited. Download from www.wowebook.com ptg 371 SQL Server Auditing 13 FIGURE 13.9 The Create Audit dialog. FIGURE 13.10 The Create Database Audit Specification dialog. After you set up the Server Audit object, the next step is to go to the Database Audit Specifications folder, as shown in Figure 13.7, in the database for which you want to set up auditing. Right-click this folder and select New Database Audit Specification to bring up the dialog shown in Figure 13.10. This is where you define your database-level audits. In the Create Database Audit Specification dialog, you specify the name of the Database Audit object and the Server Audit object it will be running under. In this example, the Database Audit name is NEW_Database_Audit_Specification, and it will be running under Download from www.wowebook.com ptg 372 CHAPTER 13 Security and Compliance the NEW_SQL_Server_Audit Audit object defined in Figure 13.9. In this example, the data- base audit is being set up to audit any SELECT statements (reads) run against the Employee table (which, of course, contains company-sensitive employee data) by any user (public). At this point you have created a Server Audit object and database audit specification asso- ciated with the server audit. However, neither of these audits is enabled. You can enable them by right-clicking on each and selecting Enable. As soon as the Server Audit object is enabled, it begins auditing and writing audit records to the specified destination (in this example, the Windows Application log). NOTE If your SQL Server login is configured for a default database other than master, enabling the SQL Server Audit object via SSMS fails with the following message: Cannot alter a server audit from a user database. This operation must be performed in the master database. If you receive this error, you need to enable/disable the server audit via T-SQL, as shown in Listing 13.1. You can review the details by right-clicking on the Ser ver Audit and selecting View Audit Logs or, if you are auditing to the Windows Application or Security Event Log, by opening the Windows Event Viewer directly. One of the advantages of opening the Audit log from within SSMS is that it automatically filters the log to show only SQL Server Audit events. In Figure 13.11, you can see that we’ve opened the Log File Viewer and selected to view the Application log (where we directed our SQL Server Audit to go). A few SELECT state- ments were run against the Employee table and, sure enough, the audit information of the SELECT statements shows up in the Application log. Within the Log File Viewer, you can filter your audit results or search them to look for patterns, specific violations, and so on. From the Log File Viewer, you also have the option of exporting the audit logs to a text file or to a comma-separated values (CSV) file. With a CSV file, you could import the audit logs into a database for further analysis and correla- tion. It’s up to your security and audit team to decide how these audits are to be used. In addition to database-level auditing of actions at the database level, you can also set up auditing of server-level events, such as management changes and logon and logoff opera- tions. These are set up in the SSMS Object Explorer through the Server Audit Specifications item in the Security folder for the SQL Server instance (refer to Figure 13.8). Setting Up Auditing via T-SQL Alternatively, you can set up auditing with T-SQL statements and also switch the audit off and on using the ALTER SERVER AUDIT command by using WITH (STATE=ON) or WITH (STATE=OFF), as shown in Listing 13.1. Download from www.wowebook.com ptg 373 Setting Up Auditing via T-SQL 13 FIGURE 13.11 Log File Viewer showing the audit events of a SQL Server Audit object. LISTING 13.1 Setting Up Auditing with T-SQL /* Create the SQL Server Audit object, and send the results to the Windows Application event log. */ USE master; go CREATE SERVER AUDIT NEW_SQL_Server_Audit TO APPLICATION_LOG WITH ( QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE); GO /* Create the Database Audit Specification object using an Audit event */ USE AdventureWorks2008R2; GO CREATE DATABASE AUDIT SPECIFICATION NEW_Database_Audit_Specification FOR SERVER AUDIT NEW_SQL_Server_Audit ADD (SELECT ON OBJECT::[HumanResources].[Employee] BY [public]) WITH (STATE = ON); GO Download from www.wowebook.com . Compliance SQL Server Auditing Introduced with SQL Server 2008 is the SQL Server Audit feature. This long-overdue feature now adds a great native auditing functionality into the SQL Server Database. specific group of server actions or database actions. The components of SQL Server Audit combine to produce an output that is called an audit. The SQL Server Audit feature in SQL Server 2008 is intended. performance debug- ging. The SQL Server Audit feature is built on top of Extended Events, a new high-perfor- mance eventing infrastructure introduced in SQL Server 2008. SQL Server Audit leverages