Guardium value proposition for fss pn 12 02-10

Editor's Notes

• #13: This is one of our larger installations – but we have another global bank customer that is currently monitoring 3,000 database instances, distributed across NA, SA, EMEA and the Far East.
• #17: Deep automation to reduce workload (e.g., compliance workflow automation to streamline audit/oversight tasks such as electronic sign-offs, escalations, etc.) Comprehensive functionality (DAM, VA, configuration auditing, discovery, blocking) based on common back-end, workflow & Web console
• #21: Updates to Deck for RSA 2010 1- Use New logo and blue wash template 2- Update bullets with the new ones in slide below. ---------------------- OLD SCRIPT NOTES BELOW-------------------------------- Let’s talk about our solution! Heterogeneous support for Databases and Applications STAP Agents lightweight cross platform support NO changes to the Database or Applications Collectors handle the heavy lifting reduces the impact on the database server No logging requirements DBAs can (sometimes have to!) turn this off Logging greatly impacts the Database Server as you increase granularity! Real-time alerting Monitor ALL Access A Privileged User working on the server console won’t be detected by any solution that only monitors network traffic!
• #22: How does this look in a Large Distributed Environment? Multiple S-TAPs and Collectors S-GATE – blocking only the traffic you need to block (such as privileged users), without affecting application traffic (see example in upcoming demo) Z-TAP – monitoring applications on mainframes as well as access by privileged users Centralized, cross-platform policy management Centralized, cross-platform audit repository Scalable Auditing (not just monitoring) millions of transactions per day in real-world environments You can easily add Collectors when and where needed to handle whatever throughput and auditing requirements you need S-TAP Agents provide failover and redundancy options
• #23: This is an example of how to detect unauthorized access when someone uses the credentials belonging to the application’s generic service account, and connects directly to the database server using these credentials. These credentials should only be used by the application itself but in most organizations, these credentials are widely-known and often shared among privileged users such as DBAs, developers and outsourced personnel. This usage typically violates corporate policies – since there is no accountability with shared accounts, and the user gains the high level of privileges granted to the application -- but these policies are difficult or impossible to enforce without a DAM solution like Guardium n place. The example above shows how to construct a Guardium policy to detect when such usage occurs, and automatically alert security personnel. This policy is typically one of the first policies implemented in Guardium accounts. The policy says: “Alert me whenever someone accesses the database server belonging to the group called “Production Servers,” [this group can be defined and maintained externally, such as in LDAP], from an IP address that is NOT in the group of “Authorized Client IPs,” using the generic service account “APPUSER.” The policies can be even more granular if desired, specifying that the rule is violated whenever a specific SQL Command gets executed (SELECT in this case) and a specific object that is touched (Employee Table in this case). The drop down box also shows other actions that can be taken when the rule is violated, such as blocking (S-TAP TERMINATE), ALERT ONCE PER SESSION, or LOG FULL DETAILS (capture all information about subsequent SQL transactions including all returned data). This shows that Guardium provides both detective controls (alerts and fine-grained audit trail) as well as preventive controls (blocking). The screen shot above only shows a subset of all fields available when defining policies; the next slide shows all of the policy fields.
• #24: Guardium includes pre-defined policies for enterprise applications such as SAP and regulations such as PCI. This example shows all of the fields available in a Guardium policy, showing the granularity of information collected such as OS User (Domain account), App User, and Source Application (the application residing on the client that is used to access the database, such as Microsoft Excel). Guardium ships with a pre-defined group (SAP – PCI) that contains all of the SAP tables for which access must be monitored for PCI compliance, saving time and effort in locating these tables and defining the group.
• #26: Updates to Deck for RSA 2010 1- Use New logo and blue wash template ---------------------- OLD SCRIPT NOTES BELOW---------------------