Skip to Content
Author's profile photo Colleen Hebbert

Security is a class of its own

3/Nov/2016 blog updated for re-tagging due to SCN migration

SAP might classify Security under the Basic Central Functions (BC) Class but career-wise it’s time to change your mindset. Security is a separate career path to Basis.


The end of my shortest blog ever!


Okay, maybe not, so let me explain my view with a few scenarios and examples. And now for my longest blog….



Stakeholders Buy-in (or so we’re told)

Search reputable magazines, interviews and reports whereby senior stakeholders (CTO and CIO) are asked their opinions of important challenges and issues for the business. You will find in your results a heap of the current buzz words relating to Cloud, Mobility and Analytics. Security is also up there but each of these important topics identifies security concerns as well.


So why is that? The fear of sending their data out in to the “Cloud” has opened up the can of worms of worry about their data? Or perhaps, legislative changes and company reputation is calling out the importance of security across all facets of IT and business. The cost of non-compliance extends beyond financial risk. Customer, Financial and proprietary information needs to be protected. The last thing these stakeholders need is being front and centre in the news due to a data breach.


So we have senior stakeholders agreeing that security is important but sometimes there is disconnect between the acknowledgement and investment to properly design and manage security. Part of this disconnect is partly due to the ownership of security and positioning of it. A Security Expert needs to be able to translate the technical risks into business language. Next time you have to explain a security issue to a stakeholder try to do so without explaining what a SAP authorisation object is. Put it in plain business terms and link it back to the business process at risk. I could go on here but it’s a separate topic that doesn’t belong in Careers.


Security is NOT SIMPLE

Sorry SAP but you are not simple. You can strive for simple all you like. However, having worked on a few “complex” landscapes now my perception is every time SAP makes things simple they complicate it further for Technical areas, especially for security. Oh and these “complex” landscapes are usually due to the need to be simple.


If we stick “just” to application layer security for roles/permissions to assign users, almost each component has its own security model or approach to build. Go back to the 4.6B systems where it was a single system with transaction PFCG and SU24 as the challenges. Even today, we have a lack of security skill and appreciation on using SU24 integration properly (for the non-security out there that’s where we can map default authorisation proposals to transactions and other objects to consistently build security roles) and it’s becoming more evident as customers upgrade or apply enhancement packs.


To extend on that, you then have the extra variety of building security for HR (structural authorisations); BW/BI/whatever (Analysis Authorisations); CRM (business roles); BOBJ (Groups based on object permissions and principals); Java systems and more. Add to that, there are a heap of authorisations objects to familiarise yourself with (7.40 release on ERP currently has about 3000 authorisation objects and 80,000+ transaction codes – you are a genius if you know them all and what they do). Each module might have a few extra settings here and there that determine if the object is checked as well (you’ll stumble on them through various parts of the IMG). Then let’s throw in some of the products SAP bought recently (SuccessFactors’ products is one example). While we’re at it let’s now consider HANA security if connecting straight the Database –something I used to be able to draw the line and have Basis look at but now ends users will need accounts.


Then we look at ‘how the hell do we support this system and monitor it?’ so we now need to add GRC, SAP IdM, SSO and a few other fun toys to capture integration. After all – we need to be simple for users to request and obtain access! While we’re at it we are now looking at a heap of tools on the systems such as Security Audit Logs, UCON, RAL, etc.
Oh and if you’re in a support team, you usually spend a heap of time proving the incident is not security related (add to your list of skills learning to debug and search code, skill across functional configuration and then communicate your findings and analysis to get another team to take responsibility). Once you’ve sorted out those issues you then spend a large amount of time explaining to your user base why their access is restricted.


Does this sound simple to you?



It’s all about the User Experience (UX)

Up there with Simple, User Experience is another big focus for SAP. The direction is now to simplify the systems and go for user experience before functionality. User Experience is a great idea as well and there have been massive improvements in that space. So what’s security got to do with User Experience other than flashing up nasty, red error when users aren’t authorised? The answer: NWBC!


NWBC screen layout is based on security role menus. It deserved its own heading as I’ve just spent two days going through all the different menu combinations to design roles to improve user experience. In other complex solution, SAP Portal or minimal user experience (user SAP GUI) as the solution. Need I say more?


The Breadth and Depth of Security

I’ve already covered a large part of this the variety of security. However, what I love about working in security is this variety. I am yet to meet a SAP Security Practitioner who is an Expert/Knowledgeable in all security topics in SAP. It is near impossible to know all components, modules, industry solution, integration, technical side of a system. Then there’s always discovery the creative ways to bypass security. The skills you use for security also extend out the breadth of what is needed to be considered an “expert”:


  • Business knowledge – you need to understand and appreciate what is important to the business and the risk if unauthorised access occurs;
  • Technical knowledge – you need to realise there is more to security than just roles and users. What about RFC Connections, ALE models, cross-system, transports, Os commands, web services, trusted systems and so? Most of these fall into the realm of ‘Basis Activities’ and the security person wash their hands of it. Add to that, what about batch jobs, background jobs and spool access. How often does a person leave the company and a job fails as the user Id was locked down (on investigation a periodic job wasn’t scheduled under a system user)?
  • Functional knowledge – you need to be aware of configuration approaches to achieving security (sometimes the SAP authorisation won’t cut it)
  • Development knowledge – you need to be aware of security risks in poorly secured programs. You don’t need to know how to code but even awareness of cursory checks you can perform. Teaching yourself to debug and read high level of code is a bonus
  • Security knowledge – you need to be able to take all of the business requirements and figure out how best to architect the solution and build it. Add to that, yes you still need to know how to use SU24 and PFCG (I beg you – please master that).
  • Communication – take all of this variety and target your communication. Who is your audience? You will have to chat to the end users and explain that nasty red error and process to obtainaccess. You will need to talk to functional and developers about specific access. You will need to talk tech with Basis. Finally, you will need to provide a higher level overview that is non-technical to management (and in that actually make a recommendation instead of providing options).


Why doesn’t Security belong to Basis?

If you’re still reading this blog as I haven’t cured your insomnia then answer to this question might be obvious to you. If not, put simply: capacity, skills and competing priorities. To those who actually succeed in doing both Basis and Security – congratulations. However, honest question – how detailed and thorough is your security? Hats off to you if you can honestly say your security is managed as a high quality and you manage to maintain a relatively complex system landscape with a highly available system.


The reality is Basis is such a big topic to master – system installations, client builds and refreshes, transports, all the components, Solution Manager, performance tuning and to name just a few. For Basis to also absorb the security tasks they would never sleep (or the team dynamics might end ups with some Basis members specialising in security); be allowed to take holidays; or even be sick for a day!


As a person responsible for system performance and, security monitoring and cleanup, which activity would you divert you attention and finite time to? As a security person, I’m not deluded in thinking cleaning up obsolete users will take priority over a Priority 1 incident where users cannot access the system. And security is rarely an activity that will involve planned outages or out of hours support. So when it comes to the crux, Basis Administrators will prioritise system administration activities over security. Yet, our stakeholders tell us Security is Important!


Security as a Career



Security salaries and contracting rates are just as competitive as a Basis Administrator. In my country (Australia), there was a period of time (and still is in areas) when Security skills were in higher demand than Basis because they needed to have the security knowledge across the product suite.


Growth and Development

For those of you who are new to SAP and technical areas, I hope this explanation of security has provided more context as to the variety and importance of it. When you have security and basis as options I hope you realise that security has variety and career progress. You might start as a junior or fresher performing the repetitious tasks, such as password resets, but with hard-work and dedication it is not where you will end up. Like all areas of SAP, there will always be something you don’t know in security that you can learn. You will continually find yourself learning new components and products. You will keep refining your approach and realise there is more than one way to design and build security. You will finally realise security is not just SU01 and PFCG.


Remember – there’s always more modules, components and security models to learn. There is always more than one way. Security doesn’t stand still. You will never stop learning if you want to master it.


Side Note: My question to SAP

Does security really belong as a subset of Basis in today’s world? Shouldn’t it be in a class of its own? Not really questions for careers but still curious none the less!



To those of you who combine security and basis why is that? Does anyone else have any thoughts on this topic? I’d love to hear opinions below J






Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Matt Fraser
      Matt Fraser

      Brilliant! A big resounding YES to everything you say here. I am one of those people whose job description says "Basis" but who also must think about security (though several years ago we finally reclassified another team member (who had been a developer) into Basis and he manages most of the authorizations and role design now), and you're right, when it comes down to what gets attention, it's keeping the system running, or applying HR legal changes, or fixing bugs, or tuning performance, or -- you mentioned my current bugaboo, Solution Manager -- or any number of things.

      Still, everything that isn't directly related to managing a user or a role, i.e. protecting the TCP ports, the RFC calls, ensuring https is working (oh, and worrying about SSLv3 vs TLS), all that stuff -- that falls to me. I actually enjoy this kind of work quite a lot, but I hardly have time to stay up-to-date on it. In the past, all the user and role management was mine, too, because that was a "Basis" task, and so I had to learn a lot about business roles and separation of duties and so forth. When we put in HR, I was the one tasked with learning about structural profiles.

      This week I'm struggling over getting all the diagnostic agents on all the systems to use https in their communications. In the past, with everything being internal and behind a firewall, we've been happy with keeping it "simple" (which of course it never was) and not worrying about encryption, but it's not so simple anymore.

      Excellent post.

      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      Hi Matt

      So it sounds like your organisation came to the realisation security is too big to be a task within a Basis Role. And you seemed to have provided an example of my point - even when security is under Basis it's usually specific team members.

      From my observations on SCN, I wonder if some junior members think security is "lessor in value" as the system availability takes priority. This prioritisation of work then sends a message that security is not as valuable or important.

      The technical side of security that you mention (ports, etc) is something I still hand over to Basis. However, I now consider it my design and checks. If anything, I ensure I have the discussion with Basis to make sure they have it covered. I'll admit in these meetings that I can at best draw the pretty picture and get the concept but rely on their technical expertise. This too, is where I recognise my shortcoming in security knowledge and know I need to develop.



      Author's profile photo Christopher Solomon
      Christopher Solomon

      GREAT blog!!! (*love the writing style too...a little humor and self-deprecation goes a long way in endearing the audience to you, eh? haha) I think the days of being the BASIS admin, DB admin and security admin all on one person (or small team all doing it) is well past us, but sadly, the mindset is not. How many more data breaches of epic (national news) proportions need to happen before it is given proper respect/status/attention? Ahhh well...good thing that isn't my world and I can just blame the "BASIS guy" when I get an authorization error in testing. HAHAHAHA! 😆

      Author's profile photo Matt Fraser
      Matt Fraser

      Heh... do I detect a little dig my way, Chris? 😉

      Author's profile photo Christopher Solomon
      Christopher Solomon

      I will have to dig up a cartoon I did years ago for my old "" web site of developers vs BASIS guys. haha 😆

      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      Hi Christopher

      Yes they are in the past... for most of us. I hope companies start acknowledging this as security is a different skill set.

      Thanks for the call out on my writing style... I think it might partly come down to being Australian - we don't take ourselves too seriously 🙂



      Author's profile photo Lars Breddemann
      Lars Breddemann

      I really liked this post, even though I am not at all a "security" person.

      Like many other aspects of complex systems - and you're right about that system landscapes that involve SAP systems typically are very complex - security is a common/shared feature (could be an aspect)  that is expected to "just be there".

      As the grouping into SAP modules stems back to the early days of R/2 I'd tend to say that there's no specific reason or intend to keep it there.

      What I wonder though is: what difference would it make if there would be a separate group/module with "SAP SECURITY" printed on it?

      Is it about the recognition of the work?

      Is it about being able to market security expertise easier?

      Would you expect that clients would start requesting more specifically security resources if SAP would change it's documentation and separate security and basis?

      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      Hi Lars

      Thanks for your comments and the history of classification.

      The title here and question was a bit of a play on words. However, I do believe people new to SAP, etc see the module classifications and would take security as a subset of Basis Functions. I had thought about writing this differently and posting under security space but decided to remain careers focused.

      Would you expect that clients would start requesting more specifically security resources if SAP would change it's documentation and separate security and basis?

      I can only but hope. 🙂 At the end of the day security is both technical and functional. In reality, reclassifying documentation won't be the answers. Improving security and recognition of its importance will come back to customers demanding and investing in it.



      Author's profile photo Otto Gold
      Otto Gold

      It is day dreaming and waaay too crazy, but let's assume you have a customer that has one basis person available. That person must do both security AND basis as that is how the skillset is perceived - one skillset. If the two areas were separate (indicated as different with its own breadth and depth), maybe, just maybe, there were two people and two budgets for that.

      I am not asking for that budget (I am a consultant) for myself. I am asking for more people for the competence centre leaders I work for. I know things, they know things, but from a certain level upwards it is IT - a cost center, not a profit center and all is technical (aka Basis). As I said, crazy 🙂

      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      Otto, I'm happy to be considered crazy with you on this one

      Just search around SCN spaces for security, GRC and even in the functional areas. When clarifying questions, too often the person admits they are Basis background and today they have to do security.

      Yes, technology treated as a cost center always makes getting adequate resourcing a difficult challenge. Security is not alone on this one.

      Author's profile photo Former Member
      Former Member

      Congratulation to this perfect description of a really complex compenent. Nothing is simple!

      Author's profile photo Ricardo Solipa
      Ricardo Solipa


      I'm wondering if SAP will ever answer you... After all there is no perfect system so far... 😉

      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      I'm not holding my breath. If I really wanted to focus on that question than I might have been better to publish this to Security space.

      However, it doesn't take  much to come across security question by basis resources that are completely lost on how to build and manage security is the system. Fun times 🙂

      Author's profile photo Rakesh Ram
      Rakesh Ram

      A very good eye opener for me to know security is beyond PFCG and SU01 and am mentally getting prepared to know I have a chosen a career where i am 10 years back still......

      thanks colleen for the wonderful article.


      Deepak M

      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      glad to hear this article has opened your eyes to there being more to security than just PFCG and SU01. However, PFCG is quite a powerful transaction and there is always lots to learn to use it properly (each enhancement packs usually brings about refinements to it). Also, you can develop your skill to start learning more of the functionality in SAP to learn how to better restrict the authorisations