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.
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: firstname.lastname@example.org
Thursday, 18 September 2014
Posted by Richard Hunt
We're delighted to welcome Richard Anderson, our first guest blogger, to the Turnkey Consulting Key Insights blog.
New "Guidance on Risk Management, Internal Control and Related Financial and Business Reporting" from the Financial Reporting Council
After much turmoil in our economy, and many, many months, if not years of consultation, the long awaited guidance on risk management (and all the rest of the things included in its snappy title) from the FRC was published at midnight last night (16/17 September 2014). And – I never thought that I would write this – it was well worth the wait. This document is miles ahead of the former incarnations of the Rutteman Report (remember that?) and subsequently various versions of the Turnbull Report. At last we have something that really addresses the needs of companies, and boards in particular, to do something sensible about risk management.
Thankfully this guidance is also pulling together the various sources of guidance on risk including the former Sharman Report on addressing the knotty issues of reporting under the going concern principle. So this becomes a one-stop source of reference and guidance for boards.
Contextually, as the document says:
The Code defines the role of the board as being "to provide entrepreneurial leadership of the company within a framework of prudent and effective controls which enables risk to be assessed and managed". Effective development and delivery of a company’s strategic objectives, its ability to seize new opportunities and to ensure its longer term survival depend upon its identification, understanding of, and response to, the risks it faces.
At last we are looking at risk management in the context where it belongs: the entrepreneurial leadership of the board, seizing new opportunities and long term survival. In other words this is not a mere governance issue: it is about the creation and protection of value. It goes on to say that the “Company’s approach to risk [needs to be] properly considered in setting the company’s strategy”. In other words risk and its proper management is a strategic issue – as I have been arguing for a very long time. Of course this is divergent with the common practice in many companies today where it is largely a compliance issue dealing with operational matters.
The responsibilities of the board are set out in Section 2 of the guidance and are comprehensive. I have summarised them below:
- Design and implementation of appropriate risk and control systems and robust assessment of principal risks;
- Determining risk appetite;
- Ensuring appropriate culture and reward systems are embedded;
- Agreeing on the approach to managing principal risks;
- Monitoring and reviewing risk management; and
- Ensuring sound information on risk management is published
There is also more material on the board’s responsibility for the Going Concern principle, which I will deal with in a subsequent note. Interestingly, references in earlier drafts to stress testing appear to have been relegated to Appendix B where the approach to longer term viability is discussed. With that exception, the list of responsibilities includes three comparatively recent additions to directors’ responsibilities: namely risk appetite, risk culture and ensuring that sound information is published on risk matters. While risk appetite appeared in the UK Corporate Governance Code a few years ago by inference, it is here explicitly (albeit in brackets!)
My personal take on this is that directors who take this list of responsibilities seriously (and who wouldn’t given the potential impact of failing to do so) will have some considerable work on their hands to address the first two of these issues: namely risk appetite and risk culture. The more fundamentalist members of the ISO31000 community will likely have a collective frenzy of horror at the “Risk Appetite” phrase creeping in – I on the contrary am delighted to see it appearing, because I believe it to be the cornerstone of an effective risk management approach, especially in the strategic domain. At a recent Internal Audit conference I asked how many internal auditors were reviewing their corporate risk culture in anticipation of these changes (they have been well trailed). The response was that depressingly low numbers are doing so and even fewer could articulate their approach to risk appetite.
Section 3 of the guidance advises boards on the exercise of their responsibilities. Five key areas strike me as being particularly relevant and they include:
- Having the board ensure that the "appropriate culture is on place". Indeed the guidance goes on to say that "it is not sufficient for the board to set the desired values."
- Ensuring that there is adequate discussion at the board: this is a far cry from the comments made by Nigel Turnbull after his Report was published when he said to the effect that it was sufficient for the board to have a chat once or twice a year. The guidance now says that "the board needs to ensure that it engages in informed debate and constructive challenge and keeps under review the effectiveness of its decision-making processes."
- Considering whether the board and any committees and management groups have the "necessary skills, knowledge, experience, authority and support to enable it to assess the risks the company faces and exercise its responsibilities effectively". For some time now, I have predicted that this is an area where boards are going to need help. There is far more to the style of risk management that is being asked for here than was implied under the previous guidance. My take on this is that we will see more boards looking for a risk specialist on their team of non-executives, and quite probably seeking board advice specifically about these areas, rather than the broader advice that might be offered to management more generally on the topic.
- Specifying and then monitoring the information that it requires to discharge its risk responsibilities, and in particular that "it is of sufficient quality to allow effective decision-making". Much of what currently passes for risk management is a data-free zone. This will have to change as boards demand better quality information over which appropriate governance procedures are exercised, more akin to the disciplines over accounting data.
- Identifying and seeking assurance on risk matters, including from "compliance, risk management, internal control and internal audit functions within the company, the external auditor’s communications to the audit committee … and other internal and external sources of information or assurance." The guidance goes on to say that "the board should satisfy itself that these sources of assurance have sufficient authority, independence and expertise to enable them to provide objective advice and information to the board." Expertise is written in my italics: it ought not to be good enough for anyone to hold themselves out as a professional risk practitioner without having appropriate credentials. In my view appropriate credentials are rarely provided solely by dint of a qualification in another professional area.
Section 4 of the guidance provides some thought on the establishment of risk management and internal control systems. There is comparatively little that is new or innovative in this regard in this document. Section 5 addresses the requirements to monitor and review risk management and internal control systems. Most important in this section are the recommendations as to what an annual review of effectiveness should address. These include:
- Risk appetite
- The operation of the risk and control systems;
- The integration of risk and control with considerations of strategy and business model;
- Changes in risks and the ability to change in response to the external environment;
- Risk communications
- Issues dealt with by the board during the year; and
- The effectiveness of the reporting process to the public.
It will be up to the board to determine how this review is carried out. No doubt internal audit will often be the default choice. I would merely caution the board to consider the relevant domain qualifications, skills and expertise resident in their internal audit departments. Some will have it, others definitely will not and the board will have to satisfy itself that the right people are conducting the review.
Section 6 of the guidance addresses specific reporting requirements, which I do not propose to cover here, apart from the “Safe Harbour Provision in relation to the Strategic Report, Directors’ Report and the Directors’ Remuneration Report”. Directors will benefit from some protection from making misleading statements in these areas provided that they did not know that the statements were untrue or misleading and did not know that the omission was a dishonest concealment of a material fact. Again, this suggests to me that directors may well wish to engage with professional advisors to assist in the preparation of relevant information being provided to shareholders (and others) in these various reports.
Appendices A and B deal with Going Concern and the Longer Term Viability Statement respectively. I will address these in a subsequent note.
Appendix C provides some useful questions for the board to consider, and Appendix D sets out the relevant sections of the UK Corporate Governance Code and other regulatory provisions.
This document is far reaching in how it addresses risk management. Many companies are going to struggle to articulate their risk appetite or understand their risk culture with sufficient depth to make the concepts meaningful. I anticipate that boards will start to recruit “risk” non executives to their cadre and that we will see more risk board advisors emerging.
My key recommendation is that all boards should consider the content of this guidance carefully and take steps sooner rather than later to address any shortcomings in their current procedures.
Richard Anderson is the Chairman of the Institute of Risk Management and was the principal author of their guidance on risk appetite and tolerance. He is the principal at AndersonRisk and works with a number of UK and overseas Boards on governance and risk management matters.
If you'd like to get in touch with Richard, please contact us at email@example.com with your questions or comments.
Friday, 29 August 2014
Posted by Tom Venables
In the previous instalment, I described the need to clearly understand the purpose of a Business Intelligence (BI) platform used for management information and to manage the expectations placed on the system. It is important to remember that your BI system should be providing targeted, business-led reporting and not simply used as a data-dump tool. In this continuation of the series, I would like to talk about the options we have to secure the stored data for targeted reporting which can bring the business requirements and compliance together.
The first principle is: do not import sensitive data unless absolutely required.
It may seem obvious, but many organisations miss this key opportunity to ensure that sensitive data cannot be accessed in the BI platforms; it really can be as simple as ensuring the data is not there in the first place. As discussed last time, with a clear understanding of the report requirements it may be possible to include only a level of information which is not considered sensitive and therefore does not require the same level of control as that of the source system.
By working closely with the extraction and transformation specialists from the BW build team, it is possible to ensure that these sensitive characteristics are then stored in a format which presents minimal risk of access to the data, such as aggregated information. Logical separation of the data, such as storing in dedicated infoproviders can further help to ensure that even users with the ability to create reports cannot access the sensitive data. This is particularly relevant in systems where you must consider Data Privacy and commercially sensitive or confidential data.
Challenging the need to import data is one of the most straightforward ways in which we can assist users at all levels of the business in thinking about the need to include information in the BW systems. ETL (extraction and transformation) layers of the datamodel encompass not only the direct extraction of data from source systems, but also have the capability to transform data. Transformation provides an up-front mechanism to identify sensitive data that may be required and to manipulate it into formats which do not present the same degree of risk to an organisation, for example aggregation, which allows data to be displayed for a team, rather than identifiably linked to individuals.
Many organisations have used BI systems merely as a replacement for table queries from their SAP systems; importing all data and providing it in a format which is difficult to secure and which does not intelligently present the data in a manner which supports business processes. Ensuring that reports are process-driven will permit authorisation teams to work with management information functions and provide compliant, business-led reporting.
Once your data is extracted from source and transformed into a form which is delivering the needs of the reports, in a more compliant format, you can think about the next principles for securing reporting data, which I will cover in the next session.
If you have any comments or questions, please feel free to use the comment submission below