Automatic (intelligent) merging of tickets

I am in the process of automating change and
configuration management processes through the
integration of RT with a slew of integrity tools like
Tripwire and AIDE, and some other tools such as cvs,
twiki, and PentaSafe/NetIQ’s Vigilent Detect. I need
some help figuring out where to start within the Perl
modules and determining if this has already been done.

Basically:

  • An integrity report runs on a server or network
    device. This is automatically mailed to RT.
  • If there is an open change request for that asset,
    determine if the change is authorized based on search
    patterns, content, and FQDN of the host or device.
  • If the change is authorized, merge the integrity
    report with the open ticket.
  • If the change is not authorized, or authorization
    cannot be determined, open a new ticket and wake
    someone up and/or route to a remediation queue.

What is the correct place to start with this? Would
the appropriate place be to write something and run it
from RT::Interface::email::Filter::???.

I would need to add some queries and flow control
which would accomplish the above criteria. The
customization needs to supplant many of the steps
below now done by humans (mainly me)…

This manual workflow is fantastic for operations,
security and auditing, but it needs a great deal of
automation. For production environments (servers), it
goes something like this:

  • A change request (server patch, user account, app
    install, config file change, etc.) is initiated into
    RT.

  • A custom field is used to assign the ticket to
    (TODO: one or more) assets based on the primary FQDN
    of the server.

  • The change request is assigned a priority.

  • The change request is assigned an owner.

  • The change is evaluated (TODO: and approved) for
    impact to the business, the production environment,
    and security considerations.

  • The change is made on a test server.

  • A scheduled or manual Tripwire or AIDE integrity
    report is run on the server.

  • When changes are found, the integrity report is
    preconfigured to automatically mail the changelog to
    the appropriate RT queue using the FQDN@DN as the
    source email address. The report also includes the
    primary FQDN of the host in a text MIME attachment
    and/or the body of the message.

  • A new ticket is generated setting the FQDN as the
    requester based on the source address.

  • The custom ‘asset’ field is also set to match the
    primary FQDN in the report.

  • The new ticket is reviewed and, if appropriate,
    merged with the already open ticket assigned to that
    "test" asset. THIS IS MANUAL and based on a query for
    open tickets, the asset field, AND the scope/nature of
    the change.

  • If there is no open ticket, then the change was
    probably not requested and the ticket is moved to a
    high priority queue reviewed/watched by both Security
    and Operations. Perhaps this is a false positive, so
    the ticket is assigned to someone who then tunes the
    integrity tool.

  • If there was an open ticket, and the reported change
    to the test environment matches the intended change,
    the change request can be moved (TODO: either a
    different status or a different queue) to a
    "production" ready status and authorized for
    release/turnover to the production server.

  • The change is made to the production server and the
    workflow repeats itself…looking for open, authorized
    tickets, etc.

Anyone doing this already with some degree of
automation? The manual steps are still very quick
relative to less mature change control workflows, but
automation would help considerably.

Thanks.

Bill

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree