Sunday 12 February 2012

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.

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.

6 comments:

  1. Truly, you are a patient guy... I hope the situation gets resolved soon.. Either the implementation gets over soon or the SI is replaced/removed...

    Best Regards!

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
  3. "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" It's funny how reality creeps up and slowly starts taking over one's thinking after a training course. Bombardment from people preventing you from applying best or even up to date practices that you've recently had the chance to learn is inevitable ! The trick is, figuring out how to convince the consultants or even the managers of the right thing to do...

    ReplyDelete
  4. good guidance and the following of the content is so helpful and useful. SAP SECURITY TRAINING

    ReplyDelete
  5. Hi this is shiva kumar i am working on sap bwbi.. i just browsing blog s on hana there i found your blog is interesting .. i like to say thank for sharing a information on sap sap-security

    ReplyDelete