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:
: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