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, 4 February 2016
Posted by Simon Persin
When it comes to security of data, I believe it important to split the discussion between cloud and managed services. With cloud, there isn’t really a difference in traditional on-premise deployments. Regardless of whether the solution is hosted in your own data centre or someone else’s data centre, the requirements for securing the information remains the same. Business critical applications have been hosted in cloud based servers for many years and with the right level of encryption, this can be equally secure as a physical server.
Corporate applications are very rarely hosted on public cloud servers, so this comes down to an economic decision about whose data centre is best placed to host the application.
The question is whether GRC and security related data is significantly more risky than any other corporate information stored in your enterprise applications. It is certainly considered sensitive due to the potential for reputational damage if the level of access risks or compliance failures become public knowledge.
If the GRC system is used to perform more tightly integrated operational tasks such as automated user provisioning or continuous monitoring of key control operating in the business processes, there is an increased risk of process disruption should the GRC system be targeted for attack. However, this does not prohibit putting GRC in a cloud environment any more than any other system. It just reinforces the need to have a coherent end to end security strategy to ensure that your company assets and information are securely maintained throughout.
GRC as a Managed Service is a slightly different proposition. In this case, a third party supplier is being invited into a position of significant trust with a potentially business critical system. There is a long-standing precedent for this to occur. It is rare to find a company that does not use contingent workforce to support their needs. Similarly, it is very common to find some sort of outsourced function either in a technical support capacity or performing a niche business function. Again, we should be asking whether GRC is significantly different to other applications.
Whilst Turnkey Consulting is offering a GRC service, there is still a requirement to retain governance within the customer organisation or at least ensure with SSAE16 (transference of risk & responsibility alongside the operation of tasks) and similar due diligence requirements, that the supplier is capable and effective in the operation of such key business process steps.
Many companies have managed to successfully outsource and achieved significant benefits. In the same way as deploying on a cloud server, treating GRC as a managed service does not in itself represent a greater risk to the organisation. Instead, the focus needs to be on ensuring the supplier is the correct fit for your business and that the roles and responsibilities of the agreement are clearly understood from both sides. As well as that, the supplier must fully understand the importance of the service they are providing and the sensitivity of operating as part of a compliance capability.
We do not see our GRC as a Service being a total outsourced function but rather a platform and complimentary services which reduce the need to duplicate the niche and expert skills that Turnkey Consulting can provide to your organisation.
Data security needn’t be a concern as long as you consider it properly and work with an organisation that truly understands it. However, there is more to consider.
Read our latest article to find out more >
Thursday, 21 January 2016
Posted by Tom Venables
As you know, this principle states that users, programs and systems should be given the least privileges, access and authorisations required to complete a task or job. This can take the form of restricted roles in SAP, or simply locking down access to an employee’s computer so they can’t install software – in both cases, we’re restricting what they can do to minimise risk.
This principle is widely considered appropriate in SAP systems as it aligns well with the way in which we allocate authorisations to the roles and users. Because SAP authorisations are additive, we start with a blank slate and add the transactions and authorisations to the role, building up a profile which should only contain what’s needed to complete the task or job the role is built for. We cannot add something to the role which restricts what a user can do (for the most part).
In theory, that sounds like the best case security principle to operate from. However, that principle often gets diluted over time. We usually come across this situation in implementations which have grown organically, with access creep and continuous change in environments chipping away at the principled design, until an amalgamation of authorisation is granted which no longer conforms to these principles.
This kind of organic departure from principle can be especially prevalent where security is handled by implementation partners or internal organisations which do not “think security”, like those which are part of a BASIS function, or with a focus on incident resolution, often without the luxury of time or, occasionally the interest in seeking design signoff or approval.
The problem, of course, is one of cost and time – building with least privilege requires designs to be robust, the testing and re-testing of authorisations and can increase time to delivery, or time to resolve incidents. This, understandably, can lead organisations to look for other ways to achieve compliant systems and user accesses.
The most highly regarded security design from a business perspective is one which is invisible to them. Users should have sufficient access to get their job done without impingement. Authorisation failures cause business pain points as they immediately stop the business user from completing the tasks at hand. When you add in the time lost from productive operations, the time taken to log, investigate, resolve and implement the fix, it can be costly to operate at a truly least privilege state. Additionally, any business process innovation or amendment may be constrained by the authorisation restriction thus stifling business dynamism and agility.
To support that desirable situation, some organisations have abandoned the least privilege principle in favour of having a risk based approach which permits potentially wider than required, authorisation profiles to be used, as long as they do not contravene pre-defined risk levels. This can be easier to deal with operationally as users are only restricted from compliance relevant risks but the design can be reactive to fast moving business innovation. It often aligns more easily with a job-based role profile, thus making the design more easily translated into language that a business user or approver may understand.
This approach does require careful management as the risk profile of the organisation may not be static. Access granted may not constitute a risk at the time, according to risk reporting but may, in future, cause additional conflicts which can take time to understand and resolve – unravelling authorisations which have grown in this way is often a more complex and costly exercise than investing the time in a proper design and implementation upfront.
In conclusion, the principle of least privilege is still a worthy aim for many IT systems, but improved risk reporting, monitoring and automation of controls are enabling organisations to approach their security design in a way that can take an approach with slightly wider privileges and place control around that. It is important to understand what your security design is there to do - is it designed to allow compliance to be easily understood by auditors and regulators or is it there to support your business operations in a controlled yet flexible manner?
The concept of least privilege will be a permanent fixture in discussions relating to security - it is still relevant, especially when managing implementation partners and lower-skilled security teams. The alignment with design and build activities plus the supportability and future-proofing of the system justifies the investment in applying these principles to your SAP estate early in development.
Please feel free to comment on your experiences of least privilege in the comments section below.
Wednesday, 13 January 2016
Posted by Simon Persin
Many people refer to “cloud” and “managed services” synonymously. However, in this instance, they are vastly different. Cloud computing has been around for a long time with organisations virtualising servers in order to run multiple applications from a smaller physical server estate. There are significant savings to be had by continuing to look for cheaper hosting rather than having to purchase physical servers for every sizing increase or application purchase.
Hosting applications in the cloud has just become the next step on that journey. Rather than hosting all of these virtual servers yourself and having direct costs to your own bottom line, why not partner with a provider of hosting solutions and share the economies of scale?
However, Managed Services are far from being just cloud. GRC as a Service means just that; a managed solution that is ready to be used. There is more in there than simply the hosted platform. A managed service is a working solution which is hosted but comes as a customer ready package of services; namely, maintenance, support & account management and customer configured content.
Having said that, there is naturally a price point that needs to be considered to make the service viable. The important thing to bear in mind however, is that the comparison should be made against a credible alternative and look at the TCO rather than just the simple calculation of a subset of costs, i.e. the license fee. As long as the other values are clearly articulated, cost should not be the primary decision factor.
So will GRC as a Service cost less than operating an On-Premise deployment? The answer to that depends on your individual requirements. If you already have a licence for the products, a mature IT infrastructure estate where increasing the capacity is easy and cheap to achieve and you have an experienced and capable support team with the correct skillset to support your GRC implementation, then it is difficult to say that GRC as a Service will be cheaper. However, if any of those elements are missing, then there is the real possibility that GRC as a Service will be competitive. However, there is more to consider than simply cost.
Read the full article….
Friday, 23 October 2015
Posted by Simon Persin
Access Control 5.3 is due to exit “Mainstream Maintenance” and enter Extended Support at the end of 2015. Many organisations will find themselves in a situation of “end of life” with unsupported applications in various states. There is always the view that if it isn’t broken, don’t fix it. If you’re happy with only “keeping the lights on” without doing anything different, then there’s no immediate action.
However if you have plans to upgrade or patch your existing SAP systems, then you may encounter problems such as GRC systems no longer reporting access violations, or missing out on particular FireFighter functionality. So what should you do?
- Examine the current SAP roadmap & upgrade plans for the GRC landscape
- Explore the migration path
- Decide whether it is worth upgrading
- Look at the benefits:
- Enhanced Risk Analysis, User Interfaces and reporting capabilities
- More logging available in the FireFighter scenarios giving you much tighter controls
- Inherent workflow capabilities within FireFighter, smoothing the audit of emergency access
- A powerful and flexible workflow engine allowing more complex and realistic approval procedures for GRC master data and automated provisioning
- More intuitive User Interface is providing much greater personal control
- Improved Transport Management, enabling you to manage changes within GRC more efficiently and greater compliance than previous versions
- Object level security providing proper robust security and authorisations capability
- Think about the wider picture
- Ensure that the project is not seen as a generic upgrade
- Keep up with technology
Controls Automation - Monitoring vs. Operation and the Business Case for Automated Controls - Part 3
Thursday, 22 October 2015
Posted by Marc Jackson
Monitoring vs. Operation
We talked briefly about the potential controls reporting challenges within a GRC application if you are using it for both control operation and monitoring purposes, so let’s take a closer look at this final element of controls automation – automated controls monitoring. I often find that the terms control operation and controls monitoring are used interchangeably and can be muddled up and confused, mainly because they tend to both be bundled under the umbrella term of automated controls. However you need to be very clear which of the two you are referring to when you embark on your controls automation initiatives as they are very different things, but understanding and appreciating the difference between them is actually quite straightforward.
Automated controls operation is operating a new control without any human intervention (e.g. implementing password parameter settings to password security), whereas automated controls monitoring is the monitoring of a control which is already operating, typically an automated control itself, to ensure it continues to operate as expected going forwards, and this is also performed without any human intervention (e.g. in your deficiency criteria you can state what the password parameter settings should be for it to operate effectively, and if it strays from those expected settings the monitoring rule would automatically detect this and enable the control to be remediated accordingly).
This type of insight into the operating effectiveness of your controls , and the real-time detective reactions to any operating effectiveness issues, means you can strengthen your internal control environment by having a much greater level of assurance and less time during the compliance year when controls are not working.
Business Case for Controls Automation
Now that we’ve covered all of the elements of controls automation, lastly we’re going to take a quick look at the things you need to consider when trying to build a business case for controls automation. The number one priority is to be absolutely clear on what it is that you wish to automate, and avoid talking about it in broad general terms which will only serve to confuse those involved in the process. As we’ve discussed, there are a few different elements of controls automation and not all of them may be relevant for you at a particular point in time (e.g. you may not have a GRC application in place and so would initially like to focus on getting the most out of your in-built application controls before looking to extend the reach to GRC-enabled controls operation and monitoring).
Once you’ve decided on what it is you wish to include you can then evaluate the benefits and costs of each of these elements. Even though the quantitative benefits make the most powerful argument in a business case, the value of the qualitative benefits should not be ignored. These benefits can be looked at in 4 dimensions:
- Cost Reduction – which refers to all direct and indirect cost savings (e.g. lower cost of controls through the reduction of manual controls, lower cost of control investigations through enhanced audit trails etc.)
- Compliance – refers to reduction in compliance costs (e.g. lower audit costs, lower management testing costs, reduction in fines/penalties etc.)
- Risk Reduction – refers to reduction in impact and/or probability of risks (e.g. revenue risk – missed revenue due to missed/under billing etc., cost risk – incurring additional costs due to errors in core processes leading to things such as duplicate payments/overpayments, reputational risk – due to errors in information exchanged with customers, business partners, public etc.)
- Process Improvement – refers to increasing processing speed by automating manual steps and validations (e.g. reduced process cycle time, 100% data validation, enhanced decision-making etc.)
Of course there are also challenges and costs associated with controls automation initiatives and so these also need to be determined and documented in order to provide a comprehensive business case. Such costs include, but are not restricted to, hardware and software costs (although not a factor if not embarking on GRC-enabled controls), cost of implementation depending upon how much is done in-house or with the use of external consultants, training staff on how to use this new technology, as well as the ongoing management and maintenance of such systems, processes and controls.
- February 2016 (1)
- January 2016 (2)
- October 2015 (4)
- September 2015 (1)
- August 2015 (1)
- 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)