Microsoft SQL Server 2008 R2 Unleashed- P43 ppsx

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 p

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

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 Management Identity 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

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 ideniden-tity 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

Billing Profile N

"Card Number"

"Card Type"

PIN

"Security Code"

Bank

"Bank Account Number"

"Bank Routing Number"

Customer Physical Address N on-K

"Street Address"

City State

"Postal Code"

Personnel Demographic N on-K BirthDate Gender

"Marital Status"

Children

Government Identification N

e

"Social Security Number"

"Passport Number"

"Drivers License Number"

"Other Government ID"

Purchases N Product

"Purchase Date"

"Purchase Amount"

"Renewal Date"

Personnel Name

N

on-K

"First Name"

"Middle Name"

"Last Name"

Internal Contact Information N on-K

"Office Phone Number"

"Job Title"

"Site Location"

Consumer Customer Name N e

"First Name"

Customer Contact Points Personnel

N

"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 authorizainforma-tion 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

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 synchroasynchro-nous 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

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

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 configure the Audit object to shut down the SQL Server instance 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

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

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 Server 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

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