Worrying About Your Whitelists

Transcription

1 Worrying About Your Whitelists TIPS AND TRICKS FOR DECIDING WHAT TO TRUST IN IBM SECURITY GUARDIUM John Haldeman Enterprise Architect, IBM Champion, Information Insights LLC July 21, 2016

2 Upcoming Tech Talk Rolling your own UI in 3 easy steps Speaker: Joann Ruvolo, Manager and Tech Lead for IBM Security Guardium UI Date and time: August 18, :00 AM PDT, 12:00 AM EDT Register here: 2 IBM Security

3 Guardium community on developerworks bit.ly/guardwiki Right nav 3 IBM Security

4 Agenda Why Filtering is Important (Objective) Making Good Decisions about Filters (Requirements) Blacklisting vs. Whitelisting Specificity Policy Anti-Patterns and Defects in the Wild (Implementation) No Members in Group used in Policy Unreachable Rules Incorrect "All Policies Fire at Once" Assumption Assuming rule order matters with IGNORES IGNORES on Statement Criteria SKIP LOGGING for Object and Command Whitelisting Double-Log Incorrect 1-Violation Expectation A Closer Look at Criteria (Operations) Some Examples of Things You Shouldn t Whitelist Examples of Things That Are Hard to Filter/Whitelist (and something to help) Criteria Reliability Testing Policy and Report Filters with the Universal Feed (Testing) 4 IBM Security

5 Why Filtering is Important

6 In a Nutshell Everything logged/analyzed has a cost DAM security programs do not have unlimited resources Creating large amounts of data means time/ resources are wasted (which is bad for security) This is all about focusing on the right things 6 IBM Security

7 Costs in Monitoring Everything logged/analyzed has a cost Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Audit Data Reports Analyst High Risk Circumstances Alerts SIEM 7 IBM Security

8 Costs in Monitoring Everything logged/analyzed has a cost Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Audit Data Reports Analyst Network Resources High Risk Circumstances Alerts SIEM 8 IBM Security

9 Costs in Monitoring Everything logged/analyzed has a cost Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Audit Data Reports Analyst High Risk CPU/Memory ResourcesCircumstances People Time Managing Guardium Alerts SIEM 9 IBM Security

10 Costs in Monitoring Everything logged/analyzed has a cost Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Audit Data Reports Disk Space and Management Resources Associated with it Analyst High Risk Circumstances Alerts SIEM 10 IBM Security

11 Costs in Monitoring Everything logged/analyzed has a cost Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Alert and Report Audit Data Processing System Resources Reports Analyst ( , Log Space, High Index Risk Costs, etc.) Circumstances Alerts SIEM 11 IBM Security

12 Costs in Monitoring Everything logged/analyzed has a cost Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Audit Data Time Reports Processing Alerts/Report Data Analyst High Risk Circumstances Alerts SIEM 12 IBM Security

13 Limited Resources DAM security programs have limited resources Quotes from the field: I have 10 minutes a day to work with Guardium - Security analyst that manages Guardium for a media conglomerate Guardium is generating too much data - SOX compliance analyst in financial services How much data are we talking about? - Almost every storage and SPLUNK admin I ve spoken to You want how much memory per collector?!?!?! - A very cranky VMWare administrator for a hospital network in the US We are not all constrained by the same things, but there are always constraints 13 IBM Security

14 Focusing on the Wrong Things If you log/report/alert on everything you are treating all pieces of information the same way: 14 IBM Security

15 A Note on Outliers The Analytic Outliers functions are very useful, but no silver bullet Backups/ Archives Long Term Storage STAP Agent Guardium Appliance Audit Data Reports Outliers are processed here on data already logged Unusual Circumstances Alerts SIEM 15 IBM Security

16 Making Good Decisions About Filters

17 Filter Design In a Nutshell There are two main decisions to make when it comes to filter design: Do You Use Whitelists or Blacklists? How Specific Do You Want to Be Your Organizational Context Drives Those Decisions 17 IBM Security

18 Example To illustrate the design choices, let s look at an example requirement for SOX compliance (or general requirement to improve data integrity): Capture all changes to database structure and data occurring by privileged users 18 IBM Security

19 Decompose and define the nouns Changes to Structure DDL Execution (Field: Command) Changes to Data DML Execution (Field: Command) Privileged Users DBAs? (Field: DB User) or Any personal account? (Field: DB User) or Any user logging into the database interactively (not via an application front end)? (Field: Client IP/DB User combination?) 19 IBM Security

20 The Whitelist/Blacklist Decision Description Simple Example Good When Bad When Whitelists A definition of the things that you filter out (the things you don t log/report/alert on) Filter (ignore) DB Users: - APPS - PEOPLE - APPLSYSPUB - SADMIN, You have little understanding of the criteria, or updating the criteria would be difficult to automate You cannot commit to keeping whitelists upto-date (quite often daily updates to Guardium groups) Blacklists A definition of the things you log/report/alert on (filtering out everything else) Filter (ignore) All DB Users Except - FBROOKS - DB2INST1 - SYSTEM - SYS - SA, You have a good understanding of the criteria. If the criteria changes frequently, you have an ability to automate the updates There is no mechanism to update lists automatically Other Notes Whitelists are clearly inherently better (they make no assumptions about the security practitioner s knowledge. But they take effort to keep up to date. You can be worse off if the whitelists are out of date/not updated than if you just used blacklists) 20 IBM Security

21 Back to Our Example Changes to Structure DDL Execution (Field: Command) Low update frequency, relatively easy to get thorough understanding of criteria - manually updated blacklists appropriate Changes to Data DML Execution (Field: Command) Low update frequency, easy to get thorough understanding of criteria - manually updated blacklists appropriate Privileged Users DBAs? (Field: DB User) High Update Frequency. If you have an accessible catalog of DBA users and can automate group population, blacklists acceptable, o/w whitelists Any personal account? (Field: DB User) High Update Frequency. Even if you have accessible catalogs of human database users, you would have to be pretty sure about your assumptions whitelists probably better Any user logging into the database interactively (not via an application front end)? (Field: Client IP/DB User combination?) High update frequency. Difficulty automating and ensure two criteria are kept well up-todate. Very likely use whitelists 21 IBM Security

22 The Specificity Decision The Specificity Tradeoff: The more specific you are, the better it is: Whitelists: Fewer false negatives Blacklists: Fewer false positives Given that a false positive isn t as bad as a false negative, whitelists tend to be more specific, and blacklists broader The more specific you are, the more effort it will take to create and update the criteria 22 IBM Security

23 The Specificity Decision Back to Privileged Users If defined as any user logging into the database interactively (not via an application front end) Let s say you choose a whitelist (define how the applications connect and filter those out), then: Using Just DB Users: 10 Entries for the Filter Using Just Client IPs: 10 Entries for the Filter Using Just Source Programs: 4 Entries for the Filter Using DB Users and Client IPs Together (any combination): 20 Entries ( ) for the Filter DB User and Client IPs Concatenated (specific combinations of DB User ad Client IPs together): Between 20 ( ) and 100 (10 * 10) Entries for the Filter DB User, Client IPs, and Source Program Concatenated (specific combinations): Between 24 ( ) and 400 (10 * 10 * 4) entries Numbers above are just examples for illustration 23 IBM Security

24 Being pretty specific in a Guardium Policy Rule: Number of Entries to Populate/Maintain: A + B + C 24 IBM Security

25 Being very specific in a Guardium Policy Rule : Number of Entries to Populate/Maintain: Between MIN(A, B, C, D, E) and A * B * C * D * E 25 IBM Security

26 Being very, very specific in a Guardium Policy Rule : Number of Entries to Populate/Maintain (7 tuple new in V10.1): Between MIN(A, B, C, D, E, F, G) and A * B * C * D * E * F * G 26 IBM Security

27 Policy Anti-Patterns and Common Defects

28 No Members in Group Used in Policy When you have an empty group, it means that criteria is always satisfied. The following rule ignores everything: 28 IBM Security

29 Unreachable Rules Rules without Continue to Next Rule are blocking (stop evaluation on rules beneath). Sometimes that s what you want, sometimes it isn t. Rule 2 below will never be reached: 29 IBM Security

30 Avoiding Unreachable Rules Try to order policies in order of specificity the more specific rules at the top, the less specific rules below Use Continue to Next Rule when it makes sense to 30 IBM Security

31 An Incorrect "All Policies Fire at Once" Assumption Policies are evaluated one at a time (serially), not all at once. Rules that stop evaluation (block) in Policy 1 will affect execution of rules in Policy 2 Another way to think about this: Having these two policies installed at once is the same as having one policy installed that has all the rules of Policy 1 in it followed immediately by the rules in Policy 2 If you have difficulty visualizing View Details Report will show you the concatenation in a report that makes the rule order obvious 31 IBM Security

32 Assuming rule order matters with IGNORES IGNORES affect sessions (SKIP LOGGING affects a statement). In the following policy, no statements will be logged except for those sessions where the first statements are GRANTS (which is very unlikely). This is the case even though the IGNORE rule shown is above the logging rule. 32 IBM Security

33 IGNORES on Statement Criteria In general, if you see an IGNORE action applied to a rule that includes OBJECT/COMMAND criteria, it s a defect. The following throws away the command and the rest of the session if an object that starts with # is accessed very unlikely to be what was intended Something like SKIP LOGGING would be better, but watch out for the next problem 33 IBM Security

34 SKIP LOGGING for Object and Command Whitelisting If you see something like this: SKIP LOGGING if accessing a non-sensitive object like DUAL 34 IBM Security

35 SKIP LOGGING for Object and Command Whitelisting Assuming the next rule logs everything else, the following is the result: Logged Skipped Looks like it s working but 35 IBM Security

36 SKIP LOGGING for Object and Command Whitelisting Skipped Skipped 36 IBM Security

37 The Double Log Alerts (other than ALERT ONLY) create policy violations (which you can report on). So, why are you logging to the ACCESS domain as well? Sometimes there are legitimate reasons, but keep in mind you are logging very similar information in two different places 37 IBM Security

38 Incorrect 1-Violation Expectation For Alerts other than ALERT ONLY, keep in mind policy violations are logged for every match 38 IBM Security

39 A Closer Look at Session Criteria

40 Some Examples of Things You Shouldn t Whitelist Good news no matter what your policy, Guardium always logs session data (a few exceptions include mainframe datasources) this means you can ignore all sessions and build pretty detailed whitelists before logging constructs/full SQL/policy violations Start by identifying things you know you shouldn t whitelist. Process: Use DB and OS Users to find direct access usernames exclude these from a whitelist immediately Using that information (and some general knowledge about databases), remove any direct-access source programs Look for workstation IPs and remove those Removing these obvious entries on a first pass can help reduce the number of application-like session profiles you need to review 40 IBM Security

41 Some Examples of Things You Shouldn t Whitelist Just a sample of things you can remove from consideration for a whitelist out of hand: Client IP DB User Name Source Program OS USER CORP\BBHSINGF MICROSOFT SQL SERVER MANAGEMENT STUDIO CORP\BBHSINGF CORP\BBHSINGF MICROSOFT SQL SERVER MANAGEMENT STUDIO - QUERY CORP\BBHSINGF MICROSOFT SQL SERVER MANAGEMENT STUDIO - TRANSACT-SQL CORP\BBHSINGF INTELLISENSE CORP\BBHSINGF C:\PROGRAM FILES\QUEST SOFTWARE\TOAD FOR ORACLE DBO 12.1\TOAD.EXE FBROOKS FBROOKS C:\PROGRAM?FILES??X86?\MICROSOFT?OFFICE\OFFICE14\MSACC ESS.EXE FBROOKS FBROOKS SQLPLUS FBROOKS 41 IBM Security

42 Examples of Things That Are Hard to Filter/Whitelist Some things could be either a direct access user or a application/batch process. For instance, this could be a direct access user or batch script DB USER Source Program Client IP OS USER ADMIN SQLPLUS NCRSHM Client Side UID Chaining can provide the distinction between a DBA and a script (whitelist batch processes at report level) 42 IBM Security

43 Client-Side UID Chaining? STAPs can be set up to monitor outgoing traffic on a database client just as they normally monitor incoming traffic on a database server Database Server Traffic from everywhere except the batch server Guardium Appliance Traffic from the batch server Batch Scripting Server Local STAP allows for UID Chain Reporting From DB Client STAP Agent 43 IBM Security

44 Client-Side UID Chaining - Configuration 1) Install STAP on Database Client 2) Enable UID Chaining as normal (hunter_trace = 1) 3) Set App Server User Identification to 1 (enables outgoing traffic forwarding) and add the IP of the database server to the Alternate IP list 44 IBM Security

45 Client-Side UID Chaining Configuration Cont 4) Filter out the server where you installed the client-side STAP from the server-side inspection engine (prevents duplicate traffic being recorded for that client) 45 IBM Security

46 What Client-Side Session Criteria are Verified? (as in can t easily be spoofed) Criteria How Does Guardium Know? Implications Client IP Detected in TCP Headers While you can modify the client IP in a packet header, the response is sent to that client IP TCP client IPs are difficult/ impossible to spoof because of the TCP handshake. As such you can trust Client IP is authentic DB User Source Program* OS User* DB User is sent in communication stream Source Program is sent in communication stream OS User is sent in communication stream The Database verifies the DB User is authentic with a password. Guardium detects the successful login response and so you can trust DB User is authentic Unlike DB User, this is not authenticated could be spoofed with a custom client, packet modification, or another method. Should not trust it alone Unlike DB User, this is not authenticated could be spoofed with a custom client, packet modification, or another method. Should not trust it alone * Note: Using these is better than not using them, the important thing is not to rely on them alone 46 IBM Security

47 Modifying OS User for an ORACLE JDBC Session 47 IBM Security

48 Guardium Trusts it s Accurate (it has to) This, BTW, is why you will sometimes see blank OS Users in JDBC sessions with Guardium some applications wipe out this variable 48 IBM Security

49 Testing Policy/Report Filters

50 This is How Testing Normally Works 1) You ask a DBA to run some commands on a database that trigger your rules and show data in your reports 2) Some rules/reports fire, some don t 3) You make adjustments 4) Repeat If the policy/reports you are building are complicated, this can take some time tying up DBA resources. 50 IBM Security

51 What We (Information Insights) are Moving To 1) You simulate traffic with the Universal Feed and execute unit tests for policies/reports 2) You make adjustments 3) Repeat 4) Have Shorter Integration Tests with DBAs to ensure things still work using conventional STAPs (more efficient) 5) For every major policy/reporting change, regress the unit tests to ensure previous functions haven t been affected 51 IBM Security

52 A Simulation Definition Using the GAMBIT (Our Guardium Tooling Suite) 52 IBM Security

53 Simulated Traffic In Guardium 53 IBM Security

54 Takeaways

55 Takeaways 1) Filtering is good for the Guardium environment and good for security 2) Understand the implications of blacklisting/whitelisting and how specificity affects maintenance and security 3) There are a lot of mistakes you can make in filtering. Think carefully about policy design 4) Not all criteria are created equally. Think like an attacker 5) Because none of this is obvious and you can make mistakes, testing is important 55 IBM Security

56 Learn More ibm.com/guardium Policy deep dive Blog post of the SKIP LOGGING for Object and Command Whitelisting problem Information on new 7-tuple policy criteria in V IBM Corporation

57 THANK YOU FOLLOW US ON: ibm.com/security securityintelligence.com youtube/user/ibmsecuritysolutions Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and / or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANYSYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.