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
Remuneration
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
Regards
Colleen
