Configuring your policy to prevent appliance problems

Transcription

1 Configuring your policy to prevent appliance problems IBM Security Guardium IBM SECURITY SUPPORT OPEN MIC To hear the WebEx audio, select an option in the Audio Connection dialog or by access the Communicate > Audio Connection menu option. To ask a question by voice, you must either Call In or have a microphone on your device. Once connected (at least on PC), you should see this in the bottom right corner: For more information, visit: WebExOverview_SupportOpenMic Oct NOTICE: BY PARTICIPATING IN THIS CALL, YOU GIVE YOUR IRREVOCABLE CONSENT TO IBM TO RECORD ANY STATEMENTS THAT YOU MAY MAKE DURING THE CALL, AS WELL AS TO IBM S USE OF SUCH RECORDING IN ANY AND ALL MEDIA, INCLUDING FOR VIDEO POSTINGS ON YOUTUBE. IF YOU OBJECT, PLEASE DO NOT CONNECT TO THIS CALL.

2 Panelists Avi Walerius Level 2 Support Greg Holmes Level 2 Support Jack Kerbert Level 2 Support Chris Beaney Level 2 Support Manager Chris Metcalfe Level 2 Support Manager Moderator: Andy McCarl Knowledge Manager, IBM security 2 IBM Security

3 Goal of session Understand the impact of different policy actions and how they relate to common problems on the Guardium appliance. 3 IBM Security

4 Agenda What typical problems are related to the policy? Using the right ignore actions Using the right log actions Using the right alert actions Steps for reviewing your policy Example policies 4 IBM Security

5 What typical problems are related to the policy? Directly Appliance database filling up Sniffer performance problems Missing data, DB User? S-TAP performance problems Missing data, DB User? Appliance disk filling up (not just because of the database) Appliance in recovery mode Indirectly More time for aggregation and audit jobs to run. Higher chance of conflicts and associated problems. 5 IBM Security

6 Use the right Ignore actions Skip Logging vs Ignoring Sessions Ignore Session / Ignore S-TAP Session When using Session based conditions in the policy. Use session based ignoring actions. Skip Logging When using SQL based conditions in the policy, use Skip Logging. Beware! it may be worse for sniffer performance to use skip logging on complicated conditions. See selective audit policy later. 6 IBM Security

7 Use the right Ignore actions Ignore S-TAP Session vs Ignore Session Ignore S-TAP Session Ignore S-TAP Session sends a signal to the S-TAP to stop sending traffic to the collector. Ignore S-TAP Session is the best way to reduce the load on the sniffer and S-TAP. Ignore Session Ignore Session ignores traffic at the sniffer level. The S-TAP is still sending the traffic to the collector. This action can not be used on SPAN or Network Tap traffic. Ignore S-TAP Session (Revocable) Soft Ignore S-TAP session that can later be revoked if needed. Useful for testing. Use session and SQL reports to see what traffic is being logged on your appliance. You may find some of it is of no value to you. In that case, ignore it with Ignore S-TAP Session. How can I check if the correct data is being logged on my Guardium Appliance? 7 IBM Security

8 Use the right Ignore actions Ignore Responses Per Session Ignore responses per Session Sends a signal to the S-TAP to ignore database results sets and SQL errors (except failed login). Database results sets - Used for extrusion rules SQL errors e.g. ORA-xxxxx errors If you do not use that data, consider ignoring responses on all or some traffic to reduce load on S-TAP and sniffer. 8 IBM Security

9 Use the right Ignore actions What problems can it prevent? Policy Change Result Problems prevented Use Ignore (S-TAP) Session instead of Skip Logging for rules based on session conditions. The sniffer no longer has to analyze every SQL in the session. Sniffer performance Use Ignore S-TAP Session instead of Ignore Session for S-TAP traffic. The S-TAP no longer captures and sends session data to the sniffer. S-TAP performance Sniffer performance Use Ignore Responses Per Session. The S-TAP no longer captures and sends results sets or SQL errors to the sniffer. S-TAP performance Sniffer performance Use Ignore S-TAP Session as widely as possible to filter out unwanted traffic. The S-TAP no longer captures and sends data of no value to you. S-TAP performance Sniffer performance Database filling up Disk filling up Report performance 9 IBM Security

10 Use the right log actions Log full details vs Default logging Log Full Details Log the full SQL string including values and the exact timestamp of each SQL. Full SQL in reports. Logs to GDM_CONSTRUCT_TEXT table. Default logging Log the SQL string with masked values (the SQL construct) and log the most recent timestamp of that construct within a session and the logging granularity (1 hour). Cases when we have default logging: - Audit Only action - Allow action - Default action of non selective audit policy SQL in reports. Logs to GDM_CONSTRUCT_INSTANCE table. Default logging is significantly easier for the sniffer and takes less space in the database. 10 IBM Security

11 Use the right log actions Selective vs Non Selective policy Selective Audit Policy By default do not log SQL constructs unless they are matching a policy rule. Use Audit Only action to log the construct ( Default logging) as part of a rule. Positive Saves space in the internal database by logging less SQL. Negative You may unknowingly be discarding interesting traffic. Non Selective Audit Policy By default log SQL constructs, even if they do not match a policy rule. Use Allow action to log the construct explicitly as part of a rule. Positive Allows a full picture of the traffic to be seen, which can be used to tune the policy. Negative If you do not pay attention, it may be filling the appliance with useless data. Although selective seems better from a database space perspective, it may prevent identification of sessions that could be ignored completely. 11 IBM Security

12 Use the right log actions What problems can it prevent? Policy Change Result Problems prevented Use default logging instead of log full details The sniffer logs traffic in a much more efficient way. Sniffer performance Database filling up Use a selective audit policy The sniffer logs less into the internal database. Database filling up Sniffer performance 12 IBM Security

13 Use the right alert actions What does an alert do? Depending on the alert action, the traffic can be logged in different ways. Logs the full SQL string including values and exact timestamp to Policy Violations domain GDM_POLICY_VIOLATIONS_LOG table. Logs the alert message details to Alert domain MESSAGE, MESSAGE_TEXT tables For syslog alerts writes to appliance syslog file /var/log/messages 13 IBM Security

14 Use the right alert actions Alert per? Alert per match Alert daily Alert once per session Alert per time granularity All create a policy violation every time they are matched. The difference is how often the alerts are sent. Example 1. Alert per match on object. Run 100x select * from object in the same session GDM_POLICY_VIOLATIONS_LOG has 100 new rows MESSAGE has 100 new rows MESSAGE_TEXT has 100 new rows You get 100 or syslog alerts. Example 2. Alert once per session on object. Run 100x select * from object in the same session GDM_POLICY_VIOLATIONS_LOG has 100 new rows MESSAGE has 1 new row MESSAGE_TEXT has 1 new row You get 1 or syslog alert. 14 IBM Security

15 Use the right alert actions Alert Only and Log Only Alert Only Same as alert per match, but does not write to GDM_POLICY_VIOLATIONS_LOG. Ideal if you are sending alerts to SIEM and not looking at them in Guardium. Log Only Same as alert per match, but does not write to MESSAGE or MESSAGE_TEXT. Read it as log policy violation only Example 3. Alert Only on object. Run 100x select * from object in the same session GDM_POLICY_VIOLATIONS_LOG has 0 new rows MESSAGE has 100 new rows MESSAGE_TEXT has 100 new rows You get 100 or syslog alerts. Example 4. Log Only on object. Run 100x select * from object in the same session GDM_POLICY_VIOLATIONS_LOG has 100 new rows MESSAGE has 0 new rows MESSAGE_TEXT has 0 new rows You get 0 or syslog alerts. 15 IBM Security

16 Use the right alert actions Manage the syslog files If you are creating a lot of syslog alerts with your policy, the syslog files may become large. In some cases large enough to fill the disk. Syslog alerts are kept in /var/log/messages. By default they rotate every week and 5 weeks are kept. Example, change to rotate every day and keep 3 days: vmguard7.hursley.ibm.com> support logrotate message USAGE: logrotate [agg message] [daily weekly monthly] [# of rotations] Ok vmguard7.hursley.ibm.com> support logrotate message daily 3 The following information has been added to /etc/logrotate.conf file:/var/log/messages { daily rotate 3 missingok postrotate /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null true endscript} Ok 16 IBM Security

17 Use the right alert actions What problems can it prevent? Policy Change Result Problems prevented Use Alert once per Session instead of Alert Per Match The sniffer has to log less data into the internal database. Less alerts are sent. Sniffer performance Database filling up Disk filling up Use Alert Only or Log Only instead of Alert Per Match The sniffer has to log less data into the internal database. Sniffer performance Database filling up Disk filling up 17 IBM Security

18 Steps for reviewing your policy 1. Check for simple configuration issues Ignore session actions based on SQL conditions and vice versa Ignore session used instead of ignore S-TAP session Alert at the right frequency and with the right action 2. Confirm you are ignoring as much data as possible with Ignore S-TAP Session Use Session and SQL reports to see what you have and ignore anything you don t need 3. Consider the level at which data needs to be logged Is logging with full details required? Is alert per match required? 4. Check your top tables to see where to make the most impact GDM_POLICY_VIOLATIONS_LOG, MESSAGE, MESSAGE_TEXT means a lot of alerts. Danger of filling the internal database and disk and impacting sniffer performance. GDM_CONSTRUCT_TEXT means a lot of log full details. Danger of filling the internal database and impacting sniffer performance. GDM_CONSTRUCT_INSTANCE means a lot of data logged with default logging. Danger of filling up the internal database. 18 IBM Security

19 Example policies 1. Log full details and alert Alert per match and log full details on everything policy. Not a real life policy but good illustration for testing. Start with empty Guardium database. Run SQL scripts on a monitored DB for 15 minutes. After ~15 minutes check the database: vmguard3.hursley.ibm.com> supp show db-top-tables all Table Size (M) I/D % Unused(M) Est. Rows Name MESSAGE_TEXT GDM_POLICY_VIOLATIONS_LOG MESSAGE GDM_CONSTRUCT_TEXT GDM_CONSTRUCT_INSTANCE GDM_SESSION What about the sniffer 19 IBM Security

20 Example policies 1. Log full details and alert Flat log requests (dropped packets by the sniffer) Analyzer queue increases Logger queue increases 20 IBM Security

21 Example policies 2. Non selective audit policy Non selective audit policy with no rules default logging on everything Start with empty Guardium database Run same traffic as in example 1 After ~15 minutes check the top tables: vmguard3.hursley.ibm.com> supp show db-top-tables all Table Size (M) I/D % Unused(M) Est. Rows Name GDM_CONSTRUCT_INSTANCE GDM_SESSION DB_ERROR_TEXT SNIFFER_BUFFER_USAGE Roughly 2GB less data logged compared to example 1 21 IBM Security

22 Example policies 2. Non selective audit policy Analyzer and logger rate similar to example 1 No analyzer queue, logger queue or flat log requests 22 IBM Security

23 Where do you get more information? HEADER CONTENT 1 HEADER CONTENT 2 Questions on this or other topics can be directed to the product forum: More articles you can review: Technotes: - Why is my internal database filling up? - What to do if I see my DB getting full? IBM Knowledge Center: - Policy actions reference iate_ignore_action.html - How to use the appropriate ignore action Useful links: Get started with IBM Security Support IBM Support Portal Sign up for My Notifications Follow us: 23 IBM Security

24 THANK YOU FOLLOW US ON: securityintelligence.com xforce.ibmcloud.com 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. Any statement of direction represents IBM's current intent, is subject to change or withdrawal, and represent only goals and objectives. 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 any systems, products or services are immune from, or will make your enterprise immune from, the malicious or illegal conduct of any party.