CEO's
Connection
Attack
of the Database Patches
by Rob Gardos,
CEO
DBAs were recently given
an extra special present from our friends
at Oracle: 13 database patches, some of
which eliminated vulnerabilities that
allowed users to access environments without
the necessary credentials. Instead of
doing more productive work, DBAs could
now enjoy countless man hours testing
and applying patches. And don’t
worry, by the time the patches have all
been applied, there will be another DST
or one-off bug fix just waiting. Considering
that many companies have hundreds (if
not thousands) of databases, how do they
handle this unrelenting source of work?
It’s not just about the application
of these patches; it’s also about
their validation across every variation
of an environment (OS and database version).
Can you be certain that this patch on
Linux RHEL4 or Solaris 10 will do no harm
to your application? Isn’t Oracle
consistent on every platform and wildly
predictable? While I appreciate Oracle’s
QA process, I’m not betting my business
on it. The only way to ensure database
upgrades are safe is to test them, and
testing on every OS, version, and application
takes serious time.
I don’t mean to single
out Oracle. Microsoft SQL Server, Sybase,
and IBM DB2 all suffer from the same problems.
The patches don’t stop and the number
of databases isn’t getting any smaller.
Ultimately companies must choose from
one of two unattractive options:
- Blindly patch databases
to keep up with the latest update,
with the knowledge that applications
will break
- Run databases in
an unpatched state, knowing full well
that they are vulnerable
Given the latest wave of
news on exploits and an increasingly stringent
regulatory environment, many organizations
simply have no choice but to patch. Downtime
is better than exposed data -- so patch
and pray. The question becomes: Can I
win the patch war without risking application
availability? With validation and automation
you can.
Companies must embrace
an internal certification process that
quickly validates patches. The two most
critical elements for doing this are configuration
consistency (environment drift is a killer
if you want to drive predictability) and
a reliable testing process. After those
are both met, companies need to create
a repeatable deployment method. This may
require scripting to ensure manual steps
are not missed. While this is additional
upfront work, it is well worth it in the
end. The final step is the ability to
massively deploy validated patches and
centrally audit all results.
While winning the
patch war will be no small task, it’s
a fight enterprises can not afford to
lose. The importance of data and applications
is growing and the underlying tools that
power them are simply becoming more vulnerable.
So be prepared for the next patch attack.
It’s just a few months away.
Robert Gardos
President and CEO
<<
back
|
