SAP Security Blogs
Turnkey's team of expert consultants share their wealth of knowledge and in-depth insight into SAP security and controls in a series of blog posts.
Thursday, 23 July 2015
Posted by Tom Venables
How sensitive is your data?
With data theft becoming more prevalent and a heightened media focus on loss of personal data affecting several notable companies in recent years, the protection of data has never been more relevant to systems administrators and governance functions. Whether it be protecting employees’ personal details, the financials behind shareholder statements, or critical customer information, it is essential that we understand the data stored in our systems and undertake implementation of processes and tools to protect this.
As with so much in security, the most important piece of achieving controls around data protection is human: we should ensure that all employees who are dealing with sensitive data understand their responsibilities and the requirements for the protection of said data. An understanding of data and the associated risk ownership in the business is essential for this.
Where is your data right now?
Do you use file sharing? How about pre-production copies of production data?
Ensure that you have a complete understanding of where sensitive data is stored and how it is transmitted and you will understand the scope required for implementation of controls around access to that data. If you have production data stored in non-production systems, then you need to bring those into the scope of your controls framework and may be exposed to clauses in data privacy legislation which require data to only be stored once, for specific processing purposes. Remember that production controls should be applied to production data, wherever it is stored or accessible, this may include management information systems as well.
SAP provide a number of tools to enable you to protect your data, the first of which is incumbent upon your role design, denying access to data for those users whom it is not deemed appropriate. Reporting on the setup of roles and who can access what data is fairly straightforward in standard authorisations, but can be complicated by more complex authorisation solutions, such as structural authorisations in HR.
For example, managers may have access to payroll information to enable MSS functionality through a portal solution, but may not be able to display this information in the backend SAP GUI. Make sure you understand the processes used to access data to avoid spending time and effort on these false-positives.
So, assuming your role design is already limiting access to data appropriately, you may still have concerns around other types of access. For example, confidential data may be extracted from a system and stored offline or on file-shares, how can you work to prevent this?
GRC Access Risk Analysis can help bolster your reporting in this area, permitting the linking of display access to data with the transactions required to misuse that access. A note of caution though – I would recommend any reporting rules set up for monitoring read access should be kept distinct from the rules around segregation of duties, in order to provide clarity of reporting on risks – consider a custom ruleset for specific DP risks.
Read Access Logging allows you to monitor and log read access to data you deem to be sensitive. You can define which data you want to be logged and ensure that monitoring of access can be conducted. The key advantage of RAL is that it should be available to most SAP customers, as long as your BASIS patch-level is up to speed. There is a guide in SAPNote 1969086 to check your compatibility.
UI Logging: While at first glance, this may seem similar to the RAL solution, UI logging provides some additional functionality when dealing with sensitive data, allowing you to see the exact set of data being displayed. Providing reporting cockpits for identification and trace tools of data incidents, it is configurable to determine which users and data logging should be enabled for.
UI Masking: Going further than the UI logging solution, UI masking offers more preventative controls for handling sensitive data. The solution can mask data within the GUI, ensuring that sensitive fields are not displayed. It can be configured to only display data to people with the correct roles defined in the tool, as well as providing audit trails of data requests. Using these tools in conjunction with your role design and increasing organisational awareness of privacy requirements and sensitive data handling, you can help to ensure that your data remains, yours.
If you would like to know more or would like to comment on this topic, please use the link below:
Wednesday, 6 May 2015
Posted by Marc Jackson
Process Controls as a concept
Although the name may suggest, it isn't simply about providing control solutions for your business processes, rather it describes the concept of providing an overall control and compliance management solution for your organisation. This means having a single centralised solution to coordinate and manage all of your controls and compliance related activities.
GRC Process Controls
SAP GRC Process Controls provides functionality in five broad areas which support both the lifecycle of a control and the underlying controls management processes and procedures required to comply with associated regulatory standards.
1) Document - Document controls and policies centrally; map to key regulations and impacted organisations
2) Scoping - Perform periodic risk assessments to determine scope and test strategies
3) Evaluate - Evaluate control design and effectiveness; raise and remediate issues
4) Monitor - Perform automated, exception-based monitoring of ERP systems
5) Report - Support decisions and promote accountability with insightful analytics and sign-off
Automated Controls Monitoring
Process Controls provides the ability to automate monitoring of configuration settings, master data and transactional data related to key control activities. For example, monitoring and preventing duplicate payments. Below is an example of a scenario where automated monitoring could be successfully applied with associated benefits over control assurance.
Control deficiency in an organisation
There is a system configuration-based control which prevents field changes after posting to General Ledger, providing full transparency into all transactions affecting the SAP General Ledger. Any changes to this control means that the system is potentially exposed to the risk of fraudulent transactions or mistakes being made leading to inaccurate financial reporting.
For example, a user with access to OB32 may change this setting allowing vendor bank account details to be changed after posting. The risk is that inappropriate persons may receive payments, particularly if this configuration setting is not routinely checked. The company may leverage the automated control monitoring functionality in Process Controls to markedly reduce the risk in this scenario. In order to achieve this, a Business Rule can be defined looking at the bank account field to see if ‘Field Can Be Changed’ is set to X or not (‘X’ meaning that changes are allowed after posting), and could be scheduled for hourly monitoring. A control deficiency would then be automatically detected and an alert will be sent to the control owner allowing them to respond accordingly as part of the in-built issue remediation process.
Process Controls & Access Controls Integration
With the release of GRC 10.0, Access Controls and Process Controls no longer come as isolated applications as they are offered as an integrated solution. This new unified platform enables increased harmonization of key master data, where organization, process and control structures can now be shared across components of Access Control and Process Control, and this in turn supports a more integrated approach to governance, risk, and compliance. A big advantage of having the functionality of both Access Controls and Process Controls is the ability to perform continued monitoring of your SOD & critical access risks, which might otherwise be checked on a much less frequent basis. Additionally, by using Process Controls to maintain, monitor and assess your mitigating controls you instantly have greater visibility over their operating effectiveness based on their latest test, assessment or monitoring results. You can also use Process Controls to ensure that your GRC solution remains ‘fit for purpose’ at all times, which helps to underline its integrity and ensure you can rely on the risk and controls-related information it is reporting on.
- Manage, maintain and coordinate multiple compliance initiatives from a single repository with greater efficiency and improved visibility
- Automation of controls monitoring, testing and assessments
- Improved communication and adherence to policies
- Integrating Process Controls & Access Controls solutions to enhance compliance initiatives
- Reduced effort to achieve audit compliance
Marc will be re running this webinar on 9th July 2015 at 11:00am. To sign up please click here.
Wednesday, 21 January 2015
Posted by Richard Hunt
Richard Hunt chats with SAPinsider's Ken Murphy about governance, risk and compliance (GRC) issues and trends important to SAP customers at the close of 2014 and beginning of 2015.
See the full transcript below or listen to the podcast.
Ken Murphy, SAPinsider: Hi this is Ken Murphy with SAPinsider, and I am pleased to be joined today by Richard Hunt, the founder and Managing Director of Turnkey Consulting and an expert on the topic of data security. Richard is here today to chat with us about data security and some trends and issues that are important to SAP customers and governance, risk, and compliance and security…sort of a year-end GRC wrap-up if you will. Richard, thanks for joining us.
Richard Hunt, Turnkey Consulting: Hi Ken, thanks for inviting me.
Ken: Curious to start off, first, if you see a lot of customers making the transition to Access Control 10.1, and how are customers transitioning to that new version?
Richard: We’ve seen a lot of customers transitioning into the later versions of GRC over the last couple of years. So 10.0 came out a couple years back now, and we’ve seen a lot of customers moving on to those ABAP versions of the tool. What I would say is I’ve seen a lot of those customers transitioning as a technical migration initially from the previous Java versions just to get themselves onto the later version. And then starting to think about how they could use the tools in the wider context with the process controls and risk management capabilities that are in the same landscape now with 10.1 and 10.0. And I think next year I could definitely see even more customers looking at that transition very carefully because the 5.3 versions of GRC, which is the last Java version that was available, is going out of support at the end of next year, so there’s quite a lot of customers thinking about that. I think the only other thing I would say on that question is that we are seeing a slight trend in newer customers looking at the GRC tools in a slightly more holistic way and thinking about if they haven’t deployed GRC at all in any capacity just thinking about whether they should be looking at all three components at the same time, whether it might make more sense to start with Risk Management, actually, and work down to Access Control as opposed to the more traditional way of deploying the tools with access controls first to meet Sarbanes-Oxley requirements, etc.
Ken: That’s interesting. So, I’m curious then if customers are maybe taking that next step in their GRC journey with the adoption of Process Control. And if you can address if there’s any misconceptions over the value that Process Control can bring.
Richard: I think we’ve seen a lot more Process Control projects in 2014. We’ve delivered several this year, and that’s been steadily on the increase over the last couple of years. I think one of the reasons for that is the maturity of the product. I think one of the main reasons is that Process Control as I said is on the same landscape now with 10.0 and 10.1 as the access controls tool, so as customers are moving out of that upgrade of their access controls tool onto version 10 or 10.1 they’re considering the Process Control tool at the same time. And I think we’ve seen an increased level of maturity in our Process Control customers, as well — you’ve described it as a journey. I think we’re seeing our existing process controls customers’ maturity increasing. Perhaps starting off their Process Control journey using the tool as a controls repository, maybe with a limited set of automated controls. And then perhaps moving beyond that to start to think about how they can optimize their controls and automate as many controls as possible and really sort of stretching the tools to their capabilities. And that’s been an interesting journey for us getting to really understand the art of the possible with process controls and really start to stretch our knowledge of those tools and the full capabilities of the tools. I think in terms of your question around misconceptions of Process Control and the value it can bring I do think there’s a little bit of that out there. I think the challenge there is that process controls tools actually are very flexible tools. There’s quite a lot of ways you can use it and therefore there isn’t necessarily one specific use case for it. It’s really the value it can bring to your organization is dependent on how you’re intending to use it and what your specific gaps are. I also think that one of the key strengths of the tool is actually around testing controls and as repository for control testing information, and not every customer quite gets that being its real core strength. A lot of them are more focused around trying to use it to operate controls, which can be done very well in Process Control but I think the real killer use of it is in the testing of controls.
Ken: Switching gears a little bit, Richard, I’m curious if there’s any significant regulatory changes or compliance issues in 2014 or coming up on the horizon that customers need to account for.
Richard: I’m based in the UK, and specifically in the UK something that I can think is quite relevant for next year would be the new guidance on risk management from the Financial Reporting Council though that came out in September this year, and I think that there’s a lot more very strong guidance in there around how internal controls and risk management practices should be applied at the governance level, and I think that’s that going to raise the broad awareness of this area and potentially drive the need for technology solutions in this space. I’m very aware this is not purely around technology. This is around improving risk management. It’s around improving internal controls, and you can do those without technology, but I think the GRC tools will be tools that customers are looking for to give them an edge in improving their alignment with those new regulations—they’re not regulations; it’s what we call a “Comply or explain.” It’s the rule that UK companies have to apply to that. It basically means that if they don’t comply with the new guidance from the FCA then they really need to explain why.
Ken: That’s important to know. Also, what general trends are you seeing in the overall GRC and security space, and how they’re important, or how they affect SAP customers?
Richard: Well actually today’s quite a topical day to think about that. I think external threats and cybersecurity threats to SAP are on the increase. I don’t know if you saw Newt Gingrich’s comment about the Sony announcement today that they were pulling their film “The Interview”. His comment was pretty strong on this. He sent a Tweet, I’ll quote, is “No one should kid themselves with Sony’s collapse. America’s lost its first cyber war. This is a very, very dangerous precedent.” While this wasn’t SAP-specific by any means, I think with the increase of external entry points to the SAP environment, with the interconnectivity of SAP systems, etc. and with the fact that SAP is a core application for most of the customers that are running it, it is potentially a target from a cybersecurity perspective. So I think the cybersecurity risk to SAP and the risk of external threats and the focus of securing SAP away from securing it toward, shall we say, securing SAP for external threats more robustly, as well as the internal controls that we’ve always been focused on around segregation of duties, sensitive access, etc. For me that means taking a slightly different approach to how we secure SAP. It means thinking — we call it end-to-end security for SAP — it means thinking about things that you wouldn’t necessarily have focused on in the past. Things like the SAP message server and all the various different Web entry points to SAP, the database security underlying the SAP environment. There’s quite a lot more things you need to think about if you really want to secure an SAP system from external threats. Also I think going forward securing the HANA environments that customers are putting up is quite a key area, as well, ensuring that you’ve applied the same level of rigor to your HANA systems as you have to the rest of your SAP environment. As with any new technology, security quite often doesn’t come first in these things. I think now that a lot of the technical guides have got all of that, most of the bugs out of the way in terms of getting SAP HANA systems up and running and working functionally, we need to start getting the opportunity from a security perspective to step in and apply the same level of rigor we would do in a normal SAP environment to those HANA systems now.
Ken: Lastly, Richard, I’m curious if you had any parting advice for customers as we head into 2015. Anything in particular that SAP customers should be on the lookout for?
Richard: Well I think I’d say two things on this. I think, you know, I’ve mentioned the external threat side of things. Two other things, though, I think would be relevant here would be the newer SAP GRC products being more mature as products: the Fraud Management and Audit Management modules. I think further integration of those products into the SAP solution, going to the SAP GRC suite, and also deployment of SAP GRC on HANA. And then I think finally there is a bit of a call to action in the SAP GRC space for me this year, which is the fact that the 5.3 solution is going out of support at the end of the year. So I think that should be driving a lot of conversations in the SAP GRC space this year, particularly for customers who’ve been using SAP GRC for a while, maybe haven’t really driven value out of that. And I think rather than just purely thinking about upgrading or migrating that to the latest version, just step back and look at what those products are now, because they’re very different from what you would’ve deployed when you deployed the Java version a few years back.
Ken: Again this is Ken Murphy with SAPinsider, and we’ve been chatting with Richard Hunt, the founder and Managing Director of Turnkey Consulting. Richard, we appreciate your insights. Have a great holiday season, and we look forward to connecting with you again next year.
Richard: Thanks, Ken. Have a fantastic Christmas and New Year, and I look forward to seeing you in Vegas if not before. Cheers.
Wednesday, 7 January 2015
Posted by Tom Venables
In this series, we have looked at ensuring that data is extracted and stored in a way which supports compliant data handling and in this final piece will look at business-led approach to providing reports to users.
The final principle of secure and compliant data provisioning is: only present the reports to correct groups of users.
Again, this seems an obvious principle which many of us in the security space take for granted, but it is a common occurence for Management Information programmes to focus on the functional split of data and associated reports, without thinking of the authorisation setup in terms of roles and user groups involved.
To overcome this, all reporting requirements should be linked to business processes, in that it should be possible to identify a step in the process for which the report is providing key information and support. With this in mind we can relate the reports to the jobs, for which roles have been created, and ensure that roles are consistently applied across landscape.
If you can achieve a consistent role design between ERP systems and your BI landscape, it is also possible to automate the allocation of authorisations in your BW analysis authorisations, based on the contents of the equivalent ERP roles. This can be achieved through the use of variables in analysis authorisations and by performing an extraction of the authorised values from the ERP roles assigned to the users. These values can then be referenced at runtime of reports to present only data for which the user is authorised in the ERP system.
Your company employs accounts payable clerks to process payments and, to support their business processes, a suite of reports has been developed. These accounts payable users have an AP clerk role for one company code in ERP and an equivalent AP clerk role in BW. You have used variables in the analysis authorisations to provide the company code access, in alignment with that which is allocated in the ERP system and the role provides access to the multiproviders which store the reports for the AP function.
This can be further extended into Business Objects (BO) reporting suite, where roles from the BW system can be imported as user groups and a folder or universe structure created which mirrors the job-aligned roles in the BW and ERP systems. In this way, provision of a role in ERP can logically extended into BW and BO systems to provide consistent, business process aligned access across the landscape and provision the reports which support that job function.
To continue the example above, our AP clerk would then have access to folders or universes in BO which provides the reports and the data which support their job, plus the access in BW to provide commensurate data access with that allocated in ERP.
If you bear in mind these principles in the design of your Management Information systems authorisation concepts, you can make life much easier and provide business focussed reporting, while ensuring compliance with your security objectives for data.
If you have any comments or questions, please feel free to use the comment submission below.
Monday, 15 December 2014
Posted by Tom Venables
Up to now, we have looked at understanding the purpose of an MI system and some options for transforming and securing sensitive data. In this piece, we will look at storing data in a way which supports compliance objectives.
The next principle to support the secure and compliant provisioning of data in BW is: store the data in a way which will support the authorisation design.
It is very common to see datamodels in BW which have been structured entirely around delivering the functionality of the reports, withoutconsideration of the responsibility to secure data, or the engagement of the authorisation team to provide or restrict access to the data as appropriate. In any LSA (layered, scalable architecture) model, there are several layers in the BI environment which can be used to ensure that data is presented to the reports in a fashion which is functional, performs efficiently and is compliant.
In circumstances where there is no option but to import and present data which is sensitive, our next approach to ensure we can make this available to those users who require it, is to ensure it is stored in a location and a format which supports the correct use of authorisations on this data. Segregating sensitive data and ring-fencing it into limited-access infoareas within the data warehouse, will support such a design and ensure that roles and analysis authorisations can be structured in a way that provides differeing levels access.
One method which have proven particularly effective is to configure a virtualisation layer within the BW data warehouse to store multiproviders, which can be used to 'hang' the reports off. By using this method, it is possible for us to authorise end-users of reports on the multiproviders and infoareas on which the reports are built themselves, without the need to provide access to the detailed infoproviders in which the raw data may be stored.
Hanging the reports in this way, with ring-fenced authorisation on the infoareas (which may be aligned to roles) will allow the analysis authorisations, which support the reporting access, to be linked to the roles themselves. This should always be considered as best-practice, as it will allow for automated allocation of analysis authorisations to the users with minimal manual maintenance overheard.
Once your users have access to the data within the reports it is time to think about the final option we have for securing data, the presentation of reports to users, which we will cover in the next entry.
If you have any comments or questions, please feel free to use the comment submission below or email us at: email@example.com
- July 2015 (1)
- May 2015 (1)
- January 2015 (2)
- December 2014 (1)
- September 2014 (1)
- August 2014 (2)
- April 2014 (1)
- February 2014 (1)
- December 2013 (1)
- October 2013 (1)
- June 2013 (1)
- May 2013 (1)
- March 2013 (1)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (3)
- October 2012 (2)
- August 2012 (2)
- July 2012 (3)