Blog Archive

The Paradox of password rules

Friday, 14 February 2014

Posted by Simon Persin

Many organisations can expect to see some sort of findings on their audit reports pertaining to their system password rules and settings. Examples of these include the number of lowercase, uppercase, numerical or special characters required in passwords in combination with not being able to reuse passwords which have already been used. It is a widely held belief that the more restrictions and conditions that are placed upon passwords, the more secure your systems is. I believe that this is actually a paradox. In my experience, more complicated password conditions actually lead to a proliferation of simplistic passwords which can be more easily guessed or cracked. This actually reduces the security of your system rather than enhance it. It is also much more likely that users will write down their passwords in an unencrypted document on their PCs or potentially on a notepad or post it note nearby as a way of remembering the complicated passwords.

If you have largely unrestricted password conditions, you open up the possibilities that the passwords can be anything. Although you will always get the common ones such as spouses names, children’s names or swear words, there is also more chance that the password will be something completely random since the user has the freedom to choose anything from the languages available across the globe. For example combining two randomly different words together as a single password would mean that the character length is naturally greater and would take an increasingly greater period of time to crack through brute force. To protect yourself from very common passwords many systems, including SAP, have a prohibited passwords list which can be maintained.

If you start enforcing greater levels of complexity, users naturally have to think harder about the passwords which they choose. Having worked on multiple client sites, I dread the time where the little dialog box is sitting there asking for me to define a new password. Often, I spend more than a few minutes trying to think about what will fit the client password conditions and then what I am likely to remember. Until you meet the criteria specified by the system, you will simply get error messages stating the deficiency in your password strength. Once you have finally met the criteria, you will then understand the minimum standards required by the system and therefore understand the likely structure of a number of users’ passwords within that system. Whilst this might actually appear to make the password itself more complicated, you tend to find that more people follow the same thought process and therefore mean that you can actually guess many more people’s passwords than you would ordinarily have been able to. I have lost count of the amount of times people end up with a swearword with a Capital first letter and an incremental number with a $ sign at the end. A worked example shows the common thought process for building a compliant password yet not actually making it difficult to work out, starting with my first name:



Previous Input Password

Updated Password based upon Condition

Length must be 6 characters



Must have upper case character



Must have a numeric value



Must have a Special Character



Next Password



Next Password




Whilst the password initially appears very secure with a combination of characters which may not easily be guessed, over time, the password settles into a very simple pattern whereby it remains largely static and simply increments the number with each change. 

Therefore, this password has retained its adherence to the complicated convention & standards set by the system yet remains an inherently weak password in general terms. 

In SAP systems, you have the option of configuring an additional parameter, login/min_password_diff, which requires that the password has a minimum number of differences from the previous one. At Turnkey Consulting, we recommend that this is set to “3” as a minimum but even then, users will find a simplistic pattern to meet those standards with as little thinking time as possible.

Make a comment

Emergency Access Logs - What is logged? And what isn't?

Tuesday, 30 October 2012

Posted by Simon Persin

The SAP GRC Emergency Access Management (EAM) log level has been the subject of a lot of questions and debate. In this post I have summarised the current available logs together with their purpose and a description of what is captured.

There are five key logs available in EAM:

Transaction Log - This is the equivalent of the STAD data and a log entry will appear whenever a transaction is called by the Firefighter ID. 

Change Log - This is based upon the data held in tables CDHDR and CDPOS for business change documents. All changes logged by those tables will be captured alongside the nature of the change. This includes the field and values updated. However, this does not include a number of system administration functions if not covered by the business change header tables. Therefore, it is not guaranteed to capture each and every change made in the system. 

OS Command Log - This captures operating system commands executed from within SAP systems (via transaction SM49).

System Log - This reads from the SAP Application to show debug and replace entries from transaction SM21.

Audit Log - This reads entries from the SM20 system audit log assuming that this is configured correctly in SM19.

The present solution does not read the DB Table log but there is a planned enhancement to include this.

Make a comment

Compliance of the Compliance Tool

Monday, 13 August 2012

Posted by Simon Persin

The SAP GRC Access Controls product is designed to support customers in their compliance objectives. To that end it comes with a number of “out of the box” capabilities to achieve this status for the connecting systems.


A common issue faced in the previous versions of GRC (5.1 to 5.3) was that the GRC system did not adhere to SAP best practice principles for system management and changes. Historically, it was easy to counter the application maintenance best practice by saying that GRC is different and not subject to the normal SAP application management conditions. Being a java environment, it did not have the transport management system available as standard to track changes in a controlled manner. Therefore, configuration changes had to be made in production directly and user authorisations were necessarily wider to be able to use the system.

Similarly, with it not being based in ABAP, the GRC system could not make use of the Firefighter application for elevated access management. The authorisations also relied upon standard java based actions rather than the object level security afforded to most SAP applications. Therefore, astute auditors raised questions over the compliance of the compliance tool. This often led to manual controls being documented and operated on the GRC system.

No more excuses

With GRC 10 being based on the SAP Netweaver ABAP there are no more excuses for managing GRC systems in a non-compliant manner, yet many implementations still do not have compliance at the heart of their implementation methodology. It is very easy to focus on the core functionality to support the SAP system processes (i.e. automated provisioning and emergency access management) but how many of the GRC implementations really take the time to understand the GRC operating processes as well?
GRC projects might then follow the pattern of what security professionals continually struggle against.
What are the symptoms?

There are tell-tale signs that not all is well with a GRC implementation. Some of these include:

  1. Authorisations are very close to, if not exactly like SAP standard proposed roles.
    Authorisations are regularly relegated to the bottom of the priority list in favour of making the technology work.
  2. The administrative functions of GRC may be left largely undefined.
    The result of this is that administrators may retain pervasive access to the GRC system under the guise of post go-live support.
  3. Configuration changes made directly in follow on systems.
    When consultants do not have significant experience in working with ABAP systems, projects may take the easy way out when performing configuration by choosing to open the client for changes rather than think about the appropriate way to transport. This is especially true with configuring the connector landscape.

What does good look like?

1. Proper security and authorisations management

There is no reason why GRC should not be used to report on itself by installing the plug-in into the GRC system. From a GRC functionality perspective, this will then allow GRC authorisations to be included, reported on and assessed as part of integrated access management processes. I would therefore expect to see that additional risks are included in the ruleset which have a GRC flavour e.g. workflow administrative access. I would also expect to see some customisation of the standard roles to fit the individual business scenarios alongside a clear roles and authorisation design to evidence that this was actually considered.

2. GRC emergency access scenarios

Firefighter can also be used to support elevated access to the GRC system as well as to the other systems in the landscape. I would expect at least some Firefighter scenarios for standard Basis system maintenance access if not access to the workflow administrative access.

3. User provisioning and role management

Provisioning to the GRC system can also be included in the access request workflows and roles can be built and managed through Business Role Management. I would expect to be able to submit access requests for GRC system access in the same way as I would for other SAP applications.

4. Best-practice application maintenance processes

Perhaps more importantly, with GRC based on standard ABAP technology it should no longer be subject to a different set of rules around system and application management. Transports can and should be used wherever possible to align to good practice for IT general controls. Opening the client should be a last resort for changes which cannot be transported rather than an easy way out to correct poor development practices.

5. GRC system controls

In more complex operating environments, it is vital to consider the controls which should operate on the GRC systems. In the majority of cases, the GRC system should be able to rely upon the controls applied throughout the rest of the SAP estate. However, care should be taken that the specific functionality used in GRC should be taken into account and the control descriptions updated to reflect GRC processes.

It is important to also think about the impact that GRC has on the wider application as some very sensitive processes such as user provisioning and emergency access management may well be managed in the GRC system rather than directly in the SAP application as a result of the GRC implementation. This should definitely be reflected so that it is clear to all parties.

Impact on Implementations?

So what does this mean for implementation projects? Ultimately, I believe that this should make very little difference to the better examples of GRC implementation projects. These good examples of projects will always have security and controls at the heart of the project. Therefore, looking for control gaps and finding ways to plug them will ensure that it is not just the technology that is implemented; but that it is implemented with clear operational guidelines for how to maintain the compliance status.

It is the experience and diligence in getting these factors right which will differentiate specialist implementation partners with a proven track record in successful GRC projects. The alternative is a potential solution which may provide the superficial impression of control but still leave further findings or significant control gaps available for auditors to find and opportunists to exploit.

Make a comment

GRC Certification - is it worth the paper its written on?

Monday, 16 July 2012

Posted by Simon Persin

The SAP GRC Access Controls certification (C_GRCAC_10) was released early in 2012. In this blog, we’ll look at the quality of the certifications and its relevance and usefulness for both clients and consultants.

SAP has a difficult job in setting content for the training courses and indeed the examinations. The most common complaint is that the content is generic and very theoretical. The exercises can often feel worthwhile given the classroom conditions but not particularly relevant for real world examples or use cases. Every customer uses SAP applications in their own particular way and therefore, it is impossible to provide specific examples to cater for each and every scenario.

GRC is no different in that regard especially when you consider the possibilies available for a workflow based user provisioning process. So how can you set an examination based upon all of the particular requirements of each and every different SAP customer?

How much is certifiable?

To my mind, the only way that SAP can really do this is to focus on the technology; how to use and configure it. Whilst we all know that technology is only a small part of the wider GRC projects, it is the only area of the project which can be adequately assessed.

Actually defining the business use cases and process designs cannot be simply taught or certified through traditional multiple choice exam questions as there is never a single correct answer. It is the experience of having worked in and around the technology for a number of projects which differentiates the quality of individual consultants, consultancies and ultimately the success of the customer project. SAP has recognised the limitation in their current certification tracks and has worked to fill that by providing the Professional and Master qualification levels. Rather than certifying these through traditional examinations, these are based more on implementation experiences based focussing on applied knowledge rather than retained technical information.

Does the Exam test the knowledge?

Given that the SAP GRC Access Controls associate certification has to be technology focussed how well does it test this area? Having implemented the technology numerous times and taught the pre-requisite course (GRC300), my belief is that the examination does provide a stern test to all delegates.

The questions really get into details and are worded in such a way that you do need to have an understanding of the actual technology and SAP terminology rather than simply the themes involved. That is not to say that there aren’t a few “freebies” thrown in there to cover the more straight-forward application areas and the wider areas of business integration.

Exam Technique

There are also elements where exam techniques can help. Understanding the way that SAP approach a subject rather than the way in which you might tackle it in a specific project is paramount to lead you to the correct answer. With multiple choice exams, there will always be the possibility to be able to work towards the correct answer by a process of applying logic, common-sense or a process of elimination and that will still work in some cases. However, I do believe that SAP has improved the quality of the examinations to accurately test against the technology.

Many of my colleagues and contacts have taken the certification and many of them have returned similar thoughts on the content; it is a tricky exam where you need to be on top of the theory and the details of the system configuration to be able to navigate it successfully. It is easy to get confused by the wording of the questions and therefore, it does seem to achieve the objectives of testing the SAP technology underpinning the GRC Systems.

The worth to consultants and customers

There is often a debate in the market as to whether customers really appreciate and respect the certification. Many great application consultants have never taken the SAP endorsed application certification and similarly many consultants who have that cetification really do not have much more to offer a customer other than that. So is it simply a rubber stamp or can it be trusted?

From a consultancy perspective, it is a fairly clear cut decision. Certification is an important differentiator, demonstrating a baseline level of technical competence and is a good way to provide that assurance that all of the consultants offered into client work have met the minimum standards set bySAP.

Individual consultants may also wish to take the certification exam for their own personal development or to be able to market themselves more clearly to clients. In this way, it is a good way for their parent organisation to demonstrate support for their development by supporting their desire to undertake this. Certainly, with this certification, the successful consultant should take some pride from passing the exam as it is certainly not a given that passing is guaranteed.

Customers do seem to like the tangible endorsement afforded by SAP certification. It can play a part in the decision process when selecting a supplier or indeed a contractor. I’m not convinced that it should play a major role and care should be taken to ensure that appropriate attention is placed upon delivery experience and references. However, it is still a very quick and easy comparison to make.


It is easy to become cynical about the SAP certification process, especially once you have attained the qualification but it does seem to be viewed positively within the market. My view is definitely that it is a useful qualification but it should not be relied upon in isolation to guarantee that the holder is right for all GRC projects. As mentioned earlier in this blog, its scope is limited to the “easy” bits of a GRC project and does not test the real agility of the consultant in implementing the customer solution. However, it still presented me with a sufficient challenge that I am proud to call myself a SAP Certified GRC Consultant and to congratulate my peers once they pass the exam.

Make a comment
Visit Turnkey Insights