Risks of automating transactions in master data management (Winshuttle)

[Former Member]

This product is being introduced at a client.

Some of the users are not technical and I understand it can be used for master data maintenance.

There seems to be acceptance of the package on the basis that it follows SAP authorisations, but it strikes me that by enabling automation, particulary of master data changes, it changes the nature of the authorisations.

i.e. It is one thing to be able to change material masterdata. If you make a mistake, it will not be a problem, but if you can now change ALL the material master data in one go, this has a significant risk. Therefore this should be signed off as tested in Q before it can happen on the production system.

Has anyone else encountered this product and am I right to be concerned about it being used without controls?

Edited by: Thomas Zloch on Apr 18, 2011 7:10 PM

[clinton_jones2]

Of course all of these are generalizations and every customer is different, has different requirements, rules and controls.

But it is true, there are risks and justifiable anxieties abound in every area of business and IT. Just the decision to get out of bed in the morning might be cause of anxiety. I might step on the dog and it might bite me and I might get tetanus, or in my blurry world of half asleep state I might not see that there is water on the floor in the bathroom and might slip and fall and lie in a helpless state on the bathroom floor waiting to be rescued by someone. So again, every situation has to be evaluated on its own merits.

I am a great advocate of getting all interested parties involved in the evaluation process of a given product from the get go. The notion of skunkworks implementations of solutions invariably results in tears somewhere at some time - maybe only months or years after implementation and use - so getting everyone (including IT) on the same page at the outset really is helpful.

Let's be clear though, products like those offered by Winshuttle exist for a reason. They wouldn't enjoy the success that they do, if they didn't address a very real need. Additionally, if they were as much of a vulnerability as is being intimated, we would be hearing a lot more noise on this topic from customers and their audtors. (Some do send Ninjas!)

Incidentally SUTL isn't required and isn't in fact on the list of recommended authorizations, and I want to emphasize 'recommended' - you can try without SDTX however you may have some difficulties making the RFC calls in which case you are probably limited in what transaction you can automate and how it will work. Generally the suggestion is for users to try to use the products with standard SAP security authorizations that have already been granted to them and then triage issues wi9th use from there.

[clinton_jones2]

Cookoid

You comment regarding 'changing the nature of authorisations' is an interesting one because as you have already pointed out and is consistent with the way the product(s) work; you cannot change any more than your SAP credentials allow you to change.

All that said, quite rightly; the idea of being able to perform mass changes on ANYTHING in your SAP system of record should not be taken lightly and due diligence should be applied in determining who should have such tools and under what circumstances they should be used. Design and testing in QA or pre-production environments is an absolute must and this discipline should be applied with the same level of enthusiasm and commitment as you would any objects that you develop for productive use even if they are LSMW or regular BDC's.

The product supports a controlled release approach if implemented in a particular way, using centralised license management and workflow controls around the scripts and data templates and workbooks. Scripts can be restricted to particular SAP instances, particular volumes of data, particular transactions, particular times of day/week/month for execution.

Additionally you have two types of licenses, author/developer licenses and runner-only licenses. This avoids you landing up in a situation where inexperienced users can create their own automation objects, in such circumstances these users would typically only be given a runner license.

Some customers don't choose to use this governance and compliance approach though and choose to buy only the authoring tools, accordingly they essentially leave the door open to the creation of potentially harmful objects.

Again exhaustive testing is always recommended. WIth over 1,000 customers globally there are plenty of ASUG member references and you should actually be able to get referrals to existing customers who can tell you how they have introduced and manage controls around the use of the products.

[Former Member]

Hmm, I dont think I am likely to get a reply with my thread moved to this forum.

Perhaps if I re worded the title as "Risks of automating transactions in master data management" ? Its a real operational issue which people may meet, rather than a musing off topic type of thing.

[clinton_jones2]

Some time back I posted a blog on this at /people/clinton.jones2/blog/2011/02/14/the-problems-with-mass-actions-with-sap-data

[ThomasZloch]

I've changed the title. I don't know where your thread originated, which SCN forum would you seem fit? Maybe a moderator of that area can then decide about moving it there.

Thomas

[Former Member]

Thanks Clinton, Thomas.

Not sure where it would be best, but now I have some info to read I can see this has indeed been considered before, which is helpful.

Looks like conventional wisdom from the manufacturers is that master data changes undergo testing and sign-off, which is my feeling too.

[Former Member]

If the auditors send a ninja then you could be in for some troublesom times with such enduser computing tools which run on the client side and connect to the backend systems via technical interfaces which are not APIs. Some of them are also explicitly mentioned by SAP as not released and uncertifiable!

When they force you into granting access to the enduser which enables them to bypass the intended application from any client of their own choosing, then you should react with outrage at such tools.

The most famous of these are function groups SUTL and SDTX. The auditors know these and will look for them.

Take care,

Julius

[ThomasZloch]

Isn't SUTL the one that contains function module PLZ_INJECT_YOUR_CODE_HERE ?

Thomas

[Former Member]

Another one to be carefull of is ZAW1. That is because SAP built S_DEVELOP and SCC4 checks into SUTL which meant that it does not run in production systems... because it is not not intended to.

ZAW1 has 28 function modules in the group, each one worse than the next.

Basically the user can build the query on the client server as text using any client tool of their choosing, which then runs on the backend system as ABAP.

From a security perspective, it is a huge design error IMO as the clients are as mighty as the application server is and you dont have an application security to use - the user can run their own code and directly access the database / operating system at runtime of it.

They also tend to start saving their passwords in places where programs can pick them up at runtime as well...

Toasted

Julius