Application Controlling Patch Management
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.
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.
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.
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.
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.
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:
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);
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.
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).
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.