Database Security with the SecureSphere Database Security Gateway

Database Security with the SecureSphere Database Security Gateway An Automated Approach to Database Assessment, Audit, and Protection

Database security represents one of the most challenging segments of the information technology landscape. The information in corporate databases is a strategic asset that is subject to strict regulatory oversight, demanding operational requirements and a variety of attacks. Database privilege abuse, worm infection, and attack through business applications are continuous threats from both internal and external sources. In this highly demanding environment, IT security teams need automated solutions that support their efforts to assess, audit, and protect database usage. Only by addressing the entire problem in a single solution can they cost-effectively reduce risk and achieve regulatory compliance. This paper provides an overview of the database threat environment, discusses the strengths and weaknesses of traditional approaches, and presents Imperva’s SecureSphere Database Security Gateway. SecureSphere is the only solution that addresses database usage assessment, audit and protection without the manual administration and performance limitations of alternative approaches.

Securing Databases with the SecureSphere Database Security Gateway

Database Security - Assessment, Audit, Protection In an information economy, the information in corporate databases is the most strategic asset of any business. By leveraging network technologies, organizations have extended access to this information to employees, customers, and partners around the world. Networked information has both dramatically reduced the cost of doing business and accelerated the pace of business. Unfortunately, as the value and accessibility of information have grown, so too has the risk associated with it. Today, there are no longer any physical barriers between strategic corporate information and those trying to steal or destroy it. As a result, identity theft, data leakage, SQL injection, and worms are increasingly common events with consequences that impact brand, revenues, and regulatory compliance. In this increasingly demanding environment, effective database security requires solutions that automate policy assessment, audit and protection. These three components represent the fundamental requirements to reducing risk and achieving regulatory compliance.

Attack Example - Identity Theft Database security solutions must provide coverage against a range of attack vectors. As the following example illustrates, a single threat such as identity theft may originate from multiple sources.

• Database Privilege Abuse involves a renegade employee who abuses his/her database access privileges for illicit purposes. For example, a software developer with privileges to access a customer account database may use standard database management tools to copy sensitive customer information and sell it to a criminal identity broker.

Database attacks come from both inside and outside the organization.

• Platform Attacks exploit vulnerabilities in underlying commercial database server (e.g. Oracle, MS-SQL Server) and operating system software (e.g. Linux, Windows 2000). Virtually all worm attacks, for example, take advantage of platform vulnerabilities. In the case of identity theft, platform vulnerabilities are often exploited to install Trojan horse programs that enable back-door access to identity information.

Page 2 Imperva


• Business Application Attacks gain access to identity information by exploiting

vulnerabilities in business applications to gain access to a back-end database. One such attack strategy, known as SQL injection, takes advantage of input validation vulnerabilities in Internet facing Web applications to pass unauthorized SQL queries to a back-end database. In this way SQL injection may enable unrestricted access to the contents of an entire database – including identity information.

Database Security Requires a New Type of Solution Defense against the attack vectors described above requires database security that extends from the specifics of each user’s SQL queries (a.k.a. “data layer database security”) down to the low level network protocols. Enterprise security managers have struggled to meet these requirements with a mix of native database security features, host-based database security software, network-based database security solutions, traditional network firewalls, and intrusion prevention systems (IPS). All approaches require a significant investment in operational resources to manually maintain effective security and none address the complete range of attack vectors. This section analyzes the strengths and weaknesses of each traditional approach to database security.

Native Database Security Capabilities Virtually all enterprise database software solutions include native database security capabilities. For audit purposes, database software provides logging and manually written triggers (in some cases, vendor pre-packaged triggers can be used). To define and enforce query level access control policies, row-level security (RLS) and other tools are available. While the scope and diversity of native database security capabilities is broad, their implementation is limited due to the following shortcomings.

• Security Independence – To maintain the integrity of the security process, database administration and database security should be handled by independent groups. Native security tools require advanced SQL expertise and put DBAs in the position of auditing themselves – a clear deviation from security best practices. DBAs could, for example, disable triggers, execute a fraudulent transaction, and then re-enable triggers leaving no trace of the attack. Independent security implementation is a challenge using native security tools since they require a level of SQL expertise and unique knowledge of database schema that is only found in administrators who manage the database on a daily basis.

• Performance Degradation and Hard Disk Consumption– Database logging and

triggers must write to local tables resulting in significant performance degradation even under moderate transaction loads. Logging and trigger storage requirements also quickly consume valuable hard disk resources.

• Centralized Security – Native database security capabilities rely on proprietary

technology that is not interoperable between vendors. Security managers dealing with multi-vendor environments must manage multiple security solutions each with their own distinct capabilities. In addition, audit data is stored on individual database servers, which may be distributed across the enterprise and managed by different DBAs. This means that consistent enterprise security policy definition, enforcement, and audit is an on-going challenge.

• Incomplete Coverage – Native security tools primarily protect against database privilege

abuse and to some extent, indirect business application attacks. They do not protect against database platform attacks or low level network attacks.

Page 3 Imperva


• Complexity and Cost – Manually created triggers and RLS rules are tightly coupled to database table schema and user access requirements. Each time the table schema or user access requirements change, rules must be re-written. This approach may work for simple tables when schema and user roles are first established. However, the cost of maintaining these policies is untenable as the enterprise grows and the relationships between users, accounts, and roles change. The task of maintaining an RLS policy for even a simple table can be daunting. Maintaining a policy for complex interdependent tables that link data stored in distributed databases is an extremely expensive, if not impossible, proposition. For most organizations, the result is a weak or non-existent policy leading to weak or non-existent security.

Host-Based Database Security Host-based database security solutions consist of dedicated software agents installed on each database host. Host-based solutions monitor database query activity and enforce policy by one of several means. Some products intercept system calls that pass between database server applications and the host operating system, others access the input queue, and others read database logs. Host-based solutions enable manually defined query-level security policies. In the event that an individual user attempts a query that violates policy, a real-time alert is sent to the appropriate security manager. The security manager is then required to coordinate with other managers to determine whether or not the alert represents a false positive or a real attack. For example, if a developer suddenly access database system management table (e.g. sysobjects) against predefined policy, the security manager must check with the development team managers to determine if the alert represents legitimate (but unusual) activity or an attack. Some host-based solutions observe database behaviors during a learning period to automatically create models of normal behavior. These models then serve as a baseline positive security model. By comparing subsequent activity to the model, the host agent is able to identify and potentially block malicious behavior. They also allow administrators to create limited manual policies defining specific “privileged operations” such as Drop Table, Truncate Table, etc. Any user behaviors which deviate from either automatically created or manually defined policies may be blocked or generate an alert. In addition, some host-based security solutions use signature detection technology to identify and block known database attack patterns. Finally, host-based database security can provide a database-independent audit record of user-specific query activity that can be stored to meet regulatory audit requirements. Host-based database security is not without drawbacks, which include the following.

• Security Independence – Database security administration should be independent of general database administration. Database administrators (or other users with administrative rights to database server infrastructure) can accidentally or intentionally tamper with host-based security mechanisms. Logging activity can be stopped, policies modified, databases may be installed without a host security agent, etc.

• Performance Degradation – Host-based solutions consume computing resources on the server resulting in significant database performance degradation.

• Software Management – Database server upgrades often requires concurrent changes to host security software. In addition, any upgrade to server or host security software must be tested for interoperability and stability. Lastly, some organizations continue to use older versions of the database server software that may not be compatible with host-

Page 4 Imperva


based database security. Organizations may be forced to upgrade database server software just to support host security software.

• Complexity and Cost – Query-level database policy management can be extremely complex. Security managers generally do not know specific query requirements for individual users and even if they did - requirements change. Therefore, host-based database security solutions that rely on manually defined policies require round-the-clock tuning and constant interaction with user groups. Policy definition and maintenance for even a simple database deployment is a costly endeavor. For most organizations, the result is a weak or non-existent policy leading to weak or non-existent security.

• Real-Time Policy Enforcement – Host based approaches that monitor log records to

track access activity do not provide real-time policy enforcement. Any attack identified in a log record is a historical event.

Database Security Appliances Database security appliances are deployed on the network to support granular inspection of SQL communications for audit purposes. Although most allow security managers to manually define query-level security policies, these policies are rarely implemented. Like native and host-based security approaches described previously, appliances often suffer from extremely high manual policy configuration and maintenance costs. Accurate database policy management, when implemented by a human administrator, requires round-the clock tuning and constant interaction with all database user groups. In short, while most database security appliances provide security managers with a convenient independent audit tool, they do not provide practical security policy definition and protection. Practical real time protection must automate the definition and ongoing maintenance of an accurate policy.

Traditional Network Security Traditional network firewall and intrusion prevention systems (IPS) are deployed on the network to inspect and enforce policy on database traffic. Unlike dedicated network-based database security tools described above, these tools do not provide granular query-level inspection. Instead they focus on inspection at the lower layers of the OSI stack and offer coarse SQL inspection. As independent devices, they do not consume database computing resources and can be deployed with no performance degradation if sized properly. Both network firewall and IPS deliver security capabilities that are critical to a sound overall database security strategy. The unique strengths and weaknesses of each are described below.

Network Firewall Network firewalls can block access to sensitive database servers from non-essential IP addresses, ports, and protocols. For example, a network firewall may allow Oracle SQL protocols from business applications and database administrators (DBAs) while blocking port scans from corporate desktops. Network firewalls prevent a wide range of network attack vectors while also preventing the spread of worms via non-essential ports and protocols. Unfortunately, network firewalls have no awareness of specific user query activity and therefore, do not address database privilege abuse or indirect business application attacks. As long as a given communication meets basic protocol and IP address restrictions, traffic is allowed. A network firewall would not detect, for example, a rogue administrator who uses a generic SQL client (e.g. SQL Plus) to delete a customer account table.

Page 5 Imperva


Intrusion Prevention System (IPS) IPS uses signature detection technology to block attacks targeting known vulnerabilities in commercial software platforms. Database platform attacks target server operating systems and database server software such as Windows 2000 and Oracle. For example, IPS can identify and block worms like SQL Slammer1 that are embedded within legitimate (allowed source IP and protocol) database traffic. Like network firewalls, IPS has no awareness of specific user queries and therefore, does not address direct database breaches or indirect attacks via business applications.

Point Solutions are Problematic The previous section presented an overview of existing database security solutions. Although each solution defends against one threat or another, none solves the entire problem and no solution provides reliable real-time protection against database privilege abuse. Basic database security requires at least three of the solutions mentioned above – dedicated database security (native, host, or appliance), IPS, and network firewall. Unfortunately, the operational cost of maintaining such a complex security infrastructure is extremely high. Training, deployment, manual policy definition, on-going monitoring, audit, and reporting functions must be duplicated for each solution. In addition, native database security tools and host-based solutions introduce software management overhead, stability risk, and performance degradation that significantly offset their security benefits. Bottom line – the operational cost and risk associated with maintaining disparate database security solutions are too high to be practical.

Point solutions are problematic to deploy, integrate, and manage

1 The SQL slammer worm caused a denial of service on some Internet hosts and dramatically slowed down general Internet traffic on January 25, 2003. It spread rapidly, infecting most of its 75,000 victims within 10 minutes. Although titled "SQL slammer worm", the program did not use the SQL language; it exploited two buffer overflow bugs in Microsoft's flagship SQL Server database product. Source: http://en.wikipedia.org

Page 6 Imperva

http://en.wikipedia.org/


Database Security Deployment and Operational Challenges In addition to the complex security challenges described previously, the strategic role of information stored in databases makes them subject to stringent deployment and operational requirements. Specific issues include availability, performance, deployment risk, and centralized management.

• Availability – Database availability is paramount for many organizations. Downtime has an immediate negative impact on revenues, customer satisfaction and productivity. Therefore, database security solutions cannot introduce new points of failure or threaten stability in any way.

• Performance – Database infrastructure is carefully designed to meet specific

performance metrics including throughput, transaction rates, and latency. Therefore, the performance of database security solutions must match or exceed other elements of the infrastructure.

• Deployment Risk – Database infrastructure is finely optimized. Any change to

database applications, server software, server hardware, or network devices introduces risks to availability, performance, and security. Mitigating this risk requires costly and time consuming testing and tuning that is a serious barrier to deployment. Therefore, database security should be deployed transparently. In other words, database security must work within the existing infrastructure and require no changes to that infrastructure.

• Centralized Management – Database infrastructure is often distributed across the

globe. Security managers need to manage policy, monitor status, and collect audit data from multiple locations without being required to manage each security endpoint separately. Therefore, a centralized management server that aggregates administration of distributed endpoints is a necessity.

Page 7 Imperva


SecureSphere Database Security Gateway

Overview The SecureSphere Database Security Gateway provides automated assessment, audit, and protection for Oracle, MS-SQL Server, DB2 (including mainframe), and Sybase databases. Dynamic Profiling technology automatically creates database usage profiles and security policies that are granular down to the query level for every user and application accessing the database. These profiles provide immediate insights into database usage and provide the basis for real time audit capabilities. SecureSphere provides complete database activity logging with zero impact on database performance and flexible reporting to enable streamlined compliance with regulatory audit requirements. By combining unique business activity analysis and correlation technologies SecureSphere can distinguish real attacks from harmless variations in user behavior. Deployed in minutes with no changes to existing database or network infrastructure, SecureSphere protects against all attack types including privilege abuse, platform attacks/worms, and business application attacks. Transparent Inspection technology delivers gigabit performance, sub-millisecond latency, and options for high availability that meet the most demanding data center requirements. A centralized management server aggregates policy management, monitoring, logging and audit reporting across the largest database environments. SecureSphere supports Oracle, MS-SQL, Sybase, and IBM DB2 (including mainframe).

SecureSphere includes both gateway and management server appliance components. Database Security Gateways are deployed in the path of database servers where they provide automated

assessment, audit and protection. The management server aggregates configuration, policy management, monitoring, logging and audit reporting for multi-gateway deployments.

Page 8 Imperva


Core Technology SecureSphere is built upon a foundation of core technology to meet the unique security, deployment and operational demands of enterprise databases. This section provides a detailed explanation of this core technology. The following section of this document covers key security features and benefits that are derived from the core technology.

Dynamic Profiling – Baseline for Automated Assessment, Audit, and Protection At the heart of SecureSphere’s automated approach to database security is Imperva’s Dynamic Profiling technology. Dynamic Profiling automatically examines live database traffic and applies sophisticated learning algorithms to create profiles of all legitimate activity for each user or application that accesses the database. The profile serves not only as the baseline against which later audit evaluates changes in user or application behavior, but is an automatically generated security policy for database usage, allowing information security teams not only to monitor and audit usage, but also to protect databases from attack. SecureSphere learning algorithms are continuously applied to live traffic so that as user activities evolve over time, valid changes are automatically recognized and incorporated into the profile. Deviations from the profile automatically trigger an alert and may be blocked depending upon severity. Each profile includes: a user name, source IP addresses, tables accessed, SQL operations used per table, queries, query groups, source applications, day and time of allowed usage, stored procedures, and privileged SQL operations. Dynamic Profiling is applicable not only to users directly accessing a database but to the applications (e.g. SAP, PeopleSoft) that interact with databases on behalf of the user. For each application login to the database, SecureSphere automatically generates a security policy tailored to that application. In this way SecureSphere provides the same security capabilities for applications accessing a database as it does for individual database users. The following section describes each of the elements in profile to provide insight on SecureSphere’s assessment and policy definition capability.

Page 9 Imperva


Database Users Dynamic Profiling automatically creates a list of legitimate users for each database along with associated database properties such as database tables accessed, type of access per table (e.g. select, update), query groups, queries and stored procedures used. This serves as baseline for assessing database usage or for future auditing and as an automatically generated role-based security policy tailored to each individual user.

SecureSphere’s Dynamic Profiling technology automatically creates baseline security

policies (profiles) for each user. When new users who are not part of the profile attempt to access the database, an alert is recorded for audit and may be blocked according to policy. Administrators can also manually add to the list of allowable users and even specify users that should be denied access to the database. SecureSphere also supports the assessment of adherence to best practices for user accounts by reporting what databases are being accessed with default database user accounts and whether or not users are “sharing” database accounts. Security groups can use this information to reconfigure databases and/or warn users to stop this practice. They may also (eventually) choose to be alerted or even block the use of default user accounts.

Source IP Addresses Dynamic Profiling automatically creates a list of legitimate source IP addresses for each user. This serves as an automatically generated security policy governing source locations for each user. The SecureSphere administrator can manually delete or add source IP addresses to this list or specify that the user can access the database from any source IP addresses. Deviations from the baseline generate an alert and may optionally be blocked depending on policy. Unauthorized

Page 10 Imperva


network segments can be specified and access attempts from those segments are logged for audit and can generate an alert or cause the login attempt to be blocked. Many organizations require this visibility into user IP addresses because user login activity from an unauthorized network segment or from a new IP address is indicative of compromised login credentials. For example, database login used by a CRM application may be uniquely associated with a pool of servers with defined IP addresses. Someone who “borrows” the CRM login to access the database from a PC can be identified as illegitimate and immediately blocked. Audit reports can include information about IP addresses in the baseline, new IP addresses used, and attempts to connect from unauthorized segments.

Source Applications Profiling source applications is useful to prevent the abuse of application user accounts. If a malicious user is able to gain access to the credentials used by an application (such as a java application or a CRM or ERP package), that user could then attempt to use that login information to gain access to the database via a standard query tool (such as Microsoft SQL Query Analyzer, or Excel) or specialized database hacking tool.

For each database user SecureSphere learns the source applications that are used to access the database. The SecureSphere administrator can manually delete or add source applications to this list or specify the user can access the database with any application. When an unprofiled source application attempts to access the database, an alert is recorded for audit and the query may be blocked according to policy.

Day of Week and Time of Day Restrictions For each user it is possible to define precise days and hours during which users can not connect to the database. If a user tries to connect to the database during unauthorized times, an alert is recorded for audit and the access may be blocked according to policy.

Page 11 Imperva


Privileged Operations SecureSphere includes specific policy and audit controls over predefined “privileged operations”. The list of privileged operations includes sensitive database operations such as drop table, shutdown, kill, etc. By default, any use of these operations generates an alert. However, security managers may create a list of allowed privileged operations for specific users (typically DBAs). Audit reports support detailed documentation of all use of privileged operations for each user and usage of privileged operations that does not match the profile

Security managers can specify allowed privileged operations for specific users.

Stored Procedures Dynamic Profiling automatically creates a baseline of legitimate stored procedures for each user. As well, administrators can define security policy that allows them to specify individual stored procedures, which whenever used, should generate an alarm or be blocked. Audit reports can document all usage of stored procedures, usage of specific default or dangerous procedures, as well as usage of stored procedure usage that does not match the profile.

Database Query Groups – Modeling Legitimate Business Activities Dynamic Profiling automatically creates a baseline of legitimate query groups and specific queries for each user. This provides security managers with a query level security policy tailored to each individual user. Query groups provide a more efficient, accurate, and maintainable query-level policy than manually created policies and is finer grained than “one-size-fits-all” role-based query policies provided by some products. After all, not everyone fits into neat roles. Different users in the same role may differ significantly in their queries and those differences may be critical to establishing strong security policy. The primary drawback to existing database activity monitoring products is their inability to provide insight into the mountain of data they generate. Most solutions cannot distinguish between normal variations in user activity and significant attack indicators. Those that claim to provide accurate attack alerts require continuous tuning and therefore do not provide dependable alerts. As a result, most solutions simply log database activity for audit purposes. The Query Groups component of the SecureSphere Dynamic Profile bridges this gap by automatically identifying consistent behavioral patterns for each user. By comparing all new queries to previously established patterns for each user, SecureSphere is able to distinguish between attacks and harmless variations in normal activity. Query groups are specifically represented in the Dynamic Profile as pairs of database tables and table operations (e.g.Table1,

Page 12 Imperva


Select and Table2, Update). These are derived from the queries of a particular database user based on SecureSphere’s Dynamic Profiling algorithms.

Query Groups Example A company’s sales staff regularly accesses a customer database using a custom reporting application. The application issues queries in the following format.

Select * from Accounts where SalesRep = ????

Select * from Accounts where SalesRep = ???? and Name = ????

The value of SalesRep and Name in these queries changes depending upon the sales person and which customer account he wants to view. This type of usage pattern for an individual sales person, lets call him Jim Smith, is represented within the Dynamic Profile by Query Groups as illustrated in the table below.

User Query Group Specific Queries

Jim Smith

(Accounts, Select)

Select * from Accounts where SalesRep = ???? Select * from Accounts where SalesRep = ???? and Name = ????

Now consider a privilege abuse scenario in which Jim Smith decides to use his login credentials to access the database using a generic SQL client such as SQL Plus. Using the client, he issues an unauthorized query for the purpose of increasing the credit limit of one of his accounts. The specific query issued by Jim Smith and observed by SecureSphere is as follows.

Update Accounts set CreditLimit = 100,000 where AccountNumber = 1234 SecureSphere immediately compares this query to Joe’s previously established patterns and recognizes deviant behavior. The use of the Update command in combination with the Accounts table does not match Jim’s existing Query Groups. SecureSphere will also detect use of SQL Plus client as a violation of his existing profile. At this point SecureSphere would alert an administrator (and perhaps block Joe’s query depending on the company’s established policy). Static and Dynamic Query Groups SecureSphere automatically classifies query groups and enforces policy according to static and dynamic usage models. In some cases, a user or application will access a database with a static (or rarely changing) set of queries within a given query group. For example, a sales reporting tool that provides sale people with a report of their customers’ purchases would have a fixed set of queries in the following format.

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Accounts.SalesRep = ????

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Accounts.SalesRep = ???? and Accounts.Name = ????

Page 13 Imperva


SecureSphere automatically recognizes this fixed behavior pattern and classifies the query group (Accounts, Select) (Sales, Select) as “static”.


Jim Smith

(Accounts, Select) (Sales, Select)

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Accounts.SalesRep = ????

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Accounts.SalesRep = ???? and Accounts.Name = ????

In the context of a static query group, even a single new query is an unusual event and therefore, generates an alert or blocking action. For example, if a sales person about to jump to a competitor wants a list of the company’s biggest customers, he might try to get the contact information for customers with purchases over $100,000 with the following query.

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Sales.SalesAmount > 100,000

SecureSphere would recognize this as outside his set of fixed queries and immediately issue an alert or block according to policy. In other cases, the list of queries that make up a given query group is constantly growing. SecureSphere automatically recognizes the unbounded nature of this overall behavior pattern and classifies the related query group as “dynamic”. A financial analyst, named Jackie Jones, is an example of a user who would have dynamic query groups. All query activity for examining customer sales is represented by a single dynamic query group (Select, Accounts, Select, Sales). But the list of specific queries for assessing customer sales is constantly growing because of the wide variety of queries such an analyst might need to run.


Jackie Jones

(Accounts, Select) (Sales, Select)

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Accounts.AccountName = ????

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Sales.SalesAmount > ????

Select * from Accounts, Sales where Accounts.AccountNum = Sales AccountNum and Accounts.IndustryNIACS = ????

Each new query that matches the query group (Accounts, Select) (Sales, Select) is added to the profile for audit purposes. In the context of dynamic query groups, new queries are not unusual events and do not justify repeated alerts. However when the financial analyst suddenly attempted to modify the sales table with the UPDATE operation, SecureSphere would recognize this as outside his query group and correctly issue an alert.

Page 14 Imperva


Custom Policy Definition In addition to the automated policy definition provided by Dynamic Profiling, SecureSphere allows security administrators to define specific policies to generate alerts and optionally block traffic based on specific attributes of SQL queries. Custom policy rules are manually configured and provide the power to perform operations that are not available or convenient to implement via the profile and protocol violation rules.

When an SQL query matches a certain custom policy rule, an alert is recorded for audit and the query may be blocked according to policy for that customer policy rule

Custom policy rules can incorporate any of the following attributes:

• Source IP Addresses: The source IP address from which the query came. • Tables: The database table names that appear in the query. • Operations: The database operations that appear in the query (for example Select or

Update). • Applications: The source application that was used to generate the query. • Users: The database user that generated the query. • SecureSphere Violations: Profile, protocol, firewall, and signature violations that were

triggered by this SQL query. Matching violations across these layers provides a flexible and powerful mechanism for enforcing security policy.

Page 15 Imperva


SecureSphere Security - Assessment, Audit, Protection This section describes how SecureSphere applies its core security technologies to the problem of database security.

Assessment of Database Usage The first stage of securing a database is understanding its usage. As described in the previous section, SecureSphere’s Dynamic Profiling examines live database network traffic to build a baseline model of usage and automatically creates database usage security policies. Administrators can easily grasp appropriate database usage by reviewing the profile. This is especially useful for security and compliance teams that are not experts in database technology. The role based administration supports “view-only” access so that users who need to assess usage (but not administer SecureSphere) can have access to this wealth of information. If needed, administrators with management privileges can make any desired modification to the profiled policies to align them with corporate security or compliance guidelines. An example of the power and simplicity of information presented in the profile is the concept of Query Groups, which model legitimate business activities. Query Groups are represented in the Dynamic Profile as pairs of database tables and table operations (e.g.Table1, Select and Table2, Update). These Query Groups are derived from the queries of a particular database user based on SecureSphere’s Dynamic Profiling algorithms.

Query Groups identify normal business activities by grouping all queries which access the same

set of tables (e.g., book_of_the_week) and use the same operations (e.g. select).

Page 16 Imperva


Database Vulnerability Profiling In addition to providing granular insight into databases usage, SecureSphere also provides insight into potential database usage vulnerabilities. Many vulnerabilities are dependent on the specifics of a database’s deployment or usage and only become apparent by observing live database user activity after a database has been placed in production. SecureSphere’s database vulnerability profiling provides a continuous, consistent and comprehensive method to identify security vulnerabilities and risks created by deviations from best practices. It also identifies security vulnerabilities introduced due to configuration complexity in the production environment. For example, SecureSphere can identify non-administrative access to default stored procedures, default user accounts, and system objects – all of which violate database security best practices. SecureSphere’s vulnerability profiling readily identifies database vulnerabilities that other vulnerability tools are not designed to detect, making it a valuable complement to traditional penetration testing and vulnerability scanning tools. A few examples of SecureSphere’s vulnerability profiling reports include the following.

• Database Default Packages And Stored Procedures Assessment highlights usage of default stored procedures by non-administrative users. Best practices usually recommend against the use of default stored procedures by non-administrative users.

• Database Users Assessment lists active default database accounts that best practices usually recommend should not be used by non-administrative users.

• Database System Objects Access Assessment - This report lists the non-administrative users accessing database system objects. By default, these objects are accessible to any user. However, most system objects contain information that should not be used by non-administrative users.

Database Audit SecureSphere can collect a rich set of audit data and provides built in reporting capabilities flexible enough to meet all internal or external compliance requirements.

Database Activity Auditing SecureSphere supports the entire spectrum of database activity logging. Administrators can specify multiple audit logs and each log can be individually configured for selective or comprehensive logging. Comprehensive logging includes all database activity by all users, including database administrators who access the database from the server console. Selective logging can be configured for any combination of attributes, including users, source IP addresses, tables accessed, SQL operations used, source applications, days of the week and time of day, stored procedures, and privileged SQL operations. As a network device, SecureSphere logs this audit data with complete independence from all database users including database administrators and developers. This enables proper separation of duties between database teams and the audit or security teams. Moreover, audit logging is accomplished without affecting database performance, stability, or administration.

Page 17 Imperva


SecureSphere audit rules can be defined to log all database access or to log only specific queries

or operations of interest.

Real-Time Alert Auditing The primary drawback to other database activity monitoring products is their inability to provide insight into the mountain of data they generate. Most solutions cannot distinguish between normal variations in user activity and truly malicious or non-compliant activity. SecureSphere provides more than just undifferentiated activity logging. SecureSphere can identify the activity that “really matters” in real time and present a prioritized view of all potentially dangerous user activity including attacks on the database application and the database platform. Reports can include current alerts or historical alerts for any time period with the ability to sort, filter, and aggregate based on any parameter of the alerts. Other database security solutions do a poor job of handling dangerous activity that generates multiple alerts. They treat each alert individually, potentially obfuscating the real problem underneath a mountain of related alerts. SecureSphere provides intelligent attack summaries that aggregate multiple alerts caused by complex attacks into a single actionable alert with the underlying events still available for detailed forensics. For example, thousands of related scanning alerts are aggregated into a single attack alert.

Page 18 Imperva


Audit reports consolidate data from multiple gateways. Data may be searched or sorted based upon a variety of parameters.

User Profile Auditing For compliance and audit teams, the user profiles provide a powerful tool for understanding actual user behavior and comparing it to best practices or compliance requirements. The format and content of the profile information is especially useful for individuals that are not experts in database technology. Audit reports can include any of the data in the current user profiles or reports can document any changes in the profile over time, such as the addition of addition of new users or changes in a user’s allowed days and times of usage. This change notification reporting can be particularly useful for tracking the deployment of new database features and adherence to change control processes.

Database Protection

Database Application Protection SecureSphere continuously compares live user interactions to the dynamic database profile. Significant deviations from the profile generate an alert and can be optionally blocked according to policy. Unique business activity analysis and correlation technologies separate harmless variations in user behavior from real attacks. For example, SecureSphere define sets of business activities (query groups) that are part of a user’s consistent behavioral patterns. By comparing all new activity to such previously established patterns, SecureSphere is able to distinguish between harmless variations in normal activity and truly malicious behavior. For example, if a user uses a new query that matches an existing business activity, SecureSphere simply issues an informative alert and logs the query for future audit. Conversely, if the new query does not match any

Page 19 Imperva


existing business activities, SecureSphere generates an alert and the query can be optionally blocked according to policy. For example, if a direct mail marketing specialist who normally pulls information only from customer address tables, begins to access credit card information in a different table, this represents a potentially malicious change in user activity. SecureSphere would issue an alert and optionally block this activity.

Suspicious queries are recorded for audit and may be blocked according to policy.

Page 20 Imperva


Deviations from the Dynamic Profile (e.g. Unauthorized Database Users) generate Alerts and may be blocked depending upon severity.

Custom Policy Enforcement In addition to security policies based on the profiles, administrators can define custom policies at whatever granularly is desired. For example, administrators can set policies for queries accessing system objects or even queries containing specific text patterns. Policy violations can generate an alert or immediately block the activity.

Database Platform Protection SecureSphere includes an integrated Intrusion Prevention System that provides protection against attacks targeting known vulnerabilities in database and platform/OS software (e.g. Oracle, Linux, and Windows 2000) with an integrated Intrusion Prevention System (IPS). SecureSphere IPS capabilities include a full Snort®-compatible signature database and proprietary database-specific signatures from the Application Defense Center (ADC), Imperva’s international security research organization. The ADC also enhances the Snort-compatible signature database with contextual attributes such as affected systems, risk, accuracy and attack frequency to enable users to customize IPS policies for their specific environment. Imperva’s Data Center Security Update Service provides automatic signature updates ensuring that the most current protections are continuously enforced. SecureSphere’s integrated stateful network firewall protects against unauthorized users, dangerous protocols, common network layer attacks and worm infections. Access control policies support both black and white listing of protocol/IP address combinations to eliminate data center

on-essential or dangerous protocols such as Telnet, PC Anywhere, or even SQL. exposure to n

Page 21 Imperva


Automatic security updates

ensure that the most current protections are continuously enforced.

Identification of Sophisticated Attacks To identify sophisticated attacks, Imperva’s unique Correlated Attack Validation (CAV) technology correlates multiple violations to validate that an activity represents an attacks rather than simply the normal deviations found in legitimate user activity.

Unlike competing products which identify an attack based on a single violation, CAV correlates multiple security violations over time, between security layers (profiles, custom policy, IPS, network firewall, etc.) and between SecureSphere gateways. For example, a new query by itself does not represent an attack; nor does a request to access a legitimate stored procedure with known vulnerabilities. However, if both events occur in the same request, CAV identifies the combination as an SQL Injection attack (since it is both a new activity and one that accesses a high-risk stored procedure). SecureSphere will alert and optionally block such a request.

Page 22 Imperva


SecureSphere Deployment This section describes how SecureSphere’s technical architecture supports seamless deployment into existing environments.

Transparent Inspection Imperva’s Transparent Inspection technology delivers multi-gigabit performance, sub-millisecond latency, and options for high availability that meet the requirements of the most demanding database environment. Transparent Inspection makes it possible for SecureSphere to be deployed in minutes with no changes to the database or any other aspect of the data center infrastructure. From a security perspective, inspecting the upper layers of the OSI model and beyond is required to deliver protection. From an operational networking perspective, the chief desire is for seamless, transparent operation. As such, from the perspective of how a device functions as a networking node, operating at lower layers is desirable for application security solutions. Transparent Inspection allows SecureSphere to operate at layer 2 of the OSI model as a transparent bridge, or at layer 3 as a network router. SecureSphere intercepts traffic at layer 2 or 3 and reconstructs the upper layers of the stack in order to inspect application and database behavior.

No Database Overhead / High Performance SecureSphere’s network-based appliance deployment does not consume database server computing resources unlike the native or host-based approaches. A single SecureSphere gateway is sufficient to meet the needs of multiple database servers and deploying multiple gateways with centralized management SecureSphere can scale to meet the needs of the largest enterprise. SecureSphere delivers multi-gigabit throughput while maintaining sub-millisecond packet latency. This level of performance is an order of magnitude better than competitive products. This difference is due to SecureSphere’s Transparent Inspection kernel-level processing architecture, which can process a high number of transactions with low latency.

No Changes to Database Infrastructure SecureSphere can be deployed with complete transparency to surrounding database infrastructure. As a network device it does not require database server administrative privilege or host software installation. Changes or upgrades to database server software require no corresponding changes to SecureSphere. SecureSphere requires no changes to existing IP address configuration, routing schemes, or database application code. In short, SecureSphere deployment and operation may be completely de-coupled from database administration. It can therefore be quickly and easily deployed (by the security or compliance team) into any enterprise’s carefully optimized data center without disruption of existing infrastructure.

Page 23 Imperva


High Availability Transparent inspection underlies SecureSphere’s ability to support a range of options2 to ensure maximum uptime and application availability.

• Redundant gateways can be deployed in environments with redundant system

infrastructures. SecureSphere supports both active-passive and active-active fail-over configurations to ensure continuous data availability and security.

• Inline/fail-open network interfaces enable single-gateway deployment while preserving

data availability in the event of hardware, software or power failures.

• Offline Network Monitor/Sniffer mode enables single gateway deployment without introducing any single point of failure. Network monitoring mode is achieved by connecting SecureSphere via the span/mirror port of a network switch or a TAPS device.

SecureSphere Active-Active Configuration

Load Balancers

SecureSphere

Switches

Load Balancers

SecureSphere

Switches

Normal Operation Failure / Recovery

SecureSphere supports a range of high availability options.

2 For detailed information on SecureSphere’s networking deployment and high availability options, please refer to the SecureSphere Networking Deployment Note.

Page 24 Imperva


SecureSphere Operations This section describes SecureSphere’s management and configuration capabilities for supporting ongoing maintenance of a database security deployment.

Independent Security Because SecureSphere is a network-based appliance solution, enterprises have the option of preserving the separation of duties that exists between most security managers and database administrators. SecureSphere requires no database server administrative privilege or host software installation. SecureSphere deployment and ongoing operations may be carried out by network security personnel without any impact on database management resources. Not only does this model fit most enterprise organizational structures, but it also complies with best practices by preserving the independence of the security function. By comparison, native database security and host-based approaches rely heavily upon database administrators for deployment, configuration, and ongoing policy management.

Automated Database Security SecureSphere delivers comprehensive database monitoring and policy enforcement without the cost of manual operational processes. The Dynamic Profile (including the query groups) represents an automatically developed and maintained role-based security policy tailored to each individual user. There is no need for security managers to manually develop and maintain detailed policies governing allowed behaviors of each user. Query groups separate normal deviations in user behavior from significant threats eliminating the operational burden of false positive alerts. As for platform attack protection, all IPS signatures are automatically and continuously updated. The final result is a security investment that maximizes attack protection and audit capabilities while minimizing total cost of ownership.

Centralized Policy Management, Monitoring, and Reporting Successful data center management requires mature management tools which scale across large multi-gateway environments. To meet this requirement, the SecureSphere MX Management Server serves as the focal point of a three-tier management architecture that automates the task of managing large multi-gateway deployments. Rather than require each gateway be managed individually, the Management Server provides a single point for aggregating policy, real-time monitoring, logging, and reporting activity across multiple SecureSphere gateways. For example, a report analyzing high-priority security alerts across ten distributed gateways requires a few simple clicks report. By comparison, less mature two-tier management infrastructures require that security managers connect to ten separate devices, collect ten alert files, and run ten separate reports using a third-party reporting product.

Page 25 Imperva


MX Management Server Capabilities Specific SecureSphere multi-gateway management capabilities include the following.

• Graphical Reporting - Both pre-configured and customized reporting is supported with a

full Crystal Reports™ package and ODBC-compliant database access. Pre-configured reports provide immediate visibility into performance, regulatory compliance, security alerts, and usage anomalies.

SecureSphere provides unified reporting across the entire enterprise

• Alert Auditing – Alerts from multiple gateways are collected and stored in a single MX

Management Server database. To support audit initiatives, alert entries can be sorted and searched based upon a variety of parameters with a few clicks. Even specific user violations (identified by session ID or IP address) originating from different SecureSphere security services (IPS, Dynamic Profile, etc.) may be instantly traced.

• Intelligent Attack Summaries –Intelligent attack summaries improve administrator

productivity by intelligently aggregating a sequence of events caused by complex attacks into a single actionable alert. For example, related scanning alerts are aggregated into a single attack alert instead of thousands. This highly focused information allows administrators to quickly understand threats precisely when rapid and effective response is critical. Aggregated alerts preserve underlying events for detailed forensics.

• Centralized Policy Distribution – Dynamic Profile, IPS policy, and system parameters

for multiple gateways are stored centrally on the MX Management Server. Changes are made on the server and automatically distributed to multiple gateways with a single click.

• Unified Real-Time Alert Monitoring – Real-time alerts originating from multiple

SecureSphere security layers (Dynamic Profile, IPS, etc.) are collected, prioritized and presented to the administrator within a single unified view. Alerts notifications may be sent via email, phone, pager, and SNMP messages. There is no need to connect to individual devices distributed throughout the data center. Log data from multiple gateways are also presented in a single view and stored in a single MX Management Server database.

Page 26 Imperva


Summary SecureSphere Database Security Gateway is designed from the ground up to meet the policy assessment, audit, and protection requirements of mission critical databases. Dynamic Profiling and IPS capabilities deliver automated security for all relevant attack vectors. Transparent Inspection delivers multi-gigabit performance, rapid deployment, and high availability. Finally, the MX Management Server enables the scalability to secure the largest data center environments.

US Headquarters

950 Tower Lane Suite 1710

Foster City, CA 94404 Tel: (650) 345-9000

Fax: (650) 345-9004 www.imperva.com

International Headquarters

12 Hachilazon Street Ramat-Gan 52522

Israel Tel: +972-3-6120133

Fax: +972-3-7511133

© 2004 Imperva, Inc. All rights reserved. Dynamic Profiling, Dynamic Profiling Firewall, Imperva, SecureSphere and Total Application Security are trademarks of Imperva, Inc. All other brand or product names are trademarks or registered trademarks of their respective holders.

Page 27 Imperva

http://www.imperva.com/

Database Security with the SecureSphere Database Security Gateway

Documents

protection database

database attacks

effective database security

database assessment

entire database

end database

data layer database

database usage assessment