Patent Application
20080270198
In the present climate of growing regulatory mandates and industry-based requirements, business organizations are being forced to more vigorously examine the effectiveness of their internal information technology (IT) controls and processes. Indeed, regulations such as the Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act (HIPAA), and the Graham-Leach-Biley Act require organizations to demonstrate that their internal IT controls and processes are appropriate. In view of such requirements, information system security managers and owners are under increased pressure to provide more timely assurance that their controls and processes are working effectively and that risk is being properly managed.
Traditionally, the compliance of information systems is evaluated on an annual basis. For example, one or more auditors may conduct an annual audit on a given information system relative to one or more sets of policies or standards to determine how closely the information system and its use complies with those policies/standards. Typically, the results of the audit are published in a lengthy report that may identify multiple problems with the information system and/or its use. Although such a report is useful in that it alerts the responsible persons as to areas that require remediation, the report may include hundreds of items that require action. One reason that the report may contain so many items is that manual auditing is both time consuming and expensive and therefore cannot practically be performed on a frequent basis. Therefore, by the time the audit is performed, many problems may have occurred that require action. In such a case, the persons responsible for resolving the problems, such as IT professionals, may be overwhelmed by the sheer number of tasks that they must perform. Adding to the difficulty of the responsible persons' task is the fact that low priority items may be listed together with high priority items without distinction, therefore making it difficult for the responsible persons to identify what problems must be addressed more immediately. Even when such difficulties do not exist, the responsible persons may not know how to resolve one or more of the problems given that audit reports normally only identify problems, not solutions.
The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. In the drawings, like reference numerals designate corresponding parts throughout the several views.
As described above, current methods for identifying problems with an information system can be disadvantageous. For example, the persons responsible for remedying the problems may be overwhelmed by the number of issues identified in an audit report. Furthermore, those persons may not know how to resolve an identified issue given that audit reports typically do not identify solutions to discovered problems.
As described in the following, such disadvantages can be reduced or eliminated by automatically evaluating an information system to identify problems with the system and/or its use and automatically providing remediation recommendations for resolving those problems. Given that the evaluation is automated, it can be performed on a relatively frequent basis, for example every month, week, or day. Assuming the problems identified through the evaluation are addressed in a timely manner, the number of problems that will be contained in an annual audit report may be reduced. Furthermore, given that remediation recommendations are provided, occurrences in which a responsible person does not know how to resolve the problem may be less frequent.
In the following, various system and method embodiments are disclosed. Although specific embodiments are described, those embodiments are mere example implementations. Therefore, other embodiments are possible. All such embodiments are intended to fall within the scope of this disclosure.
Referring now to the drawings, in which like numerals indicate corresponding parts throughout the several views,
The client computers 106 can comprise desktop computers as well as laptop computers. The peripheral devices 108 can comprise printing devices to which print jobs generated by the client computers 106 can be sent for processing. Such printing devices may comprise dedicated printers, or may comprise multifunction devices that are capable of printing as well as other functionalities, such as copying, emailing, faxing, and the like. The server computers 110 may be used to administer one or more processes for the infrastructure 100. For example, one server computer may act in the capacity as a central storage area, another server computer may act in the capacity of a print server, another server computer may act as a proxy server, and so forth.
Generally speaking, each of the devices of the infrastructure 100, including the router 102 and the switches 104, participate in operation of the information system and therefore may need to be checked for compliance with one or more policies and/or standards. It is noted that although relatively few devices are shown in
The processing device 202 can include a central processing unit (CPU) or a semiconductor-based microprocessor. The memory 204 includes any one of a combination of volatile memory elements (e.g., RAM) and nonvolatile memory elements (e.g., hard disk, ROM, tape, etc.).
The user interface 206 comprises the components with which a user interacts with the computer 200. The user interface 206 may comprise, for example, a keyboard, mouse, and a display, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor. The one or more I/O devices 208 are adapted to facilitate communications with other devices and may include one or more communication components, such as a wireless (e.g., radio frequency (RF)) transceiver, a network card, etc.
In the embodiment of
As is further shown in
The control models 300 comprise computer-readable versions of the policies and/or standards applicable to the information system under evaluation. Given that compliance of the information system is determined relative to those policies and/or standards, the control models 300 drive the evaluation process. The control models 300 specify the data sources and the operations to be performed on the data that is collected. Because the control models 300 capture security and audit processes in a rigorous manner, the models form a foundation for incremental improvement of the information system from a compliance standpoint. A library of control models 300 can be provided, representing any number of policy sets and standards from which compliance can be independently or collectively judged.
The modeling GUI 302 provides an interface for a user, such as a system administrator or auditor, to create and modify the control models 300. In at least some embodiments, the modeling GUI 302 provides a simple graphical environment for defining each model 300 that can be used with a minimal understanding of computer programming.
The report portal 304 controls access to automatically generated reports that describe the findings obtained through the evaluation of the information system. In some embodiments, the report portal 304 takes the form of a web site that authorized persons can access to view the reports. The reports document the results of automated security and audit processes as specified by the control models 300. The reports can provide anywhere from a high-level indication of the system's compliance with few details to a low-level indication of compliance including a great amount of detail. As described below, select report content can also be forwarded as a notification to a responsible entity. Such a notification can, for example, take the form of a trouble ticket entered into a workflow system, as an alarm entered into an application management system, as an email message sent to a responsible person, or as a change specification provided to an automated remediation utility such as a utility computing application. A user can review controls documentation to understand the model that has been applied and then review the resulting report to understand the results obtained through analysis of evidence collected during the evaluation.
The collection sensors 306 comprise components and/or instrumentations that extract data from the operational infrastructure of the information system under evaluation. Therefore, the sensors 306 are used by the CCMM 214 to cull the various data from the infrastructure that will be used to determine how well the information system complies with the applicable policies and/or standards. There are multiple sources from which the sensors 306 can obtain evidence in an unobtrusive manner, such as security and audit information in a data warehouse, the application programming interface (API) of an enterprise application, and log files from infrastructure devices or applications.
The CCMM engine 308 comprises the “intelligence” of the CCMM 214 and controls overall operation of the CCMM. More specifically, the CCMM engine 308 reviews the control models 300 that are to be applied in the evaluation, drives the collection of evidence pertinent to the control models using the sensors 306, processes the collected evidence relative to the control models, and generates and formats the reports that are accessible to a user via the report portal 304. Notably, the CCMM engine 308 can rapidly adapt to new security and audit models and changes to the CCMM engine software are typically not required. To exploit a new type of security or audit control, all that are required are a new model 300 and appropriate sensors 306 to collect the data for the model. The formatting of the report is automatically changed by the CCMM engine 308 relative to the model 300 that has been applied.
The audit store 310 serves as a repository for intermediate results as specified by the control models 300 and, therefore, can be used to store information collected by the sensors 306. In addition, the audit store 310 can be used to store the final results, including any reports generated by the CCMM engine 308. In some embodiments, the audit store 310 is deployed as a MySQL database on a Windows platform or as an Oracle database. In other embodiments, the audit store 310 comprises a generic store that is implemented with a relational database management system (RDBMS).
The remediation information generator 400 comprises the “intelligence” of the remediation processor 220 and therefore controls general operation of the processor. As its name implies, the remediation information generator 400 generates remediation information that can be provided to responsible entities to enable problems discovered by the CCMM 214 to be resolved in an effort to secure full compliance with policies and/or standards. As mentioned above, the remediation information can take the form of various remediation steps or actions that should be performed to rectify a problem with the information system. Therefore, explicit instruction as to how to resolve problems can be used by persons who otherwise may not know how to resolve the problems. The remediation information generator 400 generates the remediation information relative to information obtained from the control models 300 (
Once the remediation information generator 400 has identified the applicable remediation recommendations, the remediation processor 220 can provide those recommendations to the appropriate entities responsible for remedying any non-compliance in notifications. Various forms of notification can be used. For example, the remediation processor 220 can generate trouble tickets to be provided into a workflow system using the trouble ticket generator 404. Alternatively, the remediation processor 220 can generate alarms to be provided to an application management system using the alarm generator 406. As a further alternative, the remediation processor 220 can generate email messages to be sent to a responsible person using the email generator 408. In yet another alternative, the remediation processor 220 can generate a configuration change specification to be provided to an automated remediation utility using the configuration change specification generator 410. In each of the above notification mechanisms except the configuration change specification, information is generated for the review of a human being. In the case of the configuration change specification, however, the remediation information is used by the automated remediation utility to automatically fix the problems associated with the information system. Example automated remediation utilities are described in U.S. patent application Ser. No. 11/047,792, filed Jan. 31, 2005, which is hereby incorporated by reference in its entirety.
In some embodiments, the remediation processor 220 selects the appropriate notification mechanism and format for distribution of the remediation information based upon the priority of the conditions underlying the audit exceptions relative to thresholds established for those mechanisms. Therefore, high priority exceptions can be reported, for example, using an alarm while lower priority exceptions can be reported, for example, using an email message. By way of example, the priority indications can be integrated into the control models 300 and/or the remediation recommendation database 222 such that the format of the remediation information can be selected by the remediation information generator 400 through reference to the models and/or the database.
Once the appropriate notification mechanism and format have been determined, the information can be distributed using the external remediation system 218. The external remediation system 218 can comprise each of a trouble ticket API 416, an application management alarm API 418, an email routing API 420, and a utility configuration API 422 to facilitate that distribution. The recipient for the remediation information can be determined prior to distribution using the remediation processor 220 by referencing the routing database 402, which cross-references recipient information (e.g., addresses) with the notification mechanism with which the remediation information is to be distributed. In some embodiments, the routing database 402 is organized by control or policy IDs and the subject to which the policy is being applied. For example, if the subject of a given violation is a given server, the routing database 402 may indicate the owner of that server to be the recipient of the remediation information. Defaults can be established in the routing database 402 in relation to subjects for which no specific recipient is indicated.
The status manager 412 of the remediation processor 220 can collect feedback as to resolution of the various issues for which remediation recommendations were issued. In one embodiment, the remediation information generator 400 registers issues requiring resolution with the status manager 412, which then stores in the remediation status database 414 details from the remediation, such as the control at which there was an issue, the status of the issue, and who and which external remediation system to which the issue was routed. In some embodiments, the status manager 412 includes external interfaces with which the manager can report changes in the status of the issues to the CCMM engine 308 (
Various programs (i.e. logic) have been described herein. The programs can be stored on any computer-readable medium for use by or in connection with any computer-related system or method. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or means that contains or stores a computer program for use by or in connection with a computer-related system or method. These programs can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.
Example systems having been described above, operation of the systems will now be discussed. In the discussions that follow, flow diagrams are provided. Process steps or blocks in the flow diagrams may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process. Although particular example process steps are described, alternative implementations are feasible. Moreover, steps may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.
Once identified, the audit exceptions are provided to the remediation information generator, as indicated in block 504, for immediate action. The remediation information generator then consults policy information from the relevant control models (block 506) and remediation text from the remediation recommendation database (block 508). Through such consultations, remediation recommendations as to how to remedy the audit exceptions can be determined, as indicated in block 510. Turning to block 512 of
The notification mechanism that is used as to each audit exception can depend upon the priority of the audit exception. In some embodiments, thresholds can be associated with each available mechanism, and the mechanism to be used is selected based upon which thresholds the priority of the audit exception meet or exceed. For example, for notifications to be provided to human beings, a relatively low threshold can be associated with email notifications, a relatively higher threshold can be associated with trouble ticket notifications, and a further relatively higher threshold can be associated with alarm notifications. In such a case, if a given audit exception has a priority level that surpasses the alarm notification threshold, the notification will be formatted as an alarm that alerts the responsible person that action is immediately required. If, however, the audit exception has a relatively low priority that only surpasses the email notification threshold, the notification will merely be sent as an email message. In some embodiments, thresholds can be similarly assigned to remediation actions to be identified to an automated remediation utility to indicate to the utility the order in which remediations should be processed. Therefore, the remediation information generator automatically prioritizes issues to be resolved.
In addition to using the exception priority as a guide to selecting the notification mechanism, the exception priority can also be used to determine when not to provide a notification, i.e., when to suppress notification. For example, when an audit exception comprises a relatively minor infraction that does not require immediate action, no notification may be sent to avoid inundating the responsible person with actions items. In such a case, the exception may only be identified in the report generated by the CCMM. Alternatively, a notification may be temporarily suppressed, for example until a predetermined number of days have passed or until the other, higher-priority issues have been addressed.
Assuming a notification will be distributed, the remediation information generator generates remediation recommendation records that identify the exceptions and how to resolve them, as indicated in block 516. The records are then formatted for the selected notification mechanism, as indicated in block 518. As described above, the formatting can be performed by one or more of the trouble ticket generator, alarm generator, email generator, and configuration change specification generator. The appropriate generator then provides the notification to the external remediation system, as indicated in block 520, and the external remediation system processes the notification as necessary to provide the notification to a responsible entity, as indicated in block 522.
From the foregoing, it can be appreciated that, using the disclosed systems and methods, information systems can be more easily and more cost effectively evaluated for compliance with one or more policies and/or standards. Due to the relative ease and low cost of the automated evaluation provided by the disclosed systems and methods, such evaluations can be performed more frequently than an annual audit that is manually performed by human auditors. Assuming that problems identified through the evaluation are resolved in a timely manner, the number of issues identified by such an annual audit may be reduced, thereby lightening the workloads of persons responsible for performing remediation, such as IT professionals.
Furthermore, because the responsible entities are provided not only with an indication as to the existence of a problem but an indication as to its severity and/or time sensitivity, the responsible entity can more easily prioritize the tasks that the entity must perform to obtain compliance, thereby ensuring that the most important problems get resolved relatively quickly. In addition, given that low priority problems can be automatically suppressed, the number of tasks assigned to a given responsible entity can be better managed so as not to overwhelm that entity. Moreover, because explicit remediation instructions are provided, situations in which the responsible entity cannot fix the problem due to a lack of understanding as to how to fix the problem can be reduced.
