Feature IBM Guardium Imperva SecureSphere Negative Business Impact of IBM

Approach
Gateway/Collector • IBM requires 5 disk-based read/writes from • Imperva performs only 1 disk-based write • Affects real-time visibility, security
Appliance the agent to the collector appliance for each from the agent to the gateway appliance alerting and DB server performance
Performance DB activity for each DB activity • Using a RDBMS in the collector
• IBM writes the collected DB activity to a • Imperva stores the collected DB activity in appliance affects write speed when the
RDBMS in the collector appliance before a flat-file structure in the gateway rate of DB activity collection is high
policy evaluation begins on that activity appliance Reports and security alerts will be not
analyzed and generated fast enough in
real-time when required
DB Agent • IBM Agent to Collector communication is • Imperva has option to compress data • Affects DB performance – disk I/O and
Performance uncompressed, consuming valuable network before sending it to the gateway network bandwidth
bandwidth • Imperva Agents do not write to the DB • Affects real-time visibility and security
• Heavy Guardium Database Agent (aka S-TAP) disk storage during normal operations alerting
writes activity to a local log buffer impacting • Database Agents throttle up/down based
database performance and increasing network on CPU load to avoid overloading the
traffic between DB Agent and Collector. When database server while all rule evaluations
an agent can’t communicate with a collector it are done at the Gateway minimizing
will queue it locally. impact on DB server.
Flexibility of • Heavily reliant on S-TAP to collect DB activities • Imperva Gateway appliance supports both • In some segments, network inline
deployment & data inline mode and sniffer mode deployment mode is preferred because real-time
Blocking capability • Collector appliance does not support inline- to collect DB activities blocking of DB activity is required. Non-
mode deployment • Imperva DB agent supports either mode: inline blocking via TCP_RST is not as
o No real time blocking for inline o Local DB activity monitoring reliable as inline blocking.
mode o Network + Local DB activity • Some segments do not allow agents to
monitoring perform network monitoring, therefore
it is important to be able to use
physical appliance for DB monitoring
over the network.
Centralized • IBM has only a handful of predefined reports • Centralized management and real-time • Takes up a lot of time to create policies
Reporting & Policy at the centralized level- the majority must be reporting UI that minimizes the number of and ensure that it is free from human
Workflow run at the collector level (and manually steps necessary to complete a task. errors
consolidated) – Need field verification) • Provide pre-defined and optimized polices, • Scripts can be error prone, slow to
• Monitoring policy is based on ttilization of a workflows, and reports that minimize the execute and difficult to build, deploy
script based. need for subject matter experts and DBAs and maintain.
See: • Point-and click rule and policy creation,
http://www.ibm.com/support/knowledgecente eliminates the need for scripts and DBAs
r/SSMPHH_10.1.0/ • Flexible rule grouping and default
com.ibm.guardium.doc/reports/distributed_rep assignment profiles facilitate rapid
ort_builder.html deployment of new policies and databases
• Ability to “Define Once & Comply Many
Times”
Monitor all • IBM does not distinguish between compliance • Independent and parallel execution of • Imagine if your DAM solution had to
database traffic for and security rules. security and compliance policies ensure write a log of every packet before it
protection. • Requires writing a permanent record of each all activity is monitored consistently – no could enforce/apply policy.
Ability to audit only activity before the activity is elevated by the “jump outs” • Takes up a lot of time and affect real-
what is needed for monolithic script – drastically increasing lag • Fast in-memory policy evaluations for all time alerting and visibility
compliance and time and introducing performance overhead activity, with permanent logging of only • Inability to differentiate auditing and
differentiate from which limits the scope of monitoring necessary information security requirement.
security policies. • Faster evaluation improves blocking of
threats without requiring inline
monitoring
Forensics Capability • Every info must be generated in a report • Supports audit compliance and security • In the event of an incident, IBM lacks
form reporting the ability for administrator to perform
• No forensics GUI to support data pivoting • Gives the ability to perform forensics post-mortem analysis via data pivoting.
and forensics investigation investigation via the Audit Data GUI No way for an administrator to filter
• IBM is not security-focused. They do not • Imperva provides data pivoting capability through the heaps of collected DB data
provide data pivoting capability in a forensic in a forensic view dashboard. For e.g, “1st in real-time view. Everything must be
view dashboard. For e.g, “1st click: Show click: Show me what Alice did on done in a reporting format which is not
me what Alice did on database A and which database A and which IP, hosts and forensics-friendly.
 IP, hosts and application she was using. 2nd application she was using. 2nd click: Add
click: Add “table=B” to my current view “table=B” to my current view presented
presented by the 1st click such that the by the 1st click such that the view now
view now becomes, “Show me what Alice becomes, “Show me what Alice did on
did on “DB A + table=B“. This use case is “DB A + table=B“. This use case is
presented to the security analyst via the presented to the security analyst via the
GUI and this is in addition to report GUI and this is in addition to report
generation. This feature is known as data generation. This feature is known as data
pivoting. pivoting.
Artificial • No capability to learn DB user behaviors • Performs the learning of DB user • Inability to define the baseline of user
Intelligence behaviors by building a dynamic profile of behaviors
the DB user IDs. For e.g., what IP, source • Inability to alert/block in the event if
apps, host machine, tables, operations the user behavior deviates from the
the DB user ID usually perform. This is baseline behavior
known as the positive security model.
• Ability to alert/block in the event if the
DB user ID deviates from the learnt
profile
Support for large • Inflexible upgrade methodology to newer • Imperva supports backward and forward • Makes upgrade a nightmare because
scale environment versions - Lack of backward/forward compatibility at all tiers in the due to processes, it is not possible for
version compatibility, See: architecture. Don’t have to be on the the entire architecture to be running on
http://www.ibm.com/support/knowledgece same version for all during the upgrade the same version at any one point of
nter/SSMPHH_10.0.0/ and operations process time.
com.ibm.guardium.doc.install/upgrade/upg • No flexibility to maintain different
rade_plan_aggregation_cm.html versions of components in the same
• Reboots required for Oracle ASO, and AIX. setup
• Specific requirements that entire
deployment must be on same version.
Order of operations of upgrade is tricky.