Just because users “can”, doesn’t mean they “do” [Webcast with Greenlight]
Risk for organisations is growing. With more devices to protect, more people who require access to data, and more partners to integrate with, the paradigm of access control is larger than ever. The Verizon Data Breach Investigations Report (DBIR) highlighted 9 of the top attack patterns ranging from Insider & Privilege Misuse, Physical Theft & Loss, Web App attacks through to payment card skimmers. There are just a few of the top attack patterns but none the less, this highlights the importance of reducing risk.
For all of us familiar with SAP Governance, Risk, and Compliance (GRC) we’re well aware of SAP Access Control (AC). SAP Access Control is typically the 1st solution customers implement when they begin their GRC journey. AC is the solution our customers turn to when forced by internal and external auditors to perform Access Risk Analysis to get clean (i.e. identify and mitigate segregation of duties risks). SAP Access Control is also well known for its Emergency Access Management (i.e. firefighter) functionality. Rather than giving employees SAP_ALL (i.e. the “keys to the kingdom”), organizations can give users emergency access ids so that the emergency access activities are tracked and can be properly audited. Other functionalities provided by Access Control include Access Request Management (i.e. providing users a central formalized process to request authorizations) and Business Role Management (i.e. putting roles in business terms).
While we know Access Risk Analysis and the mitigation of segregation of duties risk are critical activities for organizations, we also know that the mitigation of the access risks often requires manual activities that often take plenty of time. Most of us don’t work in organizations where we can have one person do one thing and another person do another. We may have headcount and process constraints and unfortunately most of our manual controls are manual. If I can create a vendor and pay a vendor, someone (i.e. perhaps my manager) may need to review a report to see whether I’ve actually done these activities. The ability to do an activity, doesn’t mean that the activity actually occurs. What if a manager has been reviewing multiple reports showing him that while an access risk has been identified, nothing has actually occurred? How much time is that manager spending on the manual review(s)? Is a business process change required?
With the power of SAP Access Violation Management (AVM) by Greenlight organizations now have the ability to analyze the underlying transactions associated with their access risk so that they can automatically mitigate as needed. SAP Access Control leverages a rule set to uncover and provide visibility into users and roles with the capability to perform high risk transactions. SAP Access Violation Management leverages Access Control and analytics rule sets to provide visibility into actual usage and violations executed against high risk transactions in conflict with policy.
One more powerful function of Access Violation Management is the ability to connect to home grown applications, .net tools, and other cloud based solutions (e.g. Ariba), and even SAP Business Planning and Consolidation (BPC). I’m sure there are applications in your landscape with data that you wish you could consume. I’m sure you think SAP GRC solutions are only for SAP environments. I’m here to tell you that, while this is a common misconception, it’s simply not the case. SAP GRC solutions can be applied to more than SAP environments.