Tips to Remediate your Vulnerability Management Program
Guardium Presentation
1.
2.
3.
4.
5.
6. DDL = Data Definition Language (aka schema changes) DML = Data Manipulation Language (data value changes) DCL = Data Control Language
7.
8.
9.
10.
11.
12.
13. Supported Databases Supported Platform Supported Versions Oracle 8i, 9i, 10g, 11g Microsoft SQL Server 2000, 2005, 2008 IBM DB2 for LUW (Linux, Unix, Windows, z/Linux) 9.1, 9.5 IBM DB2 for z/OS 8.1, 9.1 IBM DB2 UDB for iSeries (AS/400) V5R2, V5R3, V5R4, V6R1 IBM Informix 7, 8, 9, 10, 11 Sun MySQL 4.1, 5.0, 5.1 Sybase ASE 12, 15 Sybase IQ 12.6 Teradata 6.01, 6.02
14. S-TAP Supported Platforms OS Type Version 32-Bit & 64-Bit AIX 5.1, 5.2, 5.3, 6.1 Both HP-UX 11.00, 11.11, 11.31 Both 11.23 PA 32-Bit 11.23 IA64 64-Bit Red Hat Enterprise 2, 3, 4, 5 Both SUSE Linux 9, 10 Both Solaris - SPARC 6, 8, 9, 10 Both Solaris - Intel/AMD 10 Both Tru64 5.1A, 5.1B 64-Bit Windows NT 32-Bit 2000, 2003, 2008 Both
18. Rogue users know what they’re looking for, but... SQL injection leads to SQL errors ! Guardium: 100% visibility with real-time alerts … They don’t always know where to find it! Brute force attacks result in failed logins ! IINFORMIX IINFORMIX IINFORMIX IINFORMIX
19. Identify failed login attempts using the application account! Take Action : Send alert via email, SYSLOG, SNMP or custom Java class Focus on production DB servers
20. Should my customer service rep view 99 records in an hour? Is this normal? What did he see?
21. Alert on any login using the application account sourced from a location other than the application! Application Server 10.10.9.244 Database Server 10.10.9.56
22.
23.
24.
25.
Editor's Notes
External Threats May/June 2008 SQL Injection attacks peaked at around 40 thousand. By December 2008 they peaked around 450 thousand SQL injection replaced Cross-site scripting as the #1 attack vector Bad Guys are spreading the word on HOW to attack systems and they’re making it easier for others to do the same! There are toolkits to automate this as well as embed malware into databases to further affect internal systems Can you detect this with your current solutions?
And there’s the Compliance Factor You HAVE to do this! SOX, PCI, they require that you CERTIFY that your company is doing this! Who’s reviewing the Data? Who’s making changes to the Data? Do you know how many failed logins or SQL Errors are occuring? How are they happening? Where are they happening? When are they happening? You NEED granular visibility!
Complex systems Apps, Database Types Multiple Paths to the data insiders, outsiders, criminals, hackers Privileged Users intentionally or unintentionally compromising data security or integrity Traditional Solutions Can’t help differentiate this traffic Policies Can’t be enforced There’s no visibility – especially with Privileged Users Are you only going to find out AFTER the fact?!
How does this look in a Large Distributed Environment? Multiple STAPs and Collectors SGATE – blocking for only the traffic you need to block! zTAP – monitoring MainFrames as well as Distributed platforms Centralized Policy Management Centralized Audit Repository Scalable Auditing millions of transactions Add Collectors when and where needed to handle whatever throughput and auditing requirements you need STAP Agents provide failover and redundancy options
Our Solution addresses the full life cycle of Data Security and Compliance. This demo will focus on the top two quadrants, but we have other modules to: discover databases classify data perform vulnerability assessments etc
We’ve picked some scenarios to show how our solution can address these issues for you.
First Example Your environment has applications connecting to various database servers as well as users connecting directly to these systems You need a solution that can discover and map this for you. This will help you identify malicious users and attacks!
Bad guys generate errors hunting for what they’re looking for. SQL injection is a trial by error attack Brute Force attacks are also a trial by error attack. There’s no reason for these errors on your Production Database, especially coming from the DB Account used by your Application Server! 100% Visibility gives you the information you need to know when these attacks are occurring!
Let’s show you how to setup a Policy To alert on Failed Logins We have very granular capabilities We can focus on the Production Database Servers As well as the Application Database account Looking for Failed Logins We can then send alerts via standard SMTP, SNMP, SYSLOG, even allow you to write custom Java applications You get send these alerts to your SIM/SEM!
Another Example Traditional Solutions can’t identify suspicious behavior within legitimate traffic Joe is viewing an abnormally high number of customer information! We can even take a look at what he saw! Notice that the audit information is masked, so that someone viewing these reports doesn’t also see the customer information that we’re auditing Joe for… Knowing what was breached and to what extent is what we’re looking for! Native logs won’t give you this information!
Another Example of Insider Threat How do you know and handle someone misusing credentials? Application Developers may be able to login using the account that the Application itself uses, but without all of the pesky security measures built into the application! We can create a rule that looks at the traffic going to the Production Database Servers, using the Application Account, but coming from somewhere other than the Application Server! Alerting on this activity – we can even see WHAT was executed and from WHERE! The Database doesn’t care where you are logging in from, so long as you know the right username and password!
Identifying fraud or Application Mis-Use You need a solution that shows WHO did WHAT! Native Auditing solutions and logging tools, don’t show this depth Track access back to the application user associated with a specific command Deterministically – not by ‘best guess’! Whatever middleware you are using! And with NO changes to the application or the database!
Do you have Privileged Users that use both generic DB accounts as well as generic OS accounts? In many companies, users login with their OS account and then switch to a shell account that has the needed environment to access the database. If they also use a generic database account, how do you track them back?! Joe’s bumping his bonus! Native auditing will only show you the DB Username Other monitoring solutions can only show you the OS shell account that was used! You need everything!
![COMWISE INTERNETWORK PROFILE ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)