Hedgehog: Host-Based Database Activity Monitoring & Prevention

Transcription

1 Whitepaper Hedgehog: Host-Based Database Activity Monitoring & Prevention Including: Introduction to database security, activity monitoring and intrusion prevention Unique benefits of host-base monitoring and introduction to deep memory scanning technology Sentrigo s Hedgehog architecture and features By Slavik Markovich, CTO Version 2.0, April

2 THE CHALLENGE: SECURING THE DATABASE Much of the effort in recent years to secure corporate IT infrastructure has focused on the perimeter how to defend the enterprise from external intruders, from hacking and from malicious attacks. The corporate network has also seen its share of improvements in security, providing a further layer of protection. The data layer, however, remains the soft underbelly of enterprise IT infrastructure. Databases hold much of the most sensitive and valuable data information about customers, transactions, financial performance and human resources to give a few examples. Despite this, databases remain one of the least protected areas in the enterprise. While perimeter and network security measures create a barrier against some type of attacks, they are inadequate against attack vectors that take advantage of database-specific vulnerabilities, and offer little or no protection from insider abuse, especially when dealing with privileged users who are not only inside the perimeter but are also capable of circumventing application-level security. SQL injection, buffer overflow attacks and other zero-day hacks can cut right through Web firewalls, application firewalls and intrusion detection systems (IDS) and create opportunities for data theft, unauthorized modification or destruction of data, or breaches of privacy and personally identifiable information. Since database management systems are complex, supporting an ever growing set of requirements and platforms, with addition of features they develop gaps in security vulnerabilities that are constantly being discovered by users, ethical hackers and nonethical hackers as well. Such vulnerabilities are reported to DBMS vendors who do their best to patch them, but this is a process that currently takes several months on average, years in some cases. This time lag is an open invitation to exploit the vulnerability and breach the database. Additionally, there is growing recognition that the insider threat, and specifically the threat posed by users with privileged access, is responsible for a large number of data breaches. According to annual research conducted by CERT, up to 50% of breaches are attributed to internal users. The 2007 FBI/CSI report on the insider threat notes that two thirds of surveyed organizations (both commercial and government) reported losses caused by internal breaches, and some attributed as much as 80% of the damage to internal breaches. It was also reported that 57% of implicated insiders had privileged access to data at the time of breach. It is therefore evident that perimeter and network security measures are not enough to stop such breaches Sentrigo Inc., All rights Reserved Page 2

3 Finally, legislation and regulatory requirements such as Sarbanes Oxley for public companies, HIPAA in healthcare, GLBA in financial services and the credit card industry s PCI DSS all mandate that companies and organizations take certain measures to ensure the privacy, integrity and security of sensitive data. Most compliance requirements stress the importance of monitoring privileged users, having full traceability and accountability of their actions. The evolution of security threats vis-à-vis the existing infrastructure paints a clear picture databases need protection on a granular, intimate level, using tools that can handle database-specific threats on the one hand, and deal with the insider privileged user on the other hand. EXISTING COMPONENTS OF DATABASE SECURITY There is a wide array of technologies and tools currently in use for securing various aspects of database use. As with other areas of IT security, no single tool can provide ironclad defense against all threats and abuses. It is always recommended to employ a combination of tools to achieve adequate security. Following is a brief overview of existing categories of tools that can be found in use across enterprises large and small. Authentication and Access Control PROS: Establishes roles and privileges, the most basic level of security CONS: Difficult to enforce properly, over-liberal granting of access, privilege creep, open to hacking, privileged users have free reign The ability to designate roles, logins and passwords is the most basic level of database security, and is very widely used. It establishes the basic privileges of different users and ensures that each user and application access the database to the extent that they need to do so. However, this mechanism assumes that users are generally well behaved, and that their access rights are managed according to policy. This is often not the case. Granting of excessive privileges is commonplace, as is privilege creep where users gain privileges over time without having redundant ones revoked. It is also common to have group usernames and passwords and to forget to revoke privileges of employees who no longer need them. So while such mechanisms are necessary, they do not suffice even to limit authenticated user access. Additionally, they are vulnerable to exploits (e.g., SQL injections that escalate privileges) Sentrigo Inc., All rights Reserved Page 3

4 Native Database Audit Tools PROS: Provide granular audit trail and forensics of database activity CONS: Can negatively impact database performance, no separation of duties easy to turn off and manipulate, provides only after-the-fact forensics, no prevention capabilities Most DBMSs come with features that enable granular auditing of particular database activities. In the case of highly transactional environments, however, or when DML statements need to be audited, the performance impact can be detrimental. For this reason auditing is only used very selectively. Furthermore, because auditing is a native DBMS feature, it is administered by DBAs which does not maintain segregation of duties, mandates by most security and compliance policies. Auditing is not a viable solution for monitoring the DBAs themselves, as well as other users with privileged access rights to the DBMS, because they can turn auditing on and off as they please, or manipulate the logs after the fact. Vulnerability Assessment PROS: Detects weak database configuration and security holes CONS: Is run periodically (not always on ), does not offer remediation of security gaps, cannot detect abuse of privileges Vulnerability scanners and other tools that provide a more comprehensive assessment of database configuration are a valuable addition to database security, but since they are used periodically (every month or once a quarter), leave many gaps in between scans. Ultimately, a vulnerability assessment may tell you where there are potential security holes in your database, but it will not tell you whether they ve already been exploited or not, and will not fix them for you, which makes the hardening of a large scale database deployment an arduous chore. Encryption PROS: Protects sensitive data CONS: Slow and expensive to implement correctly, key management overhead, performance impact, difficult to manage 2008 Sentrigo Inc., All rights Reserved Page 4

5 Column-level or table-level encryption within the database ensures that sensitive data such as credit card numbers cannot be viewed by users having general access to the database (e.g. via a CRM application) as well as segregation of duties. Column-level encryption is a 2-3 year project for most companies when it comes to encrypting existing databases. This makes it both impractical and expensive for many applications. Additionally, encryption alone is insufficient, because it is often decrypted for communication with applications, and this creates an opportunity for accessing the encrypted data. INTRODUCING DATABASE ACTIVITY MONITORING (DAM) Database activity monitoring (DAM), sometimes also referred to database intrusion prevention or extrusion prevention, is a relatively new set of protections targeted specifically at databases. We have seen that the range of security tools commonly available for databases are helpful in managing user rights, protecting sensitive data and finding faults in the database configuration. Those tools fail to provide (separately or combined) several important aspects that are required for regulatory compliance and adherence to best-practices in IT security: Segregation of duties between security and database administration & development Misuse or abuse of privileges given to insiders (and required for their jobs) Attacks on the database that exploit vulnerabilities and cannot be stopped by perimeter security mechanisms Database activity monitoring was invented to address those gaps and provide visibility into the activity that takes place in the databases, issue alerts when suspicious activity is detected, and in some case prevent or stop such activity from taking place. THE NETWORK APPROACH TO DAM The first generation of dedicated DAM tools was largely made up of network-based appliances. These network-based hardware solutions monitor network traffic looking for SQL statements, analyzing the statements based on policy rules to create alerts on illegitimate access to the database and attacks. Because the appliances monitoring only the network, they do not have visibility into local database activity, essentially leaving the database vulnerable to insiders that either have local access or are savvy enough to bypass 2008 Sentrigo Inc., All rights Reserved Page 5

6 the appliances. In order to provide adequate coverage, the appliance must be deployed at every choke point on the network where the database is accessed, encircling the database from all sides. For mission-critical databases that are often tied into a multitude of applications (ERP, CRM, BI, billing etc.), this significantly raises the cost, which is high to begin with. Aside to the cost issue, the network approach has several fundamental flaws: No coverage of local access to the database If you are capturing and analyzing packets from the network, local access using IPC mechanisms (or even TCP) will not be visible. To overcome this problem, some vendors introduced host-based agents as add-ons their network appliances. This approach (both installing on the host itself and in the network infrastructure) removes the only advantage that network appliances have the fact that their installation is more or less non-intrusive. Worse still, the local agents can monitor TCP traffic on the host or IPC communications, but they suffer from being even more intrusive since they must be implemented as a kernel module, making them hard to install and maintain. To truly monitor the database, it is not enough to capture network traffic, even if you are able to monitor IPC kernel calls. Let us illustrate this with a simple example: We would like to monitor all access to the customers table. All monitoring tools will alert on the following query select * from customers But what will happen when the next query is run: select * from v_cust? Where v_cust is a view based on the customers table. For monitoring tools to actually catch this they will have to load and cache all views from the database and understand that the v_cust view is actually selecting from the customers table. This deficiency extends to other objects like synonyms, triggers and stored program units (functions, procedures and packages). In order to understand if a procedure is accessing a specific table, one must parse the procedure and understand all procedure branches and cases. No network monitoring tool has ever done this and it is not feasible (the monitoring product will need to possess a lot of the DBMS s internal logic to do this). Pattern Matching Does Not Work Another area where the network approach is lacking is trying to perform pattern matching to catch suspicious activity. For example, a monitoring tool can be configured to catch grant dba commands. When a hacker tries to mount an SQL Injection attack using a known Oracle vulnerability such as: 2008 Sentrigo Inc., All rights Reserved Page 6

7 DECLARE MYC NUMBER; BEGIN END; MYC := DBMS_SQL.OPEN_CURSOR; DBMS_SQL.PARSE(MYC, 'declare pragma autonomous_transaction; begin execute immediate ''grant dba to public''; end;',0); sys.kupw$worker.main('x',''' and 1=dbms_sql.execute(' myc ')--'); Most monitoring tools will issue an alert because they will match the pattern of grant dba and the existence of a vulnerable package. If the hacker is smarter than that, he will try to evade detection by performing the same attack differently: DECLARE MYC NUMBER; BEGIN END; MYC := DBMS_SQL.OPEN_CURSOR; DBMS_SQL.PARSE(MYC,translate( 'uzikpsz fsprjppnmghgjgna_msphapimwgh) ozrwh zczinmz wjjzuwpmz (rsphmuop mg fnokwi()igjjwm)zhu)', 'poiuztrewqlkjhgfdsamnbvcxy()=!','abcdefghijklmnopqrstuvwxy z'';:='),0); sys.kupw$worker.main('x',''' and 1=dbms_sql.execute (' myc ')--'); Notice that there is no longer grant dba in the text and the network bases protections will be blind to what is really going on. To complicate things further, a hacker could also disguise the call to the vulnerable function using the same technique. The Challenge of Data-in-Motion Encryption Database traffic can be encrypted using vendor supplied tools or custom made tools like SSH tunneling. As soon as data leaves the DBMS, it is encrypted. For network-based monitoring tools to capture this type of traffic, an enterprise must compromise its private keys and 2008 Sentrigo Inc., All rights Reserved Page 7

8 share them with the monitoring appliance or application. This is only one part of the data-inmotion encryption problem database code can also be encrypted and decrypting it in real time is not possible (even if the encryption algorithm is known (and for some vendors like Oracle it is not public). If we create a function like the following one it will raise the suspicion of the monitoring tools: CREATE OR REPLACE FUNCTION get_dba RETURN VARCHAR2 AUTHID CURRENT_USER IS BEGIN END get_dba; PRAGMA AUTONOMOUS_TRANSACTION; EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT'; RETURN 'Hacked'; However, creating the function using the built-in wrap utility will not sound any alarms: CREATE OR REPLACE FUNCTION get_dba wrapped a b2 abcd abcd abcd abcd abcd abcd abcd abcd abcd abcd abcd abcd abcd abcd abcd 8 a6 db 7EiybMnZ7oeJndiapoeSr+FIvzQwg2LwLcsVfHSikx5kpaeQDbcTdSGEdl1X42LF oobwq7xp RrTcu0G50S40Y2bOeyIQqn4Ofi5EIBo/bAAdKrpeZ5rDk9jEl54mFfVcGFi4d+ny 0TufXvHy nq2ib0qhcaba+mlfphfl9gdauhfaokigrd0fgnhq0p0yhjpplpjkvvvvuiwgz5lh RNVWjA== Incompatibility with Virtualization Virtualization is a growing trend in enterprise IT, and specifically in the data center. The cost savings on hardware, reduced energy consumption and flexibility in pooling resources mean that many environments will become virtualized, including mission-critical production environments Sentrigo Inc., All rights Reserved Page 8

9 When dealing with virtualization security, we are essentially tackling two challenges protecting the host machine itself, and protecting the virtual machine (VM). The Need for a Fresh Approach It is clear that the network-based approach, while initially benefitting from ease of deployment, misses out on some of the base requirements for which database need to be monitored and protected in the first place. Given the blind-spots that the network-based approach presents, a host-based solution could be a much better approach to providing tight protection to databases if it did not suffer from the overhead in performance associated with older technologies. Such an approach would need to use a novel, non-intrusive method of accessing the database. This is the architecture we chose for Hedgehog. HEDGEHOG ENTERPRISE HOST-BASED ACTIVITY MONITORING, AUDITING AND BREACH PREVENTION Older host-based approaches were met with disapproval for having a negative impact on database performance. This was because host-based tools either relied on turning native auditing on, or used the DBMS kernel APIs to interface with the database, a technique that is slow and intrusive as it places itself in the transaction path. So despite the recognition that a host-based approach is a superior choice for handling the key requirements of privileged user monitoring, segregation of duties, and the detection and prevention of exploits real-world limitations meant that the network-based approach became more popular despite its obvious shortcomings. Sentrigo s answer was to directly access the memory allocated to the DBMS by the operating system, especially the shared cache memory (known in Oracle as SGA and in MS SQL as procedure cache), the solution we call Hedgehog Sentrigo Inc., All rights Reserved Page 9

10 Hedgehog Host-Based Based Database Activity Monitoring & Prevention H EDGEHOG A RCHITECTURE Hedgehog is comprised of a small footprint sensor, a software agent that is installed on the database host server itself and monitors all activity activity,, and a JavaEE server that manages multiple sensors Sentrigo Inc., All rights Reserved Page 10

11 Detailed architecture diagram Hedgehog Oracle Sensor Architecture The Hedgehog sensor is a stand-alone process written in C++ and running on the database host machine. It is installed using standard platform tools (RPM, PKG, EXE, etc.) in a separate OS user account that is part of the SYSDBA (ora_dba on Windows) group on the system. The sensor is made to operate independently of the server, and is extremely hard to circumvent or disable without generating alerts Sentrigo Inc., All rights Reserved Page 11

12 The sensor automatically identifies all instances on the machine and can monitor multiple instances on the same host. When running, the sensor attaches itself to the instance shared memory (SGA in the case of Oracle) and begins a polling loop of monitoring by sampling the memory multiple times per second. For every sample cycle, the sensor analyzes the currently running and previous statements for each session in the database instance and determines using pre-defined rules and administrator defined rules what statements should be alerted on. The suspicious statements are sent to the server for further analysis and alerting. The sensor can also be configured to terminate sessions on specific violations and to quarantine users. It is nonintrusive and consumes only a negligible percentage of CPU resources, with zero impact on disk I/O. The sensor prevention capabilities are implemented using DDL triggers that optionally delay DDL and DCL statements for a few milliseconds allowing the sensor to terminate the offending statements in time. The policy rules apply to types of SQL statements, database objects, time of day or day of the month, specific user profiles and the applications used. The action taken when the conditions of a rule are met can be as simple as logging an event, sending an alert to a SIM/SEM system via SNMP, syslog (CEF) or XML API, sending an or SMS, terminating a user session to prevent malicious activity and even quarantine users. The system comes with predefined rules that prevent known attacks that exploit database vulnerabilities including generic rules that prevent zero-day exploits based on context and patterns. These rules, known as virtual patches, are continuously updated by Sentrigo s team of ethical hackers and 2008 Sentrigo Inc., All rights Reserved Page 12

13 2008 Sentrigo Inc., All rights Reserved Page 13

14 Hedgehog Server Architecture A single Hedgehog server can manage and communicate with numerous sensors on different databases, and an enterprise installation can easily scale up to encompass hundreds of databases. The server also easily integrates with IT infrastructure to facilitate central IT management and security event management. The structure of the system also ensures separation of duties, a key requirement in IT security. The Hedgehog system administrator, the person defining policy rules and the person receiving alerts would normally be different people in different departments within the organization (for example, IT manager, DBA manager and CISO respectively). Hedgehog is based on unique and innovative technology, with several patent-pending breakthroughs that enable it to provide the necessary protection on the one hand, but allow business operations to continue uninterrupted on the other Sentrigo Inc., All rights Reserved Page 14

15 HEDGEHOG S UNIQUE ADVANTAGES: The only database monitoring solution that monitors all database activities and provides protection against insiders with privileged access Granular monitoring of database transactions, queries, objects and stored procedures, with real-time alerts and prevention of breaches Flexible rules that allow enforcement of corporate security policy with minimal false positive alerts Virtual patching of newly discovered database vulnerabilities, providing immediate protection with no DBMS downtime Flexible audit and reporting capabilities suitable for PCI DSS, SOX and HIPAA An easy-to-deploy and scalable software solution Multiple user roles that facilitate separation of duties Hedgehog Enterprise is available for free evaluation and is downloadable from Sentrigo s website: Sentrigo Inc., All rights Reserved Page 15

16 ABOUT SENTRIGO Sentrigo, Inc. is an innovator in security software that monitors all database activity and protects sensitive information in real time in order to prevent both internal and external data breaches. Sentrigo s Hedgehog software, including a free version, can be downloaded and easily installed to provide immediate protection against breaches, as well as virtual patching against recently discovered threats with minimal impact on database performance. The product s unparalleled level of protection, coupled with its ease of use, makes it the instant standard for database security and regulatory compliance automation. Sentrigo was named by Network World magazine as one of the top 10 IT security companies to watch in 2007 and received SC Magazine s Rookie Security Company of the Year Excellence Award in For additional information and to download Hedgehog, visit Sentrigo Inc., All rights Reserved Page 16