Getting Started - Implementing Database Security and Auditing - page 20

ler, you increase the complexity involved in securing the server and
preventing an attack.

Checking SQL Server registry key security . This check ensures that the
Everyone group is restricted to read permission for registry keys,
including HKLM\Software\Microsoft\Microsoft SQL Server and
HKLM\Software\Microsoft\MSSQLServer. If the Everyone group
has more than read permission to these keys, it will be flagged in the
security scan report as a vulnerability.

Checking SQL Server service accounts . This check determines whether
the SQL Server service accounts are members of the local or domain
administrators group on the scanned computer, or whether any SQL
Server service accounts are running under the LocalSystem context.
The MSSQLServer and SQLServerAgent service accounts are
checked on the scanned computer.

1.2 Patch your database

One of the expressions used by information security professionals is that
you should patch, patch, and then patch some more. Although patch man-
agement is not synonymous with security and certainly does not guarantee
security, it is one of the most important and fundamental techniques, with-
out which security does not exist. Software bugs are often exploited for
launching an attack, and if there is a bug in the security layer (e.g., the bugs
in MySQL's authentication systems prior to version 4.1.x), then database
security is certainly a challenge. Moreover, it is hard enough to combat
threats that use problems you may not know about. At the very least,
patches help you address threats that are launched against known problems.
Patching is difficult and unfortunately has an inherent time delay dur-
ing which your system is exposed to an attack. Some of this time delay
results from your own schedules for testing and applying patches to pro-
duction environments. Some of this delay involves vendors who don't nec-
essarily release the patches quickly enough. As an example, IBM DB2
UDB Version 7.2 had a buffer overflow vulnerability in the LOAD and
INVOKE commands. These vulnerabilities were acknowledged by IBM on
November 22, 2002. The fix was available starting September 17, 2003—
10 months later! This is not unique to IBM—any complex software takes
time to fix, test and release. Therefore, patching is not a silver bullet, but it
is a bullet nevertheless.