The Security Stuff (part 2)

I'm following on from last week's post - because I think that there is a bit more to say about this topic.

If you follow any of the people that promote the concept of "Empowerment" within a business, you'll no doubt be aware that many of these people or companies are talking about allowing staff access to more of the information held within their systems, so that it is easier for decisions to be made at lower levels, rather than having all decisions coming down from the top. This is also sometimes described as "agile" business decision making.

There is something to be said for this idea - if someone has to purchase some goods, and has been doing the job for some years, she may well be quite capable of negotiating the right kind of deal without having to refer it to her line manager. This then means that the manager is left to deal with more important issues - and when I was a younger manager, it was known as delegation. A senior manager once told me that if you cannot delegate, you cannot manage.

The problem is of course that not everyone is entirely capable of making decisions at certain levels, and need to be monitored more closely than some others. It also has to be said that there are more than a few managers and senior executives that would be horrified at the thought of more junior people making even quite minor decisons without referring to them. Even if all they are doing is glancing at an email and then replying "do what you think best", they feel that they are "managing the situation". (A bit like the PHB in the "Dilbert" cartoons!)

So it's necessary to decide how you want to secure your date as well as how you need to secure your data (the two are not the same). How you need to secure the data is often defined by regulatory compliance or the need to prevent commercially sensitive information from going astray. How you want to secure the data is more about how you structure the business and how the various processes work.

Most people would agree that when SAP was first created, the main target was the larger enterprise business. Within this size of business it is generally necessary to provide some separation of duties - you don't want the person that creates a new bank account being able to transfer money, otherwise  he might create an account for himself in the Caribbean and transfer $10 million, before taking a one way flight to his retirement (which he also puts on expenses!).

As a result, much of the way that things are structured in SAP security has been done specifically to provide the required levels of security for those large organisations. The problem is that when you get to the smaller businesses like ours, it's actually much harder to define what you need in terms of security. Worse, this can actually change a lot more frequently as staff will often be doing more types of jobs than their counterparts in the enterprise business.

Now we have a problem - I've been trying to make sure that all of the permissions are properly set-up and correctly tested, but even so, sometimes it's not always easy to do this. I will hold my hands up and admit that there have been many occasions when I was going thru a role and suddenly spotted something that didn't look right, that then needed to be corrected.

Partly this is due to some people taking the view that "give them access to everything, and we can take away what they shouldn't have". This doesn't work - why? Because the only time that you find someone can do something that they shouldn't is when they have done just that, and it has caused a problem. And usually, that is when things are going seriously wrong.

We have seen that, not just the one time, but on a number of occasions. Most recently because we have some transactions that were created for us by one of the consultants based upon standard SAP t-codes. Unfortunately, the new t-codes have absolutely no authorisation checks built into them - and as a result, we have found that some people are able to do some work that was supposed to only be done by the Production Manager once a day to clear up any issues.

Oh, and in case you wondered - when I said that I would take the offending t-code out of the role, the Production Manager asked me to leave it in. He is going to speak to staff to try to make sure that they understand that they shouldn't run this particular process, just use the t-code to look at the data. Yes - I'm sure that will work (until the next time).

We'll do the security stuff later.

A couple of days ago, there was a question posted on SDN about security, that got me thinking about how this had been handled during our implementation. If you haven't seen the question, here's a link and I would suggest that it's worth a quick look.

http://forums.sdn.sap.com/thread.jspa?threadID=2133938&tstart=0

Now I am not a security specialist, altho' I have taken a couple of SANS approved security certs. When I was told that we were going to be implementing SAP, I got talking with one of the guys from the training course that I had done, and he was a bit dismissive of SAP security. He made a comment that SAP security was based upon "security by obscurity", and said that he had never met an SAP consultant that even understood the basics of security.

When I had the chance, I asked the SI senior managers if they worked to ISO27001 - they were happy to say that they did and had been fully accredited. Subsequently, this proved to be less than true - they did not actually know what was involved in the accreditation process, and as far as I can tell have never undertaken any of the work that would be required. (I should also say that they also claimed to have a couple of other accreditations that they are not entitled to.)

When we started work on the project, their Project Leader got me started on creating user accounts, and some basic roles - but only really very simplistic stuff. As we started testing, I found that some of the things that I had been told to do were completely incorrect, and I had to make use of SDN and some other resources to identify just where I was going wrong. Later I also did the ADM940 course which filled in a number of gaps, and I've since also done ADM950 & ADM960.

Now I'm not going to say that this makes me a security expert, far from it. There are a lot of people out there that have a great deal more experience with almost no paper qualifications - and I would be happy to learn from them. But the work that I have done within the training that I have undertaken does give me a level of confidence to be able to say that our consultants really did not know some of the most basic requirements of good security practice. And from what I have sinced learned, they don't seem to be in the minority.

The quote at the head of this post is an actual comment from one of their guys - and for me, this shows a real lack of appreciation of what security is really about. For security to be of any value at all, it has to be built in from the start - trying to bolt it on after the work is done is quite simply never going to work. A bit like having a high powered sports car, and trying to add wide wheel tires to give it more grip - it will just never do what it should do.

We are fortunate - we don't have to conform to the level of compliance that a lot of other businesses have to. We get audited once a year and we have a couple of specific checks done, but that is all. I would say that's a good thing for us - if we had to go thru some of the bad practices to correct them, I'm fairly sure that we would still not have gone live.

Security is not just about PFCG and SU01 - it needs to involve so much more within the software, but it also should cover physical access to servers, workstations and other devices, good working practices, and a structured approach to everything that has to be done within the system administration and management. We've seen first hand what can go wrong when this is not done in the approved manner, and the big problem is that when you're trying to fix a problem after the event, you often only treat the symptom, not the cause.

I will say that in most cases, we never really knew who some of the consultants were that we would get from one month to the next. We never saw any information about them or their skills - I'm not even sure if the SI even bothered to check on those either. Heck, I'm not even sure if they checked to see if the person that came to site was the person that they employed!

I can understand that for some people, the drive to get the systems in and working is the top priority, and everything else is secondary. But security should be something that is fundamental to any good system, and it should be in place from the very beginning of the project. Until it is given that level of attention, it will never work the way that it should. And that is only ever going to reflect badly on SAP, no matter who is really at fault.