Project Quant: Database Security - Patch
It's time to move onto the 'Secure' phase of the process (Other sections are DB Security Intro, Planning Part 1, Planning Part 2, & Discovery). The Secure phase is where we implement many of the preventative security measures and establish the secure baseline for database operations. First up is the database patching process.
As you may have read, Rich has already produced a detailed report on Quant for Patch Management metrics and processes. And that work is certainly applicable to what we are doing here. In essence I am going to use the same process, but reduce the level of detail in the metrics to focus in on areas where you will spend the majority of your resources and omit anything not relevant to database patching. If you feel you need that level of detail for database patch management, I won't discourage you from going back and usage that as a guide. For major revisions and releases, that version will provide necessary granularity. For database security patches this process is more than adequate.
There are two types of DBAs out there: those who are more paranoid than busy, and those who are too busy to be paranoid. The later group does what I like to call "patch and pray": install the patch and pray it works. If it crashes your database you scramble to roll it back out and recover. I know a lot of DBAs for small businesses who use this model, and for the most part, the patches work and they get away with it. The other group sets up a test environment, creates acceptance tests cases, tests and bundles their approved version, plans the rollout carefully, and finally executes. This is more typical for enterprises or firms where database downtime is simply not an option and the resources are available. Regardless of which model you follow, evaluation and testing will comprise the bulk of your effort in this phase.
Security patches are a little different than general products updates to fix bugs. If you are experiencing a functional problem with an application, you know for certain that you need a certain patch and already possess some understanding of how critical that issue is to your firm. Most DBAs may not be aware of what sort of exposure, or be able to assess risk based upon known exploits. If you don't have a security group helping with the analysis, the evaluation process is often based on matching critical weaknesses to database features used within the environment. If you find a critical vulnerability you patch right away; otherwise you wait for the next patch cycle.
Database vendors make it easy to locate and obtain patches. Security patches are well publicized and alert notices are commonly emailed to DBAs when they become available. Keep in mind that some of the database patches require updates to the underlying operating system kernel, libraries, or modules, and the evaluation process needs to cover those updates as well.
Evaluate
- Time to monitor sources for advisories -- per DB type/per release: Review database vendor alerts and industry advisories.
- Time to identify which patches are applicable per database: Not all security patches are necessary for your environment. Identify patches that correspond to database type/function in use, & OS platform; then evaluate based on vendor criticality.
- Time to identify workarounds: Identify if workaround are available, and whether they are appropriate.
- Time to determine priority: Determine your operational priority for patching.
Acquire
- Time to acquire: Time required to locate and acquire patch(es).
- Variables: Costs for maintenance, licensing or support services: Updates to vendor maintenance contracts. Cost for consultants or managed service providers.
Test & Approve
- Time to develop test cases and criteria: Cost to develop functional, security, or acceptance test cases.
- Time to establish test environment: Time required to locate and gain access to testing personnel, tools, and platforms needed to verify patches.
- Variables: time to test: Time to run tests. May require multiple tests sweeps depending on test cases, resources, and configuration.
- Time to analyze test results.
- Time to establish approved packages/versions: Time to package verified versions of database and platform patches.
Deploy & Confirm
- Time to schedule and notify: Schedule personnel and resources; communicate database maintenance schedule to application users.
- Time to install: Total time to take database offline, perform backups/snapshots, install patch, bring database back online, and reconnect applications.
- Time to verify installation: Basic functional testing of core services and security tests.
- Time to clean up: Remove temp files, database snapshots, or rollback files.
Document
- Time to document: Workflow software, trouble ticket response, compliance change reports, and a record of what you did are all important aspects of this task.
—Adrian Lane
