Database Patch Management often presents conflicting demands on IT organizations charged with ensuring system security while optimizing system reliability and integrity. Because the time between discovering system vulnerability and the emergence of an attack is less, IT organizations are under pressure to apply patches before adequate testing, and without system downtime. A sound patch management strategy is a key part of any secure enterprise. Developing any database patch management plan begins with a firm understanding of the current enterprise. Data must be gathered on the configuration of every server, workstation, and network component in the system. Such data is necessary when evaluating the risk and therefore the necessity of particular patches. This base lining may be performed as part of a larger configuration management and risk assessment effort. Although data may be gathered manually, automated tools are employed, which perform the same functions while also keeping the data current. Vulnerability scans can be used to discover services that should be removed or disabled. Once data is gathered, machines should be brought to the same benchmark security risk level. For servers, an assessment must also be made of their criticality to the enterprise. Change control documents and procedures should be developed, particularly if server hardware and operating system maintenance is performed by one group while software application maintenance is performed by another. Keeping current with system updates and patches can be overwhelming. Not only are there often many, but decisions about which are critical, which are merely useful, and which are unnecessary or even potentially harmful, must be made quickly. Automated tools can make the identification and evaluation stage easier by monitoring the current patch status of the server or workstation -- or scanning it on demand -- and comparing the status with the ideal configuration for the system, producing recommendations for patch installation. Before deploying patches to the wider enterprise, deployment should be conducted in a test environment that mirrors the production environment. At a minimum the environment should represent all critical applications, and ideally, all enterprise platforms. If replication of the production hardware is not possible, at least patch compatibility with operating systems and applications should be tested. Test deployment should begin with the least critical servers first. Proof of concept of Database Patch Management at Sachs and Associates: Defines test environment; install HFNetChkPro; test patch management process (scan, assess, deploy, report). Implementation includes integrating HFNetChkPro with enterprise management systems and third-party vulnerability assessment products; execute successful rollout of HFNetChkPro.
Please Rate this Article 5 out of 54 out of 53 out of 52 out of 51 out of 5
Not yet Rated
