The present invention relates to computer implemented processes and systems including software, and in particular, to a risk analysis system and method.
Organizations have always had a need to monitor their business activities. In the wake of financial scandals like Enron and the enactment of Sarbanes-Oxley, organizations have increasingly turned to governance, risk management, and compliance (GRC) and separation of duties principles to manage and regulate their business activities. Generally, the organizations use these concepts to detect, prevent, and remedy fraud, crime, and other illicit behavior that may occur within an organization.
Risk analysis software may be used to detect the possibility of unwanted behavior occurring (i.e. risks) before they actually occur within an organization, particularly in the context of enterprise systems. Generally, many actions (i.e., transactions or tasks) can be performed on an enterprise system. For example, possible actions include creating a vendor, paying a vendor, creating a user, or approving a document. In addition, data may need to be accessed in order to perform an action. Thus, completion of an action may require the authority to access the data associated with the action. A user of the enterprise system may be given authority to perform a particular action, and in instances where data needs to be accessed to perform the action, the user may also be given authority to access the data associated with performing the action. Risk analysis software may be used to apply and enforce rules created in accordance with current laws, best practices, or other business objectives to ensure that authorization privileges for performing actions and/or accessing data, for example, do not create risks for the organization.
One problem with traditional risk analysis techniques is that existing approaches result in either false positives or false negatives, thereby reducing the accuracy of the system. False negatives happen when a rule violation has occurred, but it was not detected by the risk analysis software. False positives happen when a rule violation has not occurred, but the risk analysis software indicates one has occurred. From a risk perspective, organizations generally prefer to reduce false negatives because such results correspond to an unknown potential liability. Accordingly, risk analysis systems may be configured in favor of eliminating false negatives. As a result, the number of false positives increase, and the cost to operate the system increases because each false positive needs to be investigated manually.
What is needed is a method for increasing the accuracy of detecting rule violations that reduces produce false positives or false negatives. The present invention solves these and other problems by providing improved systems and methods for performing risk analysis.
Embodiments of the present invention improve risk analysis processing. In one embodiment the present invention includes a computer-implemented method comprising retrieving user account data records from an external system. Each user account data record comprises actions a user is authorized to perform in the external system and, for each action, permissible data manipulation activities the user is capable of performing for a corresponding action. Risk analysis rules may be applied against the user account data records. Each risk analysis rule may include different function-based sub-rules. Each risk analysis rule may apply a different function-based sub-rule to each different action in a particular user account data record, and each function-based sub-rule may be verified based on a particular action and the permissible data manipulation activities associated with said particular action. The risk analysis rule is verified if each of the different function-based sub-rules for the different actions are verified.
In one embodiment, each action corresponds to a software application page a user is authorized to access, and the permissible data manipulation activities restrict the manipulation of data fields in said application page by said user.
In one embodiment, each action is stored as an action code in said user data account records.
In one embodiment, the one or more permissible data manipulation activities said user is capable of performing for a corresponding action are permission objects associated with said action codes, said permission objects having values indicating the activities said users are capable of performing in said one or more software systems.
In one embodiment, the permission objects correspond to specific data fields of an application page and the permission object values specify one or more data manipulations a user may perform on said data fields, and wherein each function-based sub-rule comprises a Boolean combination of one or more permission object values and at least one action code value.
In one embodiment, each function-based sub-rule comprises a Boolean combination of one action code and a plurality of permission objects each having specified values.
In one embodiment, user account data records from two or more external software systems correspond to a single user, the method further comprising merging said account data records prior to applying said risk analysis rules.
In one embodiment, the method further comprises retrieving a plurality of risk analysis rules and, based on the actions in the retrieve user account data records, eliminating risk analysis rules from said plurality of risk analysis rules to produce said one or more risk analysis rules to be applied against said one or more of said plurality of user account data records.
In one embodiment, the risk analysis rules are eliminated if a risk analysis rule does not include an activity code in any of said user account data records, and wherein the activity codes specify particular application pages in at least one of the external software systems.
In one embodiment, further comprising aggregating the results of each risk analysis rule and sending the aggregated results to a reporting software component.
The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of the present invention.
Described herein are processes for performing risk analysis. The apparatuses, processes, and techniques described below may be implemented as a computer program (software) executing on one or more computers. The computer program may further be stored on a computer readable medium. The computer readable medium includes computer executable instructions that when executed on a computer system causes the system to perform the processes described below. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
Numerous users may be set up to use the different software systems. In particular, when a new employee of an organization is hired by a company, the user may be given access to specific functionality within one or more systems to perform his or her job functions or roles within the company. For example, User 1120 may be an employee in the Human Resources (“HR”) department, and may be given access to software functionality in software systems 101 and 151. Similarly, User 2121 may be an employee in the Accounts Payable (“AP”) department, and may be given access to software functionality in software systems 101 and 150. Likewise, User 3122 may be an employee in the Purchasing department, and may be given access to software functionality in software system 150. Finally, user 4123 may be an employee in the Contracts department, and may be given access to software functionality in software system 101. In most situations, each user may have a number of different functions or roles within the company, and may have access to corresponding software functionality to perform actions relating to such functions/roles.
To perform their job functions using the various software systems available within the company, each user may be given authorization to perform various actions in each software systems. For example, User 3 in Purchasing may be authorized to access a purchase order component of a software system and generate a purchase order for a new or preexisting supplier. Therefore, User 3 may further be given permission to manipulate data so that the amount of the purchase order or the supplier information, for example, can be recorded in the system. Similarly, User 2 in Accounts Payable may be authorized to access an invoice payment component of a software system and pay purchase orders received by the company. As with User 1, User 2 may be given permission to manipulate data corresponding to the action of paying the purchase order so that the supplier's bank information or payment terms (e.g., due on receipt or due 30 days after an invoice date), for example, can be recorded in the system. If the same user had access to both purchase order creation and payment, such a condition would represent a risk of fraud to the company.
The authorizations to perform various actions (i.e., transactions) within each software system are typically stored as user account data in a persistent storage mechanism, such as data repository (e.g., a database 102 in
Embodiments of the present invention include a risk analysis software component 110 that retrieves user account data records from one or more external software systems, such as Enterprise Software System 100. Risk analysis software component 110 may be a stand-alone application or a component of a larger Governance, Risk, and Compliance (“GRC”) Application, for example. Risk analysis software 110 may receive user account data from one or more software systems and access and apply risk analysis rules to the user account data records. Risk analysis rules 113 may be stored in repository 112, such as a database or another computer readable storage medium. Advantageously, according to one aspect of the present invention, risk analysis rules 113 may each include one or more different function-based sub-rules. For example, a risk analysis rule 113 may include a first function-based (or role based) sub-rule 114 directed at analyzing risk for a particular job function within the company. Risk analysis rule 113 may include a second function-based (or role based) sub-rule 115 for analyzing another function the user performs within the company.
In one embodiment, each risk analysis rule 113 applies a different function-based sub-rule to each different action specified in a particular user account data record. For example, if an employee user is set up in an Enterprise Software System 100 to perform the function of “Contract Approval” and another function of “Service Entry Sheet Acceptance”, then the user may have at least two different actions specified in his or her user account data record (e.g., a first action for performing the Contract Approval function and a second action for performing the Service Entry Sheet Acceptance function). Accordingly, a risk analysis rule may be defined that includes a first function-based sub-rule directed at the first specified action in the user account data record (e.g., an action for performing Contract Approval) and a second function-based sub-rule directed at the second specified action in the user account data record (e.g., an action for performing Service Entry Sheet Acceptance). The function-based sub-rules 114 and 115 may separately determine risk based on a user's access to software functionality corresponding to each particular action, for example. In one embodiment, risk analysis rule 113 is verified if all of the different function-based sub-rules (e.g., sub-rules 114 and 115) for the different actions are verified. In one embodiment, the risk analysis rule may only be verified (i.e., satisfied) if each of the function-based sub-rules are separately verified. For example, risk analysis rule 113 may only be verified if the first function-based sub-rule 114 applied against the first action and corresponding data manipulation privileges for performing Contract Approval is verified and if the second function-based sub-rule 115 applied against the second action and data manipulation privileges for performing Service Entry Sheet Acceptance is also verified.
Additionally, in some embodiments, each function-based sub-rule 114 or 115 may be verified based on a particular action and at least one of the permissible data manipulation activities associated with the particular action. For example, if user account data record 103 is retrieved by risk analysis software 110 and a risk analysis rule 113 is applied to the data record, each action 104 specified in the data record may be evaluated using a different function-based sub-rule as described above. Here, action 104 includes permissions 105 and 106, which specify the permissible data manipulation activities a user is capable of performing for action 104. Accordingly, the result of the evaluation of the sub-rule used for action 104 may be based on the action 104 and data specifying the permissible data manipulation activities (e.g., permission 105 or permission 106, or both), for example.
Risk analysis software 110 may include a function-level analysis engine 111. Function-level analysis 111 may receive risk analysis rules 113 from storage 112, and may further receive user account data records 103 from multiple different software systems 101, 150, and/or 151. Analysis engine 111 receives the user data records and applies the data to the rules 113, including each of the sub-rules 114 and 115, for example. If the same user has account information on multiple different software systems, the risk analysis software 110 may merge the data into a single data set to perform the analysis as described in more detail below. If a risk analysis rule is verified (i.e., if the user account data satisfies the rule and sub-rules), then an alert may be generated. In one embodiment, user account data records for numerous users across multiple software systems may be retrieved and processed to analyze risk. The results may be sent electronically from risk analysis software 110 to a reporting software component 160 for review.
Additionally, to perform his or her job function on application page 220, user 201 may be granted certain permission rights to manipulate data in application page data fields 221 or 222. As mentioned above, such permission may be different for different data fields. For example, an HR user may have the right to view (i.e., permission=display) a social security number on an application page used for company employee profiles, whereas other employees may not be granted permission to view such information. As another example, an Accounts Payable user may be granted permission to view vendors, but may not be able to create, select, or modify vendors in a purchase order application page. However, a Purchasing Department user may be granted permission to view and select vendor information in the same purchase order application page of the software application (e.g., if the action corresponds to creating a purchase order). Moreover, a Purchasing Department Management (or Supervising) user may be granted permission to create and/or modify vendor information in the same purchase order application page of the software application. The user's permission to perform data manipulation activities on fields 221 and 222 in application page(s) 220 may be specified separately as permission 211 and permission 212 in the user's account data record. This information may be used by the software system to grant the user rights to manipulate data fields 221 and 222 in application page 220, for example. Accordingly, action 210 may have corresponding permissions 211 and 212, which specify the data manipulation activities that user 201 is capable of performing on application page 220 to execute action 210. Similarly, action 230 may have corresponding permissions 231 and 232, which specify the data manipulation activities that user 201 is capable of performing on application page 240 on data fields 241 and 242 to execute to execute action 230.
Next,
The risk analysis rule and associated sub-rules can be represented by text. The following example is illustrative:
As mentioned above, each application page 300A and 300B may include one or more data fields. In this example page 300A includes data manipulation fields 302A-304A, which include fields 302A for a vendor ID and 303A for vendor name, respectively. Additionally, example page 300A includes an action button for creating a PO using data from fields 302A and 302B. In this simplified example, user may enter a vendor ID or vendor name and create a purchase order for a pre-existing vendor by mouse-clicking button 304A. Similarly, page 300B includes data manipulation fields 302B and 303B for a vendor ID and vendor name. Action button 304B may be used to pay a PO for a specified vendor. Data manipulation fields may include data entry boxes, drop down menus, electronic buttons, or other mechanisms for presenting and manipulating data on a page of an application.
In certain embodiments of the present invention, each user of the software system may have user authorization data for controlling a user's access to application pages and controlling the user's permission rights to manipulate of data on each page. As mentioned above, authorization data may be stored as user account data records in a database. In this example, the authorization data in a user account includes one or more action codes specifying the application pages in a software application that the user is authorized to access. In other words, if a user account includes an action code having the same value as an action code for an application page, then the user is authorized to access the application page, but if a user account does not include an action code having the same value as an action code for the application page, the user is not authorized to access such page and will not be able to access the page. Referring to
Features and advantages of the present invention include using user authorization data, including action codes and associated permission objects, in risk analysis rules and sub-rules to assess risk in an enterprise. Risk analysis software system 310 may execute risk analysis rule 350. In this example, risk analysis rule 350 is made up of separate sub-rules 351 and 352. Each risk analysis rule 350 may include multiple sub-rules based on different actions codes. As described above, action codes give users access to particular application pages that the user is required to access to perform their job functions. Accordingly, the action codes in a user's authorization account are representative of each user's job function. Since each risk analysis rule 350 in this example assess risk separately for different action codes using different sub-rules, the analysis is referred to as a “Functional-Level” or “Role-based” risk analysis. As illustrated in
As mentioned above, determining risk based on user permission to perform data manipulation may include processing risk analysis rules that include permission objects. The follow examples illustrate permission objects in more detail to illustrate the flexibility and granularity that may be achieved by incorporating permission objects and associated action codes into risk analysis function-based sub-rules. As mentioned above, a permission object may be implemented to include one or more fields where a field may specify one or more values. A field and value may determine what operation or operations may be performed on data, which particular data may be operated upon, or both. What a field and its specified value may represent may be based on how the field and value is defined. For example, in
In contrast,
Next, risk analysis rules are processed individually. For example, at 503, one rule from the list of action level rule violations is received. At 504, sub-rules associated with the rule and actions and permissions required to process the sub-rules may be received. At 505, user account data values for an action and one or more associated permissions specified in a sub-rule are applied against the sub-rule. At 506, the result is checked. If the user account data satisfies the action and permission in the sub-rule, then the process moves to 507. If a sub-rule for a risk analysis rule is not satisfied in this example, then further processing of the risk analysis rule is stopped and the process continues at 508. At 507, the system checks for additional sub-rules for the risk analysis rule being processed. If the risk analysis rule includes additional unprocessed sub-rules, then the process returns to 505 and further sub-rules are processed. If all sub-rules for the risk analysis rule have been processed, then a result for the risk analysis rule is generated and the process moves to step 508. At step 508, the system checks if all risk analysis rules on the list have been processed. If additional rules require processing, the process returns to step 503. If all risk analysis rules have been processed, the process moves to step 509 and additional risk analysis processing may occur, such as report generation, for example.
The following is an example of a risk analysis rule and sub-rules processed in accordance with an embodiment of the present invention:
Function-Based Sub-Rule 1 (Job Function: PO/Contract Approval)
Function-Based Sub-Rule 2 (Service Entry Sheet Acceptance):
Risk 1 is defined as the combination of Function 1 and Function 2
The rule definition for Risk 1 is processed to achieve Function Level Risk Analysis. Function-Based Sub-Rule 1 is verified if in user/profile/roles authorization is verified for one of the following:
ML81 and M_EINK_FRG/FRGGR (A1) and M_EINK_FRG/FRGCO (X2) and M_BEST_BSA/ACTVT (02);
Risk 1 is true if both Function-Based Sub-Rule 1 and Function-Based Sub-Rule 2 are verified. In the above example, ME28 and ML81 are action codes for specific pages of an application, M_EINK_FRG is a permission object having fields FRGGR and FRGCO, where field FRGGR may have values of at least CO and A1, and field FRGCO may have values of at least C1, K1, X1, and X2, M_BEST_BSA is a permission object having fields BSART, which has a value of ZODA in the sub-rule, and ACTVT, which has a value of 02.
Computer system 610 may be coupled via bus 605 to an output device, such as a display 612, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. An input device 611 such as a keyboard and/or mouse is coupled to bus 605 for communicating information and command selections from the user to processor 601. The combination of these components allows the user to communicate with the system. In some systems, bus 605 may be divided into multiple specialized buses.
Computer system 610 also includes a network interface 604 coupled with bus 605. Network interface 604 may provide two-way data communication between computer system 610 and the local network 620. The network interface 604 may be a digital subscriber line (DSL) or a modem to provide data communication connection over a telephone line, for example. Another example of the network interface is a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links using radio frequency communications are another example. In any such implementation, network interface 604 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.
Computer system 610 can send and receive information, including messages or other interface actions, through the network interface 604 to an Intranet or the Internet 630. In the Internet example, software components or services may reside on multiple different computer systems 610 or servers 631-635 across the network. The processes described above may be implemented on one or more servers, for example. A server 631 may transmit actions or messages from one component, through Internet 630, local network 620, and network interface 604 to a component on computer system 610. Different processes may be implemented on any computer system and send and/or receive information across a network, for example. In one embodiment, the techniques describe above may be implemented by software services on one or more servers 631-635, for example.
The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the invention as defined by the claims.