Live from SAPinsider Studio: San Diego Gas & Electric on Mitigating SoD Conflicts
Paul Malin, Financial Systems Client Support Manager at San Diego Gas & Electric, joins SAPinsider Studio at the SAP GRC 2016 event to discuss San Diego Gas & Electric’s journey to upgrade its GRC system.
Ken Murphy, SAPinsider: Hi, this is Ken Murphy with SAPinsider. I’m at the SAPinsider GRC event 2016, in Las Vegas, and today I’m pleased to be joined by Paul Malin of San Diego Gas & Electric. He’s here today to talk about his company’s GRC project. Paul, thanks for joining us today.
Paul Malin, San Diego Gas & Electric: Thanks for having me.
Ken: I was hoping to start, if you could just tell our viewing audience a little bit about your organization and your role at the company?
Paul: Sure. I work for San Diego Gas & Electric. Our parent entity is Sempra Energy. We also have a sister utilities, California Gas. I am a financial systems client support manager for San Diego Gas & Electric. Our department is responsible for assisting users at all three entities. Sempra Energy is a Fortune 500 services holding company based in San Diego, California. They also have other operations throughout North America and South America. Those entities are not on our SAP instance, so they’re not part of my responsibility area for helping users.
Ken: So as I said, you’re here today to talk about your GRC project, which I think involved upgrading to GRC 10.1?
Paul: Yes.
Ken: I was hoping you could start with a before snapshot, what you were using before, what were the business drivers for the upgrade, and what risks that presented to your organization.
Paul: We were on GRC 5.3. We were only using it for access provisioning requests as well as firefighter or superuser maintenance management. We were starting to face a situation for SoD monitoring for SoD risks, where we had to go through a process analyzing user-scan data provided by out external auditors, and it turned out that it was a very laborious process. So based on that, our upper management decided it was time to institute a proper segregation of duties monitoring system, and based on that we went ahead and upgraded to GRC 10.1, re-implemented the newer access provisioning superuser management. We also instituted ara, or access risk analysis, for SoD monitoring as well as brm for business role management.
Ken: Any other modules?
Paul: It was just access control. We also did, ultimately, implement user access review. It takes a little bit longer to get that going, but we did get that running.
Ken: One of your big topics at the presentation here is how the company, with this new set-up, helped to mitigate 500,000 SoD conflicts. I was hoping you could just elaborate on that for viewers, and just talk about what changes in role provisioning or access control were put in place to help accomplish that.
Paul: Let’s see if we can get through all that. So the 500,000 number is something that’s based on how the SoD tool works, and it compares t-code vs. t-code level, so all the different combinations of this t-code with all the potential conflicts over there. When you boiled it down to actual users and risks, it ended up being about 4500 user risk combinations that we had. So to clean all that up we went through many steps. Some of that was we deconstructed our composite roles. We had many, many composite roles that we had to deconstruct back to the single role level and only assign those roles that were needed to users. It turns out that a lot of users had more roles than they needed and didn’t really use.
We had to change around our document type authorizations, so no more security changes there, and change some of the roles as well as configurations to eliminate some additional risks. For certain areas that had small departments and still had need for access, we set up firefighter access for those areas. For the most part, business users didn’t really use firefighter access prior to that. So we set up those situations, or set up those accesses, for those departments to help remediate those types of risks.
Then in the end, we further remediated for roles that weren’t really needed. People still had more than what they needed, so we cleared those out. We made sure our rules set was free of false positives. And then we assigned mitigating controls to our remaining medium level risks, and right now we have somewhere around five hundred and seventy-five user risk combinations that are assigned mitigating controls in our system.
Ken: As with any project, I’m sure you had to contend with some user pushback. I’m curious how you handled that.
Paul: The pushback we got initially was because of composite role deconstruction. We had a lot more roles that had to individually be approved and in the process we also had a lot more role owners. And so we had role owners complaining, saying, why am I approving so many things? And the volume of the requests they were getting. So we said, sorry, that’s just part of what it is, it’s part of the new reality, but we also created some new composite roles. We had deconstructed a bunch of composite roles, but in the end we created some new composite roles to help mitigate some of that pushback, especially for areas that was display-type access. We knew it wasn’t going to cause a segregation of duties issue. So we did some of that type of thing to help the users and the role owners. We also did mandatory training for the role owners, to help get them introduced to the whole concept of SoD and why this was important, to be mindful about what access is being provided and what they are approving.
Ken: So having gone through this project, having put GRC 10.1 in place and having this deep reduction in SoD conflicts, how’s that led to improved business processes for the company, or maybe even helped you better serve your customers?
Paul: It has led to better business processes in that we have reduced financial statement risk, reduced risk of sox deficiencies, and reduced risk of auditing findings. Additionally, it has helped the user community in that they have better, easier to determine roles that they have to request, and hopefully fewer roles for them to request, and therefore only have the proper access that they really need.
Ken: Overall, it seems like a pretty ambitious project. Is there any advice or lessons learned that you can impart to another company, perhaps attempting something of a similar nature?
Paul: Best advice I have is to make sure to have your role master data ready to go as early as possible in the process. We didn’t have it all set up and cleaned up the way we wanted to before we did our testing, we had it ready for go-live. Because it wasn’t ready for testing, it made the testing take longer. A little more hurdles to jump through, or jump over, to get everything working right and be able to properly test and feel comfortable with how things were working.
In addition, make sure to train users. Train the managers, train the role owners, have sufficient training material available for all the people that need to access this system, because the look and feel is so much different from what we had been using to what it was now, what we have now. And then, finally, stressing, during the remediation process or review of user access managers and so on, and users trying to clean up their access, stressing to them that we’re not accusing that user of actually committing fraud when we’re saying there’s this segregation of duties risk. We’re not accusing them of doing anything. It’s just the fact that they have the access, based on the access that they have, they could do something that could potentially be turned into fraud. Not that they would do something, but that they could do something.
Ken: Can you tell the viewers what the future may hold for your SAP GRC landscape?
Paul: Sure. We are right now getting ready to have GRC actually provision to itself, or run all of its processes on the GRC system itself. So that’s set up for that, it monitors all the other systems we have connected. We want to make it actually monitor itself to help button up that control. We’re looking at turning on some automated SoD review, segregation of duties review process, as well as turning on risk terminator in the backend systems. There’s some extra control pieces there that we feel would be very beneficial to have turned on. Then in the future, we’re looking potentially at – and one of the reasons I’m here at the conference, besides my presentation – is investigating process control, and something new I just heard about recently, distributed authorization management, as well as looking at possibly putting our GRC system on hana and the reporting benefits that we can gain out of that.
Ken: Well Paul, I appreciate your joining us to tell us about your company’s GRC project.
Paul: Thank you very much.
Ken: Again, this is Ken Murphy with SAPinsider, and we have been chatting with Paul Malin of San Diego Gas & Electric.
Premium
