MULTI-ENVIRONMENT SOFTWARE PATCHING TOOL By Zak Wilson – zhw05u

1. MULTI-ENVIRONMENT SOFTWARE PATCHING TOOL By Zak Wilson – zhw05u Supervisor: Dr Jonathan M Garibaldi

2. - Abstract • Administering and monitoring all of the changes or modifications made to a system can be very hard work and is incredibly time intensive. • All levels of management need to administer, monitor and raise new changes or fixes to their own individual subsystems ensuring overall system integrity. • Effective, efficient and easy-to-use ways to administer and monitor patching on growing, large scale software packages. Not only for the experts who initiate and implement the system, but right down through the organization, top level managers checking latest statuses of their systems, support analysts monitoring and administering the patching compatibility between environments, right through to the developers making modifications and raising patches onto their development environments, testing and progressing these as well as an effective way of being able to keep track of all of their changes across all respective environments. • I aim to design and develop a simple multi-environment software patching tool to cater for all of the above needs, focussing on the effectiveness, efficiency and easy-of-use of the tool.

3. - Motivation • The initial motivation to design and develop said patching tool stemmed from identifying a serious need within Oracle for a simple, clear and intuitive way of administering patching across multiple environments. • I therefore felt the need to develop a patching tool to enable the effective and intuitive management of patching on companies own systems, ensuring patch integrity and compatibility between development, testing, staging and production environments as well as providing intuitive administration tools used to manipulate these patches. • The functionality of this patching tool shall enable the: • Top-level Managers to check, monitor, approve or reject patches. • Support Analyststo monitor & report on latest patch statuses and how they associate with the issue reported. • Developers to raise, test and progress patches. • Existing products on the market seemed hard to come by and were usually developed for individual companies, didn’t cater for such a broad range of users and were certainly not intuitive, and were notoriously buggy.

4. - Description of the work The patching tool shall enable the: • Top-level Managers: To check, monitor, approve or reject patches. Review progress of specific patches, or more generally the patching level between environments. • Support Analysts:When an issue is called in and looked into, the support team will need a way in which to check whether a patch fixing that issue has been worked on and whether it is in the progression queue soon to be applied to the live system. • Developers:Any changes to the system will be made and raised as a patch, this is then tested thoroughly on whatever environment it was applied, progressed onto the next environment where the same tests are carried out again. Developers will therefore need an efficient way of raising, monitoring, updating and progressing their patches.

5. - Functionality Proposed (i) • The extent of the functionality of this service depends on your role within the company implementing the system. There are a number of common operations available to everyone, and also there are also a number of role specific operations available, aimed to streamline many of the role specific responsibilities and processes. • Categorising operations by role allows for: • More intuitive user interface with fewer menu items and operation shortcuts cluttering up the menu bars. • limits the ‘damage’ rogue users can inflict should they gain access. The common functionalities available to everyone: • View Patch Details • Show Unprogressed Patches • Search Patches

6. - Functionality Proposed (ii) • Depending how you split the operations between the roles, and also the number of different roles in operation is entirely dependant on the individual company or organisation that is using the patching tool. • Role Based Functionality Table Developers Support Analysts Managers - Raise a patch No role specific functionality - Approve / Reject Patch - Progress a patch - Test a patch - Add / Remove User - Test a patch - Progress a patch - Add / Remove Environment - Edit a patch - Environment Summary - View User Details - Environment Summary - Set user privileges

7. - Related Work • The vast majority deals with the growing problem of guaranteeing patch integrity for common software products. Designed to protect the company or individual against the most recent security threats. • Intended for use alongside these, and is individually configured for patch management on any one of the companies systems or specific business software not scanned by existing patch management software available. • Quite often the company develop in-house a patch management tool for internal use. • Whilst working at Oracle I gained first hand experience of the problems with developing software internally for internal use only. - Shavlik HfnetchkPro - GFI LANguard N.S.S - eEye Retina - Microsoft SUS -

8. - Design Architecture

9. - Database Operations There are a number of key operations that the interface will need to support and relay to the database in order to extract the desired information, these can be broken down into categories as follows: Patches: • Raise a patch – Creates a new row in the patches table, representing a new patch. • Edit a patch – Modify details relating to the patch, stored in the patches table. • Test a patch – Sets a flag signifying any changes the patch made were successful. • Progress a patch – Updates the raiseTo field to point to the next environment to be progressed to. • Approve / Reject patch – Flag set by management to signify whether that patch has approval or not. • Search for a patch – comprehensive search functionality allowing search by various attributes. • View patch details – Displays all information relating to any patch in question. • Show Unprogressed Patches – Displays all patches that have not yet made it all the way through its progression path. Users: • Add a user – Creates a new row in the users table, representing a new user. • Remove a User – Modify users details, stored in the users table. • Show User Details – Displays a page showing all user details & activity. • Set User Privileges – Allows management to have application access control over its team. Environments: • Add an Environment – Creates a new environment and associates it with an account. • Edit an Environment – Modify details of a specific environment. • Remove an Environment – Removes the desired entry from the ENVS table. • Environment Summary – Displays patches associated with that environment & other useful info.

10. - User Interface Design • This is an initial design of the skeleton of the application, paying careful attention to keeping the interface as clear and intuitive as possible.

11. - System Design What platform chosen? • This patching tool is being developed and designed for use on Windows platforms, however support for various Unix and Linux distributions shall be forthcoming, as the application and architecture of the system are both portable. What languages chosen? • The database is going to be Oracle Database 10g, its scalable for large systems without significant performance loss, also allowing various audit and security functionalities. • The application will be developed using Java and Java Swing. • Possibility of applet development for online use.

12. - References Patching tools reviewed: • Shavlik HfnetchkPro - http://www.shavlik.com/pHFNetChkPro.aspx • GFI LANguard N.S.S - http://www.gfi.com/adentry.asp?adv=142&loc=28 • eEye Retina - http://www.eeye.com/html/Products/Retina/index.html • Microsoft SUS - http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp Further Reading (Research): • http://www.windowsecurity.com/articles/Security_Scanner_Patch_Management.html

13. Questions ?