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.

Unlocking Management Information - Part 2

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

Make a Comment

Security Engagement

Monday, 18 August 2014

Posted by Tom Venables

When should security get involved in a project?

The short answer to this is; as early in the project as possible!

One of the most challenging aspects of security for SAP projects is often seen when security teams are engaged late in the project lifecycle, when a project is already deep into the build phase of whatever development is taking place and the need to achieve functionality in a controlled, compliant manner is raised only after the requirements have been gathered. Often we see security as an afterthought to functionality and this presents a number of challenges for successful delivery.

These challenges  come about because there has been no opportunity for security to share in the design decisions, to understand the requirements from the point of view of an end-user, or to sit with process and risk owners to understand the control objectives of the organisation. 

Often, development teams proceed with creating new functionality, whether it be a portal application, a new transaction, program, or even a new report, they migrate it through a landscape and sometimes all the way to production before finding out that no-one can access their shiny new functionality. At this point, the security for the development is then handled as part of an incident management process, rather than being scoped as part of the project itself. This places pressure on security teams in terms of cost, time and results in a negative perception of the security function.

A lack of involvement from the security & authorisations function early in a project lifecycle means that important risk control objectives are often not incorporated in requirements and this can snowball and impact all phases of the project:

Design phase:

Without clear definition of the functional requirements of developments, the scope for security changes is not confirmed and it is extremely difficult to achieve a technical design which meets the requirements. Understanding the control objectives, risks which must be addressed and the technical architecture involved is essential. 

Without a clear set of requirements for both the business functionality and security, it can be particularly challenging to come up with a design for your roles which supports the needs of your organisation. In addition, security design is more effective when the needs of the business are understood by the security administrators. 

Build phase:

So, you have little or no functional / technical design documents on which to base your build of the authorisation components, but still a requirement to have roles in place to support the project. Without knowing what authorisations to grant, or restrict, the roles themselves may have insufficient authorisation (which will impact testing experience), or excessive authorisations, which will be highlighted by auditors. 


Say you have managed, by virtue of a lot of effort in your build phase, to get roles built, the roles are handed over to UAT execution and at this point, the testers identify defects in the roles. Perhaps they permit access to some sensitive data or fail in the testing of some critical activity. These issues are then raised as defects in the role, rather than changes to the scope of the roles. Without a design, how do you know that the build fits that design?


If the testing phase of the project is signed off, despite (IN SPITE OF LINGERING) some lingering issues with the security, you now have to handle issues in the production system. Forcing changes through a business as usual process, you’ve got to deal with a negative perception of security, face time pressures on getting functionality working in production or may face the prospect of failed audits. At this point, your management now have to decide if they’re going to create a remediation project purely for the authorisations. This is one common justification for the creation of GRC projects, to identify issues and remediate.

How do you get early engagement?

It’s not an easy thing to change the way an organisation engages with the security teams, but one thing which I have seen work well lies in educating project and change managers about their responsibilities to include security in all phases of the project. An element of this can include stage gate approvals from security to exit each phase of the project. Using your existing change control processes, it should be possible to include a review step in the design phase and as part of stakeholder engagement to ensure that changes cannot progress until the security impacts have been assessed.

To summarise, if security is involved in sap projects from the outset, not only will it be more liekly to work, the organisation will also save time and resources it would have deployed later in the process to fix the problems.

If you have any comments or questions, please feel free to use the comment submission below

Make a Comment

SAP GRC 2014, Orlando

Friday, 4 April 2014

Posted by Richard Hunt

Last week I attended the US based SAP GRC conference for the eighth year in a row and this year it was back to where it all started for us, Orlando Florida.

It was a great opportunity to catch up with our US based SAP colleagues and customers and I was joined by three members of our US team and a couple of our team in the UK who were speaking at the conference. The team at SAP Insider put on another well organised event and co-hosting it with the SAP Financials event, I felt, worked really well as everybody had an interest of some sort in GRC.

The event was again well attended and it was a fantastic opportunity to hear from US customers how they are leveraging their SAP GRC tools.

The highlights for us this year were:

1. The official launch of SAP GRC Audit Management on HANA.

Audit Management is the latest addition to SAP’s GRC focused solutions. The solution is focused on helping companies manage the audit cycle. The solution is still evolving and with a HANA backend its future roadmap is sure to include some very interesting audit analytics capabilities.

Here’s an overview diagram of the new product:

Audit Management Overview












2. More customers leveraging Process Controls.

At this year’s event we noted more customers with experience of SAP GRC Process Controls in their environments. This led to a lot more detailed discussions around the capabilities and potential use cases of the product and it was great to explore ideas with these customers.

It was encouraging to hear that our customers are still at the leading edge in terms of getting benefits from process controls.

3. Increased uptake of HANA in the US customer base.

We noted that the take up of HANA was significantly more prevalent amongst US based customers than we have found to be the case in Europe to date. This is a very positive development as it indicates a shift towards this technology amongst the SAP customer base generally.

HANA offers a lot of exciting possibilities in the GRC space and we are looking forward to helping more customers to harness this technology.

4. Increasing interest in SAP GRC Risk Management.

Having successfully implemented Access and Process Controls we are finding more and more customers turning to the Risk management module. This is an area we have put significant focus on over the past two years having developed a Rapid Deployment Solution (RDS) with significant enhancements over and above the SAP standard solution.

We met with a number of customers on this topic in Orlando and are looking forward to helping more customers to utilise this product.

5. Increased product integration across AC, PC and RM.

Many customers we spoke to at the event were interested in how they can make their usage of GRC more efficient and improve their GRC processes by further integrating the GRC components. We had several discussions around options for sharing risks across AC, PC and RM and around how best to integrate the products to take a more holistic approach.

This is something that we have been seeing more in our own customer base and its encouraging to see other SAP GRC users looking to maximise the return on their GRC investment.

It was great to be back in Orlando and we are already looking ahead to next year which may well be back in Vegas (TBC). For those who were not able to join us at the US conference the good news is that this year's European event is only a few weeks away and will be held at a new venue in Nice, France. We will be there again, with our speakers repeating their sessions in addition to some other content we have been asked to provide. If you’re interested in attending the Nice event please let us know – as exhibitors we are able to offer you a customer discount.

Hopefully we will see you there!

Make a Comment

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

Common Characteristics of High Performing Teams

Thursday, 19 December 2013

Posted by Alex Ayers

10 characteristics of high performing security and GRC teams.

As we come to the end of 2013 I have been thinking of some of the projects that we have been working on in this time.  One area of focus for me has been been working with clients to improving their governance around security and GRC.  A key part of that work has been helping them define their target operating models, put in the right supporting organisational structures and get responsibilities and good decision making embedded in operations.

Much of this work is classical Organisational Design (OD) and there are numerous techniques and methods that can be used to assist with this.  

Part of OD that is often difficult to articulate is how to really make a team effective.

Teams have to exist within wider organisational structures and what works for one organisation won't work for another.  Budgetary, political (internal and external), & organisational factors provide constrains that have to be considered. Naturally our clients want to know what good looks like.  Having accumulated a few hundred years of industry experience among the team has it's uses.  We are very fortunate to have worked with some fantastic teams so we spent some time analysing common characteristics and behaviours that could be applied to any situation.  These can be summarised as:

  1. Retain core competency. Overall accountabilityfor security/GRC/controls should not be outsourced. Without retained competency it is not possible to make effective decisions.
  2. Work with a partner with specialist skills to augment internal capability where required.
  3. Promote a nurturing and sharing environment.  Everyone has skills and everyone can improve.  3rd parties and contractors often don't like to share and a good environment is one where that attitude is not acceptable.
  4. Invest in internal R&D. This a great way to develop skills of a team and generate innovative ideas and solutions to our challenges.
  5. Maintain strong business engagement.  Our remit is enable the business to run in a secure and controlled manner.  That is why we do this job and not being engaged with this audience means we cannot perform our job properly.
  6. Knowing limits.  We frequently work with clients who have spent a lot of money trying to do things internally but have not invested in training or external support. Everyone has different limits but recognising them is important.
  7. Automate transactional activities.  It is often cheaper to automate than to outsource and/or offshore.  It also means that internal and 3rd party teams can focus on complex and/or value added activities.
  8. Operate strong governance over 3rd parties. Identify roles & responsibilities, embed standards, processes and procedures and operate contractual penalties for non compliance.
  9. Work with, not against suppliers.  There are several common objectives which benefit all parties when they are achieved. Good governance puts in the framework to support this and manage under delivery by supplier or customer.
  10. Last but not least, Integrate with risk management and infosec functions.  More often than not there is little to no engagement between SAP teams and risk management or infosec functions within an organisation.  The years of SAP being a silo'd application that only moves to the beat of it's own drum are over.

I would love to hear any thoughts/observations/things that I have missed.  Over to you.


Make a Comment