RR-403_Final

Applying Pattern Recognition in SOD, Fraud or Other GRC-Related Violations Reza B’Far Oracle USA 04/24/09 | Session ID: RR-403 Session Classification: Advanced 2 Agenda Applications of Pattern Recognition to GRC Introduction and Terms Definitions Examples Summary Introduction and Term Definitions The following is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decision. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Oracle Safe Harbor Statement Overview of the Discussion • Controls Automation in GRC – Today – Policy Composition and Enforcement (Detection, Prevention, etc.) – Tomorrow – Feedback into the application deployment life-cycle as may be applicable (Provisioning Systems, Business Performance Monitoring, etc.) • Tools that we'll use – Application analysis through “analytic deconstruction” via Meta-models, Models, and Instance Data – Ontology-Based and Mathematical patterns that map to solutions • Disclaimer – No “Golden-Hammer” • Example-driven discussion Approach to Discussion • Layout a matrix of various technical strategic approaches to provide automation solutions • Provide in-depth walk through of a few of the examples in the matrix • Provide references and previous works for relevant hypotheses • Finale is a set of conclusions on how the approach leads to the technical software design that will underlie next generation GRC solutions Quick Introduction • GRC Controls Automation – Given a set of policies, risks, rules, etc., we want to: • Automate Violation Detection • Automate Policy Enforcement • GRC Controls Applications – Can address authorization, transactional data, historical data, and a host of other types of information in the application – Should be an independent and external application so that • Independence and objectivity are verified • Heterogeneity is possible Application of Patterns in GRC Structural & Behavioral Analysis • Software applications have structure and behavior • Structural Analysis – Booch, G., Rumbaugh, J., Jacobson, I – Meta-modeling is analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems [5] – A meta-model is an explicit model of the constructs and rules needed to build specific models within a domain of interest [6]. IMPORTANT: Meta-Models and Ontologies are nearly synonymous. – Model is an implementation of the meta-model. A model is an abstraction of phenomena in the real world [7] – Instance data is the deployment (and temporal) specific data that comprises the actual information in the application, organized as rules of the Model specify • Behavioral Analysis – Business Logic (Not Applicable to Discussion) – Temporality (Applicable) What are Patterns? • Pattern Recognition is defined as: – “the act of taking in raw data and taking an action based on the category of the data”[4] – Within this definition, and within the application of business applications, the meaning of pattern can then be limited to the algorithm(s) which make the process of pattern recognition through business application data, for a particular purpose, possible. – Our purposes (GRC) • Provide a robust governance mechanism • Detect and prevent risk • Assure proper compliance with appropriate policies Risk & Compliance Applicability Risk Quantification Authorization Violations Statistical Algorithms Knowledge Graphs Pattern Type Unsupervised Recognition Systems Neural Networks Stochastic Algorithms Transaction Violations Risk/Perf. Optimization Fuzzy Logic DSP Techniques (Wavelets, Correlation, etc.) Medium Complex Very Complex Implementation Complexity Not Applicable (Yet) Financial Algorithms (Benford, etc.) Example Pattern Recognition and Authorization Models Deploy Policies Discover Violations Resolve Violations Real World Example • Typical Treatment of Authorization Violations 1. Design appropriate role model for organization 2. Deploy the application into production 3. Deploy risk and/or compliance based policies 4. Adjust instance (and potentially model) to minimize violations Deploy Application Design Authorization Model • Linearly automated life-cycle – Policies are refined manually, by consultants – Costs are exceedingly high to maintain Authorization Structures • Authorization Meta-Model: – Meta-modeling is analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems.[5] – A model that describes organization and information about the authorization model itself. Examples are RBAC, CBAC, etc. • Authorization Model: – Structure (potentially the implementation of a meta-model) that describes the application specific manner by which the problem of authorization is solved • Authorization Instance Data: – The data stored in a system, according to the structure specified in the Authorization Model, that can be used in an automated or manual way to, to restrict or allow the usage of a resource Authorization Meta-Models • Examples – DAC – Discretionary Access Control [2] • (Uses Access Control Lists – ACL) – MAC – Mandatory Access Control – RBAC – Role-based Access Control [1] – CBAC – Context-based Access Control • Authorization Meta-models – Aim to be flexible enough, but not too flexible – Aim to reduce the possibility of errors, in the model and the instance, that result in authorization based security or policy breaches Example – Patterns for Authorization • Problem: – The IT team at company X of a business application (for example Oracle eBusiness Suite) want to: • Configure the business application authorization model properly so as to have the fewest possible authorization violations (including, but not limited to, SOD – Segregation of Duties – violations) • Maintain the authorization model to minimize violations that occur during the life-cycle of the application • Assure the sanity of the instance data so as to minimize the number of offending users and offences of violations. • Solution: – GRC Policies, based on best practices, are built and deployed – Patterns are used to monitor and evolve (and add to) the policies Oracle EBS (v. 11 & 12) Meta-Models Ontology-Based Representation UML-Based Representation Responsibility Menu Function Responsibility Menu CompositeMenu SimpleMenu Function Oracle EBS (ver 11 & 12) Model Fragment R1 M1 SM1 F1 F1 R2 M2 R3 M3 R4 M4 R5 M6 R5 M7 F3 F4 SM2 SM5 F5 F6 F10F11 SM4 SM3 • {R1,...,Rn} are assignable to users • {M1,...,Mn} are structural “menus” of which the internal, and configurable, hierarchy of the application authorization model is comprised. • {F1,..., Fn} are actual functional rights to take specific actions in the application Oracle EBS (v. 11 & 12) Instance Fragment R1 M1 SM1 F1 F1 R2 M2 R3 M3 R4 M4 R5 M6 R6 M7 F3 F4 SM2 SM5 F5 F6 F10F11 SM4 SM3 U1 U2 U3 U4 U5 U6OEBS Meta-Model Similar to RBAC, provides protection against assigning users to low-level functional access components or mid-level structural authorization at the menu level... BUT, there are still problems! Example: Role Management Pattern-based SolutionPattern Used Volatile Role Composition nodes whose properties are changed frequently and unusually Knowledge Graph Cross-Reducing Algorithms on Instance Data Detected Problem Statistical Algorithms Performed on Instance Data and Model “God” Path's Paths that are repeated in multiple violations DSP Algorithms – (FFT, etc.) Performed on Model Find highly volatile nodes in the model and research the reason (flawed business process, etc.) Statistical Algorithms Performed on Instance Data and Model Nodes in the “God” paths must be broken to other objects as they occur since they are composites Frequent Intersects Intersections of the connecting lines indicate improper role composition Cross-reduce algorithms provide a clear view of the changes that should be made to node composition Super-user's Discovering the nodes that cause a given user to have too many rights Break the node up, functionally, so that it is not causing a super-user Knowledge Graph Applied to Model and Instance Data Cross-Functional Tolerance Too many intersections across functional portions of the authorization model indicate improper model design If the cross-functional tolerance thresholds are violated, the model design is not aligned to the application functionality and must be fixed. • Patterns can be used to look for policy violations and drive the Role Management and Design Process as a part of GRC Monitoring of Authorization (a subset of which is SOD) Volatile Role Composition: Problem • Functional changes to the authorization configuration of the application seem to cause an unending cycle of Role Design and Redesign • Isolated Role Management Solutions? – Open loop cycles of modifying the authorization model to match the functional and organizational changes trigger either more work to meet compliance requirements or put the organization out of compliance – Role Design and Management, when not being driven by a set of organizational policies, becomes biased to application implementations in heterogeneous environments (and hence ineffective in heterogeneous environments) – Many others ... Algorithmic Output Volatile Role Composition: Solution Pattern Result x-axis = Access Point (Roles, Permissions, etc.) y-axis = Access Point (Roles, Permissions, etc.) z-axis = Number of Correlating Changes Cross-Correlation • Shows the relationship between the changes that take place across different Access Points (Points in the Authorization Model) • Non-random correlation for particular points (roles, etc.) points to improper role design and requires corrective action t (optional) = Sliding Window Time Shift Algorithmic Output Volatile Role Composition: Solution Pattern Result x-axis = Access Point (Roles, Permissions, etc.) z-axis = Number of Daily Changes Frequency Analysis • Shows how frequently particular access points are changing • Access points (Roles, Permissions, etc.) with unusual frequency changes (too many) have not been designed properly in the authorization model Example 1: “God” Paths R1 M1 SM1 F1 F1 R2 M2 R3 M3 R4 M4 R5 M6 R6 M7 F3 F4 SM2 SM5 F5 F6 F10F11 SM4 SM3 U1 U2 U3 U4 U5 U6 Problem: Let's assume that F11 represents creating an invoice and F6 represents authorization to fulfill an invoice. Let's assume we have a policy that having F11 & F6 together represents a SOD violation. Diagnosis (Statistical Pattern): Then Path P1 represents a “God” Path where many violations are caused by a particular construction of the authorization model Role-Design Solutions: • Deconstruct Role R5 into multiple roles OR • Deconstruct Menu M3 into multiple menus (Both cases, parents of a “God” Path) P1 Doesn't RBAC Solve This Problem? • Fundamental question is can proper meta-modeling avoid Risk and Compliances Issues? • Answer: NO! Model (and resulting instance) can be implemented in many wrong ways. RBAC is just another meta-model Role Permission Operation Ontology-Based Representation UML-Based Representation Role Permission Operation SessionSubjectUser/Role ConstraintSubject Session Org Role Activation Constraint Doesn't RBAC Solve These Problems? • RBAC Lessens the probability of problems in the Model, but... Doesn't solve the entire problem – Model can still have a poor implementation – RBAC does not solve instance data problems since instance data inconsistencies come about because of process and policy violations (known or unknown, explicit or implicit) – RBAC has no temporal constraints – Meta-Model design, alone, cannot solve the problem by definition • Model encapsulates additional information to Meta-Model • Instance data encapsulates additional information to Model. Samples of Other Applications of Patterns in GRC Algorithmic Output Another Example : Pattern for Transactions Pattern Result x-axis = Benford Digit z-axis = Occurrence Value Financial Algorithms (example - Benford) • The basis for this "law" is that the values of real-world measurements are often distributed logarithmically, thus the logarithm of this set of measurements is generally distributed uniformly • This counter-intuitive result has been found to apply to a wide variety of data sets, including • Insurance claims • electricity bills, • street addresses, • stock prices, • population numbers, • death rates Transactional Risk and Compliance • SOD regulates the authorization model while COSO, HIPAA, IDC-9/IDC-10, etc. regulate the transactional meta-model, model, and instances • Transactional meta-models are similar in nature, simply more complex than the authorization example HYPOTHESIS Value and Effectiveness of the approach of using patterns in conjunction with meta-models/models increases proportionally (or worse) with meta-model, model, and instance complexity Side-Bar: Cost of Complexity • Complexity theory – P Problems (deterministic polynomial or better time to solve) – NPC Problems (worst case non-deterministic polynomial time to solve) – NPI Problems (non-solvable or non-deterministic time to solve) – Tipping Point: The way natural systems can absorb influences of minimal (or predictable) change until the “tipping point” is reached and then there is sudden catastrophic changes [8]. – Finding and preventing GRC violations and risks spans meta- models, models, and instances: all with increasing complexity! • Manual handling of complexity – Human's effectiveness to solve complex problems, individually or as a group, is reduced drastically as the complexity goes beyond the “tipping point”. See [9] for more information. Complexity Manifestation in GRC • Authorization and Transaction Relationship – Transaction and authorization violations interact multiplicatively in terms of their life-cycle and complexity • Example Use-Case – There are no authorization policies to detect the users from accessing a portion of the system (for example, from creating a vendor and fulfilling an invoice), but the transaction pattern or policy catches the violation. – Resolution: This helps us in creating an authorization policy – Resolution: Patterns can detect an abnormal number of circumventions of the process if emergency provisioning is being abused Conclusions on Patterns for GRC • Handling Complexity – Complexity is best managed through automation – Automation must be done in a closed-loop so that it's scalable and maintainable • Patterns help manage the complexity of GRC through automation – Patterns help us narrow down the problem areas – Patterns help us improve current policies – Patterns can be used with meta-models, models, and instance data Generate Suspects Tomorrow's GRC Solutions Closing The Loop in GRC Automation Today's GRC Solutions Implement Policy Based Controls Understand GRC Use-Cases Address Violations Refine Policies etc. Activate Appropriate Pattern Monitors Implement Controls Find Risks and Violations Understand GRC Use-Cases Going Beyond Near Future • Risk Qualification is here today with products such as GRC Manager that document controls. • Relating Authorization and Transactional Violations to Risk – Risk Quantification is achieved through risk modeling – Just as in Authorization and Transactions, Risk in applications can be described by meta-model, model, and instance data – Risk quantification adds “depth of perception” and fills one of the gaps between BPM and GRC – Risk quantification is integratable into a policy based approach Future of GRC “Meta-Model” Risk Quantification Transactional Meta-Models Authorization Meta-Models Violation Detection Policy Enforcement Today is “2D”: What's going wrong, what could go wrong and how can I fix it? Future is “3D”: What's the cost of what's going wrong? What's the cost of what could go wrong? How do I most cost-efficiently fix it? Lessons Learned • Properties of Next Generation GRC Controls Applications – Going beyond instance data: Discovery of violations in the meta- model, model, and instance of software applications – Ability to provide a long-term sustainable • GRC intersecting security at various points – Authorization Models – Unauthorized Transactions (Fraud, etc.) – Detection and Enforcement • GRC approaches the problem from fundamental business drivers: Policies and Controls Lessons Learned – Continued • Patterns – Come in many different types, some are simply knowledge graphs of “best practices”, others are complex algorithms, and everything in between – A proven tool (in many other related fields such as analytics, financial predictive models, etc.) to assist us in providing more automation – Increasing value to the end customer by providing more information with lower labor investment on customer's part – Results of each pattern can lead to a sequence of recommendations to remedy the problems that cause the policy violations Apply • Threats that you may be facing – GRC violations that cannot be completely prevented – High organizational risk caused by the few “holes in the dam” • Remediation Action – If you are a GRC vendor, pattern-based features in your products are a “Must-Have” otherwise your customers are vulnerable. – If you are a GRC buyer, you should consider the following • Cast your net wide enough. Limiting what you look at as GRC risk is simply another way of avoiding the real issues! • Use pattern recognition technology to overcome the volume and complexity of data that is presented with a “wide net”. Now What? • Are you considering GRC Controls Automation? – Reduce the cost of implementing – GRC automation is not just about financials! Risks, rules, and regulations (all three) are not exclusive to financial systems (though this is where their use is most obvious) – Select a cohesive solution with a future that covers what you need today and what will give you a roadmap into the future • Coverage: authorization, transactions, and risks • Automation: the right tech-stack • Education: GRC automation offers an opportunity to bridge security and business performance GRC Controls Automation Market • The time is NOW: all the right ingredients – Compliance violations have caused a series of failures, financial and otherwise, that have had far-reaching consequences • Financial: Mortgage Banking, Banking Crisis, etc. • Medical: Numerous instances of health insurance companies violating various regulations in reimbursements (HIPAA, IDC-9, etc.) • Energy/Financial: Enron – Get Started Soon • It takes a while to get the basics implemented • By the time you're done with the basics, your organization will understand the tangible ROI in GRC automation and be eager to advance Demo Using OAACG Visualization for Authorization Violations Acknowledgements • Chris Leone – Group Vice President, Oracle USA • Mark Stebelton – Product Manager, Oracle USA • Sidharth Sinha – Senior Director of Strategy, Oracle USA • Michele Shannon – Senior Director of Strategy, Oracle USA • Dane Roberts – Product Strategy Manager, Oracle USA • Ryan Golden – Principal Engineer, Oracle USA • Sreedhar Chitullapally – Software Engine