Application 6 | Controlling Patch Management

When analysts performed a root-cause analysis on a sample of recently reported security defects in AAG's software, they were able to determine that many of the problems were due to uncontrolled maintenance and patching of the company's applications. In fact, it appears that the programmers had been writing unvalidated and often defect-laden patches into previously secure applications. Moreover, because of those changes it has been getting harder to keep track of the security status of the organization's entire application portfolio.

As a result of this finding, management has decided to implement a Baseline Management Ledger (BML) as a way to ensure that the major security issues AAG face are properly recorded, prioritized, authorized, assigned, and controlled.

In this Application, you will establish the structure for a BML and explain its use in controlling patches to one of the applications within AAG's Revenue Acquisition Management (RAM) Platform, which is discussed on page 2 of the model case.

Include in the BML format all of the types of information you believe are necessary to understand the precise status of the patches that have been applied to every application in the organization's inventory.

Develop a template that identifies the useful categories of information and provide one set of sample entries that help to illustrate how the template should be completed by those using it. A complete BML would have an entry for each change request, but for this exercise, create only one entry.

Using Word, Excel, or a similar program, construct a form that someone in the IT organization or patch management team would fill out in order to document and track a change request for one of the applications in the AAG RAM Platform. Include categories of information such as:

•The application this patch affects (including the main application name itself, the module/component name within the system, or a specific function within a component);

•A convention for a tracking number on the change request (much like a "tracking number" you receive for tracking a shipment);

•Standard identification for the bug this patch is repairing and information about the bug itself (such as priority, severity, description of the bug's behavior/security risk);

•The authorizer for this patch release;

•Designation of the team/person doing the repair work and patch release;

•Current status;

•Relationship of this patch/fix to other patches/documented in the BML.

This is by no means an exhaustive list of all trackable items. Remember, the goal is to create a ledger template that would help your IT team understand what has changed with an application (the history as well as changes currently in progress).

Once you have developed your BML, explain your rationale for the types of information you chose to include in the BML in a 2- to 3-page paper. Explain any validation rules you would add to the form if it were developed. For example, you could have free-text entry in some of the fields, a drop-down list with standardized fields, and so on. Also include the business rules you think should apply for using this form: Who is allowed to fill it out? What kind of workflow would you recommend for the review (for example, when you need a change authorized, how does that information get communicated to the authorizer)? How would you make sure the BML stays up-to-date?

Your submission should include your paper and your completed BML form.

Attachment

• Application 6.docx (13 KB)